[Bug sanitizer/85389] posix_memalign() crash with address sanitizer when passing invalid arguments

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 18 07:02:40 2018
New Revision: 259459

URL: https://gcc.gnu.org/viewcvs?rev=259459&root=gcc&view=rev
Log:
PR sanitizer/85389
* asan/asan_allocator.h (kAllocatorSpace): For __powerpc64__ change
from 0xa00ULL to ~(uptr)0.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/asan_allocator.h

[Bug c++/84463] [6/7 Regression] Supposedly-incompliant "error: '* key0' is not a constant expression"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression]
   |Supposedly-incompliant  |Supposedly-incompliant
   |"error: '* key0' is not a   |"error: '* key0' is not a
   |constant expression"|constant expression"

--- Comment #5 from Jakub Jelinek  ---
Fixed for 8+.  Not really sure if this patch should be backported.

[Bug sanitizer/85389] posix_memalign() crash with address sanitizer when passing invalid arguments

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Oops, the above comment doesn't belong to this bug.  The commit was supposed to
fix PR85394 instead.

[Bug sanitizer/85394] [8 Regression] Unable to run sanitized executables on ppc64le Ubuntu and SLES

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 18 07:02:40 2018
New Revision: 259459

URL: https://gcc.gnu.org/viewcvs?rev=259459&root=gcc&view=rev
Log:
PR sanitizer/85389
* asan/asan_allocator.h (kAllocatorSpace): For __powerpc64__ change
from 0xa00ULL to ~(uptr)0.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/asan_allocator.h

Fixed on the trunk (though backports are still in order to release branches).

[Bug target/85445] New: [nvptx, openacc] Calls to worker and vector routine broken

[vries at gcc dot gnu.org]

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

Bug ID: 85445
   Summary: [nvptx, openacc] Calls to worker and vector routine
broken
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

og7 test-case ref-1.C fails in execution when run with trunk:
...
/* { dg-do run } */

extern "C" int printf (char const *, ...);

#pragma acc routine vector
void Vector (int *ptr,int n,const int &inc)
{
  #pragma acc loop vector
  for (unsigned ix = 0; ix < n; ix++)
ptr[ix] += inc;
}

#pragma acc routine worker
void Worker (int *ptr, int m, int n, const int &inc)
{
  #pragma acc loop worker
  for (unsigned ix = 0; ix < m; ix++)
Vector(ptr + ix * n, n, inc);
}

int main ()
{
  const int n = 32, m=32;

  int ary[m][n];
  unsigned ix,  iy;

  for (ix = m; ix--;)
for (iy = n; iy--;)
  ary[ix][iy] = (ix << 8) + iy;

#pragma acc parallel copy(ary)
  {
Worker (&ary[0][0], m, n, 1<<16);
  }

  int err = 0;

  for (ix = m; ix--;)
for (iy = n; iy--;)
  if (ary[ix][iy] != ((1 << 16) + (ix << 8) + iy))
{
  printf ("ary[%u][%u] = %x expected %x\n",
  ix, iy, ary[ix][iy], ((1 << 16) + (ix << 8) + iy));
  err++;
}

  if (err)
{
  printf ("%d failed\n", err);
  return 1;
 }

#pragma acc parallel copy(ary)
  {
Vector (&ary[0][0], m * n, (1<<24) - (1<<16));
  }

  for (ix = m; ix--;)
for (iy = n; iy--;)
  if (ary[ix][iy] != ((1 << 24) + (ix << 8) + iy))
{
  printf ("ary[%u][%u] = %x expected %x\n",
  ix, iy, ary[ix][iy], ((1 << 24) + (ix << 8) + iy));
  err++;
}

  if (err)
{
  printf ("%d failed\n", err);
  return 1;
 }

  return 0;
}
...

og7 fix was submitted here (
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01730.html ) and committed as
r239736.

