[Bug target/71245] std::atomic load/store bounces the data to the stack using fild/fistp

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
(In reply to Uroš Bizjak from comment #2)
> Recently x86 linux changed the barrier to what you propose. If it is worth,
> we can change it without any problems.

I guess it costs a code byte for a disp8 in the addressing mode, but it avoids
adding a lot of latency to a critical path involving a spill/reload to (%esp),
in functions where there is something at (%esp).

If it's an object larger than 4B, the lock orl could even cause a
store-forwarding stall when the object is reloaded.  (e.g. a double or a
vector).

Ideally we could do the  lock orl  on some padding between two locals, or on
something in memory that wasn't going to be loaded soon, to avoid touching more
stack memory (which might be in the next page down).  But we still want to do
it on a cache line that's hot, so going way up above our own stack frame isn't
good either.

> OTOH, we have "orl" here - should we
> change it to "addl" to be consistent with kernel?

That's the common idiom I've seen, but there's no reason I know of to favour
ADD instead of OR.  They both write all the flags, and both can run on any ALU
port on every microarchitecture.  Since gcc has been using OR already with I
assume nobody reporting perf problems, we should keep it.

A 32bit operand size is still a good choice.  (The obvious alternative being
8bit, but that doesn't save any code size.  From Agner Fog's insn tables, I
don't see any different entry for locked instructions with m8 vs. m32 operands,
but naturally-aligned 32bit loads/stores are probably the safest bet.)

[Bug libstdc++/71322] New: std::filesystem::permissions always follows symlinks

[eric at efcs dot ca]

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

Bug ID: 71322
   Summary: std::filesystem::permissions always follows symlinks
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

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

Currently "permissions(sym, perms::none)" resolves the symlink and sets the
permissions on the file. I believe this is incorrect.

[Bug target/71321] New: [6 regression] x86: worse code for uint8_t % 10 and / 10

[peter at cordes dot ca]

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

Bug ID: 71321
   Summary: [6 regression] x86: worse code for uint8_t % 10 and /
10
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: i386-linux-gnu, x86_64-linux-gnu

If we have an integer (0..99), we can modulo and divide by 10 to get two
decimal digits, then convert to a pair of ASCII bytes with a newline by adding
`00\n`.   When replacing div and mod with a multiplicative inverse, gcc 6.1
uses more instructions than gcc 5.3, due to poor choices.

See also https://godbolt.org/g/vvS5J6

#include 
// assuming little-endian
__attribute__((always_inline)) 
unsigned cvt_to_2digit(uint8_t i, uint8_t base) {
  return ((i / base) | (uint32_t)(i % base)<<8);
}
  // movzbl %dil,%eax# 5.3 and 6.1, with -O3 -march=haswell
  // div%sil
  // movzwl %ax,%eax

// at -Os, gcc uses a useless  AND eax, 0xFFF, instead of a movzx eax,ax.  I
think to avoid partial-register stalls?
unsigned cvt_to_2digit_ascii(uint8_t i) {
  return cvt_to_2digit(i, 10) + 0x0a3030;// + "00\n" converts to ASCII
}

Compiling with -O3 -march=haswell
## gcc 5.3 ## gcc 6.1
movzbl  %dil, %edx movzbl  %dil, %eax
leal(%rdx,%rdx,4), %ecxleal0(,%rax,4), %edx   #
requires a 4B zero displacement
leal(%rdx,%rcx,8), %edxmovl%eax, %ecx # lea
should let us avoid mov
leal(%rdx,%rdx,4), %edxaddl%eax, %edx
   leal(%rcx,%rdx,8), %edx
   leal0(,%rdx,4), %eax   #
requires a 4B zero displacement
   addl%eax, %edx
shrw$11, %dx   shrw$11, %dx
leal(%rdx,%rdx,4), %eaxleal0(,%rdx,4), %eax   #
requires a 4B zero displacement.  gcc5.3 didn't use any of these
   addl%edx, %eax
movzbl  %dl, %edx  movzbl  %dl, %edx   # same after
this
addl%eax, %eax addl%eax, %eax
subl%eax, %edi subl%eax, %edi
movzbl  %dil, %eax movzbl  %dil, %eax
sall$8, %eax   sall$8, %eax
orl %eax, %edx orl %eax, %edx
leal667696(%rdx), %eax leal667696(%rdx), %eax

with -mtune=haswell, it's  prob. best to merge with   mov ah, dil  or
something, rather than movzx/shift/or.  Haswell has no penalty for
partial-registers, but still has partial-reg renaming to avoid false
dependencies: the best of both worlds.



BTW, with -Os, both gcc versions compile it to

movb$10, %dl
movzbl  %dil, %eax
divb%dl
andl$4095, %eax  # partial reg stall.  gcc does this even with
-march=core2 where it matters
addl$667696, %eax

The AND appears to be totally useless, because the upper bytes of eax are
already zero (from movzbl %dil, %eax before div).  I thought the movzbl %ax,
%eax  in the unknown-divisor version was to avoid partial-register slowdowns,
but maybe it's just based on the possible range of the result.

Off-topic, but I noticed this while writing FizzBuzz in asm. 
http://stackoverflow.com/a/37494090/224132

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[meissner at gcc dot gnu.org]

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

--- Comment #11 from Michael Meissner  ---
Thanks for the update.

[Bug libstdc++/71320] New: filesystem::permissions does not respect add_perms/remove_perms

[eric at efcs dot ca]

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

Bug ID: 71320
   Summary: filesystem::permissions does not respect
add_perms/remove_perms
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 38585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38585=edit
reproducer.cpp

filesystem::permissions ignores add_perms and remove_perms, instead always
setting the file permissions to the specified value.

For example:

permissions(file, perms::owner_all);
assert(status(file).permissions() == perms::owner_all); // works

// Add some additional permissions
permissions(file, perms::group_all | perms::add_perms);
assert(status(file).permissions() == (perms::owner_all | perms::group_all)); //
FIRES
assert(status(file).permissions() == perms::group_all); // Doesn't fire

[Bug rtl-optimization/71275] [7 regression] Performance drop after r235660 on x86-64 in 32-bit mode.

[amodra at gcc dot gnu.org]

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

--- Comment #6 from Alan Modra  ---
Author: amodra
Date: Sat May 28 00:22:56 2016
New Revision: 236843

URL: https://gcc.gnu.org/viewcvs?rev=236843=gcc=rev
Log:
ira.c bb_loop_depth again

Follow the same practice as other places in ira.c, where
free_dominance_info is called along with loop_optimizer_finalize.  Not
doing so causes an ICE on gcc-5-branch, so avoid that possibility on
trunk.

PR rtl-optimization/71275
* ira.c (ira): Free dominance info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c

[Bug middle-end/71319] unnecessary call to __strcat_chk emitted after buffer reset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-28
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
It doesn't look like GCC has ever performed this optimization (the first case
was optimized sometime between 4.5.3 and 4.9.3).  I'll see if I can make it
work along with bug 71304.

[Bug middle-end/71319] New: unnecessary call to __strcat_chk emitted after buffer reset

[msebor at gcc dot gnu.org]

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

Bug ID: 71319
   Summary: unnecessary call to __strcat_chk emitted after buffer
