[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[rguenth at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end
   Target Milestone|--- |5.5
Summary|Incorrect behaviour at -O0  |[5/6/7/8 Regression]
   |(conditional operator)  |Incorrect behaviour at -O0
   ||(conditional operator)

--- Comment #9 from Richard Biener  ---
(In reply to Marek Polacek from comment #8)
> I wonder if I could just
> 
> --- a/gcc/fold-const.c
> +++ b/gcc/fold-const.c
> @@ -3401,14 +3401,14 @@ operand_equal_for_comparison_p (tree arg0, tree
> arg1, tree other)
>  
>primarg1 = get_narrower (arg1, &unsignedp1);
>primother = get_narrower (other, &unsignedpo);
> +  tree type = TREE_TYPE (arg0);
>  
>correct_width = TYPE_PRECISION (TREE_TYPE (arg1));
>if (unsignedp1 == unsignedpo
> +  && TYPE_PRECISION (TREE_TYPE (primarg1)) == TYPE_PRECISION (type)
>&& TYPE_PRECISION (TREE_TYPE (primarg1)) < correct_width
>&& TYPE_PRECISION (TREE_TYPE (primother)) < correct_width)
>  {
> -  tree type = TREE_TYPE (arg0);
> -
>/* Make sure shorter operand is extended the right way
>  to match the longer operand.  */
>primarg1 = fold_convert (signed_or_unsigned_type_for
> 
> so far it seems to work.

Looks a bit too conservative to me, without explanation what exactly goes wrong
here.  The code might be confused where it does the extension.

Are there any testcases that break when we change operand_equal_for_comparison
to just do operand_equal_p?

[Bug libgomp/81768] [8 Regression] error: control flow in the middle of basic block

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #2 from Tom de Vries  ---
[ Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01362.html ]

AFAIU, because while minimizing I removed the '#pragma omp declare target'
around the global declarations, this is an ice-on-invalid-code.

[Bug c++/81860] [7/8 Regression] Call to undefined inline function involving inheriting constructors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3
Summary|Call to undefined inline|[7/8 Regression] Call to
   |function involving  |undefined inline function
   |inheriting constructors |involving inheriting
   ||constructors

[Bug c/81874] New: [6.3/6.4][mips]internal compiler error: in do_SUBST, at combine.c:725

[zwzhangwen.zhang at huawei dot com]

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

Bug ID: 81874
   Summary: [6.3/6.4][mips]internal compiler error: in do_SUBST,
at combine.c:725
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zwzhangwen.zhang at huawei dot com
  Target Milestone: ---

mips-sde-elf-gcc -O2 -w test.i -S
test.i: In function 'func_1':
test.i:2438:1: internal compiler error: in do_SUBST, at combine.c:725
 }
 ^
0xd7424d do_SUBST
gcc-6.3.0/gcc/combine.c:725
0xd8328e subst
gcc-6.3.0/gcc/combine.c:5435
0xd84fa1 try_combine
gcc-6.3.0/gcc/combine.c:3274
0xd8aefd combine_instructions
gcc-6.3.0/gcc/combine.c:1475
0xd8aefd rest_of_handle_combine
gcc-6.3.0/gcc/combine.c:14370
0xd8aefd execute
gcc-6.3.0/gcc/combine.c:14413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

gcc version 6.3.0 /6.4.0

I have checked gcc-7.1.0 and that's ok because of commit NO.
ad010d47fc7bf4d598eb113c286c265b266094be
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ad010d47fc7bf4d598eb113c286c265b266094be
It do deleting redundant expr, but if using -fno-code_hoisting, ICE can be
found.
I doubt that cse1 pass has some problem and record reg 196 equal to const
-2147483648 in EQ jump_insn.   

testcase is as follows:
static long int
(safe_add_func_int32_t_s_s)(long int si1, long int si2 )
{
  return (((si1>0) && (si2>0) && (si1 > (0x7fffL -si2))) || ((si1<0) &&
(si2<0) && (si1 < ((-0x7fffL - 1)-si2 ?((si1)) :(si1 + si2);
}

static short unsigned int
(safe_mod_func_uint16_t_u_u)(short unsigned int ui1, short unsigned int ui2 )
{
  return (ui2 == 0) ? ((ui1)) : (ui1 % ui2);
}

g_71;
*g_723;
long long int func_34 (long unsigned int, long unsigned int, unsigned char,
long int *, short unsigned int);
func_1 ()
{
func_34 (0, 0, safe_add_func_int32_t_s_s (1 && g_71, *g_723), 0, 0);
}

long long int
func_34 (long unsigned int p_35, long unsigned int p_36, unsigned char p_37,
long int * p_38,
 short unsigned int p_39)
{
*p_38 = safe_mod_func_uint16_t_u_u (++*g_723, p_37);
}

[Bug c/81875] New: omp for loop optimized away

[vries at gcc dot gnu.org]

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

Bug ID: 81875
   Summary: omp for loop optimized away
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01329.html ]

Test-case from PR81805 comment 3, expanded to be runnable:
...
extern void abort (void);

#define N 32ULL
int a[N];

const unsigned long long c = 0x7fffULL;

void
f2_tpf_static32 (void)
{
  unsigned long long i;
  #pragma omp for
  for (i = c + N; i > c; i -= 1ULL)
a[i - 1ULL - c] -= 4;
}

__attribute__((noinline, noclone)) int
test_tpf_static32 (void)
{
  int i, j, k;
  for (i = 0; i < N; i++)
a[i] = i - 25;

  f2_tpf_static32 ();

  for (i = 0; i < N; i++)
if (a[i] != i - 29)
  return 1;

  return 0;
}

int
main ()
{
  if (test_tpf_static32 ())
abort ();

  return 0;
}
...

Passes with fno-openmp, fails with fopenmp.

With fopenmp, the for loop is optimized away.

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.3

[Bug c/81875] omp for loop optimized away

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Tom de Vries  ---
[ redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01359.html ]

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00848.html

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Looks like self-tests fail.  Was there a way to disable those?

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
[ Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01333.html, using PR81875
instead of PR81844, since PR81844 was overwritten ]

Filed comment 3 as PR81875 - omp for loop optimized away

This PR remains for the analysis of the test-case from comment 0.

[Bug c++/81867] Internal completer error: Segmentation Fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
GCC 4.9 is no longer maintained, please try with a newer version, at least GCC
5.4.

[Bug c++/81868] Internal completer error: Segmentation Fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
.

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

[Bug c++/81867] Internal completer error: Segmentation Fault

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
*** Bug 81868 has been marked as a duplicate of this bug. ***

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug sanitizer/81870] -fsanitize=undefined doesn't pay attention to __builtin_assume_aligned()

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Petr from comment #2)
> I see, so if I understand it correctly then:
> 
> 1. `__builtin_assume_aligned()` should be used to promote the type to a
> higher than natural alignment, for example 16 bytes for easier
> auto-vectorization.
> 
> 2. `__attribute__((aligned(N)))` should be used to relax alignment of native
> types to lower than natural alignment.
> 
> It's interesting that with `__builtin_assume_aligned()` I achieved basically
> the same effect as with `__attribute__((aligned(N))`, just the sanitizer is
> not happy.
> 
> Interestingly, I thought that __builtin_assume_aligned() is basically
> equivalent to `__assume_aligned()` provided by Intel and MS compilers.
> 
> Anyway thanks for your answer, I need to fix my code a bit.

__builtin_assume_aligned cannot be used to decrease alignment or make unaligned
accesses valid.  I didn't know __assume_aligned by Intel and MS does that.

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
This is a reduced test case that triggers with gcc-4.9 and higher (latest
tested is 7.1.1)

$ arm-linux-gnueabi-gcc-7.1.1 -mword-relocations -march=armv7-a -O2 -Wall -c
test-ww_mutex.c
$ objdump -dr test-ww_mutex.o | grep MOV
4c: R_ARM_MOVW_ABS_NC   c
50: R_ARM_MOVT_ABS  c

---
int a, d, f;
long b;
struct ww_class {
  int stamp;
} c;
struct stress {
  int locks;
  int nlocks;
};
void *e;
int atomic_add_return_relaxed(int *p1) {
  __builtin_prefetch(p1);
  return a;
}
void atomic_long_inc_return_relaxed(int *p1) {
  int *v = p1;
  atomic_add_return_relaxed(v);
}
void ww_acquire_init(struct ww_class *p1) {
  atomic_long_inc_return_relaxed(&p1->stamp);
}
void ww_mutex_lock();
int *get_random_order();
void stress_inorder_work() {
  struct stress *g = e;
  int h = g->nlocks;
  int *i = &g->locks, *j = get_random_order();
  do {
int n;
ww_acquire_init(&c);
  retry:
for (n = 0; n < h; n++)
  ww_mutex_lock(i[j[n]]);
f = n;
if (d)
  goto retry;
  } while (b);
}

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Nope, nothing breaks.  It occurred to me that we might get rid of it when I
found out that the code comes from rms, 1992.  :)

[Bug c/81876] New: [7 Regression] bogus -Wstrict-overflow warning with -O3

[bunk at stusta dot de]

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

Bug ID: 81876
   Summary: [7 Regression] bogus -Wstrict-overflow warning with
-O3
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bunk at stusta dot de
  Target Milestone: ---

Testcase based on an xbubble build error on Debian:

$ cat test.c
struct _Bubble {
  int color;
};
typedef struct _Bubble * Bubble;

typedef enum {
  EAST=0,
  NORTH_EAST,
  NORTH_WEST,
  WEST,
  SOUTH_WEST,
  SOUTH_EAST
} Quadrant;

struct _CellArray {
  Bubble cell[(8 * 12)];
  int first_row;
};
typedef struct _CellArray * CellArray;

void cell_array_lower( CellArray ca ) {
  int i;

  for ( i = ( ca->first_row*8 ); i < ( ca->first_row*8 ) + 8; i++ )
ca->cell[i] = ((void *)0);
}
$ gcc-6 -O2 -Wall -Werror -c test.c
$ gcc-6 -O3 -Wall -Werror -c test.c
$ gcc -O2 -Wall -Werror -c test.c
$ gcc -O3 -Wall -Werror -c test.c
test.c: In function ‘cell_array_lower’:
test.c:25:17: error: assuming signed overflow does not occur when assuming that
(X + c) >= X is always true [-Werror=strict-overflow]
 ca->cell[i] = ((void *)0);
 ^
cc1: all warnings being treated as errors
$


It works when replacing the "+ 8" in the loop condition with a variable whose
value is not known at compile time.

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 17 Aug 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81814
> 
> Marek Polacek  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
>Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
> gnu.org
> 
> --- Comment #10 from Marek Polacek  ---
> Nope, nothing breaks.  It occurred to me that we might get rid of it when I
> found out that the code comes from rms, 1992.  :)

I'm all for it - maybe you can do one further verification step in
instrumenting the number of cases it triggers during bootstrap?
Might be a bit awkward to only detect the cases where an actual
transform happens ...

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Sure, let me see.

[Bug fortran/81877] New: [7 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 81877
   Summary: [7 Regression] Incorrect results with lto and -fipa-cp
and -fipa-cp-clone
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

Created attachment 41991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41991&action=edit
the program which reproduce the bug

with gcc >=7.0 (7.1.0 ,7.2.0 ) this program gives incorrect results with '-O2
-fipa-cp -fipa-cp-clone -flto'.
I have reproduced this bug in Linux-64bit , MinGW-64bit ,Cygwin-64bit .

I tried my best to minimize the program to reproduce the bug.

[Bug c/81783] -Wtautological-compare could do better

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Posted: .

[Bug middle-end/81876] [7/8 Regression] bogus -Wstrict-overflow warning with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||diagnostic
   Last reconfirmed||2017-08-17
  Component|c   |middle-end
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[7 Regression] bogus|[7/8 Regression] bogus
   |-Wstrict-overflow warning   |-Wstrict-overflow warning
   |with -O3|with -O3
   Target Milestone|--- |7.3

--- Comment #1 from Richard Biener  ---
This is the loop distribution generated size argument to memcpy:

   [15.00%]:
  _1 = ca_7(D)->first_row;
  i_8 = _1 * 8;
  _13 = _1 + 1;
  _14 = _13 * 8;
  _17 = (unsigned int) _14;
  _2 = (unsigned int) i_8;
  _3 = _17 - _2;
  _5 = _3 + 4294967295;
  _4 = (sizetype) _5;
  _12 = _4 + 1;
  _11 = _12 * 8;
  _18 = i_8 < _14 ? _11 : 8;
  _19 = _1 * 8;
  _20 = (sizetype) _19;
  _21 = _20 * 8;
  _22 = ca_7(D) + _21;
  __builtin_memset (_22, 0, _18);

which later during forwprop which sees

   [15.00%]:
  _1 = ca_7(D)->first_row;
  i_8 = _1 * 8;
  _14 = i_8 + 8;
  _18 = i_8 < _14 ? 64 : 8;
  _19 = _14 - 8;
  _20 = (sizetype) _19;
  _21 = _20 * 8;
  _22 = ca_7(D) + _21;
  __builtin_memset (_22, 0, _18);

is optimized i_8 < i_8 + 8 -> 1 to

   [15.00%]:
  _1 = ca_7(D)->first_row;
  i_8 = _1 * 8;
  _14 = i_8 + 8;
  _18 = 64;
  _19 = i_8;
  _20 = (sizetype) i_8;
  _21 = _20 * 8;
  _22 = ca_7(D) + _21;
  __builtin_memset (_22, 0, _18);

this warning is somewhat fragile in that it triggers quite randomly and also
on compiler-generated intermediate code in case it gets a location.

Also warns on trunk.

I suppose we should look into niter analysis why it generates that conditional
and/or make sure niter generated GENERIC ends up with TREE_NO_WARNING set
and/or no location.

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
The __builtin_prefetch() that caused the problem in the test case from comment
2 might be a red herring, I already noticed earlier that the bug shows up both
in configurations that use a built-in function and an inline assembler version
of the same. I reduced the other one as well now, coming to almost the same
reduced source:

int a, e, f, g, h;
struct ww_class {
  int stamp;
} c;
struct stress {
  int locks;
  int nlocks;
} d;
void *i;
int fn1(int *p1) {
  void *b = p1;
  __asm__("" ::"p"(b));
  return a;
}
void fn2(int *p1) {
  int *v = p1;
  fn1(v);
}
void fn3(struct ww_class *p1) { fn2(&p1->stamp); }
void fn4();
void fn5() {
  struct stress *j = i;
  int k = j->nlocks;
  int *l = &j->locks;
  do {
fn3(&c);
  retry:
for (g = 0; g < k;)
  fn4(l[e], d);
f = g;
if (h)
  goto retry;
  } while (!0);
}

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||wrong-code
   Last reconfirmed||2017-08-17
  Component|fortran |ipa
 CC||marxin at gcc dot gnu.org,
   ||mliska at suse dot cz,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[7 Regression] Incorrect|[7/8 Regression] Incorrect
   |results with lto and|results with lto and
   |-fipa-cp and -fipa-cp-clone |-fipa-cp and -fipa-cp-clone
   Target Milestone|--- |7.3
  Known to fail||7.1.0, 8.0

--- Comment #1 from Richard Biener  ---
Confirmed.  With -O3 -fipa-cp-clone -fipa-cp -flto it works (I think -O3
already enables those).

Fails with -O[12] -fwhole-program -fipa-cp -fipa-cp-clone  (no -flto needed).

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[yroux at gcc dot gnu.org]

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

Yvan Roux  changed:

   What|Removed |Added

 CC||yroux at gcc dot gnu.org

--- Comment #4 from Yvan Roux  ---
My quick understanding is that to prevent LRA generating invalid high/lo_sum
code, arm_valid_symbolic_address_p (introduced at r227129) needs to be
strengthen and check that target_word_relocations is not defined when an addend
is present.

I'll prepare a patch for that shortly.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[andrewm.roberts at sky dot com]

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

--- Comment #2 from Andrew Roberts  ---
I can confirm gcc 7.2.0 builds ok on x86-64, arm and aarch64 with
--enable-gather-detailed-mem-stats. 

So its just 8.0.0 which is failing.

[Bug ada/81878] New: --disable-bootstrap --enable-languages=c,ada fails

[rguenth at gcc dot gnu.org]

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

Bug ID: 81878
   Summary: --disable-bootstrap --enable-languages=c,ada fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The ada tools build requires ../../xg++ which isn't there.  I suppose some
automatic language enablement is missing (usually C++ is a bootstrap language).
 This also means an Ada cross requires a C++ target compiler!?

Eventually the above xg++ should be really the host C++ compiler?

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||enkovich.gnu at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
Started with r237844 which is not IPA-related. Let me dig in..

[Bug ada/81878] --disable-bootstrap --enable-languages=c,ada fails

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
In a cross build that would use the build tools, see TOOLS_FLAGS_TO_PASS_NATIVE
vs TOOLS_FLAGS_TO_PASS_CROSS.

[Bug c/81785] Segmentation fault for signed overflow in index expression when -fwrapv is enabled

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Re-adding richi's comment.  I'm going to try the following.

--- Comment #3 from Richard Biener  ---
We emit

int k = -2147483648;
  return x + ((sizetype) ((long unsigned int) k * 4) + 18446744065119617028);

and it seems we end up zero-extending k.  I believe that's because of the
(premature) optimization in pointer_int_sum:

  /* If what we are about to multiply by the size of the elements
 contains a constant term, apply distributive law
 and multiply that constant term separately.
 This helps produce common subexpressions.  */
  if ((TREE_CODE (intop) == PLUS_EXPR || TREE_CODE (intop) == MINUS_EXPR)
  && !TREE_CONSTANT (intop)
  && TREE_CONSTANT (TREE_OPERAND (intop, 1))
  && TREE_CONSTANT (size_exp)
  /* If the constant comes from pointer subtraction,
 skip this optimization--it would cause an error.  */
  && TREE_CODE (TREE_TYPE (TREE_OPERAND (intop, 0))) == INTEGER_TYPE
  /* If the constant is unsigned, and smaller than the pointer size,
 then we must skip this optimization.  This is because it could cause
 an overflow error if the constant is negative but INTOP is not.  */
  && (!TYPE_UNSIGNED (TREE_TYPE (intop))
  || (TYPE_PRECISION (TREE_TYPE (intop))
  == TYPE_PRECISION (TREE_TYPE (ptrop)
{
  enum tree_code subcode = resultcode;
  tree int_type = TREE_TYPE (intop);
  if (TREE_CODE (intop) == MINUS_EXPR)
subcode = (subcode == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR);
  /* Convert both subexpression types to the type of intop,
 because weird cases involving pointer arithmetic
 can result in a sum or difference with different type args.  */
  ptrop = build_binary_op (EXPR_LOCATION (TREE_OPERAND (intop, 1)),
   subcode, ptrop,
   convert (int_type, TREE_OPERAND (intop, 1)),
   true);
  intop = convert (int_type, TREE_OPERAND (intop, 0));
}


compilable testcase:

int * __attribute__((__noinline__, __noclone__))
foo(int x[])
{
  int k = (-__INT_MAX__ - 1);
  return x + (k - __INT_MAX__);
}

I suggest trying to remove the above...  (doing so fixes the testcase)

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 17 10:04:04 2017
New Revision: 251143

URL: https://gcc.gnu.org/viewcvs?rev=251143&root=gcc&view=rev
Log:
2017-08-17  Richard Biener  

PR tree-optimization/81827
* tree-ssa-structalias.c (struct variable_info): Add is_reg_var
flag.
(new_var_info): Initialize it conservatively.
(get_call_vi): Mark register vars.
(new_scalar_tmp_constraint_exp): Likewise.
(handle_rhs_call): Likewise.
(handle_const_call): Likewise.
(create_function_info_for): Likewise.
(solve_constraints): Sort varinfos to separate register from
non-register vars to pack points-to solution bitmaps during
iteration.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Well, if this program is really supposed to "recursively" allocate all members
where the number of members increases exponentially with the number of levels.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|--disable-bootstrap |--disable-bootstrap
   |--enable-languages=c,ada|--enable-languages=ada
   |fails   |fails

--- Comment #2 from Richard Biener  ---
I see.  I suppose it should use the build tools if not bootstrapping as well
(and/or for stage1).  Isn't this all set up correctly from the toplevel make
anyway?!

So I guess generally enabling C++ when enabling Ada would regress cross builds.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
> I see.  I suppose it should use the build tools if not bootstrapping as well
> (and/or for stage1).  Isn't this all set up correctly from the toplevel make
> anyway?!

Do you mean that passing $(CXX) as in the cross case should work?

> So I guess generally enabling C++ when enabling Ada would regress cross
> builds.

Yes, we would need to enable it only for native.

[Bug c/81389] _mm_cmpestri segfault on -O0

[glisse at gcc dot gnu.org]

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

--- Comment #13 from Marc Glisse  ---
(In reply to rockeet from comment #7)
> @Marc @Jakub @Martin
> Intel CPU document says: operand of _mm_cmpestri can be memory or mm
> register, when the operand is memory, it does not require alignment.

That's the doc for the CPU instruction. The intrinsic, as a C function, always
takes an object of type __m128i, not a register or memory. The only question is
what the alignment of the type __m128i is. In gcc, it is 16 bytes. What does
alignof (or _Alignof or whatever variant you can get working) return with
Intel's compiler?

> The issue is: GCC does not know this knowledge(memory operand need not
> memory align), and there is no way to enforce gcc to generate a _mm_cmpestri
> which always use memory operand, not mm register.

Use inline asm? Intrinsics are not quite as low level as you seem to expect.

> If I manually load the unaligned memory into an aligned `__m128i`, it has
> performance penalty on optimizing compilation.

Uh? With -O1, the compiler merges the unaligned load with pcmpestri (it knows
that the insn can read unaligned memory). Did you mean to talk about the
performance of code generated with -O0? We explicitly do not care about that.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Btw, it looks even wrong -- the host C++ compiler built some of the objects in
the failing link (libcpp.a).  So xg++ might end up linking the wrong
standard library (try building with clang++ and libc++?)

../../xg++ -B../../ -B../../../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B../../../x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-L../../../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L../../../x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -static-libstdc++
-static-libgcc -I- -I../rts -I. -I/tmp/trunk2/gcc/ada -static-libstdc++
-static-libgcc  -DIN_GCC  -g -O2 -W -Wall -o ../../gnatmake b_gnatm.o
a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o
butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o
err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o
interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o
mlib-fil.o mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o
nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o
prj-com.o prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o
prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o
restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o
sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o
sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o
system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o
types.o uintp.o uname.o urealp.o usage.o widechar.o  ../link.o ../targext.o
../../ggc-none.o ../../libcommon-target.a ../../libcommon.a
../../../libcpp/libcpp.a ../rts/libgnat.a  
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a   
-ldl
make[3]: ../../xg++: Command not found
../gcc-interface/Makefile:2647: recipe for target '../../gnatmake' failed
make[3]: *** [../../gnatmake] Error 127

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Eric Botcazou from comment #3)
> > I see.  I suppose it should use the build tools if not bootstrapping as well
> > (and/or for stage1).  Isn't this all set up correctly from the toplevel make
> > anyway?!
> 
> Do you mean that passing $(CXX) as in the cross case should work?

I would think so.  No other host library/tool dir does this kind of dance.

Of course ada toplevel stuff is somewhat special...

> > So I guess generally enabling C++ when enabling Ada would regress cross
> > builds.
> 
> Yes, we would need to enable it only for native.

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[andrewm.roberts at sky dot com]

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

--- Comment #10 from Andrew Roberts  ---
I've attached the output for gcc 7.2.0 with -fmem-report (as
gcc-7.2.0-fmem-report.tar.bz2).

g++ -Ox -fmem-report -c testmap.cpp
where -Ox is one of: -O0, -O1, -O2, -O3, or -O1 -fgcse

This is across: x64 (x86-64) , arm, aarch64-rpi3 (aarch64)
Both Raspbery Pi 3 systems are identical, one has 32 bit OS, other has 64 bit
OS (Arch Linux ARM)

The files are named: gcc-7.2.0-[arch]-[opt].txt.

The original issue was large memory usage increase for aarch64 vs arm, on -O2
and above. So looking at -O1 vs -O2 for the above.

There seem to be leaks in the Bitmaps:

  Total Memory  Percentage
  MemoryLeaked  Leaked
arm -O1: 54067992  10582346 19.57%
arm -O2: 43536148  15595746 35.82%
aarch64 -O1: 39788848   9005047 22.63%
aarch64 -O2: 74521688  42694630 57.29% <= big increase on aarch64 at -O2

47% of the leaks at -O2 on aarch64 are in:
df-problems.c:1912 (df_mir_alloc)543920:  0.7% 202813600 
10167911: 23.8%   0   0  heap
df-problems.c:1913 (df_mir_alloc)544080:  0.7% 202798720 
10167165: 23.8%   0   0  heap

32% of the leaks at -O2 on x86-64 are also in the same place, so I guess this
is a 64bit code path.

I don't see anything else which stands out as being different between arm and
aarch64 as they move from -O1 to -O2.
There are plenty of other leaks though, although how significant these are I
have no idea.

The arm gcc is configured with:
/usr/local/gcc/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/7.2.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-7.2.0/configure --prefix=/usr/local/gcc-7.2.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--disable-libssp --host=armv7l-unknown-linux-gnueabihf
--build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a --with-float=hard
--with-fpu=vfpv3-d16 --disable-bootstrap --enable-gather-detailed-mem-stats
Thread model: posix
gcc version 7.2.0 (GCC)

The aarch64 gcc is configured with:
/usr/local/gcc/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.0/libexec/gcc/aarch64-unknown-linux-gnu/7.2.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-7.2.0/configure --prefix=/usr/local/gcc-7.2.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--enable-shared --enable-clocale=gnu --with-arch-directory=aarch64
--enable-multiarch --disable-libssp --host=aarch64-unknown-linux-gnu
--build=aarch64-unknown-linux-gnu --with-arch=armv8-a --disable-bootstrap
--enable-gather-detailed-mem-stats
Thread model: posix
gcc version 7.2.0 (GCC)

The x86-64 gcc is configured with:
/usr/local/gcc/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.0/libexec/gcc/x86_64-unknown-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-7.2.0/configure --prefix=/usr/local/gcc-7.2.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --enable-gnu-indirect-function --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-lto
--enable-multilib --with-tune=generic --with-arch_32=i686
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--with-ld=/usr/local/bin/ld --with-gnu-ld --with-as=/usr/local/bin/as
--with-gnu-as --disable-bootstrap --enable-gather-detailed-mem-stats
Thread model: posix
gcc version 7.2.0 (GCC)

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[andrewm.roberts at sky dot com]

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

--- Comment #11 from Andrew Roberts  ---
Created attachment 41992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41992&action=edit
gcc-7.2.0 -fmem-report output for arm, aarch64, and x86-64

Output for gcc 7.2.0 with -fmem-report (as gcc-7.2.0-fmem-report.tar.bz2).

g++ -Ox -fmem-report -c testmap.cpp
where -Ox is one of: -O0, -O1, -O2, -O3, or -O1 -fgcse

This is across: x64 (x86-64) , arm, aarch64-rpi3 (aarch64)
Both Raspberry Pi 3 systems are identical, one has 32 bit OS, other has 64 bit
OS (Arch Linux ARM)

The files are named: gcc-7.2.0-[arch]-[opt].txt.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 41993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41993&action=edit
Patch to reduce the problem

Can be reduced by given patch. The function is called for following loop:

  :
  # b_118 = PHI 
  # count.30_122 = PHI 
  c = 0.0;
  if (le.52_14 <= 0)
goto ;
  else
goto ;

  :
  _253 = le.52_14 + -1;
  if (le.52_14 < _253)
goto ;
  else
goto ;

  :
  _256 = le.52_14 * 2;
  if (_256 < -1)
goto ;
  else
goto ;

  :
  k2_262 = le.52_14 + 1;
  _269 = _253 + k2_262;
  j02_270 = _269 + 1;
  j04_275 = _269 + 2;
  M.0_403 = MIN_EXPR <_253, 0>;
  mo_278 = M.0_403 + 1;
  M.1_391 = MIN_EXPR ;
  if (k2_262 < 0)
goto ;
  else
goto ;

  :
  m_280 = 1 - M.1_391;

  :
  # m_281 = PHI <1(31), m_280(32)>
  if (mo_278 < m_281)
goto ;
  else
goto ;

  :
  _284 = fak[0];
  _285 = _284 - 2.99573230743408203125e+0;
  _286 = (integer(kind=8)) j02_270;
  _287 = _286 + -1;
  _288 = fak[_287];
  _289 = _285 + _288;
  _293 = _284 + _289;
  _294 = (integer(kind=8)) j04_275;
  _295 = _294 + -1;
  _296 = fak[_295];
  del_297 = _293 - _296;
  j6_299 = le.52_14 + 2;
  j7_301 = le.52_14 + 2;
  _308 = _284 + del_297;
  _313 = _284 + _308;
  _315 = (integer(kind=8)) le.52_14;
  _316 = _315 + -1;
  _317 = fak[_316];
  _318 = _313 + _317;
  _319 = (integer(kind=8)) j6_299;
  _320 = _319 + -1;
  _321 = fak[_320];
  _322 = _318 + _321;
  _323 = (integer(kind=8)) j7_301;
  _324 = _323 + -1;
  _325 = fak[_324];
  _326 = _322 + _325;
  _330 = _317 + _326;
  _331 = ((_330));
  sym_332 = _331 * 5.0e-1;

  :
  # k_333 = PHI 
  j2_335 = k2_262 + k_333;
  _336 = -k_333;
  j3_337 = 2 - k_333;
  j4_339 = 2 - k_333;
  _340 = _253 - k_333;
  j5_341 = _340 + 2;
  _342 = (integer(kind=8)) k_333;
  _343 = _342 + -1;
  _344 = fak[_343];
  _345 = sym_332 - _344;
  _349 = _345 - _344;
  _350 = (integer(kind=8)) j2_335;
  _351 = _350 + -1;
  _352 = fak[_351];
  _353 = _349 - _352;
  _354 = (integer(kind=8)) j3_337;
  _355 = _354 + -1;
  _356 = fak[_355];
  _357 = _353 - _356;
  _358 = (integer(kind=8)) j4_339;
  _359 = _358 + -1;
  _360 = fak[_359];
  _361 = _357 - _360;
  _362 = (integer(kind=8)) j5_341;
  _363 = _362 + -1;
  _364 = fak[_363];
  _365 = _361 - _364;
  _366 = __builtin_expf (_365);
  _367 = c;
  _368 = _366 - _367;
  c = _368;
  k_369 = k_333 + 1;
  if (mo_278 == k_333)
goto ;
  else
goto ;

  :
  goto ;

  :
  _370 = _253 + k_333;
  _371 = _370 + 1;
  _372 = _371 << 1;
  _373 = _372 & 2;
  _374 = 1 - _373;
  _375 = (real(kind=4)) _374;
  _377 = _368 * _375;
  c = _377;

  :
  c.58_18 = c;
  b_75 = c.58_18 + b_118;
  count.30_76 = count.30_122 + -1;
  if (count.30_76 <= 0)
goto ;
  else
goto ;

  :
  goto ;

where we return true for 'c'. The function's comment:

 /* Returns true if REF is independent on all other memory references in
   LOOP.  */

which is probably wrong as there are various memory references that influence
value of the 'c'.
I have very small experience in loop optimizations, thus leaving to somebody
more skilled.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> (In reply to Eric Botcazou from comment #3)
> > > I see.  I suppose it should use the build tools if not bootstrapping as 
> > > well
> > > (and/or for stage1).  Isn't this all set up correctly from the toplevel 
> > > make
> > > anyway?!
> > 
> > Do you mean that passing $(CXX) as in the cross case should work?
> 
> I would think so.  No other host library/tool dir does this kind of dance.
>
> Of course ada toplevel stuff is somewhat special...

As can be seen in the result:

make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
gcc -c -g -O2 -W -Wall  -gnatpg -gnata -I- -I../rts -I. -I/tmp/trunk2/gcc/ada
../rts/s-casuti.adb -o s-casuti.o
s-casuti.adb:32:08: warning: unrecognized pragma "Compiler_Unit_Warning"
s-casuti.ads:40:08: warning: unrecognized pragma "Compiler_Unit_Warning"
../gcc-interface/Makefile:296: recipe for target 's-casuti.o' failed
make[3]: *** [s-casuti.o] Error 1

so the host ada compiler (gnat 4.8) doesn't work for this part.  With
cross-compiling we require a host compiler matching the target one, right?

> > > So I guess generally enabling C++ when enabling Ada would regress cross
> > > builds.
> > 
> > Yes, we would need to enable it only for native.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
I'll take a look.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 17 Aug 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> --- Comment #3 from Martin Liška  ---
> Created attachment 41993
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41993&action=edit
> Patch to reduce the problem
> 
> Can be reduced by given patch. The function is called for following loop:
> 
>   :
>   # b_118 = PHI 
>   # count.30_122 = PHI 
>   c = 0.0;
>   if (le.52_14 <= 0)
> goto ;
>   else
> goto ;
> 
>   :
>   _253 = le.52_14 + -1;
>   if (le.52_14 < _253)
> goto ;
>   else
> goto ;
> 
>   :
>   _256 = le.52_14 * 2;
>   if (_256 < -1)
> goto ;
>   else
> goto ;
> 
>   :
>   k2_262 = le.52_14 + 1;
>   _269 = _253 + k2_262;
>   j02_270 = _269 + 1;
>   j04_275 = _269 + 2;
>   M.0_403 = MIN_EXPR <_253, 0>;
>   mo_278 = M.0_403 + 1;
>   M.1_391 = MIN_EXPR ;
>   if (k2_262 < 0)
> goto ;
>   else
> goto ;
> 
>   :
>   m_280 = 1 - M.1_391;
> 
>   :
>   # m_281 = PHI <1(31), m_280(32)>
>   if (mo_278 < m_281)
> goto ;
>   else
> goto ;
> 
>   :
>   _284 = fak[0];
>   _285 = _284 - 2.99573230743408203125e+0;
>   _286 = (integer(kind=8)) j02_270;
>   _287 = _286 + -1;
>   _288 = fak[_287];
>   _289 = _285 + _288;
>   _293 = _284 + _289;
>   _294 = (integer(kind=8)) j04_275;
>   _295 = _294 + -1;
>   _296 = fak[_295];
>   del_297 = _293 - _296;
>   j6_299 = le.52_14 + 2;
>   j7_301 = le.52_14 + 2;
>   _308 = _284 + del_297;
>   _313 = _284 + _308;
>   _315 = (integer(kind=8)) le.52_14;
>   _316 = _315 + -1;
>   _317 = fak[_316];
>   _318 = _313 + _317;
>   _319 = (integer(kind=8)) j6_299;
>   _320 = _319 + -1;
>   _321 = fak[_320];
>   _322 = _318 + _321;
>   _323 = (integer(kind=8)) j7_301;
>   _324 = _323 + -1;
>   _325 = fak[_324];
>   _326 = _322 + _325;
>   _330 = _317 + _326;
>   _331 = ((_330));
>   sym_332 = _331 * 5.0e-1;
> 
>   :
>   # k_333 = PHI 
>   j2_335 = k2_262 + k_333;
>   _336 = -k_333;
>   j3_337 = 2 - k_333;
>   j4_339 = 2 - k_333;
>   _340 = _253 - k_333;
>   j5_341 = _340 + 2;
>   _342 = (integer(kind=8)) k_333;
>   _343 = _342 + -1;
>   _344 = fak[_343];
>   _345 = sym_332 - _344;
>   _349 = _345 - _344;
>   _350 = (integer(kind=8)) j2_335;
>   _351 = _350 + -1;
>   _352 = fak[_351];
>   _353 = _349 - _352;
>   _354 = (integer(kind=8)) j3_337;
>   _355 = _354 + -1;
>   _356 = fak[_355];
>   _357 = _353 - _356;
>   _358 = (integer(kind=8)) j4_339;
>   _359 = _358 + -1;
>   _360 = fak[_359];
>   _361 = _357 - _360;
>   _362 = (integer(kind=8)) j5_341;
>   _363 = _362 + -1;
>   _364 = fak[_363];
>   _365 = _361 - _364;
>   _366 = __builtin_expf (_365);
>   _367 = c;
>   _368 = _366 - _367;
>   c = _368;
>   k_369 = k_333 + 1;
>   if (mo_278 == k_333)
> goto ;
>   else
> goto ;
> 
>   :
>   goto ;
> 
>   :
>   _370 = _253 + k_333;
>   _371 = _370 + 1;
>   _372 = _371 << 1;
>   _373 = _372 & 2;
>   _374 = 1 - _373;
>   _375 = (real(kind=4)) _374;
>   _377 = _368 * _375;
>   c = _377;
> 
>   :
>   c.58_18 = c;
>   b_75 = c.58_18 + b_118;
>   count.30_76 = count.30_122 + -1;
>   if (count.30_76 <= 0)
> goto ;
>   else
> goto ;
> 
>   :
>   goto ;
> 
> where we return true for 'c'. The function's comment:
> 
>  /* Returns true if REF is independent on all other memory references in
>LOOP.  */
> 
> which is probably wrong as there are various memory references that influence
> value of the 'c'.

Not in the above code?  Well, direct accesses of c obviously.

I will have a look.

> I have very small experience in loop optimizations, thus leaving to somebody
> more skilled.
> 
>

[Bug c++/81879] New: Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

Bug ID: 81879
   Summary: Bad compilation of small program if LTO is used
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddy77 at gmail dot com
  Target Milestone: ---

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

Trying to narrow down an issue I cannot compile and run a really small program
like

#include 

int main()
{
std::cout << std::endl;
return 0;
}

Trying to compile with 

x86_64-w64-mingw32-g++ -flto -O2 -g -pipe -Wall -Werror -Wextra -static
-mconsole -o test.exe test.cpp

It compiles without any warnings but when executed it crashes.
Note that if I remove -flto or -static program run correctly.
>From what Wine reports (but I have a crash even running on Windows directly) it
seems the crash calling do_widen virtual function (null pointer, rax was 0).

I noted different problems with LTO with MinGW, opened also these bugs
- https://bugzilla.redhat.com/show_bug.cgi?id=1475237 (similar to this one)
- https://sourceforge.net/p/mingw/bugs/2346/
- https://bugzilla.redhat.com/show_bug.cgi?id=1455137

I'm using MinGW compiler provided with Fedora 26, specifically:
mingw64-binutils-2.27-2.fc26.x86_64
mingw64-gcc-c++-7.1.0-1.fc26.x86_64
mingw64-headers-5.0.2-1.fc26.noarch

Tried to update binutils (compiler 2.29 version) without success (same crash).

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Ah, it works when leaving CC alone and only changing CXX.  Somewhat
inconsistent I guess.  Let me try if bootstrap also still works.

[Bug target/81879] Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

--- Comment #1 from Frediano Ziglio  ---
This is weird. If after the 

   x86_64-w64-mingw32-g++ -flto -O2 -g -save-temps -Wall -Werror -Wextra
-static -mconsole -o test.exe test.cpp

command I run 

   x86_64-w64-mingw32-g++ -v test.exe.ltrans0.s -static -o test.exe -mconsole

the executable I get is able to run.

Trying to find some difference between the executables I found that the widen
call is different, specifically in one case (the one crashing) do_widen is not
generated. Quite weird that in the wrong code %rdx is assigned to a pointer
inside a function while in the working case a valid pointer to a function is
used.

@@ -49312,7 +49312,7 @@
 ---:   89 d6   mov%edx,%esi
 ---:   e8 c0 fa ff ff  callq  4275e0
::_M_widen_init() const>
 ---:   48 8b 03mov(%rbx),%rax
:   48 8d 15 46 00 00 00lea0x46(%rip),%rdx# 427b70
::do_widen(char) const>
+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 427b2a
::widen(char) const [clone .part.23]+0x1a>
 ---:   48 8b 40 30 mov0x30(%rax),%rax
 ---:   48 39 d0cmp%rdx,%rax
 ---:   75 0d   jne427b40 ::widen(char)
const [clone .part.23]+0x30>
@@ -49345,30 +49345,13 @@
 ---:   90  nop
 ---:   90  nop

-00427b70 ::do_widen(char) const>:
:   89 d0   mov%edx,%eax
:   c3  retq   
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> As can be seen in the result:
> 
> make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
> gcc -c -g -O2 -W -Wall  -gnatpg -gnata -I- -I../rts -I.
> -I/tmp/trunk2/gcc/ada ../rts/s-casuti.adb -o s-casuti.o
> s-casuti.adb:32:08: warning: unrecognized pragma "Compiler_Unit_Warning"
> s-casuti.ads:40:08: warning: unrecognized pragma "Compiler_Unit_Warning"
> ../gcc-interface/Makefile:296: recipe for target 's-casuti.o' failed
> make[3]: *** [s-casuti.o] Error 1
> 
> so the host ada compiler (gnat 4.8) doesn't work for this part.  With
> cross-compiling we require a host compiler matching the target one, right?

Right, the tools always require a matching compiler, i.e. need a bootstrap.

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[chefmax at gcc dot gnu.org]

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

--- Comment #8 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Aug 17 11:58:13 2017
New Revision: 251145

URL: https://gcc.gnu.org/viewcvs?rev=251145&root=gcc&view=rev
Log:
2017-08-17  Maxim Ostapenko  

PR target/81861
* config/i386/i386.c (ix86_option_override_internal): Save target
specific options after ix86_stack_protector_guard_reg was changed.

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

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #4 from H.J. Lu  ---
This is useful to debug PR 81869.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
For

  DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 )
CALL THREEJ(LO,LE,LE,0,0,0,C)
CALL THREEJ(LO,LE,LE,0,0,0,C)
  END DO

  B=0.
  DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 )
CALL THREEJ(LO,LE,LE,MO,-2*MO-1,MO+1,C)
B = B + C
  END DO

the FE annotates both loops with IVDEP:

  if (forall_tmp->do_concurrent)
cond = build2 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
   build_int_cst (integer_type_node,
  annot_expr_ivdep_kind));

but this seems to have an adverse effect in case the last threej is inlined
(which it is only in case the first two are ipa-cp'ed).

Ok, so we have

 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x768ac348 precision
32
pointer_to_this  reference_to_this
>
tree_0 tree_1
arg 0 
public unsigned DI
size 
unit size 
align 64 symtab 0 alias set 8 canonical type 0x768ac888>

arg 0 
addressable used SF file /tmp/t.f90 line 82 col 0 size  unit size 
align 32 context  chain
>
/tmp/t.f90:102:0 start: /tmp/t.f90:102:0 finish: /tmp/t.f90:102:0>
arg 1 
constant 0>>

but then there is

c.68_18 = c;

 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x768ac348 precision
32
pointer_to_this  reference_to_this
>
addressable used SF file /tmp/t.f90 line 82 col 0 size  unit size 
align 32 context  chain >

which is not detected as equal and things go haywire (alias analysis would
detect they alias but we have safelen and thus detecting equal things as
equal is now a strict requirement!).

This is probably a case that can be easily fixed _but_ LIM is not ready to
detect, say, a.b.c and MEM[&a + 8] as equal.  This means we somehow need to
conservatively(!) compute must-aliases to make the safelen handing in LIM
safe.  Esp. for accesses with non-constant address this is impossible,
like in a loop nest (like this) with the outer loop safelen and the LIM
pass after IV optimization which might re-write things in a way that
a) isn't fully consistent, b) can have un-CSEd expressions.

Bah.

Now - the special case above is sth to fix anyways (for !safelen this will
result in a missed store motion).

Will poke at this a bit.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So started with r249991 where a new static variable of hash_table was added.
Well, the implementation of memory statistics is bit fragile as it requires
that static construction of mem_alloc_description X happens before any other
tracked data structure is created. I know that Jakub is not friend of addition
of static data structures, where pointer type is preferred variant. I've got
patch that I'm going to test.

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #13 from Oleg Endo  ---
It seems I've lost some data here in the bugzilla PR, but it's there on the
mailing list:
https://gcc.gnu.org/ml/gcc-bugs/2017-08/threads.html#01661

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 41995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41995&action=edit
Patch candidate

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Index: Makefile.in
===
--- Makefile.in (revision 251140)
+++ Makefile.in (working copy)
@@ -78,7 +78,7 @@ CXX_LFLAGS = \
 # Variables for gnattools, native
 TOOLS_FLAGS_TO_PASS_NATIVE= \
"CC=../../xgcc -B../../" \
-   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
+   "CXX=$(CXX)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \
@@ -96,7 +96,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
 # Variables for regnattools
 TOOLS_FLAGS_TO_PASS_RE= \
"CC=../../xgcc -B../../" \
-   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
+   "CXX=$(CXX)" \
"CFLAGS=$(CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \

seems to work for me, both bootstrap and --disable-bootstrap.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Created attachment 41996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41996&action=edit
patch for the missed optimization

Testing this to address the missed optimization(s).  This happens to fix the
testcase as expected but the underlying issue is still present.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[andrewm.roberts at sky dot com]

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

--- Comment #7 from Andrew Roberts  ---
Works for me on x86-64, trying aarch64 now.

[Bug c++/81880] New: thread_local static member template initialisation fails

[maiphi.public at gmx dot net]

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

Bug ID: 81880
   Summary: thread_local static member template initialisation
fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maiphi.public at gmx dot net
  Target Milestone: ---

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

thread_local static member templates do not get initialised.

Example code:

#include 
#include 

class A {
public:
  template
  thread_local static std::unordered_map m;
};

template
thread_local std::unordered_map A::m{};

int main() {
  // A::m = std::unordered_map{}; // workaround
  std::cout << A::m.bucket_count() << std::endl; // returns zero.
  A::m.insert({1,2}); // causes SIGPFE (hash modulo bucket_count)
}

The unordered_map is not initialised and has a bucket count of zero. This leads
to a zero division when the hash is taken modulo the bucket count. Without the
thread_local or without the template it works fine. A workaround is to
initialise the member manually in every thread which uses it (commented line).

OS: opensuse Leap 42.3, kernel 4.4.79-19-default x64
CPU: Intel Core i7-4790

$ g++ -o bug -v -save-temps -std=c++14 -Wall -Wextra -pedantic bug.cpp 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/path/to/gcc/svn
--disable-multilib --enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.0.0 20170817 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus -E -quiet -v
-D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++14 -Wall -Wextra
-Wpedantic -fpch-preprocess -o bug.ii
ignoring nonexistent directory
"/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0

/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/x86_64-pc-linux-gnu

/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/backward
 /path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include
 /usr/local/include
 /path/to/gcc/svn/include
 /path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus -fpreprocessed
bug.ii -quiet -dumpbase bug.cpp -mtune=generic -march=x86-64 -auxbase bug -Wall
-Wextra -Wpedantic -std=c++14 -version -o bug.s
GNU C++14 (GCC) version 8.0.0 20170817 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20170817 (experimental), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++14 (GCC) version 8.0.0 20170817 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20170817 (experimental), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7aa65dd64f7a61cf2867713db376431f
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.26.1 (x86_64-suse-linux) using BFD version (GNU
Binutils; openSUSE Leap 42.3) 2.26.1
COMPILER_PATH=/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:./:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o&#x

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> ===
> --- Makefile.in (revision 251140)
> +++ Makefile.in (working copy)
> @@ -78,7 +78,7 @@ CXX_LFLAGS = \
>  # Variables for gnattools, native
>  TOOLS_FLAGS_TO_PASS_NATIVE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
> +   "CXX=$(CXX)" \
> "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> @@ -96,7 +96,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
>  # Variables for regnattools
>  TOOLS_FLAGS_TO_PASS_RE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
> +   "CXX=$(CXX)" \
> "CFLAGS=$(CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> 
> seems to work for me, both bootstrap and --disable-bootstrap.

The patch is OK with me if you remove CXX_LFLAGS too.

[Bug target/81879] Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

--- Comment #2 from Frediano Ziglio  ---
It seems that this do_widen replacement with an invalid pointer goes on and on,
looking at differences in the generated executable:



--
 ---:   00 00 
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 5a 30 mov0x30(%rdx),%r11
:   48 8d 15 2a 65 ff fflea-0x9ad6(%rip),%rdx# 427b70
::do_widen(char) const>
+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 431636
 > >::get(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, tm*, char const*, char const*)
const+0x6e6>
 ---:   49 39 d3cmp%rdx,%r11
:   0f 84 ba fc ff ff   je 431309  >
>::get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char const*, char const*) const+0x3a9>
--
 ---:   48 89 44 24 60  mov%rax,0x60(%rsp)
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 44 24 60  mov0x60(%rsp),%rax
:   48 8d 0d a2 5f ff fflea-0xa05e(%rip),%rcx# 427b70
::do_widen(char) const>
+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 431bbe
 > >::get(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x23e>
 ---:   4c 8b 44 24 68  mov0x68(%rsp),%r8
 ---:   48 8b 10mov(%rax),%rdx
--
 ---:   48 89 44 24 48  mov%rax,0x48(%rsp)
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 44 24 48  mov0x48(%rsp),%rax
:   48 8d 0d e7 5c ff fflea-0xa319(%rip),%rcx# 427b70
::do_widen(char) const>
+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 431e79
 > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x1d9>
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 42 30 mov0x30(%rdx),%r8
--
 ---:   44 0f b6 54 24 6f   movzbl 0x6f(%rsp),%r10d
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 5a 30 mov0x30(%rdx),%r11
:   48 8d 15 ef eb fc fflea-0x31411(%rip),%rdx# 427b70
::do_widen(char) const>
+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 458f71
 >
>::get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char const*, char const*) const+0x6d1>
 ---:   49 39 d3cmp%rdx,%r11
:   0f 84 d2 fb ff ff   je 458b5c  >
>::get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char const*, char const*) const+0x2ac>
--
 ---:   48 89 44 24 58  mov%rax,0x58(%rsp)
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 44 24 58  mov0x58(%rsp),%rax
:   48 8d 0d f5 e7 fc fflea-0x3180b(%rip),%rcx# 427b70
::do_widen(char) const>
+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 45936b
 >
>::get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char, char) const+0x1eb>
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 42 30 mov0x30(%rdx),%r8
--
 ---:   48 89 44 24 48  mov%rax,0x48(%rsp)
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 44 24 48  mov0x48(%rsp),%rax
:   48 8d 0d 97 e5 fc fflea-0x31a69(%rip),%rcx# 427b70
::do_widen(char) const>
+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 4595c9
 >
>::do_get(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::ios_base&,
std::_Ios_Iostate&, tm*, char, char) const+0x1d9>
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 42 30 mov0x30(%rdx),%r8
--
 ---:   48 89 d9mov%rbx,%rcx
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 03mov(%rbx),%rax
:   48 8d 15 ea a9 fc fflea-0x35616(%rip),%rdx# 427b70
::do_widen(char) const>
+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 45d176
 >
>::do_put(std::ostreambuf_iterator >,
std::ios_base&, char, tm const*, char, char) const+0x146>
 ---:   4c 8b 40 30 mov0x30(%rax),%r8
 ---:   b8 25 00 00 00  mov$0x25,%eax
--
 ---:   48 89 f1mov%rsi,%rcx
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 06mov(%rsi),%rax
:   48 8d 15 ce a5 fc fflea-0x35a32(%rip),%rdx# 427b70
::do_widen(char) const>
+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 45d592
 >::fill() const+0x62>
 ---:   4c 8b 40 30 mov0x30(%rax),%r8
 ---:   b8 20 00 00 00  mov$0x20,%eax
--
 ---:   callq  ::_M_widen_init() const>
 ---:   48 8b 03mov(%rbx),%rax
 ---:   8b 54 24 2c mov0x2c(%rsp),%edx
:   48 8d 0d 41 a5 fc ff

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[yroux at gcc dot gnu.org]

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

--- Comment #5 from Yvan Roux  ---
Thinking more about it, I think that the right place to fix it is in the define
of TARGET_HAVE_MOVT or TARGET_USE_MOVT, but I'm a bit confused with these two
macros.

My understanding of their semantic, is that it should be in TARGET_USE_MOVT
(the chip has movt support but we don't want to use it with when
-mword_relocations is used), but if we do so the issue movw/movt will be
generated anyway since arm_movt pattern and "j" contraint uses
TARGET_HAVE_MOVT.

In fact, it seems to me that most of TARGET_HAVE_MOVT should be replaced by
TARGET_USE_MOVT.  Kyrill, Thomas can you educate me ?

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
(In reply to Ian Lance Taylor from comment #25)
> I have no particular concerns with dropping the bitfield code, but clearly it
> has to be tested on a couple of little-endian platforms.

Can we try to narrow it down what to look for?
At the moment, I can think of only two things which can go wrong:

1) sizeof (struct bits) != 8, i.e. this case here.
It wouldn't be working anyway.  Actually there should be a static_assert

2) bit order of bit-field access differs from shift-and-mask access.
What could be causing this?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 17 13:39:58 2017
New Revision: 251150

URL: https://gcc.gnu.org/viewcvs?rev=251150&root=gcc&view=rev
Log:
2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug bootstrap/81881] New: [8 Regression] bootstrap failed on x86

[hjl.tools at gmail dot com]

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

Bug ID: 81881
   Summary: [8 Regression] bootstrap failed on x86
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86
 Build: ubizjak at gmail dot com

r251148 failed to build on x86-64 when configured with

--enable-languages=c,c++ --disable-bootstrap  --prefix=/usr/gcc-8.0.0
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-clocale=gnu --with-system-zlib --disable-libcc1 --disable-libcilkrts
--disable-libsanitizer --disable-libmpx --with-fpmath=sse

0xf0c909 crash_signal
/export/gnu/import/git/sources/gcc/gcc/toplev.c:341
0x9e6c65 df_ref_equal_p
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:2039
0x9eb0bf df_refs_verify
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:4032
0x9eb5db df_bb_verify
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:4158
0x9ebb02 df_scan_verify()
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:4272
0x9d5fe9 df_verify()
/export/gnu/import/git/sources/gcc/gcc/df-core.c:1817
0x9d4855 df_analyze_1
/export/gnu/import/git/sources/gcc/gcc/df-core.c:1213
0x9d4c18 df_analyze()
/export/gnu/import/git/sources/gcc/gcc/df-core.c:1289
0xc99f1b ira
/export/gnu/import/git/sources/gcc/gcc/ira.c:5192
0xc9a9a8 execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5581
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:636: bid64_div.o] Error 1

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #4 from Jan Hubicka  ---
The ICE is about vtable:
 
readonly unsigned type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76b57150>
BLK
align 64 symtab 0 alias set -1 canonical type 0x76b572a0
pointer_to_this >
readonly addressable public static tree_5 ignored external read virtual BLK
file t.ii line 107 col 33
user align 64 context 
not-really-extern>

which is constructed without any DECL_INITIAL. Is this intended? If so, we
could just remove the assert and silently ignore it, but I see no point in
having vtable attached without actually knowning the contents.

The construction happens in:
#0  0x76eb46ab in memset () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00d9b145 in ggc_internal_cleared_alloc (size=144, f=0x0, s=0,
n=1) at ../../gcc/ggc-common.c:117
#2  0x014a352e in ggc_internal_cleared_alloc (s=144) at
../../gcc/ggc.h:148
#3  0x014a3562 in ggc_alloc_cleared_tree_node_stat (s=144) at
../../gcc/ggc.h:292
#4  0x014a58f1 in make_node_stat (code=VAR_DECL) at
../../gcc/tree.c:1008
#5  0x014b4505 in build_decl_stat (loc=673216, code=VAR_DECL,
name=0x76b99e58, type=0x76b572a0) at ../../gcc/tree.c:4730
#6  0x008ea6e3 in build_lang_decl_loc (loc=673216, code=VAR_DECL,
name=0x76b99e58, type=0x76b572a0) at ../../gcc/cp/lex.c:552
#7  0x008ea6b6 in build_lang_decl (code=VAR_DECL, name=0x76b99e58,
type=0x76b572a0) at ../../gcc/cp/lex.c:541
#8  0x007ca2db in build_vtable (class_type=0x76bb3f18,
name=0x76b99e58, vtable_type=0x76b572a0) at ../../gcc/cp/class.c:803
#9  0x007ca601 in get_vtable_decl (type=0x76bb3f18, complete=1) at
../../gcc/cp/class.c:859
#10 0x00a1e80b in tinfo_base_init (ti=0x76b5c8c8,
target=0x76b8cd20) at ../../gcc/cp/rtti.c:951
#11 0x00a1f091 in class_initializer (ti=0x76b5c8c8,
target=0x76b8cd20, n=0) at ../../gcc/cp/rtti.c:1070
#12 0x00a1f3db in get_pseudo_ti_init (type=0x76b8cd20, tk_index=8)
at ../../gcc/cp/rtti.c:1142
#13 0x00a20d2b in emit_tinfo_decl (decl=0x76b9e480) at
../../gcc/cp/rtti.c:1624
#14 0x008aa3a5 in c_parse_final_cleanups () at
../../gcc/cp/decl2.c:4546
#15 0x00b0dc51 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1126
#16 0x0114fdfb in compile_file () at ../../gcc/toplev.c:468
#17 0x01152444 in do_compile () at ../../gcc/toplev.c:2021
#18 0x01152718 in toplev::main (this=0x7fffeaa0, argc=3,
argv=0x7fffeba8) at ../../gcc/toplev.c:2155
#19 0x01c92e13 in main (argc=3, argv=0x7fffeba8) at
../../gcc/main.c:39

