[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Author: olegendo
Date: Sun Jan 21 05:13:20 2018
New Revision: 256928

URL: https://gcc.gnu.org/viewcvs?rev=256928=gcc=rev
Log:
Backport from mainline
2018-01-21  Oleg Endo  

PR target/80870
* config/sh/sh_optimize_sett_clrt.cc:
Use INCLUDE_ALGORITHM and INCLUDE_VECTOR instead of direct includes.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh_optimize_sett_clrt.cc

[Bug c++/83958] New: ICE: Segmentation fault (in find_decomp_class_base)

[asolokha at gmx dot com]

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

Bug ID: 83958
   Summary: ICE: Segmentation fault (in find_decomp_class_base)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

While reducing the testcase from PR83481 I've found a snippet that still makes
both g++ 7 and 8 (r256677) ICE:

template  struct ab;
class b;
template > class c;
template  struct ae;
template 
class e {
public:
  using ah = d;
  ah operator*();
  af operator++();
  template 
  bool operator!=(e);
};
template  class aj {
public:
  class ad;
  using ak = ae;
  using am = e;
  class ad : public am {};
  ad begin();
  ad end();
};
template  class c : aj {
  using ao = aj;

public:
  using ao::begin;
  using ao::end;
};
using ap = class aq;
class ar {
  void as() { for (auto & [ a ] : at) {} }
  c at;
};

% g++-8.0.0-alpha20180114 -std=c++1z -w -c file_upload.i
file_upload.i: In member function 'void ar::as()':
file_upload.i:32:35: internal compiler error: Segmentation fault
   void as() { for (auto & [ a ] : at) {} }
   ^~
0xea3a0f crash_signal
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/toplev.c:325
0x853a88 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree.h:3126
0x853a88 find_decomp_class_base
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/decl.c:7215
0x875eb3 cp_finish_decomp(tree_node*, tree_node*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/decl.c:7604
0x8e9e24 cp_convert_range_for(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int, bool, unsigned short)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:11928
0x8ee82b cp_parser_range_for
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:11753
0x9198de cp_parser_for
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:11615
0x9198de cp_parser_iteration_statement
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:12172
0x8f5ec6 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:10766
0x8f6ee0 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:11206
0x8f6fb7 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:11160
0x90de50 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:21700
0x90de50 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:21737
0x90e770 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:26635
0x91058c cp_parser_late_parsing_for_member
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:27515
0x90235e cp_parser_class_specifier_1
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:22666
0x903639 cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:22692
0x903639 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:16698
0x910e6c cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:13559
0x916ec3 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cp/parser.c:12867

[Bug c++/83481] ICE in const-ref structured bindings.

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
The fix seems to be backported to gcc 7 branch in r255730.

Reduced testcase:

typedef int b;
namespace a {
template  struct c;
template  class d;
} // namespace a
namespace ac {
template > class e;
template  struct h {
  ad ae;
  g f;
};
template 
class ag {
public:
  using ah = k;
  ah operator*();
  i operator++();
  template 
  bool operator!=(ag);
};
template  class ak {
public:
  class m;
  using q = h;
  using o = ag;
  using r = ag;
  class ab : public o {};
  class m : public r {};
  ab end();
  m begin();
};
template  class e : ak {
  using al = ak;

public:
  using al::begin;
  using al::end;
};
} // namespace ac
using s = b;
using am = class {};
struct ao;
struct ap;
using aq = a::d;
namespace {
class ar {
  void as(const ao &, const aq &) { for (auto & [ a, av ] : at) {} }
  ac::e at;
};
} // namespace

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||chrisj at rtems dot org

--- Comment #6 from Oleg Endo  ---
*** Bug 82530 has been marked as a duplicate of this bug. ***

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Sun Jan 21 05:03:26 2018
New Revision: 256926

URL: https://gcc.gnu.org/viewcvs?rev=256926=gcc=rev
Log:
PR target/80870
* config/sh/rx/rx.c (config/sh/sh_optimize_sett_clrt.cc):
Use INCLUDE_ALGORITHM and INCLUDE_VECTOR instead of direct includes.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh_optimize_sett_clrt.cc

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||chrisj at rtems dot org

--- Comment #6 from Oleg Endo  ---
*** Bug 82530 has been marked as a duplicate of this bug. ***

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Sun Jan 21 05:03:26 2018
New Revision: 256926

URL: https://gcc.gnu.org/viewcvs?rev=256926=gcc=rev
Log:
PR target/80870
* config/sh/rx/rx.c (config/sh/sh_optimize_sett_clrt.cc):
Use INCLUDE_ALGORITHM and INCLUDE_VECTOR instead of direct includes.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh_optimize_sett_clrt.cc

[Bug other/82530] RTEMS 4.12 SH build failure on FreeBSD 11.1 (clang) with an error in sh_optimize_sett_clrt.cc

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #2 from Oleg Endo  ---
Same as PR 80870.

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

[Bug tree-optimization/83957] ICE: Segmentation fault (in gimple_phi_arg)

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
Actually, the testcase can be reduced to just

void
k2 (int *ch, int fw)
{
  if (fw < 0)
while (fw < 1)
  {
ch = 
++fw;
  }
}

[Bug tree-optimization/83957] New: ICE: Segmentation fault (in gimple_phi_arg)

[asolokha at gmx dot com]

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

Bug ID: 83957
   Summary: ICE: Segmentation fault (in gimple_phi_arg)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180114 snapshot (r256677), 7.2, and 6.3 all ICE when compiling
the following snippet w/ -O1 -ftree-parallelize-loops=2 -fno-tree-dce --param
parloops-schedule=runtime (=dynamic, =guided):

void
k2 (int *ch, int fw)
{
  for (*ch = 0; *ch < 16; ++*ch)
{
}

  fw += *ch & 1;
  if (fw < 0)
while (fw < 1)
  {
ch = 
++fw;
  }
}

% gcc-8.0.0-alpha20180114 -O1 -ftree-parallelize-loops=2 -fno-tree-dce --param
parloops-schedule=runtime -c clnvri9r.c
during GIMPLE pass: ompexpssa
clnvri9r.c: In function 'k2':
clnvri9r.c:10:11: internal compiler error: Segmentation fault
 while (fw < 1)
   ^
0xc9910f crash_signal
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/toplev.c:325
0xb7719e gimple_phi_arg
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/gimple.h:4368
0xb7719e gimple_phi_arg_def
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/gimple.h:4413
0xb7719e expand_omp_for_generic
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/omp-expand.c:3172
0xb79c3e expand_omp_for
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/omp-expand.c:5700
0xb7a0da expand_omp
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/omp-expand.c:7730
0xb7a557 expand_omp
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/omp-expand.c:7716
0xb7bd1d execute_expand_omp
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/omp-expand.c:7954

Earlier gcc versions don't have parloops-schedule parameter.

[Bug c++/83956] New: [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

[skpgkp1 at gmail dot com]

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

Bug ID: 83956
   Summary: [8 regression] error: use of deleted function
‘{anonymous}::a::~a()’
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp1 at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

This issue appear during HHVM build with GCC 8. GCC 7 works fine.

$ cat foo.cpp.i
namespace {
struct a {
  ~a() = delete;
};
struct b {
  ~b() {}
  union {
a c;
  };
};
}


$ g++ --version
g++ (GCC) 8.0.1 20180120 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ g++ -O3 -o foo.cpp.o -c foo.cpp.i -w
foo.cpp.i: In destructor ‘{anonymous}::b::~b()’:
foo.cpp.i:6:8: error: use of deleted function ‘{anonymous}::a::~a()’
   ~b() {}
^
foo.cpp.i:3:3: note: declared here
   ~a() = delete;
   ^


Work fine with GCC 7.

$ g++ --version
g++ (GCC) 7.2.1 20180120
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++  -O3 -o foo.cpp.o -c foo.cpp.i -w
$ echo $?
0

[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[daniel.santos at pobox dot com]

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

--- Comment #3 from Daniel Santos  ---
(In reply to Richard Biener from comment #1)
> Testcase would be nice.

*sigh* Yes, I've seen that there are tests that run gdb through expect, I
haven't learned how to use that yet. 


(In reply to Jakub Jelinek from comment #2)
> So, is this about debug info (which I believe shouldn't be needed), or
> missing unwind info?

This is only about the debug

> I presume the mingw unwind info isn't done through .cfi_* directives, so
> would need to be written by hand.

This doesn't really target Windows at all, but rather Wine.  In fact, it is
disabled on Windows because the SEH code in gcc/config/i386/winnt.c doesn't
support REG_CFA_EXPRESSION.  That said, I haven't actually *tested* this with
C++, which is bad except that I am not currently aware of any such use-case --
Wine is almost entirely written in C.  None the less, it would seem some C++
tests are in order ... that might be an understatement...

> How hard is that, and is this really a
> regression, those snippets didn't exist before?

True, these stubs did not exist before, but the user always had the ability to
step through such functions and get a valid backtrace from the debugger, so I
would think it to be a regression.

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #4)
> Andrew, the OP had already closed the first PR, and you closed the second as
> duplicate of the first. Did you really mean to get to a situation where both
> are closed?

No, it was an accident that closed this one as a dup.  I did not realize he
closed the other one.

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Andrew, the OP had already closed the first PR, and you closed the second as
duplicate of the first. Did you really mean to get to a situation where both
are closed?

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

--- Comment #14 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jan 20 20:56:45 2018
New Revision: 256921

URL: https://gcc.gnu.org/viewcvs?rev=256921=gcc=rev
Log:
2018-01-20  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Set return type correctly.

2018-01-20  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_18.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/matmul_18.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/simplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jan 20 20:45:50 2018
New Revision: 256920

URL: https://gcc.gnu.org/viewcvs?rev=256920=gcc=rev
Log:
2018-01-20  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Set return type correctly.

2018-01-20  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_18.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/matmul_18.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/simplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jan 20 20:33:34 2018
New Revision: 256919

URL: https://gcc.gnu.org/viewcvs?rev=256919=gcc=rev
Log:
2018-01-20  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Set return type correctly.

2018-01-20  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_18.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/matmul_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl  ---
On Sat, Jan 20, 2018 at 04:51:24PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83900
> 
> --- Comment #10 from Steve Kargl  ---
> On Sat, Jan 20, 2018 at 03:22:50PM +, dominiq at lps dot ens.fr wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83900
> > 
> > --- Comment #9 from Dominique d'Humieres  ---
> > The original test in comment 0 still fails at r256917 on darwin with
> > 
> > pr83900.f90:4:0:
> > 
> > print *, matmul(a, b)
> > 
> > internal compiler error: in fold_convert_loc, at fold-const.c:2402
> > 
> > Should I reopen this PR or open a new one?
> > 
> 
> Interesting.  gfortran.dg/matmul_17.f90 is essentially the 
> code in comment #0 without the IO statement.  The backtrace
> in comment #0 is caused by the assert() I removed, which is
> bogus.  I think a new PR is needed.  It seems matmul is 
> hosed
> 
>integer, parameter :: a(3,2) = 1
>real, parameter :: b(2,3) = 2
>real, parameter :: c(3,3) = matmul(a,b)
>real d(3,3)
>d = matmul(a,b)
>print '(9F5.1)', c
>print '(9F5.1)', d
> % gfcx -o z -fno-frontend-optimize a.f90
> % ./z
>   4.0  4.0  4.0  4.0  4.0  4.0  4.0  4.0  4.0
>   0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
> 
> -fno-frontend-optimize is  not needed to get the above.

Something is definitely odd in the tree dump.  Lines edited to get < 80 chars.

{
  real(kind=4) d[9];
  static real(kind=4) c[9] = {4., 4., 4., 4., 4., 4., 4., 4., 4.};

  {
static real(kind=4) A.0[9] = {0., 0., 0., 0., 0., 0., 0., 0., 0.};

(void) __builtin_memcpy ((void *) , (void *) , 36);
{
  struct __st_parameter_dt dt_parm.1;

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Sat, Jan 20, 2018 at 03:22:50PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83900
> 
> --- Comment #9 from Dominique d'Humieres  ---
> The original test in comment 0 still fails at r256917 on darwin with
> 
> pr83900.f90:4:0:
> 
> print *, matmul(a, b)
> 
> internal compiler error: in fold_convert_loc, at fold-const.c:2402
> 
> Should I reopen this PR or open a new one?
> 

Interesting.  gfortran.dg/matmul_17.f90 is essentially the 
code in comment #0 without the IO statement.  The backtrace
in comment #0 is caused by the assert() I removed, which is
bogus.  I think a new PR is needed.  It seems matmul is 
hosed

   integer, parameter :: a(3,2) = 1
   real, parameter :: b(2,3) = 2
   real, parameter :: c(3,3) = matmul(a,b)
   real d(3,3)
   d = matmul(a,b)
   print '(9F5.1)', c
   print '(9F5.1)', d
% gfcx -o z -fno-frontend-optimize a.f90
% ./z
  4.0  4.0  4.0  4.0  4.0  4.0  4.0  4.0  4.0
  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0

-fno-frontend-optimize is  not needed to get the above.

[Bug c++/54278] [6 regression] __attribute__((noreturn)) called from destructor when another auto-scoped variable has a non-trivial dtor erroneously fails with "control reaches end of non-void functio

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems r246314 fixed this.

[Bug c/83955] false positive implicit-fallthrough warning on switch enum

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The warning is correct for c.  The enum type is really an int in size and
space.  That is assigning 3 or 4 to it is still well defined code.

[Bug c/83955] New: false positive implicit-fallthrough warning on switch enum

[rimvydas.jas at gmail dot com]

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

Bug ID: 83955
   Summary: false positive implicit-fallthrough warning on switch
enum
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

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

Attached testcase on openSUSE and DragonFly BSD for trunk gives:

$ /opt/gcc/20180120/bin/gcc -v -Wall -Wextra -c enum_fall.c
enum_fall.c: In function 'cu_fgets':
enum_fall.c:19:3: warning: this statement may fall through
[-Wimplicit-fallthrough=]
   switch (script->type) {
   ^~
enum_fall.c:25:2: note: here
  case ST_FILE:

gcc version 7.2.1 20171224 is known to work without emitting the diagnostic.

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
The original test in comment 0 still fails at r256917 on darwin with

pr83900.f90:4:0:

print *, matmul(a, b)

internal compiler error: in fold_convert_loc, at fold-const.c:2402

Should I reopen this PR or open a new one?

[Bug lto/83954] New: LTO: Bogus -Wlto-type-mismatch warning for pointer to incomplete type

[dobonachea at lbl dot gov]

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

Bug ID: 83954
   Summary: LTO: Bogus -Wlto-type-mismatch warning for pointer to
incomplete type
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Keywords: diagnostic, lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dobonachea at lbl dot gov
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 43198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43198=edit
Source code and preprocessed output

I'm seeing bogus -Wlto-type-mismatch warnings in C for an array of pointers to
incomplete type with gcc 7.2.0 -flto.

Source files (also attached):

==> lto.h <==
struct foo;
extern struct foo *FOO_PTR;
extern struct foo *FOO_PTR_ARR[1];
extern int*INT_PTR_ARR[1];

==> lto1.c <==
#include "lto.h"

int main() { 
  // just to prevent symbol removal
  FOO_PTR = 0;
  FOO_PTR_ARR[1] = 0;
  return 0;
}

==> lto2.c <==
#include "lto.h"

struct foo {
 int x;
};
struct foo *FOO_PTR = 0;
struct foo *FOO_PTR_ARR[1] = { 0 };
int*INT_PTR_ARR[1] = { 0 };

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/pkg/gcc/7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local/pkg/gcc/7.2.0
Thread model: posix
gcc version 7.2.0 (GCC) 

$ uname -a
Linux  3.10.0-693.1.1.el7.x86_64 #1 SMP Tue Aug 15 08:36:44 CDT 2017
x86_64 x86_64 x86_64 GNU/Linux

$  gcc -pedantic -flto -fuse-linker-plugin lto1.c lto2.c
lto.h:3:20: warning: type of 'FOO_PTR_ARR' does not match original declaration
[-Wlto-type-mismatch]
 extern struct foo *FOO_PTR_ARR[1];
^
lto2.c:7:13: note: 'FOO_PTR_ARR' was previously declared here
 struct foo *FOO_PTR_ARR[1] = { 0 };
 ^
lto2.c:7:13: note: code may be misoptimized unless -fno-strict-aliasing is used

Note the warning only occurs for the array-of-pointer-to-incomplete-type, and
not for the analogous pointer-to-incomplete-type or array-of-pointer-to-int.

[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

Summary|new Throw_2 failures in |gcc sometimes generates
   |libjava under Xcode 4.0 |code that uses the buggy
   ||libgcc_s unwinder on darwin
   ||(originally exposed by
   ||Throw_2 failures in libjava
   ||testsuite under Xcode 4.0)

--- Comment #16 from Eric Gallager  ---
(In reply to Eric Gallager from comment #14)
> (In reply to Iain Sandoe from comment #13)
> > 
> > We can leave this open, but as stated,  someone should try to find a
> > non-Java reproducer.
> 
> Compromise between closing and leaving open: I'll change the status to
> SUSPENDED until there's a non-Java reproducer.

Also retitling to be more accurate

[Bug c++/54278] [6 regression] __attribute__((noreturn)) called from destructor when another auto-scoped variable has a non-trivial dtor erroneously fails with "control reaches end of non-void functio

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |6.4
Summary|__attribute__((noreturn))   |[6 regression]
   |called from destructor when |__attribute__((noreturn))
   |another auto-scoped |called from destructor when
   |variable has a non-trivial  |another auto-scoped
   |dtor erroneously fails with |variable has a non-trivial
   |"control reaches end of |dtor erroneously fails with
   |non-void function" at -O0   |"control reaches end of
   ||non-void function" at -O0

--- Comment #2 from Eric Gallager  ---
Work properly with gcc8, it looks like 6 is the only branch this bug is still
relevant for

[Bug c++/83875] [feature request] target_clones compatible SIMD capability/length check

[kretz at kde dot org]

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

--- Comment #9 from Matthias Kretz  ---
> inside multi-versioned (target_clones/target) function it depends on the 
> active target

Yes., this part is easy.

> inside a constexpr context (function/variable, your examples) or 
> always_inline function it depends on the caller

Except that a constexpr variable isn't "called". Maybe for variables a
target_clones attribute could be used. But it feels like going a bit too far.

A constexpr function without arguments would implicitly have to take a "target"
argument. I can't judge how much of a problem that would be.

[Bug tree-optimization/83940] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1531

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug target/80547] [6/7/8 Regression] nvptx back end ICE with OpenACC "reduction(OP:x)", "x = [...]"

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #3 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #0)
> Created attachment 41280 [details]
> r.c
> 
> As far as I remember, it is permissible to directly write into an
> OpenACC/OpenMP reduction variable ("x = [...]", as opposed to modifying it
> with some binary operator: "x = x OP [...]").  Looking at the attached test
> case (greatly reduced from another test case), that works (and returns the
> expected result) for the OpenMP code therein, but runs into a nvptx back end
> ICE for OpenACC, if optimizations "-O" are enabled:
> 

Using this tentative patch, the ICE is fixed and the test-case executes
successfully:
...
@@ -5354,7 +5361,8 @@ nvptx_goacc_reduction_init (gcall *call)
init = var;
}

-  gimplify_assign (lhs, init, );
+  if (lhs)
+   gimplify_assign (lhs, init, );
 }

   pop_gimplify_context (NULL);
...

[Bug tree-optimization/83940] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1531

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sat Jan 20 13:43:22 2018
New Revision: 256918

URL: https://gcc.gnu.org/viewcvs?rev=256918=gcc=rev
Log:
Fix vect_def_type handling in x86 scatter support (PR 83940)

As Jakub says in the PR, the problem here was that the x86/built-in
version of the scatter support was using a bogus scatter_src_dt
when calling vect_get_vec_def_for_stmt_copy (and had since it
was added).  The patch uses the vect_def_type from the original
call to vect_is_simple_use instead.

However, Jakub also pointed out that other parts of the load and store
code passed the vector operand rather than the scalar operand to
vect_is_simple_use.  That probably works most of the time since
a constant scalar operand should give a constant vector operand,
and likewise for external and internal definitions.  But it
definitely seems more robust to pass the scalar operand.

The patch avoids the issue for gather and scatter offsets by
using the cached gs_info.offset_dt.  This is safe because gathers
and scatters are never grouped, so there's only one statement operand
to consider.  The patch also caches the vect_def_type for mask operands,
which is safe because grouped masked operations share the same mask.

That just leaves the store rhs.  We still need to recalculate the
vect_def_type there since different store values in the group can
have different definition types.  But since we still have access
to the original scalar operand, it seems better to use that instead.

2018-01-20  Richard Sandiford  

gcc/
PR tree-optimization/83940
* tree-vect-stmts.c (vect_truncate_gather_scatter_offset): Set
offset_dt to vect_constant_def rather than vect_unknown_def_type.
(vect_check_load_store_mask): Add a mask_dt_out parameter and
use it to pass back the definition type.
(vect_check_store_rhs): Likewise rhs_dt_out.
(vect_build_gather_load_calls): Add a mask_dt argument and use
it instead of a call to vect_is_simple_use.
(vectorizable_store): Update calls to vect_check_load_store_mask
and vect_check_store_rhs.  Use the dt returned by the latter instead
of scatter_src_dt.  Use the cached mask_dt and gs_info.offset_dt
instead of calls to vect_is_simple_use.  Pass the scalar rather
than the vector operand to vect_is_simple_use when handling
second and subsequent copies of an rhs value.
(vectorizable_load): Update calls to vect_check_load_store_mask
and vect_build_gather_load_calls.  Use the cached mask_dt and
gs_info.offset_dt instead of calls to vect_is_simple_use.

gcc/testsuite/
PR tree-optimization/83940
* gcc.dg/torture/pr83940.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr83940.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug rtl-optimization/83951] [missed optimization] difference calculation for floats vs ints in a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
*** Bug 83952 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
.

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

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
We don't do ivopts for conversion into floating point types.

[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
As the preprocessed source comes from some early 5.x version (not even current
one, and 5.x is not maintained anymore anyway), can't check current trunk.
What I see in 5.x is that:
#3  0x01132085 in ggc_internal_cleared_alloc (s=18446744072616236162)
at ../../gcc/ggc.h:149
#4  0x011321ac in ggc_alloc_string (
contents=0x7ff8a5f06020
"joint_iter, usage=DINFO_USAGE_DIR_USE)
at ../../gcc/dwarf2out.c:20014

where decl_as_string for some instantiation needs almost 3GB long string and
ggc_strdup only supports strings < 2GB, as ggc_alloc_string has int length
argument and tree_string has int length field.
Supporting >= 2GB and < 4GB or even >= 4GB STRING_CSTs would be hard, making
ggc_strdup work for >= 2GB coudl mean just:
--- gcc/stringpool.c.jj 2018-01-03 10:19:55.544534019 +0100
+++ gcc/stringpool.c2018-01-20 14:28:54.452768825 +0100
@@ -70,15 +70,16 @@ alloc_node (cpp_hash_table *table ATTRIB
 const char *
 ggc_alloc_string (const char *contents, int length MEM_STAT_DECL)
 {
+  size_t len = length;
   if (length == -1)
-length = strlen (contents);
+len = strlen (contents);

-  if (!length)
+  if (!len)
 return "";

-  char *result = (char *) ggc_alloc_atomic (length + 1);
-  memcpy (result, contents, length);
-  result[length] = '\0';
+  char *result = (char *) ggc_alloc_atomic (len + 1);
+  memcpy (result, contents, len);
+  result[len] = '\0';

   return (const char *) result;
 }

But, even if it doesn't crash with this, I doubt it would actually produce any
useful debug info, except for MIPS we emit 32-bit DWARF and so .debug_str
offsets need to fit into 4GB for the whole shared library or binary.  If you
have 3GB long just a single string, I doubt you can fit the rest into 1GB. 
Perhaps don't abuse templates that much?

[Bug fortran/83953] Internal compiler error with -fcheck=bounds option on derived type components and forall construct

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-20
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (8.0). The backtrace is

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x8)
frame #0: 0x00010012a556 f951`gfc_conv_expr_val(se=0x7ffeefbfe010,
expr=0x) at trans-expr.c:7915
   7912 {
   7913   tree val;
   7914 
-> 7915   gcc_assert (expr->ts.type != BT_CHARACTER);
   7916   gfc_conv_expr (se, expr);
   7917   if (se->post.head)
   7918 {
Target 0: (f951) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x8)
  * frame #0: 0x00010012a556 f951`gfc_conv_expr_val(se=0x7ffeefbfe010,
expr=0x) at trans-expr.c:7915
frame #1: 0x00010012a6a1 f951`gfc_conv_expr_type(se=0x7ffeefbfe010,
expr=, type=0x000143e16738) at trans-expr.c:7930
frame #2: 0x0001000f4dd0 f951`gfc_conv_array_ref(se=0x7ffeefbfe2c0,
ar=0x000143923b18, expr=0x0001439238b0, where=0x000143923908) at
trans-array.c:3599
frame #3: 0x00010012b2e8
f951`::gfc_conv_variable(se=0x7ffeefbfe2c0, expr=0x0001439238b0) at
trans-expr.c:2691
frame #4: 0x00010012739b f951`gfc_conv_expr(se=0x7ffeefbfe2c0,
expr=0x0001439238b0) at trans-expr.c:7871
frame #5: 0x00010012a568 f951`gfc_conv_expr_val(se=0x7ffeefbfe2c0,
expr=) at trans-expr.c:7916
frame #6: 0x00010012a6a1 f951`gfc_conv_expr_type(se=0x7ffeefbfe2c0,
expr=, type=0x000143e16738) at trans-expr.c:7930
frame #7: 0x0001000f4b1d f951`gfc_conv_array_ref(se=0x7ffeefbfe6c0,
ar=0x000143923738, expr=0x000143923650, where=0x0001439236a8) at
trans-array.c:3582
frame #8: 0x00010012b2e8
f951`::gfc_conv_variable(se=0x7ffeefbfe6c0, expr=0x000143923650) at
trans-expr.c:2691
frame #9: 0x00010012739b f951`gfc_conv_expr(se=0x7ffeefbfe6c0,
expr=0x000143923650) at trans-expr.c:7871
frame #10: 0x0001001306b4
f951`::gfc_trans_assignment_1(expr1=0x000143922c90,
expr2=0x000143923650, init_flag=, dealloc=,
use_vptr_copy=false, may_alias=) at trans-expr.c:10039
frame #11: 0x00010016a936
f951`::gfc_trans_forall_1(code=0x000143922bc0,
nested_forall_info=0x000143901fa0) at trans-stmt.c:4626
frame #12: 0x0001000e95b8 f951`::trans_code(code=0x000143922bc0,
cond=0x) at trans.c:1972
frame #13: 0x000100119413
f951`gfc_generate_function_code(ns=) at trans-decl.c:6451
frame #14: 0x0001000ee072
f951`gfc_generate_module_code(ns=0x000144077400) at trans.c:2206
frame #15: 0x00010009a118 f951`gfc_parse_file() at parse.c:6090
frame #16: 0x00010009a073 f951`gfc_parse_file()
frame #17: 0x0001000e580c f951`::gfc_be_parse_file() at f95-lang.c:204
frame #18: 0x000100c1fd2a f951`::compile_file() at toplev.c:455
frame #19: 0x00010127f6ef f951`toplev::main(int, char**) + 2511
frame #20: 0x00010128113e f951`main + 46
frame #21: 0x7fff6d1c0115 libdyld.dylib`start + 1
frame #22: 0x7fff6d1c0115 libdyld.dylib`start + 1

[Bug c++/83921] [7/8 Regression] GCC rejects constexpr initialization of empty aggregate.

[eric at efcs dot ca]

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

--- Comment #3 from Eric Fiselier  ---
The problem also reproduces when the empty type has an explicitly defaulted
default constructor. Example:

struct Foo { Foo() = default; };
constexpr void test() { Foo f; };

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #19 from Oleg Endo  ---
Yep, that's a bug in binutils.  So let's continue it there ...
https://sourceware.org/bugzilla/show_bug.cgi?id=22737

[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Tom de Vries from comment #4)
> > Using this rudimentary workaround, I got the failing tests of this PR
> > passing again:

> Shouldn't it be sufficient to emit this only for JUMP_Ps that jump to
> immediately following LABEL_Ps (without intervening non-note insns)?

The emitted code actually looks like:
...
@ %r36 bra $L5;
// join x;
// fork x;
$L5:
...
so we'll have to skip over this pattern as well (given that the join are fork
are individual insns) .

But indeed, this is a rudimentary workaround, not a minimal one.

[Bug fortran/83953] New: Internal compiler error with -fcheck=bounds option on derived type components and forall construct

[norio.takemoto at gmail dot com]

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

Bug ID: 83953
   Summary: Internal compiler error with -fcheck=bounds option on
derived type components and forall construct
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: norio.takemoto at gmail dot com
  Target Milestone: ---

Created attachment 43197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43197=edit
Fortran source code main_t000.f90 to reproduce the issue

I encountered an `internal compiler error: Segmentation fault` when I tried to
compile a Fortran code which contains a forall construct involving derived type
components with `-fcheck=bounds` option. Some of the derived type components
are allocatable arrays. I do not see the error if I turn off the
`-fcheck=bounds` option. I saw this error with gfortran 7.2.0 on Ubuntu 17.10
and gfortran 5.4.0 on Ubuntu 16.04. 

I attach a sample code `main_t000.f90`. The problem will be reproduced by
compiling it by 

gfortran -std=f2008 -fcheck=bounds main_t000.f90

The error reads as following. 

$ gfortran -std=f2008 -fcheck=bounds main_t000.f90
main_t000.f90:49:0:

 forall(js=lbound(self%obsed_val,1):ubound(self%obsed_val,1))

internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ 

I am aware of similar bug reports such  as 
 Bug 27766 (Fortran_bounds_checking) - [meta-bug] -fbounds-check related bugs 
 Bug 81095 - fcheck=bounds and empty forall 
 Bug 36683 - -fbounds-check failure for allocated array and spread 
but I was not able to decide if the present one originates from a common
problem. I wish you could kindly look into the issue.

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo  ---
Created attachment 43196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43196=edit
binary compressed data

I have tapped lto_end_compression and dumped the compressed binary data into a
separate file.  Compiling the whole thing with -save-temps will write the
intermediate .o file.

Comparing the binary data from lto_end_compression with the binary data in the
.o file shows one byte difference at data offset 0x138A.  It should be 0x3F but
it is 0x31. Changing that single byte in the .o file and compiling it with LTO
succeeds.

So the problem is in writing the binary data to the ELF file.

The RX target uses default_elf_asm_output_ascii from varasm.c to write the
escaped strings.  Since this is also used by other targets, I guess the chance
of a bug there is low.

I remember another case from the past, where RX binutils/GCC had problems
interpreting each others' text.  Maybe that's a problem here, too.

[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Tom de Vries from comment #4)
> Using this rudimentary workaround, I got the failing tests of this PR
> passing again:
> ...
> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
> index afb0e4dd185..3ac28b3d903 100644
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -78,6 +78,7 @@
>  #include "target-def.h"
>  
>  #define WORKAROUND_PTXJIT_BUG 1
> +#define WORKAROUND_PTXJIT_BUG_2 1
>  
>  /* The various PTX memory areas an object might reside in.  */
>  enum nvptx_data_area
> @@ -4431,6 +4432,12 @@ nvptx_reorg (void)
>if (TARGET_UNIFORM_SIMT)
>  nvptx_reorg_uniform_simt ();
>  
> +#if WORKAROUND_PTXJIT_BUG_2
> +  for (rtx_insn *insn = get_insns (); insn; insn = NEXT_INSN (insn))
> +if (LABEL_P (insn))
> +  emit_insn_before (gen_fake_nop (), insn);
> +#endif
> +
>regstat_free_n_sets_and_refs ();
>  
>df_finish_pass (true);
> diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
> index f9c087b6d22..909484c329a 100644
> --- a/gcc/config/nvptx/nvptx.md
> +++ b/gcc/config/nvptx/nvptx.md
> @@ -994,6 +994,15 @@
>""
>"")
>  
> +(define_insn "fake_nop"
> +  [(const_int 1)]
> +  ""
> +  "{
> + .reg .u32 %%nop_src;
> + .reg .u32 %%nop_dst;
> + mov.u32 %%nop_dst, %%nop_src;
> +   }")
> +
>  (define_insn "return"
>[(return)]
>""
> ...

Shouldn't it be sufficient to emit this only for JUMP_Ps that jump to
immediately following LABEL_Ps (without intervening non-note insns)?

[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop

[eyalroz at technion dot ac.il]

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

--- Comment #1 from Eyal Rozenberg  ---
Also seeing this with -O3 -fno-unroll-loops -fno-tree-loop-vectorize :
https://godbolt.org/g/r2v7X8

[Bug rtl-optimization/83952] New: [missed optimization] difference calculation for floats vs ints in a loop

[eyalroz at technion dot ac.il]

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

Bug ID: 83952
   Summary: [missed optimization] difference calculation for
floats vs ints in a loop
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Created attachment 43195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43195=edit
Code exemplifying the issue

Consider the following code:

template 
void foo(T* __restrict__ a)
{
int i; T val = 0;
for (i = 0; i < 100; i++) {
val = 2 * i;
a[i] = val;
}
}

template void foo(int* __restrict__ a);
template void foo(float* __restrict__ a);

(This is based on example 7.26 in Agner Fog's Optimizing Software in C++; but
the use of C++ here is immaterial).

The int version compiles, with -O2, into:

void foo(int*):
xor eax, eax
.L2:
mov DWORD PTR [rdi], eax
add eax, 2
add rdi, 4
cmp eax, 200
jne .L2
rep ret

One would expect that the float version would compile into something similar,
except that instead of rdi we would have a floating-point register, initialized
to 0 and incremented by float 2.0 with each iteration. Instead, we get:

void foo(float*):
xor eax, eax
.L6:
pxorxmm0, xmm0
add rdi, 4
cvtsi2ssxmm0, eax
add eax, 2
movss   DWORD PTR [rdi-4], xmm0
cmp eax, 200
jne .L6
rep ret

which seems to be much slower.

Checked here: https://godbolt.org/g/t8Hvyn

[Bug rtl-optimization/83951] [missed optimization] difference calculation for floats vs ints in a loop

[eyalroz at technion dot ac.il]

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

Eyal Rozenberg  changed:

   What|Removed |Added

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

--- Comment #2 from Eyal Rozenberg  ---
Whoops, some typos. Let me redo this. Sorry.

[Bug other/83951] [missed optimization] difference calculation for floats vs ints in a loop

[eyalroz at technion dot ac.il]

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

--- Comment #1 from Eyal Rozenberg  ---
Created attachment 43194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43194=edit
Source producing the optimized (int) and unopmitized (float) object code

[Bug other/83951] New: [missed optimization] difference calculation for floats vs ints in a loop

[eyalroz at technion dot ac.il]

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

Bug ID: 83951
   Summary: [missed optimization] difference calculation for
floats vs ints in a loop
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Consider the following code:

template 
int foo(T* __restrict__ a)
{
int i; T val = 0;
for (i = 0; i < 100; i++) {
val = 2 * i;
a[i] = val;
}
}

template int foo(int* __restrict__ a);
template int foo(float* __restrict__ a);

(This is based on example 7.26 in Agner Fog's Optimizing Software in C++; but
the use of C++ here is immaterial).

The int version compiles, with -O2, into:

foo(int*):
xor eax, eax
.L2:
mov DWORD PTR [rdi], eax
add eax, 2
add rdi, 4
cmp eax, 200
jne .L2
rep ret

One would expect that the float version would compile into something similar,
except that instead of rdi we would have a floating-point register, initialized
to 0 and incremented by float 2.0 with each iteration. Instead, we get:

int foo(float*):
xor eax, eax
.L6:
pxorxmm0, xmm0
add rdi, 4
cvtsi2ssxmm0, eax
add eax, 2
movss   DWORD PTR [rdi-4], xmm0
cmp eax, 200
jne .L6
rep ret

which seems to be much slower.

Checked here: https://godbolt.org/g/RVBNyY

[Bug middle-end/83945] [7 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] internal   |[7 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault with -O  |Segmentation fault with -O
   |-fcode-hoisting |-fcode-hoisting

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

[Bug middle-end/83945] [7/8 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jan 20 09:58:31 2018
New Revision: 256916

URL: https://gcc.gnu.org/viewcvs?rev=256916=gcc=rev
Log:
PR middle-end/83945
* tree-emutls.c: Include gimplify.h.
(lower_emutls_2): New function.
(lower_emutls_1): If ADDR_EXPR is a gimple invariant and walk_tree
with lower_emutls_2 callback finds some TLS decl in it, unshare_expr
it before further processing.

* gcc.dg/tls/pr83945.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tls/pr83945.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-emutls.c

[Bug target/83930] [6/7 Regression] ICE: RTL check: expected code 'const_int', have 'mem' in simplify_binary_operation_1, at simplify-rtx.c:3302

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE: RTL |[6/7 Regression] ICE: RTL
   |check: expected code|check: expected code
   |'const_int', have 'mem' in  |'const_int', have 'mem' in
   |simplify_binary_operation_1 |simplify_binary_operation_1
   |, at simplify-rtx.c:3302|, at simplify-rtx.c:3302

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

[Bug target/83930] [6/7/8 Regression] ICE: RTL check: expected code 'const_int', have 'mem' in simplify_binary_operation_1, at simplify-rtx.c:3302

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jan 20 09:54:06 2018
New Revision: 256915

URL: https://gcc.gnu.org/viewcvs?rev=256915=gcc=rev
Log:
PR target/83930
* simplify-rtx.c (simplify_binary_operation_1) : Use
UINTVAL (trueop1) instead of INTVAL (op1).

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

Added:
trunk/gcc/testsuite/gcc.dg/pr83930.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Using the workaround, I get pretty good results:
...
Running /home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.c/c.exp
...
FAIL: libgomp.c/target-32.c (test for excess errors)
FAIL: libgomp.c/target-33.c execution test
FAIL: libgomp.c/target-34.c execution test
FAIL: libgomp.c/target-link-1.c (test for excess errors)
FAIL: libgomp.c/thread-limit-2.c (test for excess errors)
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.c++/c++.exp ...
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/fortran.exp
...
FAIL: libgomp.fortran/target2.f90   -O0  execution test
FAIL: libgomp.fortran/target2.f90   -O1  execution test
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.graphite/graphite.exp
...
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.hsa.c/c.exp ...
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-c/c.exp ...
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-c++/c++.exp
...
Running
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
...

=== libgomp Summary ===

# of expected passes8731
# of unexpected failures7
# of unresolved testcases   3
# of unsupported tests  240
...

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.0 |6.5

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for bug report.

[Bug fortran/83900] [8 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4593

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jan 20 08:29:23 2018
New Revision: 256914

URL: https://gcc.gnu.org/viewcvs?rev=256914=gcc=rev
Log:
2018-01-19  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Delete bogus assertion.

2018-01-19  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_17.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/matmul_17.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/simplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Using this rudimentary workaround, I got the failing tests of this PR passing
again:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index afb0e4dd185..3ac28b3d903 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -78,6 +78,7 @@
 #include "target-def.h"

 #define WORKAROUND_PTXJIT_BUG 1
+#define WORKAROUND_PTXJIT_BUG_2 1

 /* The various PTX memory areas an object might reside in.  */
 enum nvptx_data_area
@@ -4431,6 +4432,12 @@ nvptx_reorg (void)
   if (TARGET_UNIFORM_SIMT)
 nvptx_reorg_uniform_simt ();

+#if WORKAROUND_PTXJIT_BUG_2
+  for (rtx_insn *insn = get_insns (); insn; insn = NEXT_INSN (insn))
+if (LABEL_P (insn))
+  emit_insn_before (gen_fake_nop (), insn);
+#endif
+
   regstat_free_n_sets_and_refs ();

   df_finish_pass (true);
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index f9c087b6d22..909484c329a 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -994,6 +994,15 @@
   ""
   "")

+(define_insn "fake_nop"
+  [(const_int 1)]
+  ""
+  "{
+ .reg .u32 %%nop_src;
+ .reg .u32 %%nop_dst;
+ mov.u32 %%nop_dst, %%nop_src;
+   }")
+
 (define_insn "return"
   [(return)]
   ""
...