reset
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 71304, in the following test case, since the string in the
destination buffer is truncated at a known offset after it has been copied
there by the checked call, the subsequent strcat call doesn't need to expand to
a checked call because there is enough space in the buffer to append the source
string to its contents.  GCC performs this optimization in the first test case
(function f) when the string a truncated by calling strcpy, but it doesn't do
the same thing when the string is truncated by inserting a NUL into the same
position.

$ cat strcat.c && /home/msebor/build/gcc-6-branch/gcc/xgcc
-B/home/msebor/build/gcc-6-branch/gcc -O2 -S -fdump-tree-optimized=/dev/stdout
strcat.c
#define strcat(d, s)\
  __builtin___strcat_chk (d, s, __builtin_object_size (d, 0))

#define strcpy(d, s) \
  __builtin___strcpy_chk (d, s, __builtin_object_size (d, 0))

void sink (const char*);

int f (const char *s)
{
  char a [4] = "1";
  strcat (a, "2");   // safe
  strcat (a, s); // must be checked

  strcpy (a, "1");
  strcat (a, "3");   // safe

  sink (a);
}

int g (const char *s)
{
  char a [4] = "1";
  strcat (a, "2");   // safe
  strcat (a, s); // must be checked

  a [1] = '\0';
  strcat (a, "3");   // safe but checked (missing optimization)

  sink (a);
}


;; Function f (f, funcdef_no=0, decl_uid=1758, cgraph_uid=0, symbol_order=0)

f (const char * s)
{
  char a[4];

  :
  a = "1";
  __builtin___strcpy_chk ([(void *) + 2B], s_4(D), 4);
  MEM[(char * {ref-all})] = 49;
  __builtin_memcpy ([(void *) + 1B], "3", 2);
  sink ();
  a ={v} {CLOBBER};
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1762, cgraph_uid=1, symbol_order=1)

g (const char * s)
{
  char a[4];

  :
  a = "1";
  __builtin___strcpy_chk ([(void *) + 2B], s_4(D), 4);
  a[1] = 0;
  __builtin___strcat_chk (, "3", 4);
  sink ();
  a ={v} {CLOBBER};
  return;

}

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
I've been working on this for about 2 weeks and still I don't see the problem
will be solved soon.  Therefore I've decided to write some update.

First of all after analyzing hot functions, I found that LRA generates more
code to load high parts of addresses than the reload pass.  Digging into the
reload pass I found that the reload does an inheritance beyond memory
load/stores and reuse values in pseudos containing an address high part where
it is possible.  This functionality is missed in LRA.  I started to think how
to better implement it in LRA (inheritance or rematerialization) but I came to
the conclusion that the inheritance is the only way to do this. Unfortunately,
inheritance in LRA is a complicated thing and I need to make it even more
complicated.

I almost finished the implementation of the inheritance beyond the spills. 
Unfortunately, I found that even LRA generates fewer insns and loads of address
high parts for the code examples, there are still additional reg-reg moves in
comparison with the code generated by the reload pass.  I think removing these
additional moves will require changes in LRA assignment sub-pass.  Currently
LRA assigns hard registers to reload pseudos first (to guarantee they will get
hard registers in any case) and then to inheritance pseudos.  To remove the
moves, assignment to reload pseudos and inheritance pseudos connected to the
reload pseudos should be assigned at the same time (or one immediately after
another).  It means that we need to able to spill the inheritance pseudos (or
assign it to other registers) if another reload pseudo needs an inheritance
pseudo register.

So I am going to try this new assignment scheme.  ETA for this is June-July.

[Bug middle-end/70988] missing buffer overflow detection in chained strcat calls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-27
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
Testing a patch.

[Bug middle-end/71318] New: Can't disable ISAs via function attribute

[hjl.tools at gmail dot com]

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

Bug ID: 71318
   Summary: Can't disable ISAs via function attribute
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

GCC calls init_optabs to initialize the optabs for the current target
machine before compilation.  It will use them even when they are disabled
by function attribute.

[Bug ada/71317] New: Compiling gnat for rtems fails at s-taprop.adb

[soja-lists at aries dot uberspace.de]

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

Bug ID: 71317
   Summary: Compiling gnat for rtems fails at s-taprop.adb
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: soja-lists at aries dot uberspace.de
  Target Milestone: ---

Recent versions of gnat fail to build for RTEMS because of missing/wrong
declarations in s-osinte-rtems.ads which is inculded in s-taprop.

I will provide a patch for gcc-5, gcc-6 and trunk.

[Bug tree-optimization/71316] New: [7 regression] test case gcc.dg/tree-ssa/ssa-dom-thread-4.c fails starting with r236831

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 71316
   Summary: [7 regression] test case
gcc.dg/tree-ssa/ssa-dom-thread-4.c fails starting with
r236831
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This test case fails on both BE and LE powerpc64.

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c  
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2
-fdump-tree-dom2-details -std=gnu89 -S   -o ssa-dom-thread-4.s(timeout =
300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-dom2-details -std=gnu89 -S -o ssa-dom-thread-4.s
PASS: gcc.dg/tree-ssa/ssa-dom-thread-4.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom2 "Threaded" 1

[Bug c++/60385] confused by earlier errors, bailing out

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  ---
Fixed.

[Bug c++/65608] [meta-bug] friend issues

[paolo.carlini at oracle dot com]

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

Bug 60385 Summary: confused by earlier errors, bailing out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60385

   What|Removed |Added

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

[Bug c++/60385] confused by earlier errors, bailing out

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri May 27 19:19:23 2016
New Revision: 236835

URL: https://gcc.gnu.org/viewcvs?rev=236835=gcc=rev
Log:
/cp
2016-05-27  Paolo Carlini  

PR c++/60385
* name-lookup.c (push_namespace): Return bool, false when pushdecl
fails.
* name-lookup.h (push_namespace): Adjust declaration.
* parser.c (cp_parser_namespace_definition): Check push_namespace
return value.

/testsuite
2016-05-27  Paolo Carlini  

PR c++/60385
* g++.dg/parse/namespace13.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/namespace13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/name-lookup.h
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71245] std::atomic load/store bounces the data to the stack using fild/fistp

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Peter Cordes from comment #0)

> We don't need to allocate any stack space.  We could implement the StoreLoad
> barrier with  lock or $0, -4(%esp) instead of reserving extra stack to avoid
> doing it to our return address (which would introduce extra store-forwarding
> delay before the ret could eventually retire).

This can be trivially implemented in config/i386/sync.md by changing

(define_insn "mfence_nosse"
  [(set (match_operand:BLK 0)
(unspec:BLK [(match_dup 0)] UNSPEC_MFENCE))
   (clobber (reg:CC FLAGS_REG))]
  "!(TARGET_64BIT || TARGET_SSE2)"
  "lock{%;} or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
  [(set_attr "memory" "unknown")])

Recently x86 linux changed the barrier to what you propose. If it is worth, we
can change it without any problems. OTOH, we have "orl" here - should we change
it to "addl" to be consistent with kernel?

[Bug target/71245] std::atomic load/store bounces the data to the stack using fild/fistp

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|c++ |target
   Target Milestone|--- |7.0

[Bug c++/71245] std::atomic load/store bounces the data to the stack using fild/fistp

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-27
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Created attachment 38584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38584=edit
Prototype patch

Attached patch implements a couple of peephole2 patterns that remove unneeded
instructions.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02216.html

[Bug middle-end/71315] missing strlen optimization on a POINTER_PLUS expression

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I pasted the wrong test case in comment #0.  The correct test case is as
follows:

void f (unsigned);

void g (void)
{
char s[] = "1234";

f (__builtin_strlen (s + 1));
f (__builtin_strlen (s + 1));
}

[Bug middle-end/71315] missing strlen optimization on a POINTER_PLUS expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
This optimization was never performed (going as far back as 4.5.3).

[Bug middle-end/71315] New: missing strlen optimization on a POINTER_PLUS expression

[msebor at gcc dot gnu.org]

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

Bug ID: 71315
   Summary: missing strlen optimization on a POINTER_PLUS
expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In addition to bug 71303 and bug 71304, another optimization missing from 
tree-ssa-strlen.c is for calls to strlen with arguments that point past the
first element of a string are not optimized into constants, resulting in
(repeated) calls to strlen with the same argument.

Clang emits optimal code for this test case.

$ cat z.cpp && /build/gcc-6-branch/gcc/xgcc -B /build/gcc-6-branch/gcc -O2 -S
-Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout zz.cpp

template
class C
{
  template
  class C2 { };
};

template<> template
class C::C2 { };
template<> template
class C::C2 { };


;; Function void g() (_Z1gv, funcdef_no=0, decl_uid=2254, cgraph_uid=0,
symbol_order=0)

void g() ()
{
  char s[5];
  long unsigned int _3;
  unsigned int _4;
  long unsigned int _6;
  unsigned int _7;

  :
  s = "1234";
  _3 = __builtin_strlen ([(void *) + 1B]);
  _4 = (unsigned int) _3;
  f (_4);
  _6 = __builtin_strlen ([(void *) + 1B]);
  _7 = (unsigned int) _6;
  f (_7);
  s ={v} {CLOBBER};
  return;

}

[Bug c++/71306] bogus -Wplacement-new with an array element

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02208.html

[Bug tree-optimization/71314] New: test case gcc.dg/tree-ssa/ssa-thread-14.c fails starting with its introduction in r235653

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 71314
   Summary: test case gcc.dg/tree-ssa/ssa-thread-14.c fails