Honza

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 41998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41998&action=edit
patch for the missed optimization

Patch I am testing, fixing the missed optimization (and this testcase as a
side-effect) but not the underlying issue.

[Bug bootstrap/81881] [8 Regression] bootstrap failed on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
   Target Milestone|--- |8.0
  Build|ubizjak at gmail dot com   |

[Bug c++/81880] thread_local static member template initialisation fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 Ever confirmed|0   |1
  Known to fail||7.2.0

--- Comment #1 from Richard Biener  ---
works with clang++

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[andrewm.roberts at sky dot com]

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

--- Comment #8 from Andrew Roberts  ---
aarch64 also ok with gcc-8.0.0 for me.

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 17 14:33:13 2017
New Revision: 251152

URL: https://gcc.gnu.org/viewcvs?rev=251152&root=gcc&view=rev
Log:
PR middle-end/81814
* fold-const.c (operand_equal_for_comparison_p): Remove code that used
to mimic what shorten_compare did.  Change the return type to bool.
(fold_cond_expr_with_comparison): Update call to
operand_equal_for_comparison_p.
(fold_ternary_loc): Likewise.

* gcc.dg/torture/pr81814.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81814.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[gnugcc at marino dot st]

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

--- Comment #10 from John Marino  ---
The original updates by rguenth were lost by the bugzilla-wide data failure,
and the rework only fixed the target milestone.  I don't have permission to fix
the missing data, so I'm going to paste the contents of the email received so
someone else can:


8/14/2017 04:05
Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|7.2 |7.3
Summary|[7/8 regression] ICE in |[7 regression] ICE in
   |add_gnat_descriptive_type_a |add_gnat_descriptive_type_a
   |ttribute|ttribute
  Known to fail||7.2.0

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
==19335== 
==19335== HEAP SUMMARY:
==19335== in use at exit: 3,187,351,790 bytes in 240,687 blocks
==19335==   total heap usage: 10,232,166 allocs, 9,991,479 frees,
177,590,129,479 bytes allocated
==19335== 
==19335== 96 bytes in 8 blocks are definitely lost in loss record 897 of 2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x23C8167: xstrdup (xstrdup.c:34)
==19335==by 0xCDCD21: gen_internal_sym(char const*) (dwarf2out.c:7396)
==19335==by 0xCE0F01: gen_llsym(dw_loc_list_struct*) (dwarf2out.c:9635)
==19335==by 0xCFBF0C: dw_loc_list(var_loc_list_def*, tree_node*, int)
(dwarf2out.c:16329)
==19335==by 0xCFDF21: loc_list_from_tree_1(tree_node*, int,
loc_descr_context*) (dwarf2out.c:17370)
==19335==by 0xCFFF4D: loc_list_from_tree(tree_node*, int,
loc_descr_context*) (dwarf2out.c:17974)
==19335==by 0xD04666: add_location_or_const_value_attribute(die_struct*,
tree_node*, bool) (dwarf2out.c:19179)
==19335==by 0xD112D4: gen_variable_die(tree_node*, tree_node*, die_struct*)
(dwarf2out.c:22945)
==19335==by 0xD18DEA: gen_decl_die(tree_node*, tree_node*, vlr_context*,
die_struct*) (dwarf2out.c:25378)
==19335==by 0xD17389: process_scope_var(tree_node*, tree_node*, tree_node*,
die_struct*) (dwarf2out.c:24853)
==19335== 
==19335== 268 bytes in 6 blocks are definitely lost in loss record 1,182 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x2374590: append_file_to_dir(char const*, cpp_dir*)
(files.c:1568)
==19335==by 0x2372249: find_file_in_dir(cpp_reader*, _cpp_file*, bool*,
unsigned int) (files.c:390)
==19335==by 0x237274C: _cpp_find_file (files.c:542)
==19335==by 0x23735D8: _cpp_stack_include (files.c:1032)
==19335==by 0x2367BA2: do_include_common(cpp_reader*, include_type)
(directives.c:858)
==19335==by 0x2367BE8: do_include(cpp_reader*) (directives.c:869)
==19335==by 0x23671EA: _cpp_handle_directive (directives.c:547)
==19335==by 0x237B2CA: _cpp_lex_token (lex.c:2566)
==19335==by 0x238663D: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2462)
==19335==by 0x2386AAC: cpp_get_token_with_location(cpp_reader*, unsigned
int*) (macro.c:2648)
==19335== 
==19335== 8,032 bytes in 1 blocks are possibly lost in loss record 1,663 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x237D635: new_buff(unsigned long) (lex.c:3540)
==19335==by 0x237D703: _cpp_get_buff (lex.c:3573)
==19335==by 0x2375C3C: cpp_create_reader(c_lang, ht*, line_maps*)
(init.c:252)
==19335==by 0xB45533: c_common_init_options(unsigned int,
cl_decoded_option*) (c-opts.c:221)
==19335==by 0x12F5722: toplev::main(int, char**) (toplev.c:2146)
==19335==by 0x23176DD: main (main.c:39)
==19335== 
==19335== 8,032 bytes in 1 blocks are possibly lost in loss record 1,664 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x237D635: new_buff(unsigned long) (lex.c:3540)
==19335==by 0x237D703: _cpp_get_buff (lex.c:3573)
==19335==by 0x237D971: _cpp_unaligned_alloc (lex.c:3646)
==19335==by 0x23789ED: create_literal(cpp_reader*, cpp_token*, unsigned
char const*, unsigned int, cpp_ttype) (lex.c:1539)
==19335==by 0x2379EA7: lex_string(cpp_reader*, cpp_token*, unsigned char
const*) (lex.c:2033)
==19335==by 0x237BE84: _cpp_lex_direct (lex.c:2915)
==19335==by 0x237B27A: _cpp_lex_token (lex.c:2554)
==19335==by 0x238663D: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2462)
==19335==by 0x2386A87: cpp_get_token(cpp_reader*) (macro.c:2604)
==19335==by 0x2369A75: get_token_no_padding(cpp_reader*)
(directives.c:1771)
==19335== 
==19335== 8,032 bytes in 1 blocks are possibly lost in loss record 1,665 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x237D635: new_buff(unsigned long) (lex.c:3540)
==19335==by 0x237D703: _cpp_get_buff (lex.c:3573)
==19335==by 0x237D971: _cpp_unaligned_alloc (lex.c:3646)
==19335==by 0x23789ED: create_literal(cpp_reader*, cpp_token*, unsigned
char const*, unsigned int, cpp_ttype) (lex.c:1539)
==19335==by 0x2379EA7: lex_string(cpp_reader*, cpp_token*, unsigned char
const*) (lex.c:2033)
==19335==by 0x237BA92: _cpp_lex_direct (lex.c:2808)
==19335==by 0x238762B: lex_expansion_token(cpp_reader*, cpp_macro*)
(macro.c:2968)
==19335==by 0x2387C44: create_iso_definition(cpp_reader*, cpp_macro*)
(macro.c:3140)
==19335==by 0x2387FB1: _cpp_create_definition (macro.c:3216)
==19335==by 0x236750C: do_define(cpp_reader*) (directives.c:644)
==19335== 
==19335== 14,072 bytes in 1 blocks are po

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
This