[Bug c++/84630] [6/7/8 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Apr 18 08:03:45 2018
New Revision: 259460

URL: https://gcc.gnu.org/viewcvs?rev=259460&root=gcc&view=rev
Log:
/cp
2018-04-18  Paolo Carlini  

PR c++/84630
* pt.c (tsubst_lambda_expr): Check begin_lambda_type return value
for error_mark_node.

/testsuite
2018-04-18  Paolo Carlini  

PR c++/84630
* g++.dg/cpp0x/pr84630.C: New.

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

[Bug c++/84630] [6/7 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |TYPE_NAME() used on |TYPE_NAME() used on
   |error_mark_node in  |error_mark_node in
   |tsubst_lambda_expr, at  |tsubst_lambda_expr, at
   |cp/pt.c:17141   |cp/pt.c:17141

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug tree-optimization/85446] New: [7/8 Regression] wrong-code on riscv64

[jakub at gcc dot gnu.org]

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

Bug ID: 85446
   Summary: [7/8 Regression] wrong-code on riscv64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Starting with r238754 we can miscompile narrowing conversion of pointer to
integer compared against constant (unfortunately the only testcase for this I
have is for riscv64 (due to different IVOPTS decisions) which has been
introduced in r245224, so technically this is just latent bug).

Testcase for -O2 -fwrapv -fno-strict-aliasing -mabi=lp64 -march=rv64g
typedef struct
{
  void *cdr;
  void *car;
} cons_;
typedef cons_ *Cons;
typedef struct
{
  union
  {
void *_GCself;
unsigned char flags[sizeof (void *) / sizeof (unsigned char)];
  } header;
  void *symvalue;
  void *symfunction;
  void *hashcode;
  void *proplist;
  void *pname;
  void *homepackage;
} symbol_;
typedef symbol_ *Symbol;
typedef struct
{
  union
  {
void *_GCself;
unsigned char flags[sizeof (void *) / sizeof (unsigned char)];
  } header;
  signed char rectype;
  unsigned char recflags;
  unsigned char reclength;
  unsigned char recxlength;
  void *ht_maxcount;
  void *ht_kvtable;
  void *ht_lookupfn;
  void *ht_hashcodefn;
  void *ht_testfn;
  void *ht_gcinvariantfn;
  void *ht_rehash_size;
  void *ht_mincount_threshold;
  void *ht_mincount;
  void *ht_test;
  void *ht_hash;
  unsigned int ht_size;
} *Hashtable;
typedef struct
{
  union
  {
void *_GCself;
unsigned char flags[sizeof (void *) / sizeof (unsigned char)];
  } header;
  unsigned int length;
  void *hal_filler;
  void *hal_itable;
  void *hal_count;
  void *hal_freelist;
  void *hal_data[0];
} *HashedAlist;
extern void **STACK;
extern struct symbol_tab_
{
  symbol_ S_nil;
  symbol_ S_t;
} symbol_tab_data;
extern unsigned int mv_count;
extern void *mv_space[127];
void
C_hash_table_iterate (void)
{
  void *state = (STACK -= 1, STACK[0]);
  if (((unsigned long) state) & (1UL << 62))
{
  void *table = ((Cons) ((void *) ((unsigned long) state & ((1UL << 56) -
1->car;
  while (1)
{
  unsigned int index = (unsigned long) ((unsigned long) Cons)
((void *) ((unsigned long) state & ((1UL << 56) - 1->cdr)) & ((2UL << 55) -
1));
  if (index == 0)
break;
  ((Cons) ((void *) ((unsigned long) state & ((1UL << 56) - 1->cdr
= ((void *) ((unsigned char *) Cons) ((void *) ((unsigned long) state &
((1UL << 56) - 1->cdr)) + (long) (-1)));
  {
void **KVptr = &((HashedAlist) ((void *) ((unsigned long) table &
((1UL << 56) - 1->hal_data[3 * index - 3];
if (!(KVptr[0] == (void *) 0x38000FFUL))
  {
mv_space[0] = (void *) ((unsigned char *)
(&symbol_tab_data.S_t) + (1UL << 58));
mv_space[1] = KVptr[0];
mv_space[2] = KVptr[1];
mv_count = 3;
return;
  }
  }
}
}
  mv_space[0] = (void *) ((unsigned char *) (&symbol_tab_data.S_nil) + (1UL <<
58));
  mv_count = 1;
}

The difference between cddce3 and forwprop4 shows the bug:
   unsigned int index;
...
   void * prephitmp_40;
...
[local count: 1073741825]:
   # prephitmp_40 = PHI 
   # ivtmp.14_36 = PHI 
   index_46 = (unsigned int) prephitmp_40;
-  if (index_46 == 0)
+  if (prephitmp_40 == 0B)
 goto ; [5.50%]
   else
 goto ; [94.50%]

The original was comparing only the low 32-bits of the pointer against 0, the
modified code compares the whole pointer against NULL.

[Bug tree-optimization/85446] [7/8 Regression] wrong-code on riscv64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

[Bug tree-optimization/85446] [7/8 Regression] wrong-code on riscv64

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Created attachment 43973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43973&action=edit
Unreduced test-case

Unfortunately I see one more ICE (reduced from Firefox w/ -O3). I'm currently
reducing that, but hopefully will be possible to debug for unreduced version.

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
(In reply to Martin Liška from comment #12)
> Created attachment 43973 [details]
> Unreduced test-case
> 
> Unfortunately I see one more ICE (reduced from Firefox w/ -O3). I'm
> currently reducing that, but hopefully will be possible to debug for
> unreduced version.

$ ./xg++ -B. -O3 -c ~/Downloads/ice.ii 

/home/marxin/Downloads/ice.ii:5441:214: internal compiler error: in
create_specialized_node, at ipa-cp.c:3870
 already_AddRefed
nsImageLoadingContent::GetCurrentRequestFinalURI() {   nsCOMPtr uri;  
if (mCurrentRequest) { mCurrentRequest->GetFinalURI(getter_AddRefs(uri));  
}   return uri.forget(); }
   
   
  ^
0x1624b99 create_specialized_node
../../gcc/ipa-cp.c:3870
0x16252a2 decide_about_value
../../gcc/ipa-cp.c:4699
0x1626440 decide_whether_version_node
../../gcc/ipa-cp.c:4743
0x1626440 ipcp_decision_stage
../../gcc/ipa-cp.c:4906
0x1626440 ipcp_driver
../../gcc/ipa-cp.c:5086

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[marxin at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug other/84613] [meta-bug] SPEC compiler performance issues

[marxin at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[marxin at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 18 08:47:26 2018
New Revision: 259461

URL: https://gcc.gnu.org/viewcvs?rev=259461&root=gcc&view=rev
Log:
PR target/81084
* config.gcc: Obsolete powerpc*-*-*spe*.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

[Bug ipa/85447] New: [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[marxin at gcc dot gnu.org]

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

Bug ID: 85447
   Summary: [8 Regression] ICE in create_specialized_node, at
ipa-cp.c:3870 since r259319
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

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

Comes from Firefox with -O3:

$ ./xg++ -B. -O3 -c ~/Downloads/ice.ii 

/home/marxin/Downloads/ice.ii:5441:214: internal compiler error: in
create_specialized_node, at ipa-cp.c:3870
 already_AddRefed
nsImageLoadingContent::GetCurrentRequestFinalURI() {   nsCOMPtr uri;  
if (mCurrentRequest) { mCurrentRequest->GetFinalURI(getter_AddRefs(uri));  
}   return uri.forget(); }
   
   
  ^
0x1624b99 create_specialized_node
../../gcc/ipa-cp.c:3870
0x16252a2 decide_about_value
../../gcc/ipa-cp.c:4699
0x1626440 decide_whether_version_node
../../gcc/ipa-cp.c:4743
0x1626440 ipcp_decision_stage
../../gcc/ipa-cp.c:4906
0x1626440 ipcp_driver
../../gcc/ipa-cp.c:5086

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[marxin at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[marxin at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|8.0.1   |

--- Comment #14 from Martin Liška  ---
New ICE has a new PR85447.

[Bug other/84613] [meta-bug] SPEC compiler performance issues

[marxin at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2018-4-18
Version|unknown |8.0.1
  Known to fail||8.0.1

[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from Richard Biener  ---
Patch was reverted.

[Bug middle-end/85382] code compiled with fno-builtin uses builtin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
__powidf2 is provided by libgcc.a and thus available.  -fno-builtin is not
intended to prevent GCC from emitting calls to its runtime.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #26 from Jakub Jelinek  ---
Port is now obsolete, will be removed in GCC9 unless sufficient maintenance is
provided.

[Bug rtl-optimization/85390] possible missed optimisation / regression from 6.3 with conditional expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|tree-optimization   |rtl-optimization

--- Comment #1 from Richard Biener  ---
I think we statically predict the test to be non-even and thus avoid the cmov. 
Not sure if current cores still prefer branches over cmov for well-predicted
branches.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libstdc++/85442] [8 Regression] cxx11-ios_failure.lo build fails for microblaze

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Can be reproduced even on x86_64-linux with
CXXFLAGS='-g -O2 -D_GNU_SOURCE -gno-as-loc-support'
cxx11-ios_failure-lt.s: Assembler messages:
cxx11-ios_failure-lt.s: Fatal error: duplicate .debug_line sections
make: *** [Makefile:766: cxx11-ios_failure.lo] Error 1

Otherwise it just creates duplicate debug info.

[Bug c++/80290] [6/7/8 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[6/7 Regression] g++ uses   |[6/7/8 Regression] g++ uses
   |unreasonable amount of  |unreasonable amount of
   |memory compiling nested |memory compiling nested
   |string maps |string maps

--- Comment #24 from Richard Biener  ---
While memory use improved the testcase in comment#10 still shows substantial
increase in memory and time for each added init element:

1.24user 0.04system 0:01.28elapsed 100%CPU (0avgtext+0avgdata
170772maxresident)k
1.49user 0.07system 0:01.56elapsed 99%CPU (0avgtext+0avgdata
206396maxresident)k
0inputs+0outputs (0major+50914minor)pagefaults 0swaps
1.70user 0.05system 0:01.76elapsed 100%CPU (0avgtext+0avgdata
233904maxresident)k

so we improved some constant factor but didn't really address the underlying
issue.

Numbers from before the patch (on a loaded system, sorry) were

3.87user 0.10system 0:04.33elapsed 91%CPU (0avgtext+0avgdata
235760maxresident)k
0inputs+0outputs (0major+54479minor)pagefaults 0swaps
5.23user 0.16system 0:06.06elapsed 88%CPU (0avgtext+0avgdata
283860maxresident)k
0inputs+0outputs (0major+64971minor)pagefaults 0swaps
6.17user 0.15system 0:06.90elapsed 91%CPU (0avgtext+0avgdata
323796maxresident)k
0inputs+0outputs (0major+74942minor)pagefaults 0swaps

[Bug libstdc++/85396] _M_t._M_emplace_hint_unique

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm

--- Comment #1 from Richard Biener  ---
It works for me with 6.2.0, 6.3.0 and 6.4.0 on x86_64-linux.

[Bug go/85429] Several gotools tests FAIL with Solaris as

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Ian Lance Taylor  ---
> Does the SPARC Solaris assembler support a syntax like
>
> .section ".go.buildid",#exclude
>
> ?  That's what gas seems to support for compatibility.

It does indeed.  I didn't think to look into gas docs because I couldn't
find anything in the Solaris SPARC assembler manual.

> Does that syntax work for x86?

Almost: you need

.section .go.buildid,#exclude

It's weird that they use the sparc synatx in this case instead of the
common "e" flag.

One caveat, though: #exclude wasn't present in the original Solaris 10
assemblers.  However, both the current ones and the Solaris 11
assemblers do support it.  While I'll handle this when adding
SHF_EXCLUDE support with Solaris as to gcc proper, I don't know if I
care enough about those ancient systems...

[Bug fortran/85448] New: the compiler selects the wrong subroutine because of bind(c,name=...)

[francois.jacq at irsn dot fr]

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

Bug ID: 85448
   Summary: the compiler selects the wrong subroutine because of
bind(c,name=...)
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.jacq at irsn dot fr
  Target Milestone: ---

In the following example, the subroutine c_open of the module m2, which should
call the subroutine odopen of the module m1, calls itself instead...

Tested with gcc 4.9.2 , 5.3.0, 6.3.0

result :

dev005{bug} 114 : gfortran -c m1.f90 m2.f90
dev005{bug} 114 : gcc main.c *.o -lgfortran
dev005{bug} 114 : ./a.out
c_odopen
c_odopen
c_odopen
...

module m1
   implicit none
   contains
   subroutine odopen(unit)
  integer,intent(out) :: unit
  write(*,*) 'odopen'
  unit=8
   end subroutine
end module

module m2
   use iso_c_binding
   use m1
   implicit none
   contains
   subroutine c_odopen(unit) bind(c,name="odopen")
  integer(c_int),intent(out) :: unit
  write(*,*) 'c_odopen'
  call odopen(unit)
   end subroutine
end module

#include 
void odopen(int*);
int main(){
   int unit;
   odopen(&unit);
   printf("unit=%d \n",unit);
   return 0;
}

[Bug other/85398] g++ reports "array subscript is above array bounds" when it cannot be sure

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
This is the simple case of GCC optimizing the access to a constant:

   [50.00%]:
  max.0_11 = max;
  if (max.0_11 > 1)
goto ; [50.00%]
  else
goto ; [50.00%]

   [25.00%]:
  _13 = right[0];
  left[1] = _13;

   [50.00%]:
  return;

and we warn for the case of max > 1.

Similarly we warn for

int bar () { return left[2]; }

even if we can't prove that bar() is actually executed.

We could change the warning to have a "may be above array bounds" form
for your case but that wouldn't handle the bar() case.

[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 18 09:46:58 2018
New Revision: 259462

URL: https://gcc.gnu.org/viewcvs?rev=259462&root=gcc&view=rev
Log:
PR jit/85384
* acx.m4 (GCC_BASE_VER): Remove \$\$ from sed expression.

* configure.ac (gcc-driver-name.h): Honor --with-gcc-major-version
by using gcc_base_ver to generate a gcc_driver_version, and use
it when generating GCC_DRIVER_NAME.
* configure: Regenerate.

* configure: Regenerate.

Modified:
trunk/config/ChangeLog
trunk/config/acx.m4
trunk/fixincludes/ChangeLog
trunk/fixincludes/configure
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/libada/ChangeLog
trunk/libada/configure
trunk/libatomic/ChangeLog
trunk/libatomic/configure
trunk/libcc1/ChangeLog
trunk/libcc1/configure
trunk/libffi/ChangeLog
trunk/libffi/configure
trunk/libgcc/ChangeLog
trunk/libgcc/configure
trunk/libgfortran/ChangeLog
trunk/libgfortran/configure
trunk/libgomp/ChangeLog
trunk/libgomp/configure
trunk/libhsail-rt/ChangeLog
trunk/libhsail-rt/configure
trunk/libitm/ChangeLog
trunk/libitm/configure
trunk/libmpx/ChangeLog
trunk/libmpx/configure
trunk/libobjc/ChangeLog
trunk/libobjc/configure
trunk/liboffloadmic/ChangeLog
trunk/liboffloadmic/configure
trunk/liboffloadmic/plugin/configure
trunk/libquadmath/ChangeLog
trunk/libquadmath/configure
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/configure
trunk/libssp/ChangeLog
trunk/libssp/configure
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libvtv/ChangeLog
trunk/libvtv/configure
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/configure

[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Richard prefered David's patch and we have some sed invocations that expect
s/something.*// to match everything until end of line in gcc/Makefile.in, so if
some sed versions don't do it, it would break other things.

So, fixed for GCC8+ so far, should be backported to 7 at some point.

[Bug lto/85405] [6/7 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

[Bug tree-optimization/85406] Unnecessary blend when vectorizing short-cutted calculations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-18
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I don't see any vectorization being done on the testcase.  Please specify the
GCC version you tested as well as the command-line flags and eventually
complete the testcase (there's no loop here?).

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Jambor  ---
Confirmed and I guess mine.

[Bug other/85398] g++ reports "array subscript is above array bounds" when it cannot be sure

[patrickdepinguin at gmail dot com]

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

--- Comment #3 from Thomas De Schampheleire  
---
(In reply to Richard Biener from comment #2)
> 
> We could change the warning to have a "may be above array bounds" form
> for your case but that wouldn't handle the bar() case.

The problem with giving warnings about potential-but-not-definite issues is
that projects that compile with '-Wall -Werror' assume zero warnings to guard
quality.

But if some warnings are false-positives, this strategy no longer works. The
project will fail to compile even though it is perfectly fine.

You'd need a way to tell gcc that this code is fine, or put such cases in a
separate warning category that is not included in Wall or can be disabled
explicitly.

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Reduced test-case:

typedef int a;
enum b : a;
class c {
public:
  enum { d };
  virtual b e(int *, int, const int *) = 0;
};
class f : c {
  b e(int *, int, const int *);
  b g();
};
b f::e(int *h, int i, const int *j) {
  if (i == d)
return g();
  for (;;)
e(h, i, j);
}
int k;
c *l;
void m() { l->e(&k, c::d, nullptr); }

[Bug rtl-optimization/85409] [8/9 Regression] ICE in alloc_succs_info, at sel-sched-ir.c:4730

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Priority|P3  |P2
   Target Milestone|8.0 |9.0
Summary|[8 Regression] ICE in   |[8/9 Regression] ICE in
   |alloc_succs_info, at|alloc_succs_info, at
   |sel-sched-ir.c:4730 |sel-sched-ir.c:4730

[Bug c++/84611] [6/7/8 Regression] ICE in operator[], at vec.h:826 (local_class_index())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
On it.

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Priority|P3  |P2
   Target Milestone|--- |9.0
Summary|[8 Regression] ICE in   |[8/9 Regression] ICE in
   |put_TImodes, at |put_TImodes, at
   |sel-sched.c:7191|sel-sched.c:7191

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Martin Jambor  ---
The problem here is that IPA-CP clones node cgraph_edge Notify/1680
which has a speculative self-recursive edge.  Because it now needs to
make sure that eventually clones of such edges call the node clone and
not the original node (while the original edge is not redirected and
still leads to the original node), it takes such edges out of
redirect_callers and stores in a vector to deal with post-cloning.

Normally, after create_virtual_clone returns, it walks this vector,
finds clones of these self-recursive edges in array next_edge_clone
because that is where they are linked by ipcp_edge_duplication_hook,
and redirects the clone.

However, in this case, before create_virtual_clone returns
ipa_fn_summary_t::duplicate is invoked and it re-evaluates edge
predicates, during which it decides the edge is impossible, which
leads to speculation resolution removing the new edge, clone,
ipcp_edge_removal_hook being invoked which deletes it from the linked
list of edge clones and subsequently ipa-cp code not finding it there.



Breakpoint 6, ipcp_edge_removal_hook (cs=
Notify/1680>)
at /home/mjambor/gcc/icln/src/gcc/ipa-cp.c:3435
3435  grow_edge_clone_vectors ();
(gdb) bt
#0  ipcp_edge_removal_hook (cs=
Notify/1680>)
at /home/mjambor/gcc/icln/src/gcc/ipa-cp.c:3435
#1  0x00be7669 in symbol_table::call_edge_removal_hooks
(this=0x767aa100, 
e= Notify/1680>) at
/home/mjambor/gcc/icln/src/gcc/cgraph.c:329
#2  0x00be8e66 in cgraph_edge::remove (this= Notify/1680>)
at /home/mjambor/gcc/icln/src/gcc/cgraph.c:1028
#3  0x00be94c0 in cgraph_edge::resolve_speculation (
this= Notify/1680>, 
callee_decl=)
at /home/mjambor/gcc/icln/src/gcc/cgraph.c:1200
#4  0x00eb8f97 in redirect_to_unreachable (e= Notify/1680>)
at /home/mjambor/gcc/icln/src/gcc/ipa-fnsummary.c:239
#5  0x00eb90a0 in edge_set_predicate (e= Notify/1680>, 
predicate=0x7fffd680) at
/home/mjambor/gcc/icln/src/gcc/ipa-fnsummary.c:267
#6  0x00eba5ef in ipa_fn_summary_t::duplicate (this=0x7fffe7c702a0, 
src=, 
dst=,
info=0x7fffe7c54e70)
at /home/mjambor/gcc/icln/src/gcc/ipa-fnsummary.c:714
#7  0x00ec7339 in function_summary::symtab_duplication
(
node=, 
node2=,
data=0x7fffe7c702a0)
at /home/mjambor/gcc/icln/src/gcc/symbol-summary.h:189
#8  0x00be7b2c in symbol_table::call_cgraph_duplication_hooks
(this=0x767aa100, 
node=, 
node2=)
at /home/mjambor/gcc/icln/src/gcc/cgraph.c:495
#9  0x00c04800 in cgraph_node::create_virtual_clone (
this=, redirect_callers=...,
tree_map=0x7fffee721370, 
args_to_skip=0x7fffef8570c0, suffix=0x24396e0 "constprop")
at /home/mjambor/gcc/icln/src/gcc/cgraphclones.c:618
#10 0x01bf5341 in create_specialized_node (node=, 
known_csts=..., known_contexts=..., aggvals=0x0, callers=...)
at /home/mjambor/gcc/icln/src/gcc/ipa-cp.c:3863

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
flags?  A simple ./xgcc -fopenacc doesn't reproduce it.  With my GCC 7 install
I see

lto-wrapper: fatal error: problem with building target image for nvptx-none

but no way to see the lto1 invocations :/ (tried -Wl,-debug -Wl,-v already)

[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Recent regression, so P1-ish.

[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #2)
> Recent regression, so P1-ish.

True, but requires the -fselective-scheduling* -fvar-tracking-assignments
combination, which explicitly warns that it doesn't work properly (and doesn't)
and I think people rarely use either of those options and even less likely both
of them together.

[Bug c/85427] ICE in constant_lower_bound, at poly-int.h:1527

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
I think Richard had a patch for this or a related issue.

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
I guess the best fix is to move the clone-redirecting logic to
cgraph::create_clone.

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 43975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43975&action=edit
libgomp.log

[Bug ipa/85449] New: [8 Regression] Wrong specialization is called in self recursive functions after r259319

[tnfchris at gcc dot gnu.org]

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

Bug ID: 85449
   Summary: [8 Regression] Wrong specialization is called in self
recursive functions after r259319
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

After commit r259319 IPA seems to be calling the wrong specialized function.

The testcase comes from the following library
https://github.com/akheron/jansson, specifically this file
https://github.com/akheron/jansson/blob/master/src/dump.c

I have not been able to reduce it yet as I have no real easy way to check when
it does the replacement wrong but I have attached a `.i` file and issue can be
reproduced using it by using `-Ofast` or `-O3`.

This is what I have been able to tell so far. The issue is caused by a self
recursive call in the function

static int do_dump(const json_t *json, size_t flags, int depth,
   json_dump_callback_t dump, void *data)

where json_dump_callback_t dump is a function pointer to local functions. There
are only two call sites for do_dump other than itself.

char *json_dumps(const json_t *json, size_t flags)
{
strbuffer_t strbuff;
char *result;

if(strbuffer_init(&strbuff))
return NULL;

if(json_dump_callback(json, dump_to_strbuffer, (void *)&strbuff, flags))
result = NULL;
else
result = jsonp_strdup(strbuffer_value(&strbuff));


strbuffer_close(&strbuff);
return result;

}


int json_dumpf(const json_t *json, FILE *output, size_t flags)

{
return json_dump_callback(json, dump_to_file, (void *)output, flags);
}

where dump_to_strbuffer expects to write into a memory buffer and dump_to_file
writing to an actual file.

So IPA decides to create 8 specializations for this function (whereas before
this patch it created 4.), it creates them by amongst others inlining the calls
to these two dump callbacks, and eventually even inlines the callbacks
themselves.

The problematic specialization occurs for the function {{do_dumps}} which has
amonst others

.LVL289:
.loc 1 368 24
fmovx4, d8
mov x3, x19
mov w2, 1
mov x1, x21
bl  do_dump

The first specialization occurs when a helper function {{dump_indent}} is
inline, creating {{do_dumps.constprop.4}} which is supposed to still take the
callbacks as arguments.

and indeed looking at the assembly is shows

json_dumps:
...
.L260:
adrpx2, dump_to_strbuffer
mov x1, x20
mov x0, x19
add x3, sp, 40

.LVL440:
add x2, x2, :lo12:dump_to_strbuffer
bl  do_dump.constprop.4


so far so good. But the recursive call to do_dump in the specialized
constprop.4 version inexplicably calls do_dump.constprop.5 in some (2 out of
the many) cases.

Where do_dump.constprop.5 is a more specialized version of constprop.4 which
also inlined the dump_to_file function.

do_dump.constprop.5:
...
add x0, x0, :lo12:.LC14
mov x1, 4
bl  fwrite

So the initial callback which is passed is dump_to_strbuffer is ignored and a
call to dump_to_file is essentially made. causing a segfault.

The first place this seems to go wrong is `.i.075i.cp`

looking at the dependencies of `constprop.4/82` which is supposed to be the
generic clone

do_dump.constprop.4/82 (do_dump.constprop) @0x7ff4280128a0
  ...

  Calls: json_integer_value/55 (119292717 (estimated locally),0.11 per call)
snprintf/56 (119292717 (estimated locally),0.11 per call) json_real_value/57
(119292717 (estimated locally),0.11 per call) jsonp_dtostr/58 (119292717
(estimated locally),0.11 per call) json_string_value/59 (119292717 (estimated
locally),0.11 per call) dump_string/39 (119292717 (estimated locally),0.11 per
call) json_array_size/60 (116799499 (estimated locally),0.11 per call)
dump_indent.constprop/85 (56497842 (estimated locally),0.05 per call)
json_array_get/61 (341791464 (estimated locally),0.32 per call)
do_dump.constprop/83 (341791464 (estimated locally),0.32 per call)
dump_indent.constprop/85 (244621272 (estimated locally),0.23 per call)
dump_indent/38 (70872647 (estimated locally),0.07 per call) json_object_iter/62
(116799499 (estimated locally),0.11 per call) dump_indent.constprop/85
(79811293 (estimated locally),0.07 per call) json_object_size/63 (26063814
(estimated locally),0.02 per call) jsonp_malloc/64 (26063814 (estimated
locally),0.02 per call) jsonp_object_iter_fullkey/65 (209930993 (estimated
locally),0.20 per call) json_object_iter_next/66 (209930993 (estimated
locally),0.20 per call) __assert_fail/67 (10379 (estimated loc

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Created attachment 43976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43976&action=edit
compile.log

-save-temps -v output. Contains lto1 invocation.

[Bug c++/85444] asm specifier on typedef silently ignored

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
For a start, patches go to the mailing list, not in bugzilla :-)

https://gcc.gnu.org/contribute.html

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Created attachment 43978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43978&action=edit
configure lines

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #15 from Tamar Christina  ---
Hi All,

I created a new issue PR85449 that occurs after this change. IPA seems to be
mixing up some of the recursive calls in a specialized function causing an
invalid code path.

[Bug target/85436] [7 Regression] ICE compiling go code with -mcpu=power9

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||7.3.1

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64
 Status|UNCONFIRMED |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Only snapshots though a release (candiate) is not far away.

[Bug ipa/85449] [8 Regression] Wrong specialization is called in self recursive functions after r259319

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
 CC||mjambor at suse dot cz
Version|8.0 |8.0.1
 Ever confirmed|0   |1
  Known to fail||8.0.1

[Bug c++/85441] Empty loops not optimised away

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Confirmed with -fsyntax-only, generating code doesn't change things much.

[Bug libstdc++/85442] [8 Regression] cxx11-ios_failure.lo build fails for microblaze

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug target/85443] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|Xstormy16   |stormy16

--- Comment #1 from Richard Biener  ---
GCC 5.5 is no longer maintained, please try a newer version, preferably GCC 7.3
or a snapshot from trunk (GCC 8).

[Bug c++/85444] asm specifier on typedef silently ignored

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
 Ever confirmed|0   |1

[Bug c++/85444] asm specifier on typedef silently ignored

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Btw, it could maybe used to adjust mangling... (in C++, that is).

[Bug tree-optimization/85446] [7/8 Regression] wrong-code on riscv64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ipa/85449] [8 Regression] Wrong specialization is called in self recursive functions after r259319

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug c++/85396] _M_t._M_emplace_hint_unique

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-18
  Component|libstdc++   |c++
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Also works fine at https://godbolt.org/g/xfSvy5 with:
GNU C++11 (crosstool-NG crosstool-ng-1.23.0) version 6.3.0
(arm-unknown-linux-gnueabi)


So this might be due to a patch backported to Debian's GCC, and would need to
be reported to Debian.

It's certainly not a libstdc++ bug because the preprocessed source compiles
fine on i686-linux.


(In reply to microprogs from comment #0)
> // C++11: ERROR, cannot compile
> //g++ -std=c++11 -o test test.cpp
> //
> // C++14: OK
> //g++ -std=c++14 -o test test.cpp
> //
> // old C++: OK
> //g++ -o test test.cpp

N.B. this is not "old C++" this is -std=gnu++14, because that's the default in
GCC 6.x

[Bug ipa/85447] [8 Regression] ICE in create_specialized_node, at ipa-cp.c:3870 since r259319

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Created attachment 43979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43979&action=edit
Untested WIP fix

I have to leave office for a few hours, I'm attaching an untested fix I have so
far.  I will continue with it after I try to reproduce PR 85449 (which on the
face of it looks more sinister).

[Bug libstdc++/84442] FAIL: 30_threads/thread/cons/terminate.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 18 11:15:38 2018
New Revision: 259463

URL: https://gcc.gnu.org/viewcvs?rev=259463&root=gcc&view=rev
Log:
PR libstdc++/84442 if _Exit isn't declared then use _exit instead

PR libstdc++/84442
* testsuite/30_threads/thread/cons/terminate.cc
[!_GLIBCXX_USE_C99_STDLIB] : Use _exit or std::exit instead of _Exit.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc

[Bug libstdc++/84442] FAIL: 30_threads/thread/cons/terminate.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Thanks, this should be fixed on trunk now.

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #7 from Tom de Vries  ---
(In reply to Richard Biener from comment #3)
> flags?  A simple ./xgcc -fopenacc doesn't reproduce it.  With my GCC 7
> install I see
> 
> lto-wrapper: fatal error: problem with building target image for nvptx-none
> 
> but no way to see the lto1 invocations :/ (tried -Wl,-debug -Wl,-v already)

I ran into the same problem when trying to use an installed compiler. Fixed by
adding -B options for:
- the dir containing accel/nvptx-none/mkoffload
- the dir containing the offload gcc (in my case,
  x86_64-pc-linux-gnu-accel-nvptx-none-gcc)

So:
...
$ ./install/bin/x86_64-pc-linux-gnu-gcc \
  -fopenacc \
  src/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85422.c \
  -B $(pwd -P)/install/offload-nvptx-none/bin \
  -B $(pwd -P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1
...

The error message could certainly be be better.

[Bug libstdc++/85442] [7/8 Regression] cxx11-ios_failure.lo build fails for microblaze

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.4
Summary|[8 Regression]  |[7/8 Regression]
   |cxx11-ios_failure.lo build  |cxx11-ios_failure.lo build
   |fails for microblaze|fails for microblaze

--- Comment #3 from Joseph S. Myers  ---
Appears on GCC 7 branch as well as the patch was backported there (my bot only
rebuilds release branch compilers weekly, so it was slower to show the failure
there).

https://sourceware.org/ml/libc-testresults/2018-q2/msg00078.html

[Bug c++/85441] Empty loops not optimised away

[sebastian321123 at interia dot pl]

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

--- Comment #3 from sebastian321123 at interia dot pl ---
I am afraid that nothing changes with optimisation flags. I am getting the same
results for -O1, -O2, -O3 and -Os

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Author: hubicka
Date: Wed Apr 18 11:29:26 2018
New Revision: 259464

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

PR lto/85391
* lto.c (lto_read_decls): Do not test TYPE_CANONICAL before registering
odr
types.
* g++.dg/lto/pr83121_0.C: Update template.
* g++.dg/lto/pr83121_1.C: Update template.
* g++.dg/lto/pr84805_0.C: Update template.
* g++.dg/lto/pr84805_1.C: Update template.
* g++.dg/lto/pr84805_2.C: Update template.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/pr83121_0.C
trunk/gcc/testsuite/g++.dg/lto/pr83121_1.C
trunk/gcc/testsuite/g++.dg/lto/pr84805_0.C
trunk/gcc/testsuite/g++.dg/lto/pr84805_1.C
trunk/gcc/testsuite/g++.dg/lto/pr84805_2.C

[Bug libstdc++/85442] [7/8 Regression] cxx11-ios_failure.lo build fails for microblaze

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Yes, the branch will need the same fix.

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Apr 18 11:42:10 2018
New Revision: 259465

URL: https://gcc.gnu.org/viewcvs?rev=259465&root=gcc&view=rev
Log:
[ARM] Fix PR85261: ICE with FPSCR setter builtin

Instruction pattern for setting the FPSCR expects the input value to be
in a register. However, __builtin_arm_set_fpscr expander does not ensure
that this is the case and as a result GCC ICEs when the builtin is
called with a constant literal.

This commit fixes the builtin to force the input value into a register.
It also remove the unneeded volatile in the existing fpscr test and
fixes the function prototype.

2018-04-18  Thomas Preud'homme  

Backport from mainline
2018-04-11  Thomas Preud'homme  

gcc/
PR target/85261
* config/arm/arm-builtins.c (arm_expand_builtin): Force input operand
into register.

gcc/testsuite/
PR target/85261
* gcc.target/arm/fpscr.c: Add call to __builtin_arm_set_fpscr with
literal value.  Expect 2 MCR instruction.  Fix function prototype.
Remove volatile keyword.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm-builtins.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/fpscr.c

[Bug libgcc/85379] Missing ENDBR in __stack_split_initialize

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
 CC||igor.v.tsimbalist at intel dot 
com
   ||, ubizjak at gmail dot com
 Ever confirmed|0   |1

[Bug middle-end/85450] New: ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[rguenth at gcc dot gnu.org]

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

Bug ID: 85450
   Summary: ICE: invalid types in nop conversion during GIMPLE
pass: ompexp
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I see

Running target unix//-m32
FAIL: libgomp.c/for-3.c (internal compiler error)
FAIL: libgomp.c/for-3.c (test for excess errors)
UNRESOLVED: libgomp.c/for-3.c compilation failed to produce executable
FAIL: libgomp.c/for-5.c (internal compiler error)
FAIL: libgomp.c/for-5.c (test for excess errors)
UNRESOLVED: libgomp.c/for-5.c compilation failed to produce executable
FAIL: libgomp.c/for-6.c (internal compiler error)
FAIL: libgomp.c/for-6.c (test for excess errors)
UNRESOLVED: libgomp.c/for-6.c compilation failed to produce executable
FAIL: libgomp.c++/for-11.C (internal compiler error)
FAIL: libgomp.c++/for-11.C (test for excess errors)
UNRESOLVED: libgomp.c++/for-11.C compilation failed to produce executable
FAIL: libgomp.c++/for-13.C (internal compiler error)
FAIL: libgomp.c++/for-13.C (test for excess errors)
UNRESOLVED: libgomp.c++/for-13.C compilation failed to produce executable
FAIL: libgomp.c++/for-14.C (internal compiler error)
FAIL: libgomp.c++/for-14.C (test for excess errors)
UNRESOLVED: libgomp.c++/for-14.C compilation failed to produce executable

with the following fix for the r177828 change:

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 259457)
+++ gcc/tree-cfg.c  (working copy)
@@ -3842,7 +3842,7 @@ verify_gimple_assign_unary (gassign *stm
|| (POINTER_TYPE_P (rhs1_type)
&& INTEGRAL_TYPE_P (lhs_type)
&& (TYPE_PRECISION (rhs1_type) >= TYPE_PRECISION (lhs_type)
-   || ptrofftype_p (sizetype
+   || ptrofftype_p (lhs_type
  return false;

/* Allow conversion from integral to offset type and vice versa.  */

One example is

/space/rguenther/src/svn/trunk/libgomp/testsuite/libgomp.c/for-2.h: In function
'f13_dpf_guided32':^M
/space/rguenther/src/svn/trunk/libgomp/testsuite/libgomp.c/for-2.h:193:10:
error: invalid types in nop conversion^M
long long unsigned int^M
int[1500] *^M
D.13174 = (long long unsigned int) D.13222;^M

so we're casting a 32bit pointer to a 64bit int which we don't allow since
we do not know how to extend the pointer at the GIMPLE level (we really
don't want to use POINTERS_EXTEND_UNSIGNED there but rely on TYPE_UNSIGNED).
The question is what the ompexp code wants here anyway.

The fix is to do an intermediate conversion to a pointer-sized integral type.

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
For for-3.c it is:

static void
expand_omp_for_static_nochunk (struct omp_region *region,
   struct omp_for_data *fd,
   gimple *inner_stmt)
{ 
...
  if (POINTER_TYPE_P (type))
t = fold_build_pointer_plus (n1, t); 
  else
t = fold_build2 (PLUS_EXPR, type, t, n1);
  t = fold_convert (TREE_TYPE (startvar), t);

where a fix could be to do

Index: omp-expand.c
===
--- omp-expand.c(revision 259457)
+++ omp-expand.c(working copy)
@@ -3501,7 +3501,10 @@ expand_omp_for_static_nochunk (struct om
   t = fold_convert (itype, s0);
   t = fold_build2 (MULT_EXPR, itype, t, step);
   if (POINTER_TYPE_P (type))
-t = fold_build_pointer_plus (n1, t);
+{
+  t = fold_build_pointer_plus (n1, t);
+  t = fold_convert (unsigned_type_for (TREE_TYPE (n1)), t);
+}
   else
 t = fold_build2 (PLUS_EXPR, type, t, n1);
   t = fold_convert (TREE_TYPE (startvar), t);

but there are likely a few "copies" of the code.  The for-3.c testcase
also exercises the following spot:

@@ -3515,7 +3518,10 @@ expand_omp_for_static_nochunk (struct om
   t = fold_convert (itype, e0);
   t = fold_build2 (MULT_EXPR, itype, t, step);
   if (POINTER_TYPE_P (type))
-t = fold_build_pointer_plus (n1, t);
+{
+  t = fold_build_pointer_plus (n1, t);
+  t = fold_convert (unsigned_type_for (TREE_TYPE (n1)), t);
+}
   else
 t = fold_build2 (PLUS_EXPR, type, t, n1);
   t = fold_convert (TREE_TYPE (startvar), t);

and that's still not enough to fix it fully...

Note that I think even for GENERIC using fold_convert the original way
is wrong.  Given fold_convert is "interesting" we might consider using
POINTERS_EXTEND_UNSIGNED there... (ok, I didn't suggest that).

[Bug libstdc++/85442] [7/8 Regression] cxx11-ios_failure.lo build fails for microblaze

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 18 12:14:58 2018
New Revision: 259467

URL: https://gcc.gnu.org/viewcvs?rev=259467&root=gcc&view=rev
Log:
PR libstdc++/85442 fix duplicate debuginfo for cxx11-ios_failure.cc

2018-04-18  Jonathan Wakely  
Jakub Jelinek  

PR libstdc++/85442
* src/c++11/Makefile.am: Don't generate debuginfo again for
cxx11-ios_failure-lt.s and cxx11-ios_failure.s files.
* src/c++11/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/Makefile.am
trunk/libstdc++-v3/src/c++11/Makefile.in

[Bug lto/85451] New: [offloading] Improve lto-wrapper error message when not finding mkoffload

[vries at gcc dot gnu.org]

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

Bug ID: 85451
   Summary: [offloading] Improve lto-wrapper error message when
not finding mkoffload
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When using an installed host/offloading compiler, you may run into this error
message:
...
$ ./install/bin/x86_64-pc-linux-gnu-gcc -fopenacc test.c
lto-wrapper: fatal error: problem with building target image for nvptx-none

compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

This means that mkoffload could not be found.

By providing -B with the path to accel/nvptx-none/mkoffload, we get past the
rror:
...
$ ./install/bin/x86_64-pc-linux-gnu-gcc -fopenacc test.c \
  -B $(pwd -P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1
mkoffload: fatal error: offload compiler
x86_64-pc-linux-gnu-accel-nvptx-none-gcc not found
compilation terminated.
lto-wrapper: fatal error:
/home/vries/oacc/trunk/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

And by providing another -B with the path to
x86_64-pc-linux-gnu-accel-nvptx-none-gcc, we finally succeed:
...
$ ./install/bin/x86_64-pc-linux-gnu-gcc -fopenacc test.c \
  -B $(pwd -P)/install/offload-nvptx-none/bin \
  -B$(pwd -P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1
$
...

From the last error message, it's easy to figure out that
x86_64-pc-linux-gnu-accel-nvptx-none-gcc cannot be found (though it doesn't
suggest using -B to fix that).

But from the first error message, it's impossible to know what's going wrong
without stepping with gdb through lto-wrapper.

[Bug lto/85451] [offloading] Improve lto-wrapper error message when not finding mkoffload

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 43980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43980&action=edit
Tentative patch

[Bug lto/85451] [offloading] Improve lto-wrapper error message when not finding mkoffload

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> Created attachment 43980 [details]
> Tentative patch

Improved error message:
...
$ ./install/bin/x86_64-pc-linux-gnu-gcc -fopenacc test.c
lto-wrapper: fatal error: could not find accel/nvptx-none/mkoffload in
/home/vries/oacc/trunk/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/:/home/vries/oacc/trunk/install/bin/../libexec/gcc/
(use -B?)

compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
(In reply to Tom de Vries from comment #7)
> (In reply to Richard Biener from comment #3)
> > flags?  A simple ./xgcc -fopenacc doesn't reproduce it.  With my GCC 7
> > install I see
> > 
> > lto-wrapper: fatal error: problem with building target image for nvptx-none
> > 
> > but no way to see the lto1 invocations :/ (tried -Wl,-debug -Wl,-v already)
> 

> The error message could certainly be be better.

Filed as PR85451 - "[offloading] Improve lto-wrapper error message when not
finding mkoffload"

[Bug lto/85451] [offloading] Improve lto-wrapper error message when not finding mkoffload

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> ...
> $ ./install/bin/x86_64-pc-linux-gnu-gcc -fopenacc test.c \
>   -B $(pwd
> -P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1
> mkoffload: fatal error: offload compiler
> x86_64-pc-linux-gnu-accel-nvptx-none-gcc not found
> compilation terminated.
> lto-wrapper: fatal error:
> /home/vries/oacc/trunk/install/offload-nvptx-none/libexec/gcc/x86_64-pc-
> linux-gnu/8.0.1//accel/nvptx-none/mkoffload returned 1 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> ...

> From the last error message, it's easy to figure out that
> x86_64-pc-linux-gnu-accel-nvptx-none-gcc cannot be found (though it doesn't
> suggest using -B to fix that).

Which is fixed by:
...
diff --git a/gcc/config/nvptx/mkoffload.c b/gcc/config/nvptx/mkoffload.c
index c0093909448..097446c5db6 100644
--- a/gcc/config/nvptx/mkoffload.c
+++ b/gcc/config/nvptx/mkoffload.c
@@ -454,7 +454,7 @@ main (int argc, char **argv)

   if (!found)
 fatal_error (input_location,
-"offload compiler %s not found", GCC_INSTALL_NAME);
+"offload compiler %s not found (use -B?)", GCC_INSTALL_NAME);

   /* We may be called with all the arguments stored in some file and
  passed with @file.  Expand them into argv before processing.  */
...

which gives us:
...
$ ./install/bin/x86_64-pc-linux-gnu-gcc -fopenacc test.c -B$(pwd
-P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1 
mkoffload: fatal error: offload compiler
x86_64-pc-linux-gnu-accel-nvptx-none-gcc not found (use -B?)
compilation terminated.
lto-wrapper: fatal error:
/home/vries/oacc/trunk/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/8.0.1//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
 Ever confirmed|0   |1

--- Comment #9 from Richard Biener  ---
Confirmed with GCC7.

> gcc-7 t.c -fopenacc
In function 'main._omp_fn.0':
lto1: internal compiler error: Segmentation fault
0x7b2d3f crash_signal
../../gcc/toplev.c:337
0x4a1056 flow_loops_find(loops*)
../../gcc/cfgloop.c:456
0x6cc63b input_cfg
../../gcc/lto-streamer-in.c:844
...

adjusted patch:

Index: gcc/lto-streamer-out.c
===
--- gcc/lto-streamer-out.c  (revision 259467)
+++ gcc/lto-streamer-out.c  (working copy)
@@ -2077,6 +2077,9 @@ output_function (struct cgraph_node *nod
  debug info.  */
   if (gimple_has_body_p (function))
 {
+  /* Fixup loops if required to match discovery done in the reader.  */
+  loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
+
   streamer_write_uhwi (ob, 1);
   output_struct_function_base (ob, fn);

@@ -2134,6 +2137,7 @@ output_function (struct cgraph_node *nod

   output_cfg (ob, fn);

+  loop_optimizer_finalize ();
   pop_cfun ();
}
   else

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[lh_mouse at 126 dot com]

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

Liu Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #21 from Liu Hao  ---
This comment could be important:



> mstorsjo commented 10 days ago
> However, this only seems to be an issue when passing such variables by value. 
> Local variables seem to be properly aligned even with GCC:

If the `__m256` in question in the original post was made to pass by reference,
the crash would go away. From the assembly code following that reply we can
also conclude that, it is not the impossibility of realigning the stack during
run time that is the issue (because RSP was aligned in that snippet of code and
I believe that code was correct). It is GCC does not realign the stack at all
that is the issue.

[Bug libstdc++/85442] [7/8 Regression] cxx11-ios_failure.lo build fails for microblaze

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 18 13:13:29 2018
New Revision: 259468

URL: https://gcc.gnu.org/viewcvs?rev=259468&root=gcc&view=rev
Log:
PR libstdc++/85442 fix duplicate debuginfo for cxx11-ios_failure.cc

2018-04-18  Jonathan Wakely  
Jakub Jelinek  

PR libstdc++/85442
* src/c++11/Makefile.am: Don't generate debuginfo again for
cxx11-ios_failure-lt.s and cxx11-ios_failure.s files.
* src/c++11/Makefile.in: Regenerate.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.am
branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.in

[Bug libstdc++/85442] [7/8 Regression] cxx11-ios_failure.lo build fails for microblaze

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Should be fixed for 7.4 and 8.1

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Apr 18 13:17:30 2018
New Revision: 259469

URL: https://gcc.gnu.org/viewcvs?rev=259469&root=gcc&view=rev
Log:
[ARM] Fix PR85261: ICE with FPSCR setter builtin

Instruction pattern for setting the FPSCR expects the input value to be
in a register. However, __builtin_arm_set_fpscr expander does not ensure
that this is the case and as a result GCC ICEs when the builtin is
called with a constant literal.

This commit fixes the builtin to force the input value into a register.
It also remove the unneeded volatile in the existing fpscr test and
fixes the function prototype.

2018-04-18  Thomas Preud'homme  

Backport from mainline
2018-04-11  Thomas Preud'homme  

gcc/
PR target/85261
* config/arm/arm-builtins.c (arm_expand_builtin): Force input operand
into register.

gcc/testsuite/
PR target/85261
* gcc.target/arm/fpscr.c: Add call to __builtin_arm_set_fpscr with
literal value.  Expect 2 MCR instruction.  Fix function prototype.
Remove volatile keyword.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/arm-builtins.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/fpscr.c

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.4.1
 Resolution|--- |FIXED
  Known to fail|6.4.1   |6.4.0

--- Comment #7 from Thomas Preud'homme  ---
Fixed in all release branches.

[Bug libstdc++/85439] mt19937_64 producing unexpected result only in certain configuration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-18
 Ever confirmed|0   |1

[Bug target/85220] [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Filed:
- PR85221 "[openacc] ICE in install_var_field, at omp-low.c:657" 
- PR85445 "[nvptx, openacc] Calls to worker and vector routine broken" 
and updated a few existing PRs.

There are lots of execution failures due to OpenACC patches not being ported
from og7 to trunk, but for the purposes of this investigation I'm only
interested in missing nvptx patches.

Marking resolved-fixed.

[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects

[hyrosen at mail dot com]

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

hyrosen at mail dot com changed:

   What|Removed |Added

 CC||hyrosen at mail dot com

--- Comment #9 from hyrosen at mail dot com ---
The storage for an object can still be accessible after the object is
destroyed.  Therefore, writes in the destructor should not be eliminated unless
they are provably inaccessible:

struct X { int i; ~X() { i = 0; } };

void destroy(X &x) { x.~X(); }

int main()
{
alignas(X) char buf[sizeof(X)], save[sizeof(X)];
X *x = new (buf) X;
x->i = 1;
memcpy(save, buf, sizeof(X));
destroy(*x);
assert(memcmp(buf, save, sizeof(X)) != 0);
}

[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to hyrosen from comment #9)
> The storage for an object can still be accessible after the object is
> destroyed.  Therefore, writes in the destructor should not be eliminated
> unless they are provably inaccessible:
> 
> struct X { int i; ~X() { i = 0; } };
> 
> void destroy(X &x) { x.~X(); }
> 
> int main()
> {
> alignas(X) char buf[sizeof(X)], save[sizeof(X)];
> X *x = new (buf) X;
> x->i = 1;
> memcpy(save, buf, sizeof(X));
> destroy(*x);
> assert(memcmp(buf, save, sizeof(X)) != 0);
> }

No, that invokes UB.

[Bug libstdc++/85439] mt19937_64 producing unexpected result only in certain configuration

[foddex at foddex dot net]

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

--- Comment #1 from Marc "Foddex" Oude Kotte  ---
When one adds std::hex output formatting for the first four std::cout calls,
for example the first line would then look like:

std::cout << "32 bits gen, uint32_t: " << std::hex <<
generateRandom() <<
std::endl;

The output on MSVC and OSX becomes:
32 bits gen, uint32_t: d091bb5c
32 bits gen, uint64_t: d091bb5c22ae9ef6
64 bits gen, uint32_t: f6f6aea6
64 bits gen, uint64_t: c96d191cf6f6aea6

And the output on Linux becomes:
32 bits gen, uint32_t: d091bb5c
32 bits gen, uint64_t: d091bb5c22ae9ef6
64 bits gen, uint32_t: c96d191d
64 bits gen, uint64_t: c96d191cf6f6aea6

A number of observations:
- on line 3, MSVC + OSX seem to return the lower 32 bits of line 4
- on line 3, Linux seems to return the upper 32 bits of line 4, with 1 added
But:
- on line 1, everybody just seems to return the upper 32 bits of line 2

I am at a loss who is right here.

[Bug demangler/85452] New: Stack-Overflow in nm-new / C++ name demangler (binuitils-2.30-15ubuntu1)

[sergej at schumilo dot de]

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

Bug ID: 85452
   Summary: Stack-Overflow in nm-new / C++ name demangler
(binuitils-2.30-15ubuntu1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergej at schumilo dot de
  Target Milestone: ---

Dear all,
according to the bintutils maintainers the following stack-overflow bug is in
the C++ name demangler (instead of the binutils application nm-new), which is
part of the libiberty library. 

This is the original binutils bug report
(https://sourceware.org/bugzilla/show_bug.cgi?id=23058):

-

Dear all,
after reporting the following bugs to the Ubuntu security team
(https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1763099), we were
asked to report them directly to the binutils developers: 



Dear all,
The following binutils nm-new Stack-Overflow was found by a modified version of
the kAFL fuzzer (https://github.com/RUB-SysSec/kAFL). I have attached the
crashing input and an ASAN report.

Steps to reproduce:

Build current verison of binutils:
```
pull-lp-source binutils
cd binutils-2.30
CC=clang CXX=clang++ CFLAGS="-fsanitize=address -fsanitize-recover=address
-ggdb" CXXFLAGS="-fsanitize=address -fsanitize-recover=address -ggdb"
LDFLAGS="-fsanitize=address" ./configure
CC=clang CXX=clang++ CFLAGS="-fsanitize=address -fsanitize-recover=address
-ggdb" CXXFLAGS="-fsanitize=address
-fsanitize-recover=address -ggdb" LDFLAGS="-fsanitize=address" make
```

Run inputs under ASAN:

```
ASAN_OPTIONS=halt_on_error=true:allow_addr2line=true ./nm-new a -C -l
--synthetic $file
```

We can verify this issue for nm-new binuitils-2.30-15ubuntu1 (Ubuntu 16.04.4
LTS / sources from "pull-lp-source bintuils").

Credits: Sergej Schumilo, Cornelius Aschermann (both of Ruhr-Universität
Bochum)

Best regards,
Sergej Schumilo

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
(In reply to Wilco from comment #4)
> Clearly rematerialization isn't working correctly. Immediates and constant
> addresses like this should never be spilled (using MOV/MOVK could increase
> codesize, but with -Os you should use the literal pool anyway). Check
> legitimate_constant_p returns true, see
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00052.html for how it's done
> on AArch64.

By the time LRA happens, this is what LRA sees of the address computation:

(insn 321 6 322 2 (set (reg:SI 274)
(unspec:SI [
(symbol_ref:SI ("__stack_chk_guard") [flags 0xc0] )
] UNSPEC_PIC_SYM)) "test_arm_sp_fpic.c":41 181
{pic_load_addr_32bit}
 (expr_list:REG_EQUIV (unspec:SI [
(symbol_ref:SI ("__stack_chk_guard") [flags 0xc0] )
] UNSPEC_PIC_SYM)
(nil)))
(insn 322 321 11 2 (set (reg/f:SI 175)
(mem:SI (plus:SI (reg:SI 176)
(reg:SI 274)) [0  S4 A32])) "test_arm_sp_fpic.c":41 876
{*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 274)
(expr_list:REG_DEAD (reg:SI 176)
(expr_list:REG_EQUIV (symbol_ref:SI ("__stack_chk_guard") [flags
0xc0] )
(nil)

It is this 175 which is spilled because LRA sees it doesn't have a register of
the right class to allocate that pseudo. Because it's a MEM it doesn't see it
as a constant expression and thus does not rematerialize it.

[Bug demangler/85453] New: OOM-Bug in cxxfilt / C++ name demangler (binuitils-2.30-15ubuntu1)

[sergej at schumilo dot de]

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

Bug ID: 85453
   Summary: OOM-Bug in cxxfilt / C++ name demangler
(binuitils-2.30-15ubuntu1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergej at schumilo dot de
  Target Milestone: ---

Dear all,
according to the bintutils maintainers the following OOM-bug is in the C++ name
demangler (instead of the binutils application cxxfilt), which is part of the
libiberty library. 

This is the original binutils bug report
(https://sourceware.org/bugzilla/show_bug.cgi?id=23059):

-

Dear all,
after reporting the following bugs to the Ubuntu security team
(https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1763101), we were
asked to report them directly to the binutils developers: 



Dear all,
The following binutils cxxfilt OOM bug was found by a modified version of the
kAFL fuzzer (https://github.com/RUB-SysSec/kAFL). I have attached the input and
an ASAN report.

Steps to reproduce:

Build current verison of binutils:

```
pull-lp-source binutils
cd binutils-2.30
CC=clang CXX=clang++ CFLAGS="-fsanitize=address -fsanitize-recover=address
-ggdb" CXXFLAGS="-fsanitize=address -fsanitize-recover=address -ggdb"
LDFLAGS="-fsanitize=address" ./configure
CC=clang CXX=clang++ CFLAGS="-fsanitize=address -fsanitize-recover=address
-ggdb" CXXFLAGS="-fsanitize=address
-fsanitize-recover=address -ggdb" LDFLAGS="-fsanitize=address" make
```

Run inputs under ASAN:

```
ASAN_OPTIONS=halt_on_error=false:allow_addr2line=true ./cxxfilt -t < oom
```

We can verify this issue for cxxfilt binuitils-2.30-15ubuntu1 (Ubuntu 16.04.4
LTS / sources from "pull-lp-source bintuils") on an Intel(R) Core(TM) i7-6700
CPU @ 3.40GHz server machine with 32GB RAM.

Credits: Sergej Schumilo, Cornelius Aschermann (both of Ruhr-Universität
Bochum)

Best regards,
Sergej Schumilo