starting with its introduction in r235653
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on powerpc64 on both LE and BE.  It also appears to fail on s390 and
m68k targets from looking at some recent logs.

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c  
-fno-diagnostics-show-caret -fdiagnostics-color=never   -ansi -pedantic-errors
-O2 -fdump-tree-vrp-details -S   -o ssa-thread-14.s(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -ansi -pedantic-errors
-O2 -fdump-tree-vrp-details -S -o ssa-thread-14.s
PASS: gcc.dg/tree-ssa/ssa-thread-14.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-thread-14.c scan-tree-dump-times vrp1 "Threaded jump"
8

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  ---
(In reply to Anatol from comment #5)
> It is a severe compiler issue that stop avr-gcc 6 from using.
> Consider changing "Importance" status to blocker.

It's definite not a "blocker".  "blocker" would mean the issue is so severe
that no toolchain could be released, e.g. because the compiler for a primary or
secondary platform cannot be built.

Moreover, as Senthil pointed out above, the problem can be worked around by
adding -fno-merge-constants to the command options.

Anyway, twiddling the "importance" won't have any effect w.r.t. bug fixing
quality or swiftness...  In the case of avr, that speed is solely determindey
by the number of people that are willing to contribute to avr-gcc...

If all goes well I might have a day or two to work on avr-gcc in June.

[Bug c++/60385] confused by earlier errors, bailing out

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||regehr at cs dot utah.edu

--- Comment #4 from Paolo Carlini  ---
*** Bug 68723 has been marked as a duplicate of this bug. ***

[Bug c++/68723] [4.9/5/6/7 Regression] ice in pop_nested_namespace, at cp/name-lookup.c:3816

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Dup. Being an ICE on invalid, I'm not going to fix it only in trunk.

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

[Bug libstdc++/71313] New: [Filesystem TS] remove_all fails to remove directory contents recursively

[felix.morgner at gmail dot com]

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

Bug ID: 71313
   Summary: [Filesystem TS] remove_all fails to remove directory
contents recursively
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.morgner at gmail dot com
  Target Milestone: ---

Created attachment 38583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38583=edit
Sample code to reproduce the problem

According to the Filesystem TS [fs.op.remove_all], remove_all should
recursively remove the contents of the given file.

From the final draft:

...
Recursively deletes the contents of p if it exists, then deletes file p
itself, as if by POSIX remove().
...

The current implementation in libstdc++-v3 (libstdc++fs) fails to do so.

The following code:

#include 

#include 
#include 

namespace fs = std::experimental::filesystem;

int main() try
  {
  auto const kDirectory = fs::path("dtop");
  create_directory(kDirectory);
  create_directory(kDirectory / "dsub");
  std::ofstream out{kDirectory / "dsub" / "file"};
  out.close();
  fs::remove_all(kDirectory);
  }
catch(fs::filesystem_error const & e)
  {
  std::cout << "Error: " << e.what() << '\n';
  }

produces the following output:

Error: filesystem error: cannot remove all: Directory not empty [dtop]

I assume that the bug is caused by 4 missing characters in 'filesystem/ops.cc'.
From the current HEAD:

std::uintmax_t
fs::remove_all(const path& p, error_code& ec) noexcept
{
  auto fs = symlink_status(p, ec);
  uintmax_t count = 0;
  if (ec.value() == 0 && fs.type() == file_type::directory)
for (directory_iterator d(p, ec), end; ec.value() == 0 && d != end;
++d)
  count += fs::remove(d->path(), ec);
  if (ec.value())
return -1;
  return fs::remove(p, ec) ? ++count : -1;  // fs:remove() calls ec.clear()
}

I believe that the line

count += fs::remove(d->path(), ec);

should really be

count += fs::remove_all(d->path(), ec);

[Bug c++/69855] Missing diagnostic for overload that only differs by return type

[ville at gcc dot gnu.org]

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

--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Fri May 27 14:59:01 2016
New Revision: 236826

URL: https://gcc.gnu.org/viewcvs?rev=236826=gcc=rev
Log:
/cp
PR c++/69855
* name-lookup.c (pushdecl_maybe_friend_1): Push local function
decls into the global scope after stripping template bits
and setting DECL_ANTICIPATED.

/testsuite
PR c++/69855
* g++.dg/overload/69855.C: New.
* g++.old-deja/g++.law/missed-error2.C: Adjust.
* g++.old-deja/g++.pt/crash3.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/overload/69855.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.law/missed-error2.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/crash3.C

[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #12 from Eric Gallager  ---
This seems to be fixed on trunk.

[Bug libstdc++/71312] New: mutexes for shared_ptr atomics should be padded to cacheline size

[redi at gcc dot gnu.org]

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

Bug ID: 71312
   Summary: mutexes for shared_ptr atomics should be padded to
cacheline size
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

src/c++11/shared_ptr.cc has:

__gnu_cxx::__mutex&
get_mutex(unsigned char i)
{
  static __gnu_cxx::__mutex m[mask + 1];
  return m[i];
}

This should be:

__gnu_cxx::__mutex&
get_mutex(unsigned char i)
{
  struct M {
alignas(C) __gnu_cxx::__mutex mx;
  };
  static M m[mask + 1];
  return m[i].mx;
}

where C == std::hardware_destructive_interference_size

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville at gcc dot gnu.org]

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

--- Comment #9 from ville at gcc dot gnu.org ---
Author: ville
Date: Fri May 27 14:08:37 2016
New Revision: 236822

URL: https://gcc.gnu.org/viewcvs?rev=236822=gcc=rev
Log:
2016-05-24  Ville Voutilainen  

PR libstdc++/66338
* include/std/tuple (_TMC): Add a check for _NotSameTuple.
* include/std/tuple (tuple(_UElements&&...)): Remove the separate
check for _NotSameTuple.
* include/std/tuple (_TMCT): New.
* include/std/tuple (tuple(const tuple<_UElements...>&)): Use it.
* include/std/tuple (tuple(tuple<_UElements...>&&)): Likewise.
* include/std/tuple (tuple(allocator_arg_t, const _Alloc&,
  const tuple<_UElements...>&)): Likewise.
* include/std/tuple (tuple(allocator_arg_t, const _Alloc&,
  tuple<_UElements...>&&)): Likewise.
* testsuite/20_util/tuple/cons/66338.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/66338.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple

[Bug rtl-optimization/71309] Copying fields within a struct followed by use results in load hit store

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-27
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
Confirmed based on Segher's comment.

[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #6 from Jiong Wang  ---
fixed.

[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used

[jiwang at gcc dot gnu.org]

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

--- Comment #5 from Jiong Wang  ---
Author: jiwang
Date: Fri May 27 13:05:34 2016
New Revision: 236819

URL: https://gcc.gnu.org/viewcvs?rev=236819=gcc=rev
Log:
[AArch64] PR target/63596, honor tree-stdarg analysis result to improve VAARG
codegen

gcc/
PR target/63596
* config/aarch64/aarch64.c (aarch64_expand_builtin_va_start): Honor
tree-stdarg analysis results.
(aarch64_setup_incoming_varargs): Likewise.

gcc/testsuite/
* gcc.target/aarch64/va_arg_1.c: New testcase.
* gcc.target/aarch64/va_arg_2.c: Likewise.
* gcc.target/aarch64/va_arg_3.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/va_arg_1.c
trunk/gcc/testsuite/gcc.target/aarch64/va_arg_2.c
trunk/gcc/testsuite/gcc.target/aarch64/va_arg_3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71310] Bitfields cause load hit store with smaller store and larger load

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-27
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
At expand time this is

  skb_5(D)->csum_valid = 1;
  _1 = BIT_FIELD_REF <*skb_5(D), 64, 64>;
  _2 = _1 & 27021597764222976;
  _7 = _2 != 0;
  _8 = (int) _7;
  return _8;

The RMW of writing csum_valid is done as a SImode memory access.
The BIT_FIELD_REF is DImode however.  Why?

[Bug middle-end/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-27
 CC||izamyatin at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug middle-end/71311] New: [7 Regression] spec2006 test case 416.gamess fails since r235817

[rguenth at gcc dot gnu.org]

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

Bug ID: 71311
   Summary: [7 Regression] spec2006 test case 416.gamess fails
since r235817
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We currently observe miscompare for x86 (32 and 64 bits) and bisect points to
r235817.

No source bisecting yet, however

[Bug target/71310] Bitfields cause load hit store with smaller store and larger load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
bit-field-lowering avoids this by lowering the store to a RMW of
the DECL_BIT_FIELD_REPRESENTATIVE and the load to a read of it plus a bit
extraction from the loaded word (so it ends up as a store after a load).

[Bug rtl-optimization/71309] Copying fields within a struct followed by use results in load hit store

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #1 from Segher Boessenkool  ---
At gimple level, this is

  nd_2(D)->path = nd_2(D)->root;
  d_4 = nd_2(D)->path.dentry;
  return d_4;

For 64-bit powerpc, this is expanded to a TImode move, followed by
a DImode load.  The TImode moves aren't split into DImode until after
reload, for powerpc anyway.  For BE, the load is optimised away by dse1:

trying to replace DImode load in insn 9 from TImode store in insn 8
deferring rescan insn with uid = 9.
deferring rescan insn with uid = 17.
 -- replaced the loaded MEM with (reg 161)

but not for LE:

trying to replace DImode load in insn 9 from TImode store in insn 8
 -- could not extract bits of stored value

32-bit already expands as two SImode moves, so there is no problem there.

[Bug target/71310] New: Bitfields cause load hit store with smaller store and larger load

[anton at samba dot org]

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

Bug ID: 71310
   Summary: Bitfields cause load hit store with smaller store and
larger load
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

The following testcase built on ppc64le:

typedef unsigned char __u8;

struct sk_buff {
void*junk;

__u8pkt_type:3;
__u8pfmemalloc:1;
__u8ignore_df:1;
__u8nfctinfo:3;

__u8nf_trace:1;
__u8ip_summed:2;
__u8ooo_okay:1;
__u8l4_hash:1;
__u8sw_hash:1;
__u8wifi_acked_valid:1;
__u8wifi_acked:1;

__u8no_fcs:1;
__u8encapsulation:1;
__u8encap_hdr_csum:1;
__u8csum_valid:1;
};

int foo(struct sk_buff *skb)
{
skb->csum_valid = 1;

if (skb->ip_summed)
return 1;

return 0;
}

Results in a LHS, where the load is larger than the previous store:

lwz 9,8(3)
ori 9,9,0x1000
stw 9,8(3)
ori 2,2,0
ld 9,8(3)
rldicr 9,9,9,54
rldicr 9,9,55,10
addic 3,9,-1
subfe 3,3,9
blr

This may trip up the load hit store forwarding and require the store to hit the
L2 before the load can proceed.

[Bug middle-end/71308] [7 Regression] ICE (segfault) in in gimple_fold_call gimple-fold.c:3060

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri May 27 12:08:03 2016
New Revision: 236815

URL: https://gcc.gnu.org/viewcvs?rev=236815=gcc=rev
Log:
PR middle-end/71308
* gimple-fold.c (gimple_fold_call): Check that LHS is not null.

* g++.dg/torture/pr71308.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr71308.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71308] [7 Regression] ICE (segfault) in in gimple_fold_call gimple-fold.c:3060

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/71309] New: Copying fields within a struct followed by use results in load hit store

[anton at samba dot org]

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

Bug ID: 71309
   Summary: Copying fields within a struct followed by use results
in load hit store
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

When chasing down a LHS on ppc64le, I found the following issue:

struct path {
void *mnt;
void *dentry;
};

struct nameidata {
struct path path;
struct path root;
};

void *foo(struct nameidata *nd)
{
void *d;

nd->path = nd->root;
d = nd->path.dentry;

return d;
}

On little endian we get:

ld 11,24(3)
ld 10,16(3)
std 11,8(3)
std 10,0(3)
ori 2,2,0
ld 3,8(3)
blr

Strangely big endian is fine:

ld 3,24(3)
ld 10,16(9)
std 3,8(9)
std 10,0(9)
blr

[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127

[robertgjenssen at gmail dot com]

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

--- Comment #9 from robertgjenssen at gmail dot com ---
The following apply to the log file attached in comment 8 (they got lost when I
added the attachment):

I triggered a similar problem by trying to build current octave sources with
LTO and address-sanitizer:

hg clone http://hg.savannah.gnu.org/hgweb/octave/
cd octave
./bootstrap
mkdir build
cd build
export CFLAGS="-O3 -march=nehalem -flto -ffat-lto-objects" 
export CXXFLAGS="-O3 -march=nehalem -flto -ffat-lto-objects"
../configure --without-fltk --disable-java --enable-bounds-check \
 --disable-docs --enable-address-sanitizer-flags \ 
 --prefix=/usr/local/octave --program-prefix=asan-
make -j 6

My uname and gcc version are:

build# uname -a
Linux morgawr 4.4.9-300.fc23.x86_64 #1 SMP Wed May 4 23:56:27 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
build# g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--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
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC) 

The build fails with:

lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1164
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

A log file is attached.

[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127

[robertgjenssen at gmail dot com]

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

robertgjenssen at gmail dot com changed:

   What|Removed |Added

 CC||robertgjenssen at gmail dot com

--- Comment #8 from robertgjenssen at gmail dot com ---
Created attachment 38582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38582=edit
Log file for failure building octave with LTO and address-sanitizer

[Bug c/71255] Implement #pragma may_alias

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de  ---
On Fri, 27 May 2016, fw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
> 
> --- Comment #18 from Florian Weimer  ---
> (In reply to rguent...@suse.de from comment #17)
> > On Fri, 27 May 2016, fw at gcc dot gnu.org wrote:
> > > I think the real question is whether it matters anywhere if a pointer to 
> > > an
> > > incomplete struct has the may_alias attribute or not.
> > 
> > As we can't dereference it it doesn't matter I think.
> 
> Does a cast discard the may_alias status from a pointer?

Yes.

>  What about LTO? 
> Could the lack of the may_alias attribute propagate across a TU boundary to
> code which has a complete definition of the struct?

No.

[Bug c/71255] Implement #pragma may_alias

[fw at gcc dot gnu.org]

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

--- Comment #18 from Florian Weimer  ---
(In reply to rguent...@suse.de from comment #17)
> On Fri, 27 May 2016, fw at gcc dot gnu.org wrote:
> > I think the real question is whether it matters anywhere if a pointer to an
> > incomplete struct has the may_alias attribute or not.
> 
> As we can't dereference it it doesn't matter I think.

Does a cast discard the may_alias status from a pointer?  What about LTO? 
Could the lack of the may_alias attribute propagate across a TU boundary to
code which has a complete definition of the struct?

[Bug c/71255] Implement #pragma may_alias

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Fri, 27 May 2016, fw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
> 
> --- Comment #16 from Florian Weimer  ---
> (In reply to Marek Polacek from comment #15)
> > Yeah, only the C++ side was changed.  I think it's wrong that we reject the
> > testcase in Comment 14 in C (I have a fix for that).
> 
> Good.
> 
> > But even with that fixed we still need the new #pragma because of the second
> > testcase in Comment 13, right?
> 
> I'm surprised this is even valid C.  The test case as-is does not seem 
> relevant
> to the glibc usage scenario because all completions would use the may_alias
> attribute.  Only some forward declarations would not.  This could be a 
> relevant
> fringe case we need to support:
> 
> struct S s;
> struct __attribute__((may_alias)) S { int i; };
> 
> Although it can only arise if there is a definition *before* including the
> relevant header file.
> 
> I think the real question is whether it matters anywhere if a pointer to an
> incomplete struct has the may_alias attribute or not.

As we can't dereference it it doesn't matter I think.

[Bug c/71255] Implement #pragma may_alias

[fw at gcc dot gnu.org]

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

--- Comment #16 from Florian Weimer  ---
(In reply to Marek Polacek from comment #15)
> Yeah, only the C++ side was changed.  I think it's wrong that we reject the
> testcase in Comment 14 in C (I have a fix for that).

Good.

> But even with that fixed we still need the new #pragma because of the second
> testcase in Comment 13, right?

I'm surprised this is even valid C.  The test case as-is does not seem relevant
to the glibc usage scenario because all completions would use the may_alias
attribute.  Only some forward declarations would not.  This could be a relevant
fringe case we need to support:

struct S s;
struct __attribute__((may_alias)) S { int i; };

Although it can only arise if there is a definition *before* including the
relevant header file.

I think the real question is whether it matters anywhere if a pointer to an
incomplete struct has the may_alias attribute or not.

[Bug middle-end/71308] [7 Regression] ICE (segfault) in in gimple_fold_call gimple-fold.c:3060

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/71308] [7 Regression] ICE (segfault) in in gimple_fold_call gimple-fold.c:3060

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Ah, that must be mine :(.
Fix:
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -3053,7 +3053,8 @@ gimple_fold_call (gimple_stmt_iterator *gsi, bool
inplace)
  == void_type_node))
gimple_call_set_fntype (stmt, TREE_TYPE (fndecl));
  /* If the call becomes noreturn, remove the lhs.  */
- if (gimple_call_noreturn_p (stmt)
+ if (lhs
+ && gimple_call_noreturn_p (stmt)
  && (VOID_TYPE_P (TREE_TYPE (gimple_call_fntype (stmt)))
  || should_remove_lhs_p (lhs)))
{

[Bug middle-end/71308] [7 Regression] ICE (segfault) in in gimple_fold_call gimple-fold.c:3060

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-27
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug middle-end/71308] New: [7 Regression] ICE (segfault) in in gimple_fold_call gimple-fold.c:3060

[burnus at gcc dot gnu.org]

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

Bug ID: 71308
   Summary: [7 Regression] ICE (segfault) in in gimple_fold_call
gimple-fold.c:3060
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Compiling the following program with
  g++ -O2 input13.ii

fails with

input13.ii:15:1: internal compiler error: Segmentation fault
 }
 ^
0xd870bf crash_signal
../../gcc/toplev.c:333
0xb12c20 gimple_fold_call
../../gcc/gimple-fold.c:3060
0xb12c20 fold_stmt_1
../../gcc/gimple-fold.c:3778
0xdf737b fold_marked_statements
../../gcc/tree-inline.c:4925
0xe05d54 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5005
0x144b131 early_inliner(function*)
../../gcc/ipa-inline.c:2724

//== Test program:
class RubberBase
{
  void _undraw ();
  virtual void draw () = 0;
  virtual ~ RubberBase ();
};
inline void
RubberBase::_undraw ()
{
  draw ();
};
RubberBase::~RubberBase ()
{
_undraw ();
}

[Bug middle-end/71279] [6/7 Regression] ICE on trunk gcc with knl target

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #6 from Ilya Enkovich  ---
Fixed

[Bug middle-end/71279] [6/7 Regression] ICE on trunk gcc with knl target

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri May 27 10:43:34 2016
New Revision: 236811

URL: https://gcc.gnu.org/viewcvs?rev=236811=gcc=rev
Log:
gcc/

Backport from mainline r236810.
2016-05-27  Ilya Enkovich  

PR middle-end/71279
* fold-const.c (fold_ternary_loc): Don't fold VEC_COND_EXPR
into comparison.

gcc/testsuite/

Backport from mainline r236810.
2016-05-27  Ilya Enkovich  

PR middle-end/71279
* gcc.dg/pr71279.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr71279.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71279] [6/7 Regression] ICE on trunk gcc with knl target

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri May 27 10:39:40 2016
New Revision: 236810

URL: https://gcc.gnu.org/viewcvs?rev=236810=gcc=rev
Log:
gcc/

PR middle-end/71279
* fold-const.c (fold_ternary_loc): Don't fold VEC_COND_EXPR
into comparison.

gcc/testsuite/

PR middle-end/71279
* gcc.dg/pr71279.c: New test.

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

[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 26 May 2016, andre.simoesdiasvieira at arm dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237
> 
> --- Comment #1 from Andre Vieira  ---
> So yes disabling LIM will make the tests "PASS". Though I couldnt find an
> option to do this, I disabled the pass by changing passes.def, so that doesnt
> sound like a good idea to test SCCP. 

-fno-tree-loop-im

> However, it might be good to point out that at least for arm-none-eabi and
> x86_64-pc-linux-gnu these tests are no longer testing SCCP, SCCP will not
> change this code. I looked at the dumps and compared assembly of -O2 with and
> without '-fno-tree-scev-cprop'.

Yeah, so we're likely looking at bit-rotten SCCP tests ... :/

> On arm-none-eabi, it used to be IVOPTS that made the test pass, it would 
> reuse the same ivtmp for computing the address used by the memory 
> dereference and the a_p assignment. Now due to the reordering of LIM, it 
> will no longer do this.
> 
> On x86_64 I see the following code coming out of the OPTIMIZED dump for the
> scev-4.c case:
> 
> ...
>   :
>   # ivtmp.10_14 = PHI <_24(3), ivtmp.10_25(4)>
>   i_11 = (int) ivtmp.10_14;
>   MEM[symbol: a, index: ivtmp.10_14, step: 8, offset: 4B] = 100;
>   ivtmp.10_25 = ivtmp.10_14 + _24;
>   i_22 = (int) ivtmp.10_25;
>   if (i_22 <= 999)
> goto ;
>   else
> goto ;
> 
>   :
>   _2 = (sizetype) i_11;
>   _3 = _2 * 8;
>   _10 = _3 + 4;
>   _1 =  + _10;
>   a_p = _1;
> ...
> 
> Now yes the scan-times  will pass, but thats because the MEM is using
> symbol:a instead of base:  Not sure this can be qualified as a proper PASS.
> Disabling LIM here the same way I did before, that is removing the pass_lim
> after pass_laddress and before pass_split_crit_edges generates the following
> OPTIMIZED dump:
> 
> ...
>   :
>   _16 = (sizetype) k_4(D);
>   _15 = _16 * 8;
>   _21 = _15 + 4;
>   _22 =  + _21;
>   ivtmp.9_14 = (unsigned long) _22;
> 
>   :
>   # i_11 = PHI 
>   # ivtmp.9_13 = PHI 
>   _1 = (int *) ivtmp.9_13;
>   MEM[base: _1, offset: 0B] = 100;
>   i_8 = k_4(D) + i_11;
>   ivtmp.9_17 = ivtmp.9_13 + _15;
>   if (i_8 <= 999)
> goto ;
>   else
> goto ;
> 
>   :
>   a_p = _1;
> ...
> 
> I prefer this output, since you loose the needless tailing address 
> calculation. I am not so sure the eventually generated assembly is 
> better in this case though. Ill add both as attachments.

Yes, in a more complicated loop with more register pressure the
new variant could be better.

That said, it would be interesting to see what the testcase originally
was added for and if we can massage it to test that again.

[Bug c++/60385] confused by earlier errors, bailing out

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
c++/68723 is related

[Bug c++/68929] GCC hangs in nested template instantiations even after static_assert fails.

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Seems related to c++/55722

[Bug tree-optimization/71307] [7 Regression] Code quality regression with lane extraction arm_neon.h intrinsics on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
If the BIT_FIELD_REF covers the whole object then it should be simplified to
a VIEW_CONVERT.  There is "related" simplification in match.pd:

(simplify
 (BIT_FIELD_REF @0 @1 @2)
 (switch
  (if (TREE_CODE (TREE_TYPE (@0)) == COMPLEX_TYPE
   && tree_int_cst_equal (@1, TYPE_SIZE (TREE_TYPE (TREE_TYPE (@0)
   (switch
(if (integer_zerop (@2))
 (view_convert (realpart @0)))
(if (tree_int_cst_equal (@2, TYPE_SIZE (TREE_TYPE (TREE_TYPE (@0)
 (view_convert (imagpart @0)
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
   && INTEGRAL_TYPE_P (type)
   /* On GIMPLE this should only apply to register arguments.  */
   && (! GIMPLE || is_gimple_reg (@0))
   /* A bit-field-ref that referenced the full argument can be stripped. 
*/
   && ((compare_tree_int (@1, TYPE_PRECISION (TREE_TYPE (@0))) == 0
&& integer_zerop (@2))
...
   (convert @0

but restricted to integral types as we use convert and not view_convert.

Other than that, BIT_FIELD_REF expansion might simply miss a trick.

[Bug tree-optimization/71307] [7 Regression] Code quality regression with lane extraction arm_neon.h intrinsics on aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.1.0
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug tree-optimization/71307] New: [7 Regression] Code quality regression with lane extraction arm_neon.h intrinsics on aarch64

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71307
   Summary: [7 Regression] Code quality regression with lane
extraction arm_neon.h intrinsics on aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

After r236630 I'm seeing the following testcase regress on aarch64 at -O2:

#include "arm_neon.h"

float64x1_t
test_copy_laneq_f64 (float64x1_t a, float64x2_t b)
{
  return vset_lane_f64 (vgetq_lane_f64 (b, 1), a, 0);
}

Before the commit it would generate a single:
test_copy_laneq_f64:
dup d0, v1.d[1]
ret

but now on current trunk the codegen is:
test_copy_laneq_f64:
umovx0, v1.d[1]
fmovd0, x0
ret


The optimised tree dump from the "good" case is:
test_copy_laneq_f64 (float64x1_t a, float64x2_t b)
{
  float64x1_t __vec;
  double _4;

  :
  __builtin_aarch64_im_lane_boundsi (16, 8, 1);
  _4 = BIT_FIELD_REF ;
  __builtin_aarch64_im_lane_boundsi (8, 8, 0);
  __vec_7 = VIEW_CONVERT_EXPR(_4);
  return __vec_7;

}

and in the "bad" case it's:
test_copy_laneq_f64 (float64x1_t a, float64x2_t b)
{
  __Float64x1_t _4;
  double _5;

  :
  __builtin_aarch64_im_lane_boundsi (16, 8, 1);
  _5 = BIT_FIELD_REF ;
  __builtin_aarch64_im_lane_boundsi (8, 8, 0);
  _4 = BIT_FIELD_REF <_5, 64, 0>;
  return _4;

}

Is there something that the target needs to do to handle BIT_FIELD_REFs?

[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-27
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Looks good - so leaving to target folks to investigate.

[Bug c++/60385] confused by earlier errors, bailing out

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Looking into it.

[Bug middle-end/71279] [6/7 Regression] ICE on trunk gcc with knl target

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/71281] [7 Regression] ICE on gcc trunk on knl, wsm, ivb and bdw targets (tree-ssa-reassoc)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on gcc trunk on knl,|[7 Regression] ICE on gcc
   |wsm, ivb and bdw targets|trunk on knl, wsm, ivb and
   |(tree-ssa-reassoc)  |bdw targets
   ||(tree-ssa-reassoc)

[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135

[vekumar at gcc dot gnu.org]

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

--- Comment #5 from vekumar at gcc dot gnu.org ---
The expand dump after SLP split 

---snip--
;; MEM[(logical(kind=1) *)] = { 1, 0, 1, 0 };

(insn 71 70 72 (set (reg:SI 308)
(const_int 16777472 [0x1000100])) intrinsic_pack_1.f90:49 -1
 (nil))

(insn 72 71 0 (set (mem/c:SI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -576 [0xfdc0])) [8
MEM[(logical(kind=1)D.7 *)]+0 S4 A64])
(reg:SI 308)) intrinsic_pack_1.f90:49 -1
 (nil))

;; MEM[(logical(kind=1) *) + 4B] = { 1, 0, 1, 0 };

(insn 73 72 74 (set (reg:SI 309)
(const_int 16777472 [0x1000100])) intrinsic_pack_1.f90:49 -1
 (nil))

(insn 74 73 0 (set (mem/c:SI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -572 [0xfdc4])) [8
MEM[(logical(kind=1)D.7 *) + 4B]+0 S4 A32])
(reg:SI 309)) intrinsic_pack_1.f90:49 -1
 (nil))

;; MEM[(logical(kind=1)[9] *)][8] = 1;

(insn 75 74 76 (set (reg:SI 310)
(const_int 1 [0x1])) intrinsic_pack_1.f90:49 -1
 (nil))

(insn 76 75 77 (set (reg:QI 311)
(subreg:QI (reg:SI 310) 3)) intrinsic_pack_1.f90:49 -1
 (nil))

(insn 77 76 0 (set (mem/c:QI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -568 [0xfdc8])) [8 A.8D.3679+8 S1 A64])
(reg:QI 311)) intrinsic_pack_1.f90:49 -1
 (nil))
--snip---

[Bug c++/71285] [7 regression] spurious 'insufficient contextual information' for member access on fold expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/71286] 6.1.0: compiling djgpp programs with LTO emits "visibility attribute not supported in this configuration" warnings

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto

--- Comment #1 from Richard Biener  ---
LTO requires visibility support of some sort.

[Bug tree-optimization/71261] [7 Regression] Trunk GCC hangs on knl and broadwell targets

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Created attachment 38581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38581=edit
incomplete patch

Attached my work-in progress to remove bool fixup in favor of improving bool
pattern recognition.

Still has some testsuite ICEs:

FAIL: c-c++-common/cilk-plus/AN/if_test.c  -O2 -ftree-vectorize -fcilkplus
(internal compiler error)
...
FAIL: gcc.c-torture/compile/pr53410-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/921013-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gcc.dg/pr50310-1.c (internal compiler error)
FAIL: gcc.dg/pr50310-1.c (test for excess errors)
WARNING: gcc.dg/pr50310-1.c compilation failed to produce executable
FAIL: gcc.dg/pr64087.c (internal compiler error)
FAIL: gcc.dg/pr64087.c (test for excess errors)
FAIL: gcc.dg/pr70026.c (internal compiler error)
FAIL: gcc.dg/pr70026.c (test for excess errors)
...
(and some more)

[Bug tree-optimization/71261] [7 Regression] Trunk GCC hangs on knl and broadwell targets

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

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

[Bug tree-optimization/71288] [7 Regression] Time and memory hog during if-conversion at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Dup.

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

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #7 from Jonathan Wakely  ---
This is caused by --with-gxx-include-dir

Configured with: /home/jwakely/src/gcc/gcc-6/configure --prefix=/tmp/6
--with-gxx-include-dir=/tmp/6/include/c++/6.1.1 [...]

ignoring nonexistent directory
"/tmp/6/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/6/include/c++/6.1.1
 /tmp/6/include/c++/6.1.1/x86_64-pc-linux-gnu
 /tmp/6/include/c++/6.1.1/backward
 /tmp/6/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
 /usr/local/include
 /tmp/6/include
 /tmp/6/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 6.1.1 20160526 (x86_64-pc-linux-gnu)

Relocated:

ignoring nonexistent directory
"/tmp/reloc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/tmp/reloc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.1/include"
ignoring duplicate directory
"/tmp/reloc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed"
ignoring nonexistent directory
"/tmp/reloc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/reloc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
 /tmp/reloc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
 /tmp/reloc/bin/../lib/gcc/../../include/c++/6.1.1
 /tmp/reloc/bin/../lib/gcc/../../include/c++/6.1.1/x86_64-pc-linux-gnu
 /tmp/reloc/bin/../lib/gcc/../../include/c++/6.1.1/backward
 /usr/local/include
 /tmp/reloc/bin/../lib/gcc/../../include
 /usr/include
End of search list.

[Bug c++/71290] [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug target/71293] [7 regression] test case gcc.dg/plugin/must-tail-call-2.c fails starting with r236514

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug tree-optimization/71299] [7 regression] test case gcc.dg/torture/pr69909.c fails with ICE starting with r236634

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/71303] missing strlen optimization for strings initialized via a braced-init-list

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
IMHO we should make sure that the braced-init becomes a STRING_CST very early.

[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #4 from Richard Biener  ---
  MEM[(logical(kind=1)D.7 *)_769] = vect_cst__873;
  # .MEM_1440 = VDEF <.MEM_777>
  MEM[(logical(kind=1)D.7[9] *)][8] = 1;

there's different alias-ptr types.  Can you double-check that RTL expansion
produces MEMs with the same MEM_ALIAS_SET?

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
For the record, the test gfortran.dg/pr71252.f90 still fails at revision
r236796 on x86_64-apple-darwin15.

[Bug c++/71251] [5/6/7 regression] ICE on invalid code, with unusual template name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug c++/71274] [5/6/7 Regression] deprecated static const member of struct raises warning without use

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug c/71115] [4.9/5/6 Regression] Missing warning: excess elements in struct initializer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug lto/70929] [4.9/5/6/7 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |6.1.0
   Target Milestone|--- |4.9.4

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug rtl-optimization/70224] [5 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||6.1.0

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[lh_mouse at 126 dot com]

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

--- Comment #6 from lh_mouse  ---
(In reply to Jonathan Wakely from comment #4)
> Please provide the missing information that https://gcc.gnu.org/bugs/ asks
> for, so we know how you configured GCC.

The following command shows how gcc has been configured:
```
E:\>i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw
32/i686-w64-mingw32/include --libexecdir=/mingw32/lib
--with-gxx-include-dir=/mingw32/include/c++/6.1.1 --enable-bootstrap
--with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++ --enable-sh
ared --enable-static --enable-libatomic --enable-threads=mcf --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-vers
ion-specific-runtime-libs --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror
 --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32
--with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32
--with-pkgversion='gcc-6-branch HEAD with MCF thread model, built
 by LH_Mouse.' --with-bugurl=http://cpp.ra2diy.com/ --with-gnu-as --with-gnu-ld
--disable-tls --disable-sjlj-exceptions --with-dwarf2
Thread model: mcf
gcc version 6.1.1 20160511 (gcc-6-branch HEAD with MCF thread model, built by
LH_Mouse.)
```



A minimal testcase with a relocated toolchain is:
```
LH_Mouse@LH-PC  /mingw32/bin
$ echo '#include ' | g++ -v -x c++ -
Using built-in specs.
COLLECT_GCC=C:\new_directory\MSYS2\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw
32/i686-w64-mingw32/include --libexecdir=/mingw32/lib
--with-gxx-include-dir=/mingw32/include/c++/6.1.1 --enable-bootstrap
--with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++ --enable-sh
ared --enable-static --enable-libatomic --enable-threads=mcf --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-vers
ion-specific-runtime-libs --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror
 --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32
--with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32
--with-pkgversion='gcc-6-branch HEAD with MCF thread model, built
 by LH_Mouse.' --with-bugurl=http://cpp.ra2diy.com/ --with-gnu-as --with-gnu-ld
--disable-tls --disable-sjlj-exceptions --with-dwarf2
Thread model: mcf
gcc version 6.1.1 20160511 (gcc-6-branch HEAD with MCF thread model, built by
LH_Mouse.)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686'

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/cc1plus.exe
-quiet -v -iprefix
C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/
-U_REENTRANT - -quiet -dumpba
se - -mtune=generic -march=i686 -auxbase - -version -o
C:\Users\LH_Mouse\AppData\Local\Temp\ccUWITfc.s
GNU C++14 (gcc-6-branch HEAD with MCF thread model, built by LH_Mouse.) version
6.1.1 20160511 (i686-w64-mingw32)
compiled by GNU C version 6.1.1 20160511, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/new_directory/MSYS2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include"
ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include"
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory
"C:/new_directory/MSYS2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed"
ignoring duplicate directory
"C:/new_directory/MSYS2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory
"C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../include

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[gk at torproject dot org]

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

--- Comment #7 from Georg Koppen  ---
(In reply to Martin Liška from comment #6)
> (In reply to Georg Koppen from comment #3)
> > Created attachment 38573 [details]
> > ASan stack trace
> > 
> > This is https://bugzilla.mozilla.org/show_bug.cgi?id=1268854 and attached is
> > the ASan stack trace to begin with.
> 
> Even thought I'm logged in, I'm not authorized to see the issue.
> Can you please past the stack trace here?

It's already attached to this bug:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=38573.

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||i686-w64-mingw32

--- Comment #5 from Jonathan Wakely  ---
(In reply to lh_mouse from comment #0)
> The following message is copied from
> https://gcc.gnu.org/ml/gcc/2016-05/msg3.html
> ```
> 
> This is a cross-post from gcc-help as there haven't been any replies on
> gcc-help since two days ago. Hope someone could help.
> ```
> 
> I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows
> today.
> Now I have a relocation problem:
> 
> Assuming mingw-w64 headers are located in the follow directory,which is, the
> native_system_header_dir:
> > C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
> I have built GCC and it has that hard-coded path.
> When I compile something using g++ -v, the headers are searched in the
> following paths:
> ```
> ignoring nonexistent directory "/mingw32/include"
> ignoring duplicate directory
> "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  C:/MinGW/MSYS2/mingw32/include/c++/6.1.1
>  C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/i686-w64-mingw32
>  C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/backward
>  C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
>  C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../include
>  C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include-fixed
>  C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-
> mingw32/include
> End of search list.
> ```
> The C++ headers are searched before any mingw-w64 headers, which is just
> fine.
> 
> However, if I move gcc to another directory, let's say,
> C:/this_is_a_new_directory/mingw32/,
> then re-compile the same program with g++ -v, the headers are searched in
> the following paths:
> ```
> ignoring duplicate directory
> "C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.
> 1.1/include"
> ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include"
> ignoring nonexistent directory "/mingw32/include"
> ignoring duplicate directory
> "C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.
> 1.1/include-fixed"
> ignoring duplicate directory
> "C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.
> 1.1/../../../../i686-w64-mingw32/include"
> ignoring nonexistent directory
> "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/
> include
>  C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../
> ../../../include
>  C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/
> include-fixed
>  C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../
> ../../../i686-w64-mingw32/include
>  C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1
>  C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/i686-w64-
> mingw32
>  C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/backward
> End of search list.
> ```
> This time the C++ headers are searched after mingw-w64 headers, which causes
> the following error:
> ```
> In file included from
> C:/MinGW/mingw32/include/c++/6.1.1/ext/string_conversions.h:41:0,
>  from
> C:/MinGW/mingw32/include/c++/6.1.1/bits/basic_string.h:5402,
>  from C:/MinGW/mingw32/include/c++/6.1.1/string:52,
>  from
> C:/MinGW/mingw32/include/c++/6.1.1/bits/locale_classes.h:40,
>  from C:/MinGW/mingw32/include/c++/6.1.1/bits/ios_base.h:41,
>  from C:/MinGW/mingw32/include/c++/6.1.1/ios:42,
>  from C:/MinGW/mingw32/include/c++/6.1.1/ostream:38,
>  from C:/MinGW/mingw32/include/c++/6.1.1/iostream:39,
>  from test.cpp:1:
> C:/MinGW/mingw32/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No
> such file or directory
>  #include_next 
>  ^
> compilation terminated.
> ```
> 
> Do you know how to solve this problem (modifications to gcc source code are
> expected)?
> Thanks in advance.
> 
> 
>   
> --
> Best regards,
> lh_mouse
> 2016-05-02
> 
> I made some investigation yesterday and here is the result:
> ```
> 
> Diff'ing gcc/libstdc++-v3/include/c_global/cstdlib from gcc-5-branch and
> gcc-6-branch gives the following result:
> (git diff gcc-5-branch gcc-6-branch -- libstdc++-v3/include/c_global/cstdlib)
> ```
> @@ -69,7 +69,11 @@ namespace std
>  
>  #else
>  
> -#include 
> +// Need to ensure this finds the C library's  not a libstdc++
> +// wrapper that might already be 

[Bug bootstrap/71292] Bootstrap failure with segfault in tree-reassoc.c

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
The patch fixes that ICE in the testcase for me.
Thanks!

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
(In reply to Georg Koppen from comment #3)
> Created attachment 38573 [details]
> ASan stack trace
> 
> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1268854 and attached is
> the ASan stack trace to begin with.

Even thought I'm logged in, I'm not authorized to see the issue.
Can you please past the stack trace here?

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-27
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
Please provide the missing information that https://gcc.gnu.org/bugs/ asks for,
so we know how you configured GCC.

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
This problem does not exiast for a native compiler on GNU/Linux.

Installation in $PREFIX=$HOME/gcc/6.1.0:

ignoring nonexistent directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0"
ignoring duplicate directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/x86_64-pc-linux-gnu"
ignoring duplicate directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/backward"
ignoring duplicate directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include"
ignoring duplicate directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed"
ignoring nonexistent directory
"/home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/jwakely/gcc/6.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0

/home/jwakely/gcc/6.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/x86_64-pc-linux-gnu

/home/jwakely/gcc/6.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/backward
 /home/jwakely/gcc/6.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include
 /home/jwakely/gcc/6.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed
 /usr/local/include
 /home/jwakely/gcc/6.1.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C++14 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)

After relocating to /tmp/gcc:

ignoring nonexistent directory
"/tmp/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/tmp/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0"
ignoring duplicate directory
"/tmp/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/x86_64-pc-linux-gnu"
ignoring duplicate directory
"/tmp/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/backward"
ignoring duplicate directory
"/tmp/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include"
ignoring duplicate directory
"/tmp/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed"
ignoring nonexistent directory
"/tmp/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/tmp/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0

/tmp/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/x86_64-pc-linux-gnu

/tmp/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/backward
 /tmp/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include
 /tmp/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed
 /usr/local/include
 /tmp/gcc/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C++14 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)

The paths are the same except for the prefix, as expected.