==19335==still reachable: 3,185,786,922 bytes in 240,513 blocks

probably kills 32-bit hosts.

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

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

--- Comment #9 from Maxim Ostapenko  ---
Fixed on trunk.

[Bug middle-end/81814] [5/6/7 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[5/6/7/8 Regression]|[5/6/7 Regression]
   |Incorrect behaviour at -O0  |Incorrect behaviour at -O0
   |(conditional operator)  |(conditional operator)

--- Comment #14 from Marek Polacek  ---
Fixed for GCC 8.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #7 from Alexander Monakov  ---
Small C testcase demonstrating the issue with -O2 -fno-tree-sra:

void g(int *out)
{
  struct s {int x;} s;
#pragma GCC ivdep
  for (int i = 0; i < 100; i++)
{
  int *x = &s.x;
  asm("" : "+r"(x));
  *x = 42;
  out[i] = s.x;
}
}

I think the main question is how safelen introduced via pragma-ivdep or
do-concurrent is supposed to interact with addressable vars written in the loop
body? It doesn't seem well-defined?..

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 17 Aug 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> Alexander Monakov  changed:
> 
>What|Removed |Added
> 
>  CC||amonakov at gcc dot gnu.org
> 
> --- Comment #7 from Alexander Monakov  ---
> Small C testcase demonstrating the issue with -O2 -fno-tree-sra:
> 
> void g(int *out)
> {
>   struct s {int x;} s;
> #pragma GCC ivdep
>   for (int i = 0; i < 100; i++)
> {
>   int *x = &s.x;
>   asm("" : "+r"(x));
>   *x = 42;
>   out[i] = s.x;
> }
> }
> 
> I think the main question is how safelen introduced via pragma-ivdep or
> do-concurrent is supposed to interact with addressable vars written in the 
> loop
> body? It doesn't seem well-defined?..

I think this one is simply undefined given the must-alias dependency
isn't "obvious" (aka literal).  The fortran case would be similar
(it has a function call).

But of course GCC itself could introduce above obfuscation.

[Bug bootstrap/81881] [8 Regression] bootstrap failed on x86

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
I can't reproduce it now.

[Bug c++/81873] spurious -Wreturn-type calling a locally declared noreturn function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69855,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81608

--- Comment #3 from Martin Sebor  ---
As mentioned in comment #2, this bug could be caused by the same underlying
problem as bug 81608, which is a duplicate of 69855.

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html which was lost:

--- Comment #8 from neil.n.carlson at gmail dot com ---
Ping.  Is there any interest in fixing this regression?

[Bug target/72804] Poor code gen with -mvsx-timode

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Thu Aug 17 15:56:48 2017
New Revision: 251153

URL: https://gcc.gnu.org/viewcvs?rev=251153&root=gcc&view=rev
Log:
gcc/
PR target/72804
* config/rs6000/vsx.md (*vsx_le_permute_): Add support for
operands residing in integer registers.
(*vsx_le_perm_load_): Likewise.
(*vsx_le_perm_store_): Likewise.
(define_peephole2): Add peepholes to optimize the above.

gcc/testsuite/
PR target/72804
* gcc.target/powerpc/pr72804.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr72804.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin17.0.0
 Status|UNCONFIRMED |NEW
   Keywords||build
   Last reconfirmed||2017-08-17
  Component|libstdc++   |target
 CC||egallager at gcc dot gnu.org,
   ||howarth.at.gcc at gmail dot com
   Host||x86_64-apple-darwin17.0.0
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin17.0.0

--- Comment #4 from Eric Gallager  ---
Redoing lost comments:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01294.html

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot
com

--- Comment #3 from Jack Howarth  ---
I don't see this issue with the gcc7-7.1.0-1 fink package build on High Sierra.
This is from a clean install of fink master on 10.13 using the proposed changes
from...

https://github.com/fink/fink/pull/143

to bootstrap fink git master on 10.13 and patching all the fink package
dependencies that trip over the increased format string strictness in 10.13...

http://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00056.html

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01310.html

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-13
 Ever confirmed|0   |1

--- Comment #4 from Francois-Xavier Coudert  ---
We have a Homebrew user report it, and I can see it myself. It is intermittent,
and I have seen it happen twice, always with "make -j4" (2 out of 4 parallel
builds). Building with -j1 does not appear to trigger the issue.

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01311.html

--- Comment #5 from Francois-Xavier Coudert  ---
I've also found one case where the error is slightly different (also "make
-j4"):

make "AR_FLAGS=rc" "CC_FOR_BUILD=clang"
"CC_FOR_TARGET=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc
-B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/" "CFLAGS=-g -O2 
-m32" "CXXFLAGS=-g -O2  -m32" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g
-O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c"
"LDFLAGS=-m32" "LIBCFLAGS=-g -O2  -m32" "LIBCFLAGS_FOR_TARGET=-g -O2"
"MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500
--split-size=500 " "SHELL=/bin/sh" "RUNTESTFLAGS="
"exec_prefix=/usr/local/Cellar/gcc/7.1.0"
"infodir=/usr/local/Cellar/gcc/7.1.0/share/info"
"libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7"
"includedir=/usr/local/Cellar/gcc/7.1.0/include"
"prefix=/usr/local/Cellar/gcc/7.1.0"
"tooldir=/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0"
"gxx_include_dir=/usr/local/Cellar/gcc/7.1.0/include/c++/7.1.0" "AR=ar"
"AS=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/as"
"LD=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/collect-ld"
"RANLIB=ranlib"
"NM=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/nm"
"NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive
Making all in include
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc
-B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc -nostdinc++
-L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src
-L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs
-L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include  -m32 -x
c++-header -nostdinc++ -g -O2  -m32 
-I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0
-I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include

[Bug c++/59949] lambda expression as default argument of function template causes "already defined" messages in assembler

[jj at stusta dot net]

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

--- Comment #3 from Jonas Jelten  ---
This bug is still present in g++ 6.4.0.

[Bug c++/39466] frepo relinking causes error - object in .o but not in .rpo or vice versa

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from Eric Gallager  ---
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01604.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from Eric Gallager  ---
I can't reproduce with current gcc on i386-apple-darwin9.8.0, compilation fails
instead with: 

$ /usr/local/bin/g++ -frepo -DCOMPILING_WITH_FREPO=1 -pipe -frepo
-DCOMPILING_WITH_FREPO=1 -D_REENTRANT -Wctor-dtor-privacy -Wall -DNDEBUG
-fstack-protector-all -O2 -ftree-loop-linear -fweb -march=core2 -mssse3
-fdiagnostics-show-option -fomit-frame-pointer -fPIC -rdynamic -std=gnu++98 -o
XmlImplementationFactory.exe XmlImplementationFactory.ii 2>&1
: warning: -frepo must be used with -c
util/impl/xml/XmlImplementationFactory.cpp:33:1: error: declaration of
‘boost::shared_ptr >
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) [with T =
dogs::util::xml::TSimpleTypes >]’ has a different
exception specifier
In file included from util/impl/xml/XmlImplementationFactory.cpp:3:0:
util/impl/../include/XmlImplementationFactory.h:26:11: note: from previous
declaration ‘boost::shared_ptr >
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) throw
(dogs::util::xml::XmlException) [with T =
dogs::util::xml::TSimpleTypes >]’
util/impl/xml/XmlImplementationFactory.cpp:49:1: error: declaration of
‘boost::shared_ptr >
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) [with T =
dogs::util::xml::TSimpleTypes >]’ has a different
exception specifier
In file included from util/impl/xml/XmlImplementationFactory.cpp:3:0:
util/impl/../include/XmlImplementationFactory.h:26:11: note: from previous
declaration ‘boost::shared_ptr >
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) throw
(dogs::util::xml::XmlException) [with T =
dogs::util::xml::TSimpleTypes >]’
$

