[Bug c++/69649] New: [6 Regression] ICE in assign_temp

[jakub at gcc dot gnu.org]

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

Bug ID: 69649
   Summary: [6 Regression] ICE in assign_temp
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Following testcase (reduced from LibreOffice) ICEs at -O2 starting with
r232167.

struct A { virtual void m1 (); };
struct C : A { void m1 () { m1 (); } };
template  struct B
{
  T *t;
  B (T *x) : t (x) { if (t) t->m1 (); }
  B (const B &);
};
struct D : public C {};
struct F : public D
{
  virtual B m2 ();
  virtual B m3 ();
  int m4 ();
};
struct G : F
{
  B m2 ();
  B m3 ();
};
B G::m2 ()
{
  if (m4 () == 0) return this;
  return 0;
}
B G::m3 ()
{
  if (m4 () == 0) return this;
  return 0;
}

[Bug c++/69649] [6 Regression] ICE in assign_temp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-03
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug c++/69649] [6 Regression] ICE in assign_temp

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[trippels at gcc dot gnu.org]

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

--- Comment #14 from Markus Trippelsdorf  ---
*** Bug 69649 has been marked as a duplicate of this bug. ***

[Bug c++/69649] [6 Regression] ICE in assign_temp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I don't think this is a dup.  PR69241 is a fnsplit bug (-O2
-fno-partial-inlining fixes it), this one is IPA-ICF bug (-O2 -fno-ipa-icf
fixes it).

[Bug c++/69649] [6 Regression] ICE in assign_temp

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Well, comment 9 of 69241 is an exact dup.

[Bug target/69647] gcc build for avr-unknown-elf

[pieter.cardoen at hotmail dot com]

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

--- Comment #2 from Pieter Cardoen  ---
I am using binutils 2.24.

Best regards
Pieter

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
*** Bug 69649 has been marked as a duplicate of this bug. ***

[Bug c++/69649] [6 Regression] ICE in assign_temp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Ok then.

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

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[nickc at gcc dot gnu.org]

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

--- Comment #11 from Nick Clifton  ---
Hi Kyrill,

> For this failure (among others) I proposed the series at:
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01713.html

Ah - much better! I have approved the parts of your series that I can,  In fact
you should have enough approval now to check in everything except the new test.

Cheers
  Nick

PS.  For the record my patch had one regression: c-c++-common/torture/pr61184.c
when compiled with -mthumb and -Os.

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to Nick Clifton from comment #11)
> Hi Kyrill,
> 
> > For this failure (among others) I proposed the series at:
> > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01713.html
> 
> Ah - much better! I have approved the parts of your series that I can,  In
> fact you should have enough approval now to check in everything except the
> new test.
> 
> Cheers
>   Nick
> 
> PS.  For the record my patch had one regression:
> c-c++-common/torture/pr61184.c when compiled with -mthumb and -Os.

Thanks!
As I mentioned in the cover letter for the series it is based on a patch by Jim
Wilson posted at:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02132.html
So I'd like approval for the arm.h hunk of that as well before committing the
series if possible

[Bug c++/69641] invalid int32 comparison

[vvsed at hotmail dot com]

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

--- Comment #3 from Vladimir Sedach  ---
Thanks. Better to use "unsigned int" than options:

0 > (int)((unsigned int)i + 0x0080)

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

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

Fixes the two failures, while still passing vect/pr46032.c.