Can you try again?

[Bug c++/67075] Infinite GC loop with ggc-min-expand=0

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01605.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #2)
> Sounds more like ggc_collect is now always doing the gc and there are a lot
> of ggc_collect calls. 
> 
> So what is happening we are close to your 32M limit you set, so any garbage
> that is produced in a pass will cause the next call to ggc_collect to always
> collect. This means there a lot of calls to ggc_collect but in the normal
> case (non 0 case), it does not matter. 
> 
> You might want to try 5.2 as 4.8.x is no longer supported and there have
> been some memory reductions happened since 4.8.x.

Changing to WAITING until reporter tries a supported version.

[Bug c++/71192] Coredump - SIGSEGV exception handling on GCC 4.8.2 in Solaris 11.3, Solaris 11.2 works with same GCC version

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01606.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Could you please:

- attach the preprocessed source that triggers this bug
- try again with a version of GCC that is still supported, and
- specify your full target triplet?

[Bug c++/81787] [5/6/7/8 Regression] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |5.5
Summary|`#pragma GCC diagnostic |[5/6/7/8 Regression]
   |warning "-fpermissive"` no  |`#pragma GCC diagnostic
   |longer works since gcc 4.8  |warning "-fpermissive"` no
   ||longer works since gcc 4.8

[Bug c++/80227] [5/6/7/8 Regression] SFINAE ambiguity with a pointer to array argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing lost comments:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01610.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc rejects the former and accepts the latter, although the
former should probably still get a warning anyways even if it's not supposed to
error, just for being confusing (in my
biased-against-c++-things-like-overloading opinion)

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01626.html

--- Comment #2 from Jonathan Wakely  ---
Idiomatic C++ code should not warn.

Clang and ICC accept the former and reject the latter. VC++ rejects both, which
is odd.

bIJbR

[fHPvw via gcc-bugs]

ARMwbOY


eha92a5z.pdf
Description: Binary data

[Bug c++/65870] Explicit function instantiation with default valued lambda causes duplicate symbol

[jj at stusta dot net]

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

--- Comment #1 from Jonas Jelten  ---
This is probably the same as bug 59949, and still present in 6.4.0.

[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el

[james410 at cowgill dot org.uk]

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

--- Comment #5 from James Cowgill  ---
I have just noticed this which seems curious. Is the 39 -> 40 combine really a
valid transformation? It seems we've lost the sign extension and we're just
putting a 32-bit value into a 64-bit register without trying to clear the upper
bits anymore?

Before
-
(insn 38 37 39 3 (set (reg:SI 235)
(ne:SI (reg:SI 234 [ h ])
(const_int 0 [0]))) "reduced.c":16 500 {*sne_zero_sisi}
 (expr_list:REG_DEAD (reg:SI 234 [ h ])
(nil)))
(insn 39 38 40 3 (set (reg:HI 233)
(subreg:HI (reg:SI 235) 0)) "reduced.c":16 358 {*movhi_internal}
 (expr_list:REG_DEAD (reg:SI 235)
(nil)))
(insn 40 39 133 3 (set (reg:DI 207 [ iftmp.3_18 ])
(sign_extend:DI (reg:HI 233))) "reduced.c":16 244 {*extendhidi2_seh}
 (expr_list:REG_DEAD (reg:HI 233)
(nil)))

combine
-
Trying 39 -> 40:
Successfully matched this instruction:
(set (reg:DI 207 [ iftmp.3_18 ])
(subreg:DI (reg:SI 235) 0))
allowing combination of insns 39 and 40
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 39.
modifying insn i340: r207:DI=r235:SI#0
  REG_DEAD r235:SI
deferring rescan insn with uid = 40.

Trying 38 -> 40:
Successfully matched this instruction:
(set (subreg:SI (reg:DI 207 [ iftmp.3_18 ]) 0)
(ne:SI (reg:SI 234 [ h ])
(const_int 0 [0])))
allowing combination of insns 38 and 40
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 38.
modifying insn i340: r207:DI#0=r234:SI!=0
  REG_DEAD r234:SI
deferring rescan insn with uid = 40.

After
--
(note 38 37 39 3 NOTE_INSN_DELETED)
(note 39 38 40 3 NOTE_INSN_DELETED)
(insn 40 39 133 3 (set (subreg:SI (reg:DI 207 [ iftmp.3_18 ]) 0)
(ne:SI (reg:SI 234 [ h ])
(const_int 0 [0]))) "reduced.c":16 500 {*sne_zero_sisi}
 (expr_list:REG_DEAD (reg:SI 234 [ h ])
(nil)))

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Aug 17 16:50:06 2017
New Revision: 251157

URL: https://gcc.gnu.org/viewcvs?rev=251157&root=gcc&view=rev
Log:
PR c/81859 - [8 Regression] valgrind error from warn_about_normalization

gcc/ChangeLog:

PR c/81859
* pretty-print.c (pp_format): Use strnlen in %.*s to avoid reading
past the end of an array.
(test_pp_format): Add test cases.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/pretty-print.c

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
Fix committed in r251157.

[Bug c++/78919] Lambdas, default parameters and std::function cause assembly error

[jj at stusta dot net]

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

--- Comment #1 from Jonas Jelten  ---
Probably the same as bug 59949, if the default value is always created for a
template even if the call overwrites the default value.

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
I mean simply to build the compiler on a couple of little-endian systems using
fp-bit and make sure that the floating point code works correctly.  I don't
mean test fp-bit separately, though that's not a bad idea.  But if we are going
to change something that has been around for more than ten years, we need to
check that the generated code will continue to work.  I have no reason to think
that it won't work, but we must try it.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov  ---
I don't understand how LIM may deduce that store sinking is safe without
considering may-alias relations. If it is UB to write the same object from
different declared-independent iterations, then I think the correct deduction
would be "iteration count is at most 1", not "store sinking is safe"?


A C++ variation of the test, doesn't need -fno-tree-sra or asm() shenanigans:

void g(int p, int *out)
{
  int x = 0, y;
#pragma GCC ivdep
  for (int i = 0; i < 100; i++)
{
  int &r = p ? x : y;
  r = 42;
  out[i] = x;
}
}

[Bug c/81882] New: attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

Bug ID: 81882
   Summary: attribute ifunc documentation uses invalid code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The documentation of the ifunc ("resolver") attribute in the GCC manual isn't
quite correct.  It advises users to declare the resolver to return a pointer to
a void function returning void, and shows an example of how to do that, like
so:

typedef __SIZE_TYPE__  size_t;

void* my_memcpy (void *dst, const void *src, size_t len)
{
  // ...
  return dst;
}

static void (*resolve_memcpy (void)) (void)
{
  return my_memcpy; // we'll just always select this routine
}

But the example returns the address of a function of incompatible type, which
then causes compilation warnings in C and errors in C++ (see below).

Instead, the resolver should be declared to return a pointer to the a function
of the same type as whose address it returns.

x.c: In function ‘resolve_memcpy’:
x.c:10:10: warning: returning ‘void * (*)(void *, const void *, size_t) {aka
void * (*)(void *, const void *, long unsigned int)}’ from a function with
incompatible return type ‘void (*)(void)’ [-Wincompatible-pointer-types]
   return my_memcpy; // we'll just always select this routine
  ^
At top level:
x.c:8:15: warning: ‘resolve_memcpy’ defined but not used [-Wunused-function]
 static void (*resolve_memcpy (void)) (void)
   ^~

[Bug c/81882] attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-17
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I believe the documentation should be changed like so:

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 251156)
+++ gcc/doc/extend.texi (working copy)
@@ -2783,21 +2783,24 @@ The @code{ifunc} attribute is used to mark a funct
 function using the STT_GNU_IFUNC symbol type extension to the ELF
 standard.  This allows the resolution of the symbol value to be
 determined dynamically at load time, and an optimized version of the
-routine can be selected for the particular processor or other system
+routine to be selected for the particular processor or other system
 characteristics determined then.  To use this attribute, first define
 the implementation functions available, and a resolver function that
 returns a pointer to the selected implementation function.  The
 implementation functions' declarations must match the API of the
-function being implemented, the resolver's declaration is be a
-function returning pointer to void function returning void:
+function being implemented.  The resolver should be declared to
+be a function returning a pointer to a function taking no arguments
+and returning a pointer to a function of the same type as the
+implementation.  For example:

 @smallexample
 void *my_memcpy (void *dst, const void *src, size_t len)
 @{
   @dots{}
+  return dst;
 @}

-static void (*resolve_memcpy (void)) (void)
+static void* (*resolve_memcpy (void))(void *, const void *, size_t)
 @{
   return my_memcpy; // we'll just always select this routine
 @}