[Bug lto/69650] New: [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[marxin at gcc dot gnu.org]

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

Bug ID: 69650
   Summary: [6 Regression] ICE in linemap_line_start, at
libcpp/line-map.c:803
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

During reduction of another ICE, I observed the following one:

$ cat Unified_cpp_js_src35.ii
namespace js {}
# 9 "" 2
namespace js {
int a;
}

$ c++ -flto Unified_cpp_js_src35.ii
line-map.c: file "" left but not entered
lto1: internal compiler error: in linemap_line_start, at libcpp/line-map.c:803
0x17b4ebc linemap_line_start(line_maps*, unsigned int, unsigned int)
../../libcpp/line-map.c:803
0xbadeb3 lto_location_cache::apply_location_cache()
../../gcc/lto-streamer-in.c:193
0x7a3399 lto_read_decls
../../gcc/lto/lto.c:1788
0x7a3c38 lto_file_finalize
../../gcc/lto/lto.c:2043
0x7a3c8c lto_create_files_from_ids
../../gcc/lto/lto.c:2053
0x7a3db8 lto_file_read
../../gcc/lto/lto.c:2094
0x7a7632 read_cgraph_and_symbols
../../gcc/lto/lto.c:2804
0x7a86bf lto_main()
../../gcc/lto/lto.c:3304

Martin

[Bug c++/69631] [6 Regression] Bogus overflow in constant expression error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-03
   Target Milestone|--- |6.0
Summary|Bogus overflow in constant  |[6 Regression] Bogus
   |expression error|overflow in constant
   ||expression error
 Ever confirmed|0   |1

[Bug target/69118] Wrong condition in avx512f_maskcmp3

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-03
 CC||kyukhin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kirill Yukhin  ---
Will fix.

[Bug target/69120] sse2_shufpd_v2df_mask has wrong name

[kyukhin at gcc dot gnu.org]

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

--- Comment #1 from Kirill Yukhin  ---
Will fix.

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from vehre at gcc dot gnu.org ---
No complaints so far closing as fixed.

[Bug libfortran/69651] New: Usage of unitialized pointer io/list_read.c

[kyukhin at gcc dot gnu.org]

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

Bug ID: 69651
   Summary: Usage of unitialized pointer io/list_read.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

Unfortunately I have no testcase.

But code itself looks awful to me:
/* Worker function to save a KIND=4 character to a string buffer,
   enlarging the buffer as necessary.  */

static void
push_char4 (st_parameter_dt *dtp, int c)
{
  gfc_char4_t *new, *p = (gfc_char4_t *) dtp->u.p.saved_string;

  if (p == NULL)
{
  dtp->u.p.saved_string = xcalloc (SCRATCH_SIZE, sizeof (gfc_char4_t));
  dtp->u.p.saved_length = SCRATCH_SIZE;
  dtp->u.p.saved_used = 0;
  p = (gfc_char4_t *) dtp->u.p.saved_string;
}

  if (dtp->u.p.saved_used >= dtp->u.p.saved_length)
{
  dtp->u.p.saved_length = 2 * dtp->u.p.saved_length;
  p = xrealloc (p, dtp->u.p.saved_length * sizeof (gfc_char4_t));

  memset4 (new + dtp->u.p.saved_used, 0, // <-- ??? new==junk ???
  dtp->u.p.saved_length - dtp->u.p.saved_used);
}

  p[dtp->u.p.saved_used++] = c;
}

It was introduced w/ r210948
(https://gcc.gnu.org/ml/fortran/2014-05/msg00149.html). Before that new was [at
least] initialized.

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

[kyukhin at gcc dot gnu.org]

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

--- Comment #1 from Kirill Yukhin  ---
File is: libgfortran/io/list_read.c

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
There's something fishy going on with TI mode shifts, either the way we expand
them, or the way the aarch64 backend handles the components.
I'll look deeper

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Feb  3 09:44:18 2016
New Revision: 233099

URL: https://gcc.gnu.org/viewcvs?rev=233099&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* gfortran.dg/coarray_allocate_2.f08: New test.
* gfortran.dg/coarray_allocate_3.f08: New test.
* gfortran.dg/coarray_allocate_4.f08: New test.


gcc/fortran/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* trans-expr.c (gfc_copy_class_to_class): For coarrays just the
pointer is passed.  Take it as is without trying to deref the
_data component.
* trans-stmt.c (gfc_trans_allocate): Take care of coarrays as
argument to source=-expression.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_2.f08
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_4.f08
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Feb  3 09:44:18 2016
New Revision: 233099

URL: https://gcc.gnu.org/viewcvs?rev=233099&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* gfortran.dg/coarray_allocate_2.f08: New test.
* gfortran.dg/coarray_allocate_3.f08: New test.
* gfortran.dg/coarray_allocate_4.f08: New test.


gcc/fortran/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* trans-expr.c (gfc_copy_class_to_class): For coarrays just the
pointer is passed.  Take it as is without trying to deref the
_data component.
* trans-stmt.c (gfc_trans_allocate): Take care of coarrays as
argument to source=-expression.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_2.f08
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/coarray_allocate_4.f08
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Created attachment 37565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37565&action=edit
gcc6-pr69241.patch

So, it seems we have at least 3 different issues, the attached patch fixes two
of them, there is one remaining somewhere in ipa-split.c.

[Bug target/69120] sse2_shufpd_v2df_mask has wrong name

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
Looked closely.
The name was chosen intentionally to simplify "sse2_shufpd"
expand. If we want to fix this name - new subst attribute need to be introduced
and 
if () 
  emit_insn (avx512vl_...
else
  emit_insn (sse2_...
inserted into the expand.

Beside of the expand this template never called by name.

So, I bet to have the name unchanged and keep things simple.

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On February 3, 2016 10:01:45 AM GMT+01:00, "vries at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69599
>
>--- Comment #3 from vries at gcc dot gnu.org ---
>Created attachment 37564
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37564&action=edit
>tentative patch
>
>Fixes the two failures, while still passing vect/pr46032.c.

Looks good but I'm not sure if you should ask for in other partition for
builtins.

[Bug libgomp/69597] execution failure for libgomp.oacc-c-c++-common/atomic_capture-1.c with -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from vries at gcc dot gnu.org ---
The tentative patch for PR69599 fixes these oacc failures as well.

Marking resolved-duplicate.

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

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
*** Bug 69597 has been marked as a duplicate of this bug. ***

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[trippels at gcc dot gnu.org]

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

--- Comment #17 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 37565 [details]
> gcc6-pr69241.patch
> 
> So, it seems we have at least 3 different issues, the attached patch fixes
> two of them, there is one remaining somewhere in ipa-split.c.

Your testcase from PR69649 still fails with the patch.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[trippels at gcc dot gnu.org]

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

--- Comment #18 from Markus Trippelsdorf  ---
Here is Jakub's testcase. It it shorter and nicer than that from comment1.

struct A { virtual void m1 (); };
struct C : A { void m1 () { m1 (); } };
template  struct B
{
  T *t;
  B (T *x) : t (x) { if (t) t->m1 (); }
  B (const B &);
};
struct D : public C {};
struct F : public D
{
  virtual B m2 ();
  virtual B m3 ();
  int m4 ();
};
struct G : F
{
  B m2 ();
  B m3 ();
};
B G::m2 ()
{
  if (m4 () == 0) return this;
  return 0;
}
B G::m3 ()
{
  if (m4 () == 0) return this;
  return 0;
}

[Bug tree-optimization/69599] [6 Regression] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #4)
> Looks good but I'm not sure if you should ask for in other partition for
> builtins.

We ask for in_other_partition for parallelized fns (indirectly) called by
builtins GOMP/GOACC_parallel.

[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Feb  3 10:39:09 2016
New Revision: 233101

URL: https://gcc.gnu.org/viewcvs?rev=233101&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* gfortran.dg/coarray_allocate_2.f08: New test.
* gfortran.dg/coarray_allocate_3.f08: New test.
* gfortran.dg/coarray_allocate_4.f08: New test.


gcc/fortran/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* trans-expr.c (gfc_copy_class_to_class): For coarrays just the
pointer is passed.  Take it as is without trying to deref the
_data component.
* trans-stmt.c (gfc_trans_allocate): Take care of coarrays as
argument to source=-expression.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_2.f08
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_4.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Feb  3 10:39:09 2016
New Revision: 233101

URL: https://gcc.gnu.org/viewcvs?rev=233101&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* gfortran.dg/coarray_allocate_2.f08: New test.
* gfortran.dg/coarray_allocate_3.f08: New test.
* gfortran.dg/coarray_allocate_4.f08: New test.


gcc/fortran/ChangeLog:

2016-02-03  Andre Vehreschild  

PR fortran/67451
PR fortran/69418
* trans-expr.c (gfc_copy_class_to_class): For coarrays just the
pointer is passed.  Take it as is without trying to deref the
_data component.
* trans-stmt.c (gfc_trans_allocate): Take care of coarrays as
argument to source=-expression.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_2.f08
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_3.f08
trunk/gcc/testsuite/gfortran.dg/coarray_allocate_4.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

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

[vehre at gcc dot gnu.org]

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Hi Paul,

I will have a look at it today. May be a fresh pair of eyes can be of help.

- Andre

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Commited fix; waiting one week for error reports before closing.

[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 #5 from Paul Thomas  ---
(In reply to vehre from comment #4)
> Hi Paul,
> 
> I will have a look at it today. May be a fresh pair of eyes can be of help.
> 
> - Andre

Thanks. I haven't given it much attention yet. I diverted into recursive
allocatable derived type components because the patch is already suffering from
bit-rot. In preparing it for submission, I uncovered one of the weirdest bugs I
have yet encountered - I might have to appeal to the list for help on it :-(

Cheers

Paul

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 37566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37566&action=edit
output assembly (intel syntax)

The failing instructions are around line 156:
mov eax, DWORD PTR 60[esp]  # tmp87, %sfp
pinsrw  xmm0, WORD PTR .LC9@GOTOFF[eax], 1  # tmp276,,

The code is using eax,ebx,ecx as a base for accessing of the data - but only
one register would be enough. This might be caused by the low optimisation
level though.

[Bug tree-optimization/66330] gcc.c-torture/execute/20040709-1.c compilation fatal error with -flto -O2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from vries at gcc dot gnu.org ---
Can't reproduce this anymore.

Marking resolved-worksforme.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Markus Trippelsdorf from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> > Created attachment 37565 [details]
> > gcc6-pr69241.patch
> > 
> > So, it seems we have at least 3 different issues, the attached patch fixes
> > two of them, there is one remaining somewhere in ipa-split.c.
> 
> Your testcase from PR69649 still fails with the patch.

I know.  But fnsplit is a mess.  I'd think if !split_part_set_retval, we have
two different cases.  If the split part really doesn't set the return value in
any way and for DECL_BY_REFERENCE RESULT_DECL doesn't even use the
corresponding default def SSA_NAME, it might be best to arrange for the
*.part.* function to have void return value rather than returning the
aggregate, but not sure how hard it would be to convince the cloning
infrastructure about that.

And for the case where the SSA_NAME is used, but it is not used inside of
MEM_REF (then it is treated as nonssa use and split_part_set_retval is true),
then perhaps consider_split should be smarter.
Consider:
struct A { A(); ~A (); };
void bar (A *) throw ();
volatile int v;

static inline A
foo (bool x)
{
  A a;
  if (x)
{
  v++; v++; v++; v++; v++;
  bar (&a);
}
  return a;
}

A
bar (bool x)
{
  return foo (x);
}

A
baz (bool x)
{
  return foo (x);
}
where at -O2 we currently give up on the partial inlining, because:
Refused: need to pass non-param values
That is:
  if (num_args != bitmap_count_bits (current->ssa_names_to_pass))
and the difference is the DECL_BY_REFERENCE RESULT_DECL default def SSA_NAME.
Perhaps consider_split should take that into account and force
split_part_set_retval in that case?

[Bug c++/59627] ICE with OpenMP "declare reduction" and -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #2 from vries at gcc dot gnu.org ---
At original:
...
{
  struct A a;
  void omp declare reduction operator+~1A (struct A &);

struct A a;
  #pragma omp parallel reduction(+:a)
{
  {

  }
}
}
...

We assert when trying to get the discriminator for the omp-declare-reduction
function:
...
(gdb) 
#5  0x009ad52b in discriminator_for_local_entity
(entity=0x761b1380) at src/gcc/cp/mangle.c:1762
1762gcc_unreachable ();
(gdb) call debug_generic_expr (entity)
omp declare reduction operator+~1A
(gdb) call debug_tree (entity)
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x7619af18
arg-types 
chain >>>
used ignored external autoinline decl_0 QI file omp.C line 6 col 9 align 8
context  attributes 
full-name "void omp declare reduction operator+~1A(A&)"
   >

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Ah, as for whether versioning supports changing return type to void, clearly it
supports it and even fnsplit uses it for the !split_part_return_p.

So perhaps:

--- ipa-split.c.jj1 2016-01-04 14:55:52.0 +0100
+++ ipa-split.c 2016-02-03 13:01:45.905136051 +0100
@@ -1254,7 +1254,7 @@ split_function (basic_block return_bb, s
   else
main_part_return_p = true;
 }
-  /* The main part also returns if we we split on a fallthru edge
+  /* The main part also returns if we split on a fallthru edge
  and the split part returns.  */
   if (split_part_return_p)
 FOR_EACH_EDGE (e, ei, split_point->entry_bb->preds)
@@ -1364,8 +1364,9 @@ split_function (basic_block return_bb, s
   /* Now create the actual clone.  */
   cgraph_edge::rebuild_edges ();
   node = cur_node->create_version_clone_with_body
-(vNULL, NULL, args_to_skip, !split_part_return_p, split_point->split_bbs,
- split_point->entry_bb, "part");
+(vNULL, NULL, args_to_skip,
+ !split_part_return_p || !split_point->split_part_set_retval,
+ split_point->split_bbs, split_point->entry_bb, "part");

   node->split_part = true;

(completely untested, but fixes the testcase).  And as incremental step there
could be what I spoke above, handle SSA uses of DECL_BY_REFERENCE RESULT_DECL
as artificial "parameter".

[Bug c++/59627] ICE with OpenMP "declare reduction" and -flto

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 37567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37567&action=edit
ten

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
If I understand the .reload dump correctly, r87 is not live in insn 289, but it
should be:

...
  289: r416:SI=r87:SI+const(unspec[`*.LC9'] 1)
  REG_EQUAL `*.LC9'

  Creating newreg=417 from oldreg=87, assigning class GENERAL_REGS to
address r417
   Change to class INDEX_REGS for r417
0 Non pseudo reload: reject++
  alt=0,overall=1,losers=0,rld_nregs=0
 Choosing alt 0 in insn 289:  (0) =r  (1) Ts {*leasi}
  289: r416:SI=r417:SI+const(unspec[`*.LC9'] 1)
...
   Insn 289: point = 104
...
  r87 is added to live at bb2 start
...
 r87: [107..246]

But maybe I misunderstand the dump - why is r87's live range 107..246, when it
is live at bb start?

[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
(In reply to Jan Hubicka from comment #2)
> I will take a look. It works in my tree with changes to avoid use of
> IDENTIFIER_TRANSPARENT_ALIAS.

r232560 doesn't seem to fix any known problem in trunk.  Can we revert it for
now?

[Bug c++/69628] [6 Regression] Conditional jump or move depends on uninitialised value(s) in lex_charconst(cpp_token const*) (c-lex.c:1252)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-03
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37568&action=edit
gcc6-pr69628.patch

Untested fix.

[Bug target/69120] sse2_shufpd_v2df_mask has wrong name

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Can you add a comment and resolve it?

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  ---
It's not crashing for me, but I think I agree there's a problem. Will
investigate a bit.

[Bug tree-optimization/69652] New: [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize

[kyukhin at gcc dot gnu.org]

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

Bug ID: 69652
   Summary: [6 Regression] [ICE] verify_ssa fail w/ -O2
-ffast-math -ftree-vectorize
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

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

While building huge workload I've encountered ICE.
creduce finished w/ attached reproducer.

Reproduce:
$ ./gcc -O2 -ffast-math -ftree-vectorize -march=sandybridge repro.i
repro.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
 fn1() {
 ^~~
repro.i: In function ‘fn1’:
repro.i:1:1: error: definition in block 8 does not dominate use in block 7
for SSA_NAME: .MEM_134 in statement:
# VUSE <.MEM_134>
_24 = *_13;
repro.i:1:1: internal compiler error: verify_ssa failed
0xd12f09 verify_ssa(bool, bool)
/export/users/kyukhin/gcc/git/gcc/gcc/tree-ssa.c:1039
0xa52dad execute_function_todo
/export/users/kyukhin/gcc/git/gcc/gcc/passes.c:1965
0xa5363b execute_todo
/export/users/kyukhin/gcc/git/gcc/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Recent gcc-5-branch works fine w/ the case

[Bug c/69627] [6 Regression] Conditional jump or move depends on uninitialised value(s) in (anonymous namespace)::layout::get_state_at_point

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-03
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37570&action=edit
gcc6-pr69627.patch

Untested fix.

[Bug target/69647] gcc build for avr-unknown-elf

[pieter.cardoen at hotmail dot com]

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

--- Comment #3 from Pieter Cardoen  ---
Created attachment 37571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37571&action=edit
console printout

[Bug c++/69631] [6 Regression] Bogus overflow in constant expression error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah,
(insn 12 11 13 (set (reg:DI 85)
(lshiftrt:DI (subreg:DI (reg/v:OI 79 [ v32u128_1 ]) 0)
(const_int 1 [0x1]))) pr69613-3.c:19 -1
 (nil))
and similar shifts by 1 look just weird when the TImode shift is with variable
shift count.

[Bug target/69120] sse2_shufpd_v2df_mask has wrong name

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Kirill Yukhin  ---
This makes corresponding expand much simpler. So I think this little naming
inconsistency is preferable to additional checks in define_expand.

[Bug c++/59627] ICE with OpenMP "declare reduction" and -flto

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
*** Bug 69594 has been marked as a duplicate of this bug. ***

[Bug c++/69594] ICE in discriminator_for_local_entity for libgomp.c++/udr-*.C with -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from vries at gcc dot gnu.org ---
The tentative patch for PR59627 fixes these failures.

Marking resolved-duplicate.

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

[Bug target/69118] Wrong condition in avx512f_maskcmp3

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
Author: kyukhin
Date: Wed Feb  3 13:44:50 2016
New Revision: 233103

URL: https://gcc.gnu.org/viewcvs?rev=233103&root=gcc&view=rev
Log:
PR target/69118

gcc/
* config/i386/sse.md (define_insn "avx512f_maskcmp3"):
Fix target.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug target/69118] Wrong condition in avx512f_maskcmp3

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
Author: kyukhin
Date: Wed Feb  3 13:48:27 2016
New Revision: 233104

URL: https://gcc.gnu.org/viewcvs?rev=233104&root=gcc&view=rev
Log:
PR target/69118.

gcc/
* config/i386/sse.md (define_insn "avx512f_maskcmp3"):
Fix target.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/sse.md

[Bug target/69118] Wrong condition in avx512f_maskcmp3

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

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

--- Comment #4 from Kirill Yukhin  ---
Fixed.

[Bug tree-optimization/69653] New: More CSE opportunities in address expressions

[amker at gcc dot gnu.org]

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

Bug ID: 69653
   Summary: More CSE opportunities in address expressions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Given below simple test:

#define MAX (1024)

void bar1 (int *, int *, int *, int *);
void bar2 (int *, int *, int *, int *);
int foo (unsigned int n)
{
  unsigned int i;
  int a0[MAX], a1[MAX], a2[MAX], a3[MAX];

  bar1 (a0, a1, a2, a3);
  for (i = 0; i < n; i++)
{
  unsigned char j = (unsigned char) i;
  a0[j] = a0[j] + 1;
  a1[j + 1] = a1[j + 1] + 2;
  a2[j + 2] = a2[j + 2] + 1;
  a3[j + 3] = a3[j + 3] + 3;
}
  bar2 (a0, a1, a2, a3);
  return 0;
}

Below code is generated on AArch64 with option "-O2 -mcpu=cortex-a57":

foo:
sub sp, sp, #16384
mov x1, 12352
stp x29, x30, [sp, -64]!
add x29, sp, 0
stp x19, x20, [sp, 16]
add x20, x29, x1
mov x1, 8256
stp x21, x22, [sp, 32]
add x21, x29, x1
mov x1, 4160
add x22, x29, x1
add x19, x29, 64
str x23, [sp, 48]
mov x3, x20
mov w23, w0
mov x2, x21
mov x1, x22
mov x0, x19
bl  bar1
cbz w23, .L4
mov w4, 0
.p2align 2
.L5:
and w0, w4, 255
add w4, w4, 1
add w3, w0, 1
add w2, w0, 2
add w1, w0, 3
sxtwx3, w3
cmp w23, w4
sxtwx0, w0
sxtwx2, w2
ldr w7, [x22, x3, lsl 2]
sxtwx1, w1
ldr w8, [x19, x0, lsl 2]
ldr w6, [x21, x2, lsl 2]
add w7, w7, 2
ldr w5, [x20, x1, lsl 2]
add w8, w8, 1
str w7, [x22, x3, lsl 2]
add w6, w6, 1
str w8, [x19, x0, lsl 2]
add w5, w5, 3
str w6, [x21, x2, lsl 2]
str w5, [x20, x1, lsl 2]
bne .L5
.L4:
mov x3, x20
mov x2, x21
mov x1, x22
mov x0, x19
bl  bar2
ldp x19, x20, [sp, 16]
mov w0, 0
ldp x21, x22, [sp, 32]
ldr x23, [sp, 48]
ldp x29, x30, [sp], 64
add sp, sp, 16384
ret

The loop is not optimal because CSE opportunities among address expressions are
missed.  All addr expressions in this case are in the form of "base + i <<
scale + const".  The scaling part "i << scale" is common sub expression, while
"base + const" part is (sfp related) loop invariant.
In my understanding, tree passes like ivopt/slsr should be able to handle cse
in addresses, and let RTL optimizer decide if the loop-invariant part can be
embedded in addressing mode or be hoisted out of loop.

In this case, the index variable isn't a SCEV, so ivopt can't help.  
In my understanding, SLSR are designed to do strength reduction in addr exprs,
maybe it should be improved to deal with addresses with different bases.  Also
lowering all memory reference to MEM_REF/TARGE_MEM_REF before SLSR could make
SLSR's job easier.

After all, below pseudo code in loop is wanted:
Loop-preheader:
  r0 = base0 + const0;
  r1 = base1 + const1;
  r2 = base2 + const2;
  r3 = base3 + const3;
loop-body:
  x = i << scale;
  ldr [r0 + x]
  ldr [r1 + x]
  ldr [r2 + x]
  ldr [r3 + x]
  //...
  str [r0 + x]
  str [r1 + x]
  str [r2 + x]
  str [r3 + x]

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Bernd Schmidt from comment #3)
> It's not crashing for me, but I think I agree there's a problem. Will
> investigate a bit.

Looks like PIC register is not initialized properly.

[Bug tree-optimization/69653] More CSE opportunities in address expressions

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
Since tree optimizer cannot handle cse opportunities as described here, backend
needs to force register scaling expr (instead of loop invariant part address
expression) out of memory reference, hoping RTL CSE can catch these.  It would
be better handled in tree optimizer because backend legitimize_address doesn't
have context information and this is done at a cost of missing loop invariant
opportunities.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

--- Comment #5 from Bernd Schmidt  ---
Yeah, my current theory is that r87 is spilled at the start, then the spill reg
is inherited in all the existing uses of it, and lra thinks it can avoid
storing it to memory.

Then we add a new reference to it for the pinsrw insn, and that isn't
initialized.

I seem to recall that this is a general problem with the idea of using a pseudo
for the PIC register, so surely there must have been some attempt to address
this when x86 was converted. So far I can't find anything though. Uroš - any
pointers?

[Bug libgomp/69625] deadlock in libgomp.c/doacross-1.c test

[vogt at linux dot vnet.ibm.com]

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

--- Comment #1 from Dominik Vogt  ---
It's a bug in the S/390 backend that sometimes trashes r6 in vararg functions. 
We're working on a fix.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #6 from Uroš Bizjak  ---
(In reply to Bernd Schmidt from comment #5)
> Yeah, my current theory is that r87 is spilled at the start, then the spill
> reg is inherited in all the existing uses of it, and lra thinks it can avoid
> storing it to memory.
> 
> Then we add a new reference to it for the pinsrw insn, and that isn't
> initialized.
> 
> I seem to recall that this is a general problem with the idea of using a
> pseudo for the PIC register, so surely there must have been some attempt to
> address this when x86 was converted. So far I can't find anything though.
> Uroš - any pointers?

Let's ask Ilya.

[Bug target/69634] [6 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fschedule-insns -fno-tree-vrp @ i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||aoliva at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Assignee|jakub at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #3 from Jakub Jelinek  ---
This goes wrong during sched1 pass, some real instructions are scheduled
differently between -g and -g0.

[Bug fortran/69654] New: ICE in gfc_trans_structure_assign

[talebi.hossein at gmail dot com]

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

Bug ID: 69654
   Summary: ICE in gfc_trans_structure_assign
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: talebi.hossein at gmail dot com
  Target Milestone: ---

Created attachment 37572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37572&action=edit
the minimalistic test file

Hi,

Compiling the attached file, using gfrotran versions 4.8.5, 5.3.0 and 6.0
(build 20160131) I get internal compiler error. Running 5.3.0 I get:

$ gfortran-5 -c gfortranbug1.f90 
gfortranbug1.f90:45:0:

 end subroutine  foo_script1
 1
internal compiler error: Segmentation fault
0xa3e2ef crash_signal
../../src/gcc/toplev.c:383
0x6b3565 gfc_trans_structure_assign
../../src/gcc/fortran/trans-expr.c:7064
0x6b41a4 gfc_trans_subcomponent_assign
../../src/gcc/fortran/trans-expr.c:6971
0x6b358b gfc_trans_structure_assign
../../src/gcc/fortran/trans-expr.c:7074
0x6b41a4 gfc_trans_subcomponent_assign
../../src/gcc/fortran/trans-expr.c:6971
0x6b358b gfc_trans_structure_assign
../../src/gcc/fortran/trans-expr.c:7074
0x6b4bd4 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../src/gcc/fortran/trans-expr.c:7103
0x6b5bb0 gfc_trans_assignment_1
../../src/gcc/fortran/trans-expr.c:8990
0x69bf47 gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool)
../../src/gcc/fortran/trans-decl.c:3733
0x6a0b1b gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../src/gcc/fortran/trans-decl.c:4288
0x6a258b gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:5917
0x685b41 gfc_generate_module_code(gfc_namespace*)
../../src/gcc/fortran/trans.c:2036
0x6403bd translate_all_program_units
../../src/gcc/fortran/parse.c:5330
0x6403bd gfc_parse_file()
../../src/gcc/fortran/parse.c:5540
0x67f9d5 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.

Cheers
H.

[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-03
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r233068

[Bug lto/69655] libgomp lto failures: segfault in cgraph_node::mark_force_output

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from vries at gcc dot gnu.org ---
Confirmed. Remarked before by Ilya at
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01870.html:
...
This doesn't work when there is more than one LTO partition, because only first
partition contains full offload table to maintain correct order, but cgraph and
varpool nodes aren't necessarily created for the first partition.  To
reproduce:

$ make check-target-libgomp RUNTESTFLAGS="c.exp=for-*
--target_board=unix/-flto"
FAIL: libgomp.c/for-3.c (internal compiler error)
FAIL: libgomp.c/for-5.c (internal compiler error)
FAIL: libgomp.c/for-6.c (internal compiler error)
$ make check-target-libgomp RUNTESTFLAGS="c++.exp=for-*
--target_board=unix/-flto"
FAIL: libgomp.c++/for-11.C (internal compiler error)
FAIL: libgomp.c++/for-13.C (internal compiler error)
FAIL: libgomp.c++/for-14.C (internal compiler error)
...

[Bug lto/69655] New: libgomp lto failures: segfault in cgraph_node::mark_force_output

[vries at gcc dot gnu.org]

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

Bug ID: 69655
   Summary: libgomp lto failures: segfault in
cgraph_node::mark_force_output
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

These failures surface when running libgomp testsuite with -flto for a
configuration with offloading configured:
...
FAIL: libgomp.c/for-3.c (internal compiler error)
FAIL: libgomp.c/for-3.c (test for excess errors)
FAIL: libgomp.c/for-5.c (internal compiler error)
FAIL: libgomp.c/for-5.c (test for excess errors)
FAIL: libgomp.c/for-6.c (internal compiler error)
FAIL: libgomp.c/for-6.c (test for excess errors)
FAIL: libgomp.c++/for-11.C (internal compiler error)
FAIL: libgomp.c++/for-11.C (test for excess errors)
FAIL: libgomp.c++/for-13.C (internal compiler error)
FAIL: libgomp.c++/for-13.C (test for excess errors)
FAIL: libgomp.c++/for-14.C (internal compiler error)
FAIL: libgomp.c++/for-14.C (test for excess errors)
FAIL: libgomp.fortran/target2.f90   -O0  (internal compiler error)
FAIL: libgomp.fortran/target2.f90   -O0  (test for excess errors)
...

[Bug lto/69655] [6 Regression] libgomp lto failures: segfault in cgraph_node::mark_force_output

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|libgomp lto failures:   |[6 Regression] libgomp lto
   |segfault in |failures: segfault in
   |cgraph_node::mark_force_out |cgraph_node::mark_force_out
   |put |put

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

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
What I have learnt so far:

When the gimple optimisation algorithm 'remove_unused_locals ()' in
gcc/tree-ssa-live.c is done, it has removed the temporary for the
_gfortran_transfer_character_write's string length. In the previous analysis
step this (ssa-)temporary has the uid 3471 in my current fortran. That var
occurs in two basicblocks (bb), once in  of ssa, where it is only used to
check whether a preallocated incoming string has the correct length. That whole
bb can be eliminated, because it is unreachable which can be deduced from the
propagated attributes. But in the  it must not be eliminated as well.
Because in both bbs the uid of the temporary is the same, I tried several ways
to prevent this association (adding a further temporary using gfc_evaluate_now
(), copying the tree using copy_node ()), but to no avail yet. 

Having said this my assumption is, that at both occurrences of .__result_4 the
exactly same tree is used (and not a separate copy in each place). Maybe this
is the issue, but I am still investigating. Just thought to let you know
whether anything of this rings a bell.

[Bug sanitizer/69656] New: -fsanitize=undefined compile time hog

[trippels at gcc dot gnu.org]

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

Bug ID: 69656
   Summary: -fsanitize=undefined compile time hog
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

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

The compile time for the attached testcase increases from 
~4o sec (-O2) to 3:32 minutes (-O2 -fsanitize=undefined).

(clang: from 1 minute to 1:30 minutes)

[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
This is my fault - forgot to fix vuse for scalar statements which are crossed
by masked stores during code motion. Fix is testing and will be sent for review
tomorrow.

[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC|jakub at redhat dot com|

--- Comment #3 from Jakub Jelinek  ---
Clearly a bug in optimize_mask_stores.
At the start of that function we have:
...
mask__46.14_129 = vect__14.9_121 != vect__21.12_127;
_46 = _14 != _21;
mask__ifc__47.15_130 = mask__46.14_129;
_ifc__47 = _46;
MASK_STORE (vectp.16_132, 8B, mask__ifc__47.15_130, vect__22.13_128);
vect__24.20_140 = MEM[(double *)vectp.18_138];
_24 = *_13;
vect__25.21_141 = vect__21.12_127 + vect__24.20_140;
_25 = _21 + _24;
MASK_STORE (vectp.22_145, 8B, mask__ifc__47.15_130, vect__25.21_141);
k_27 = k_28 + 1;
...
Now, the MASK_STORE calls are processed from last to first, which is fine, we
first move the second MASK_STORE and the vector stmts that feed it:
vect__24.20_140 = MEM[(double *)vectp.18_138];
vect__25.21_141 = vect__21.12_127 + vect__24.20_140;
MASK_STORE (vectp.22_145, 8B, mask__ifc__47.15_130, vect__25.21_141);
but then continue trying to move the second MASK_STORE into the same
conditional block, because it has the same mask.  In this case it is wrong,
because there is
the scalar load in between (_24 = *_13) that just waits for DCE, but generally
there could be arbitrary code.
/* Put other masked stores with the same mask to STORE_BB.  */
if (worklist.is_empty ()
|| gimple_call_arg (worklist.last (), 2) != mask
|| worklist.last () != stmt1)
  break;
has a simplistic check (doesn't consider other MASK_STORE unless the walking
walked up to that stmt), but of course it doesn't work too well if some scalar
stmts were skipped.

I see various issues in that function:
1) wrong formatting:
  gsi_to = gsi_start_bb (store_bb);
  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_NOTE, vect_location,
   "Move stmt to created bb\n");
  dump_gimple_stmt (MSG_NOTE, TDF_SLIM, last, 0);
}
/* Move all stored value producers if possible.  */
while (!gsi_end_p (gsi))
  {
The Move all stored value and everything below up to corresponding closing }
should be moved two columns to the left
2) IMHO stmt1 should be set to NULL before that while (!gsi_end_p (gsi)),
as the function is prepared to handle multiple bbs
3) next to gimple_vdef non-NULL break IMHO should be also
gimple_has_volatile_ops -> break check, just for safety, we don't wanto to
mishandle say volatile reads etc.
4) you have to skip over debug stmts if there are any, otherwise we have a
-fcompare-debug issue
5) IMHO you should give up also for !is_gimple_assign, say trying to move an
elemental function call into the conditional is just wrong
6) the
/* Skip scalar statements.  */
if (!VECTOR_TYPE_P (TREE_TYPE (lhs)))
  continue;
should be reconsidered.  IMHO if you have scalar stmts that feed just the stmts
in the STORE_BB, there is no reason not to move them too, if you have scalar
stmts that feed other stmts too, IMHO you should give up on them if they have a
vuse; what code did you have in mind when adding the !VECTOR_TYPE_P check?
7) FOR_EACH_IMM_USE_FAST loop should ignore debug stmts, at least for decisions
when to stop in some stmt; bet the debug stmts if there are any need to be
reset
if we move the def stmt that they are using, otherwise we risk -fcompare-debug
issues
8) the worklist.last () != stmt1 check need to be -fcompare-debug friendly too,
so if there are debug stmts in between the last moved stmt and the previous
MASK_STORE, we need to handle it as if there aren't any debug stmts in between

[Bug sanitizer/69656] -fsanitize=undefined compile time hog

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
# Overhead  Command  Shared Object  Symbol
 4.48%  cc1plus  cc1plus[.] bitmap_set_bit
 2.34%  cc1plus  cc1plus[.] bitmap_clear_bit
 1.48%  cc1plus  cc1plus[.] record_operand_costs
 1.37%  cc1plus  cc1plus[.] bitmap_bit_p
 1.23%  cc1plus  cc1plus[.] gt_ggc_mx_lang_tree_node
 1.11%  cc1plus  cc1plus[.] run_fast_df_dce
 1.09%  cc1plus  cc1plus[.] df_note_compute
 0.98%  cc1plus  cc1plus[.] df_insn_refs_collect

[Bug rtl-optimization/64081] [5/6 Regression] r217827 prevents RTL loop unroll

[afomin.mailbox at gmail dot com]

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

--- Comment #21 from Alexander Fomin  ---
I'm sorry for a late response.

When applying this patch over r233079, I can't see any bootstrap issues on AIX
machine except some missing symbols from libintl.
Adding --disable-nls to options provided by David eliminates this problem, and
GCC bootstrap exits with 0 code.

What else should I check to be sure it's OK? Any suggestions?

[Bug rtl-optimization/64081] [5/6 Regression] r217827 prevents RTL loop unroll

[dje at gcc dot gnu.org]

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

--- Comment #22 from David Edelsohn  ---
We can try it again or I can try an additional bootstrap test with your patch.

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Feb  3 17:58:34 2016
New Revision: 233107

URL: https://gcc.gnu.org/viewcvs?rev=233107&root=gcc&view=rev
Log:
2016-02-03  Vladimir Makarov  
Alexandre Oliva  

PR target/69461
* lra-constraints.c (simplify_operand_subreg): Check additionally
address validity after potential reloading.
(process_address_1): Check insns validity.  In case of failure do
nothing.

2016-02-03  Vladimir Makarov  
Alexandre Oliva  

PR target/69461
* gcc.target/powerpc/pr69461.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr69461.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/64081] [5/6 Regression] r217827 prevents RTL loop unroll

[afomin.mailbox at gmail dot com]

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

--- Comment #23 from Alexander Fomin  ---
Created attachment 37574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37574&action=edit
Original patch

It would be great, thank you.
Here is the original patch I've evaluated.

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #14 from Markus Trippelsdorf  ---
Fixed. Thanks.
Firefox now builds fine with -mlra (and -flto) on gcc112.

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[vmakarov at gcc dot gnu.org]

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

--- Comment #15 from Vladimir Makarov  ---
(In reply to Alexandre Oliva from comment #12)
> Vlad, thanks for taking this over.  Let me just point out, just in case you
> missed, that I believe it is important for any register allocator to test
> HARD_REGNO_MODE_OK, and that AFAICT we were not doing that.  Please let me
> know if I'm mistaken.  Thanks,


No, you are not mistaken.  But the problem is that not always all hard
registers of a class can have HARD_REGNO_MODE_OK the same value.  As we don't
know yet the exact hard reg at some point of LRA (which is different from
reload) and can not guarantee the pseudo will get a specific hard register
later.

Actually, there are pros and cons for each solution.

[Bug libstdc++/69657] New: [6 Regression] abs() not inlined after including math.h

[wdijkstr at arm dot com]

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

Bug ID: 69657
   Summary: [6 Regression] abs() not inlined after including
math.h
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

Since a recent C++ header change abs() no longer gets inlined if we include an
unrelated header before it.

#include 
#include 

int
wrap_abs (int x)
{
  return abs (x) + std::abs(x);
}


Until recently GCC6 with -O2 -S produced for AArch64:

_Z8wrap_absi:
cmp w0, wzr
csneg   w0, w0, w0, ge
lsl w0, w0, 1
ret

However trunk GCC6 now emits:

_Z8wrap_absi:
stp x29, x30, [sp, -16]!
add x29, sp, 0
bl  abs
lsl w0, w0, 1
ldp x29, x30, [sp], 16

This may result in significant slowdowns as it adds a call and PLT indirection
to execute a 3-instruction function. There might be other builtin functions
that are affected in a similar way.

[Bug target/69619] [6 Regression] compilation doesn't terminate during CCMP expansion

[wdijkstr at arm dot com]

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

--- Comment #5 from Wilco  ---
Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00206.html

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #10 from alalaw01 at gcc dot gnu.org ---
The stores are getting optimized out because equal_mem_array_ref_p considers
equal pairs of MEM_REFS like

fmcom.x[_168] and fmcom.x[_208]

That is, a ARRAY_REF whose first operand is a COMPONENT_REF fmcom.x (of a
VAR_DECL and a FIELD_DECL), and whose second operand is an SSA_NAME _168 or
_208; I don't see anything obvious to suggest that they should be equal).

get_ref_base_and_extent then returns base=fmcom, size=64, max_size=64 (so not a
variable-sized access), and offset 0 :-(.

[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 #7 from Paul Thomas  ---
(In reply to vehre from comment #6)
> What I have learnt so far:
> 
> When the gimple optimisation algorithm 'remove_unused_locals ()' in
> gcc/tree-ssa-live.c is done, it has removed the temporary for the
> _gfortran_transfer_character_write's string length. In the previous analysis
> step this (ssa-)temporary has the uid 3471 in my current fortran. That var
> occurs in two basicblocks (bb), once in  of ssa, where it is only used
> to check whether a preallocated incoming string has the correct length. That
> whole bb can be eliminated, because it is unreachable which can be deduced
> from the propagated attributes. But in the  it must not be eliminated
> as well. Because in both bbs the uid of the temporary is the same, I tried
> several ways to prevent this association (adding a further temporary using
> gfc_evaluate_now (), copying the tree using copy_node ()), but to no avail
> yet. 
> 
> Having said this my assumption is, that at both occurrences of .__result_4
> the exactly same tree is used (and not a separate copy in each place). Maybe
> this is the issue, but I am still investigating. Just thought to let you
> know whether anything of this rings a bell.

Andre,

You have gone further in the diagnosis than I have. However, I would take a
look at comment #3. There is no reason at all why gimple should treat explicit
and implicit result variables differently. I THINK that the difference must lie
in the dead wood that I left in place in trans-decl.c(gfc_get_symbol_decl).

(A few minutes later) I just removed the whole lot and this did not fix this
PR. However, unsurprisingly, it does regtest OK, which tells me that the whole
lot should go.

I still can see absolutely no difference in the generated code.

Index: /svn/trunk/gcc/fortran/trans-decl.c
===
*** /svn/trunk/gcc/fortran/trans-decl.c (revision 233015)
--- /svn/trunk/gcc/fortran/trans-decl.c (working copy)
*** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1366,1386 
}
  }

-   /* All deferred character length procedures need to retain the backend
-  decl, which is a pointer to the character length in the caller's
-  namespace and to declare a local character length.  */
-   if (!byref && sym->attr.function
-   && sym->ts.type == BT_CHARACTER
-   && sym->ts.deferred
-   && sym->ts.u.cl->passed_length == NULL
-   && sym->ts.u.cl->backend_decl
-   && TREE_CODE (sym->ts.u.cl->backend_decl) == PARM_DECL)
- {
-   sym->ts.u.cl->passed_length = sym->ts.u.cl->backend_decl;
-   gcc_assert (POINTER_TYPE_P (TREE_TYPE (sym->ts.u.cl->passed_length)));
-   sym->ts.u.cl->backend_decl = build_fold_indirect_ref
(sym->ts.u.cl->backend_decl);
- }
- 
fun_or_res = byref && (sym->attr.result
 || (sym->attr.function && sym->ts.deferred));
if ((sym->attr.dummy && ! sym->attr.function) || fun_or_res)
--- 1366,1371 
*** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1409,1447 
 (sym->ts.u.cl->passed_length == sym->ts.u.cl->backend_decl))
sym->ts.u.cl->backend_decl = NULL_TREE;

- if (sym->ts.deferred && byref)
-   {
- /* The string length of a deferred char array is stored in the
-parameter at sym->ts.u.cl->backend_decl as a reference and
-marked as a result.  Exempt this variable from generating a
-temporary for it.  */
- if (sym->attr.result)
-   {
- /* We need to insert a indirect ref for param decls.  */
- if (sym->ts.u.cl->backend_decl
- && TREE_CODE (sym->ts.u.cl->backend_decl) == PARM_DECL)
-   {
- sym->ts.u.cl->passed_length = sym->ts.u.cl->backend_decl;
- sym->ts.u.cl->backend_decl =
-   build_fold_indirect_ref (sym->ts.u.cl->backend_decl);
-   }
-   }
- /* For all other parameters make sure, that they are copied so
-that the value and any modifications are local to the routine
-by generating a temporary variable.  */
- else if (sym->attr.function
-  && sym->ts.u.cl->passed_length == NULL
-  && sym->ts.u.cl->backend_decl)
-   {
- sym->ts.u.cl->passed_length = sym->ts.u.cl->backend_decl;
- if (POINTER_TYPE_P (TREE_TYPE (sym->ts.u.cl->passed_length)))
-   sym->ts.u.cl->backend_decl
-   = build_fold_indirect_ref (sym->ts.u.cl->backend_decl);
- else
-   sym->ts.u.cl->backend_decl = NULL_TREE;
-   }
-   }
- 
  if (sym->ts.u.cl->backend_decl == NULL_TREE)
length = gfc_create_string_

[Bug fortran/69636] ICE(s) on using option -fmodule-private

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
To begin with a short example, namely function_kinds_3.f90.

Placing statement "private" explicit in source, reducing a bit,
then compiling without "-fmodule-private" :


$ cat z1.f90
module m
  private
  integer, parameter :: char_t = kind('a')
end module m

character(1,char_t) function test1()
  use m
  test1 = 'A'
end function test1


$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]


$ gfortran-6 -c z1.f90
z1.f90:6:12:

 character(1,char_t) function test1()
1

Error: Parameter ‘char_t’ at (1) has not been declared or is a variable, which
does not reduce to a constant expression
f951: internal compiler error: in gfc_convert_chartype, at
fortran/intrinsic.c:4812


$ gfortran-5.3.1 -c z1.f90
(null):0: confused by earlier errors, bailing out


$ gfortran-4.9.0 -c z1.f90
f951: internal compiler error: in gfc_convert_chartype, at
fortran/intrinsic.c:4623

[Bug c++/69658] New: [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[mpolacek at gcc dot gnu.org]

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

Bug ID: 69658
   Summary: [6 Regression] Bogus "C99 designator outside aggregate
initializer" error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct S { S(int); };
struct T { char n[22]; S s; };
T t[1] = { { "foo", (1) }, };

is rejected with
e.C:3:28: error: C99 designator ‘T::n’ outside aggregate initializer
 T t[1] = { { "foo", (1) }, };
^
since r224286.

[Bug fortran/69659] [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
List of affected files :

   actual_array_offset_1.f90
   allocate_class_3.f90
   allocate_with_source_16.f90
   allocate_with_source_8.f08
   class_array_11.f03
   class_array_20.f03
   class_array_21.f03
   class_array_6.f03
   class_array_7.f03
   class_to_type_1.f03
   elemental_dependency_5.f90
   finalize_10.f90
   finalize_15.f90
   finalize_29.f08
   sizeof_4.f90
   typebound_generic_14.f03
   type_to_class_1.f03
   unlimited_polymorphic_17.f90
   unlimited_polymorphic_18.f90
   unlimited_polymorphic_19.f90
   unlimited_polymorphic_1.f03

[Bug fortran/69659] New: [6 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69659
   Summary: [6 Regression] ICE on using option -frepack-arrays, in
gfc_conv_descriptor_data_get
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

A validation run with option -frepack-arrays exposes a regression
when running on test files from ./gcc/testsuite/gfortran.dg/ ...

One example :

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]


$ gfortran-6  -frepack-arrays  -c class_array_11.f03
class_array_11.f03:17:0:

   SUBROUTINE vector_operation(pvec)

internal compiler error: in gfc_conv_descriptor_data_get, at
fortran/trans-array.c:144


$ gfortran-5.3.1  -frepack-arrays  -c class_array_11.f03
# no ICE

$ gfortran-4.9.0  -frepack-arrays  -c class_array_11.f03
# no ICE

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic, rejects-valid
   Target Milestone|--- |6.0

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-03
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||paolo at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Bet we shouldn't use get_ref_base_and_extent comparisons if there is a variable
ARRAY_REF index and the corresponding array is flexible array member or poor
man's flexible array member.

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Otherwise, we happily consider in

struct S { char a[1]; int b; char c[1]; };
void
foo (struct S *p, int i, int j)
{
  p->c[i]
...
  p->c[j]
}

the above two as equivalent, while we should only consider those for p->a[i]
and p->a[j], where it is only valid to use i == j == 0.  If char c[2]; is used,
then max_size would indicate variable access, but for poor man's flexible array
member of size 1 array we need to avoid this, both during hashing and during
equality comparison.

[Bug c++/69056] Argument pack deduction failure during overload resolution

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka  ---
Author: ppalka
Date: Wed Feb  3 20:14:43 2016
New Revision: 233108

URL: https://gcc.gnu.org/viewcvs?rev=233108&root=gcc&view=rev
Log:
Fix PR c++/69056 (argument pack deduction failure during overload resolution)

gcc/cp/ChangeLog:

PR c++/69056
* pt.c (try_one_overload): Handle comparing argument packs so
that there is no conflict if we deduced more arguments of an
argument pack than were explicitly specified.

gcc/testsuite/ChangeLog:

PR c++/69056
g++.dg/cpp0x/pr69056.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr69056.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69056] Argument pack deduction failure during overload resolution

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 6.

[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
With:
- the tentative fix for PR69599
- the tentative fix for PR59627
- the undo of r232384 patch that caused PR69655 
this still reproduces. Apparently this is an independent issue.

[Bug lto/69655] [6 Regression] libgomp lto failures: segfault in cgraph_node::mark_force_output

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
In addition, these also fail (hiding PR69607, which is triggered in the same
test-cases when undoing r232384):
...
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (internal compiler error)
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (internal compiler error)
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
...

[Bug target/53440] [arm] generic thunk code fails for method which uses '...'

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #6 from Bernd Edlinger  ---
Created attachment 37575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37575&action=edit
untested patch for virtual thunk code

This patch does not handle every possible vcall_offset but
usually vcall_offset is either -12 or 0, so a simple approach
should be sufficient.

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[andreast at gcc dot gnu.org]

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

Andreas Tobler  changed:

   What|Removed |Added

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

--- Comment #6 from Andreas Tobler  ---
patch request is here:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00242.html

[Bug target/69660] New: Microblaze break_handler and symbol `_interrupt_handler' is already defined

[a_fisch at gmx dot de]

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

Bug ID: 69660
   Summary: Microblaze break_handler and symbol
`_interrupt_handler' is already defined
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a_fisch at gmx dot de
  Target Milestone: ---

Hi all,

I tried to implement some low level routines for the microblaze target and used
some rarely used features of the microblaze GCC toolchain. 
When I tried to implement a break_handler and an interrupt_handler, I found
unexpected behavior and the emitted assembler output terminated compilation
with: Error: symbol `_interrupt_handler' is already defined

I am not familiar with bug reporting procedure, and I don't have a system,
which is ready to compile GCC to fix it myself. But I'll try my best.

The GCC Toolchain I used is part of the Xilinx Vivado 2015.4 SDK.

d:\>mb-gcc --version
mb-gcc (crosstool-NG 1.20.0) 4.9.2

I assume, that the following patch is introducing support for break_handler,
but is not completely correct: 
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00951.html

In the meantime I crosschecked different versions and found out, that the error
was introduced earlier. Part of the erroneous code pattern was introduced with
the first version in 2010. Afterwards it was copied and extended several times.
It is still present up to now (HEAD).


I used this example, which has an interrupt_handler and a break_handler within
the same compile unit:

// Invoke:
//  mb-gcc -save-temps Interrupt_u_BreakHandler.c
//  Command returns with the following error:
//Interrupt_u_BreakHandler.s: Assembler messages:
//Interrupt_u_BreakHandler.s:132: Error: symbol `_interrupt_handler' is
already defined
//
//   See assembler output in Interrupt_u_BreakHandler.s
//

void BreakH(void) __attribute__ ((break_handler)); // <-- Error triggered here
void BreakH(void) 
{
}

void __attribute__ ((interrupt_handler)) ISR(void) // <-- Together with this
{
}

int main(int argc, char **argv)
{
  return(0);
} 


It looks like the resulting function prolog in the assembler output for the
break_handler is wrong.


.text
.align  2
.globl  _interrupt_handler //<-- I expected _break_handler here!
.globl  BreakH
.ent_interrupt_handler //<-- I expected _break_handler here!
BreakH:
_interrupt_handler:// <-- ???
_break_handler:
.frame  r19,24,r15  # vars= 0, regs= 4, args= 0
.mask   0x000e0800
addik   r1,r1,-24
swi r15,r1,0
swi r11,r1,8
swi r17,r1,12
swi r18,r1,16
swi r19,r1,20
mfs r11,rmsr  #mfs
swi r11,r1,4
addkr19,r1,r0 #add movsi
lwi r15,r1,0
addkr1,r19,r0 #add movsi
lwi r11,r1,4
mts rmsr,r11  #mts
lwi r11,r1,8
lwi r17,r1,12
lwi r18,r1,16
lwi r19,r1,20
addik   r1,r1,24
rtbdr16,8
nop # Unfilled delay slot

.end_break_handler  // <-- Epilog ok!!!
$Lfe1:
.size   BreakH,$Lfe1-BreakH
.align  2
.globl  _interrupt_handler
.globl  ISR
.ent_interrupt_handler
ISR:
_interrupt_handler:
.frame  r19,24,r15  # vars= 0, regs= 4, args= 0
.mask   0x000e0800
addik   r1,r1,-24
swi r15,r1,0
swi r11,r1,8
swi r17,r1,12
swi r18,r1,16
swi r19,r1,20
mfs r11,rmsr  #mfs
swi r11,r1,4
addkr19,r1,r0 #add movsi
lwi r15,r1,0
addkr1,r19,r0 #add movsi
lwi r11,r1,4
mts rmsr,r11  #mts
lwi r11,r1,8
lwi r17,r1,12
lwi r18,r1,16
lwi r19,r1,20
addik   r1,r1,24
rtidr14,0 
nop # Unfilled delay slot

.end_interrupt_handler

I tried to track the problem and found the following suspicious code within the
sources of the gcc toolchain:
(mb-gnu-20150907.tar.gz was the newest one I could find on the xilinx web site,
but I found the same files and code lines in the git repositories here.)

 
mb-gnu-20150907.tar.gz\mb-gnu-20150907.tar\microblaze_2015.3_sources\gcc\gcc\config\microblaze\microblaze.c

Line 2918: microblaze_function_prologue (FILE * file, HOST_WIDE_INT size
ATTRIBUTE_UNUSED)

  if (interrupt_handler && strcmp (INTERRUPT_HANDLER_NAME, fnname))//<-- Wrong! 
fputs ("_interrupt_handler", file);
  else if (break_handler && strcmp (BREAK_HANDLER_NAME, fnname))//<-- Wrong!
fputs ("_break_handler", file);
  else if (fast_interrupt && strcmp (FAST_INTERRUPT_NAME, fnname))//<--Wrong!
fputs ("_fast_interrupt", file);
  else