[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[andrewm.roberts at sky dot com]

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

--- Comment #8 from Andrew Roberts  ---
The initial bug report was for cross compiling. Bug 70211 is for native builds
on ARM. Given the huge growth in ARM development boards, this needs at least
documenting. As with the original reporter I spent ages trying to figure this
out before stumbling across a solution (and the solution isn't to build GMP out
of tree either). Building GMP out of tree creates another can of worms (esp on
multiarch machines). 

Any documentation fix should mention the targets that need the change (ARM),
and that both cross and native builds are affected. Also reference the
undefined symbol __gmpn_invert_limb so people know they have run across it.

Once you do the above it sort of becomes obvious that actually building GMP
intree with the correct CPU instead of none is proper solution. Or does that
not work for cross compilies? 

The easier it is for people to build gcc themselves the more testing prelease
versions will get.

[Bug c/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[wink at saville dot com]

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

--- Comment #2 from Wink Saville  ---
(In reply to H.J. Lu from comment #1)
> (In reply to Wink Saville from comment #0)
> > I have identified one possible problem and with this scheme, what if the
> > compiler needs to setup a stack frame by pushing rbp and then moving rsp to
> > rbp, how would that case be handled.
> 
> Why should be it a problem unless you don't want to restore RSP and RBP
> to its original values upon returning from ISR.  Please provide an example
> here.

Here a possible example, I added a printf and local variables to
timer_reschedule_isr:

void timer_reschedule_isr(struct intr_frame* frame) {
  __asm__ volatile(""::: "rax", "rbx", "rcx", "rdx", "rsi", "rdi", "rbp",
 "r8",  "r9",  "r10", "r11", "r12", "r13", "r14",
"r15");

  volatile ac_u64 array[3];  // << new
  array[2] = get_sp();  // << new
  ac_printf("timer_reschedule_isr array[0]=%p\n", array[2]); // << new

  tcb_x86 *ptcb = thread_scheduler((ac_u8*)get_sp(), get_ss());
  __asm__ volatile("movq %0, %%rsp;" :: "rm" (ptcb->sp) : "rsp");
  __asm__ volatile("movw %0, %%ss;" :: "rm" (ptcb->ss));
  set_apic_timer_initial_count(ptcb->slice);

  __atomic_add_fetch(_reschedule_isr_counter, 1, __ATOMIC_RELEASE);

  send_apic_eoi();
} // line 254 <


The compiler generates an error on the function's closing brace at line 254:

/home/wink/prgs/sadie/arch/x86/libs/thread_x86/srcs/thread_x86.c: In function
'timer_reschedule_isr':
/home/wink/prgs/sadie/arch/x86/libs/thread_x86/srcs/thread_x86.c:254:1: error:
bp cannot be used in asm here
 }


If I now remove "rbp" from the clobber list it compiles:

void timer_reschedule_isr(struct intr_frame* frame) {
  __asm__ volatile(""::: "rax", "rbx", "rcx", "rdx", "rsi", "rdi", // "rbp", <<
remove
 "r8",  "r9",  "r10", "r11", "r12", "r13", "r14",
"r15");

  volatile ac_u64 array[3];  // << new
  array[2] = get_sp();  // << new
  ac_printf("timer_reschedule_isr array[0]=%p\n", array[2]); // << new

  tcb_x86 *ptcb = thread_scheduler((ac_u8*)get_sp(), get_ss());
  __asm__ volatile("movq %0, %%rsp;" :: "rm" (ptcb->sp) : "rsp");
  __asm__ volatile("movw %0, %%ss;" :: "rm" (ptcb->ss));
  set_apic_timer_initial_count(ptcb->slice);

  __atomic_add_fetch(_reschedule_isr_counter, 1, __ATOMIC_RELEASE);

  send_apic_eoi();
} // line 254 <


And the generated subroutine prologue/epilogue is:

00100410 :
  100410:   55  push   %rbp
  100411:   48 89 e5mov%rsp,%rbp
  100414:   41 57   push   %r15
  100416:   41 56   push   %r14
  100418:   41 55   push   %r13
  10041a:   41 54   push   %r12
  10041c:   41 53   push   %r11
  10041e:   41 52   push   %r10
  100420:   41 51   push   %r9
  100422:   41 50   push   %r8
  100424:   57  push   %rdi
  100425:   56  push   %rsi
  100426:   53  push   %rbx
  100427:   51  push   %rcx
  100428:   52  push   %rdx
  100429:   50  push   %rax
  10042a:   48 83 e4 f0 and$0xfff0,%rsp
  10042e:   48 83 ec 20 sub$0x20,%rsp
  100432:   fc  cld



  10048b:   48 8d 65 90 lea-0x70(%rbp),%rsp
  10048f:   58  pop%rax
  100490:   5a  pop%rdx
  100491:   59  pop%rcx
  100492:   5b  pop%rbx
  100493:   5e  pop%rsi
  100494:   5f  pop%rdi
  100495:   41 58   pop%r8
  100497:   41 59   pop%r9
  100499:   41 5a   pop%r10
  10049b:   41 5b   pop%r11
  10049d:   41 5c   pop%r12
  10049f:   41 5d   pop%r13
  1004a1:   41 5e   pop%r14
  1004a3:   41 5f   pop%r15
  1004a5:   5d  pop%rbp
  1004a6:   48 cf   iretq  

So now the compiler saves/restores rbp and align's and adjusts rsp in the
prologue/epilogue code, is this something the programmer could do properly,
maybe but I was speculating it might be a problem.

[Bug c/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
(In reply to Wink Saville from comment #0)
> I have identified one possible problem and with this scheme, what if the
> compiler needs to setup a stack frame by pushing rbp and then moving rsp to
> rbp, how would that case be handled.

Why should be it a problem unless you don't want to restore RSP and RBP
to its original values upon returning from ISR.  Please provide an example
here.

[Bug c++/41437] No access control for classes in template functions

[barry.revzin at gmail dot com]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #7 from Barry Revzin  ---
This bug still exists in 5.3.0. For instance:

class X {
int mem;
};

template 
auto foo(T) {
return ::mem;
}

int main() {
foo(0);
}

[Bug tree-optimization/69951] wrong code at -O1 and above on x86_64-linux-gnu

[chengniansun at gmail dot com]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #5 from Chengnian Sun  ---
(In reply to Richard Biener from comment #4)
> Fixed for GCC 6.

Hi Richard, 

Is there any way to get the id of the revision that fixed this issue?

Thanks.

[Bug c/70220] New: [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[wink at saville dot com]

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

Bug ID: 70220
   Summary: [x86] interrupt attribute optionally needs to provide
read, write and control the set of saved registers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wink at saville dot com
  Target Milestone: ---

I'm using the new C interrupt attribute for x86 and its working well. But when
I expanded its use to include handling thread context switches, I found that
its current implementation lacking.

When using an ISR for a thread context it is necessary to save and restore all
registers but by default it saves a few as it thinks are necessary. It is
possible to use the clobber list of inline assembly to tell the interrupt
attribute code to save additional registers but you can't seem to mention the
segment registers in that clobber list, thus to save these additional registers
you must manually save them manually.

In addition, there is a second problem. I need to know the location of the
registers so they can be read and written. For thread context switching I only
need to be able to initialize a few registers to specific values, but if the
ISR was being used for debugging such as handling a break point interrupt, then
you need to be able to read/write every register.

My current solution is uses the clobber list technique and then looking at the
generated code to determine where in the stack the registers are saved so they
can be initialized. As I mentioned above the clobber list is only a partial
solution but good enough for proof of concept.

Below are snippets a "working" interrupt service routine:

typedef struct intr_frame {
  ac_uptr ip;
  ac_uptr cs;
  ac_uptr flags;
  ac_uptr sp;
  ac_uptr ss;
} intr_frame;

struct saved_regs {
  ac_u64 rax;
  ac_u64 rdx;
  ac_u64 rcx;
  ac_u64 rbx;
  ac_u64 rsi;
  ac_u64 rdi;
  ac_u64 rbp;
  ac_u64 r8;
  ac_u64 r9;
  ac_u64 r10;
  ac_u64 r11;
  ac_u64 r12;
  ac_u64 r13;
  ac_u64 r14;
  ac_u64 r15;
};

struct full_stack_frame {
  union {
struct saved_regs regs;
ac_u64 regs_array[15];
  };
  struct intr_frame iret_frame;
} __attribute__ ((__packed__));

static void init_stack_frame(ac_u8* pstack, ac_uptr stack_size, ac_uptr flags,
void* (*entry)(void*), void* entry_arg, ac_u8** psp, ac_u16 *pss) {
  ac_u8* tos = pstack + stack_size;
  struct full_stack_frame* sf =
(struct full_stack_frame*)(tos - sizeof(struct full_stack_frame));

  sf->regs.rdi = (ac_u64)entry_arg;
  sf->iret_frame.ip = (ac_uptr)entry;
  sf->iret_frame.cs = 0x8;
  sf->iret_frame.flags = flags;

  sf->iret_frame.sp = (ac_uptr)(tos);
  sf->iret_frame.ss = 0x10;

  *psp = (ac_u8*)sf;
  *pss = sf->iret_frame.ss;
}

__attribute__((__interrupt__))
void timer_reschedule_isr(struct intr_frame* frame) {
  __asm__ volatile(""::: "rax", "rbx", "rcx", "rdx", "rsi", "rdi", "rbp",
 "r8",  "r9",  "r10", "r11", "r12", "r13", "r14",
"r15");

  tcb_x86 *ptcb = thread_scheduler((ac_u8*)get_sp(), get_ss());
  __asm__ volatile("movq %0, %%rsp;" :: "rm" (ptcb->sp) : "rsp");
  __asm__ volatile("movw %0, %%ss;" :: "rm" (ptcb->ss));
  set_apic_timer_initial_count(ptcb->slice);

  __atomic_add_fetch(_reschedule_isr_counter, 1, __ATOMIC_RELEASE);

  send_apic_eoi();
}


I've discussed this with H.J. Lu and currently we are leaning to a solution
where the interrupt attribute can have an optional list of registers to NOT
save and then assume the programmer will provide the code to save the desired
registers, thus all registers can be saved and their location known because the
programmer is in control. I'd also like an "all" to indicate that none of the
registers as I see that as a typical use case. And if possible I'd like the
compiler to detect if a register was used but not saved before being modified.

I have identified one possible problem and with this scheme, what if the
compiler needs to setup a stack frame by pushing rbp and then moving rsp to
rbp, how would that case be handled.

[Bug c++/70205] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, it ICEs with checking turned on.
> 
> Note this might be invalid code as what GCC is iceing on is an error_mark
> node.

Andrew, this should be valid code. Also see below: 

$ g++-5.3 -Wall -Wextra -pedantic -c small.cpp
$ clang++ -Weverything -pedantic -c small.cpp
$

[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use

[dominiq at gcc dot gnu.org]

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

--- Comment #9 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Mar 13 23:22:15 2016
New Revision: 234172

URL: https://gcc.gnu.org/viewcvs?rev=234172=gcc=rev
Log:
2016-03-13  Dominique d'Humieres  

PR fortran/45076
gfortran.dg/prof/prof.exp: New script.
gfortran.dg/prof/dynamic_dispatch_6.f03: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/dynamic_dispatch_6.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/prof.exp
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/70211] gcc-6-20160306 fails to build on ARM Linux with in tree ISL due to undefined GMP symbol __gmpn_invert_limb in isl_test

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 67728.

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

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||andrewm.roberts at sky dot com

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

[Bug c++/70212] internal compiler error: Segmentation fault when compiling easylogging++.h v9.80

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-13
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?

Also note 4.6.x is no longer supported can you try 4.9.3 or 5.3.0?

[Bug target/70216] [SH] Implement __builtin_trap

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-13
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #4 from Andrew Pinski  ---
Confirmed.

[Bug target/69284] [5.3] SIGSEGV when running 32-bit result on MinGW when linked dynamically

[pinskia at gcc dot gnu.org]

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

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

[Bug c++/70207] use of causes segmentation fault

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 69284.

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

[Bug c++/70205] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-13
 Ever confirmed|0   |1
  Known to fail||5.0, 6.0

--- Comment #1 from Andrew Pinski  ---
Confirmed, it ICEs with checking turned on.

Note this might be invalid code as what GCC is iceing on is an error_mark node.

[Bug c++/70204] [6 Regression] ICE on x86_64-linux-gnu in non_const_var_error, at cp/constexpr.c:2764

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.2, 5.0
   Keywords||error-recovery,
   ||ice-on-invalid-code
   Last reconfirmed||2016-03-13
 Ever confirmed|0   |1
Summary|ICE on x86_64-linux-gnu in  |[6 Regression] ICE on
   |non_const_var_error, at |x86_64-linux-gnu in
   |cp/constexpr.c:2764 |non_const_var_error, at
   ||cp/constexpr.c:2764
   Target Milestone|--- |6.0
  Known to fail||6.0
   Severity|normal  |minor

--- Comment #1 from Andrew Pinski  ---
Confirmed.  5.0 did not ICE.

[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03

[noloader at gmail dot com]

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

--- Comment #5 from Jeffrey Walton  ---
(In reply to Jonathan Wakely from comment #3)
> dup of PR 70176 ?
> 
> My guess is Cygwin uses a new version of newlib which has stricter C headers
> that don't define the C99 functions for __cplusplus < 201103L &&
> __STRICT_ANSI__

Is there anything I can do to help? Do you need a bug report filed against
newlib?

[Bug c++/70202] ICE on invalid code on x86_64-linux-gnu in build_simple_base_path, at cp/class.c:579

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
class A
{
  virtual void foo () { }
};
class B : public A, A
{
};
B b1,  = b1;
A a = b2;

[Bug middle-end/70199] [5/6 Regression] Crash at -O2 when using labels.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Here is a reduced testcase:
static volatile int v = 0;
static
void benchmark(long runs) {
  void* labels[] = {
&, &, &
  };
  for(unsigned int mask = 0x1F; mask > 0; mask >>= 1) {
unsigned lfsr = 0xACE1u;
long n = 1000;
while(n > 0) {
  l2: v;
  l1: v;
  goto *labels[lfsr & mask];
  l0: n--;
}
  }
}
int f(void) {
  benchmark(1000);
}

 CUT -

[Bug middle-end/70199] [5/6 Regression] Crash at -O2 when using labels.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.4.5, 4.8.2
   Target Milestone|--- |5.4
Summary|Crash at -O2 when using |[5/6 Regression] Crash at
   |labels. |-O2 when using labels.
  Known to fail||6.0

[Bug tree-optimization/70214] [4.9/5/6 regression] pthread_kill is not considered a barrier

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Actually it is not a glibc bug either:
Note that leaf functions might invoke signals and signal handlers might be
defined in the current compilation unit and use static variables. The only
compliant way to write such a signal handler is to declare such variables
volatile.

[Bug ipa/70188] [4.9/5/6 Regression] gcc 4.9+ miscompiles code on hppa

[deller at gmx dot de]

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

--- Comment #6 from deller at gmx dot de ---
Hi Dave,

On 13.03.2016 21:58, danglin at gcc dot gnu.org wrote:
> Try to find 4.9 regression.  So far, range has been reduced to r220635 to 
> r221480.

So, it compiles correctly with r220635 ?
Is that then a gcc-4.8 or gcc-4.9 ?

Helge

[Bug tree-optimization/70214] [4.9/5/6 regression] pthread_kill is not considered a barrier

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---

leaf
Calls to external functions with this attribute must return to the current
compilation unit only by return or by exception handling. In particular, leaf
functions are not allowed to call callback function passed to it from the
current compilation unit or directly call functions exported by the unit or
longjmp into the unit. Leaf function might still call functions from other
compilation units and thus they are not necessarily leaf in the sense that they
contain no function calls at all.

This is not a GCC bug; if it is a bug it is a glibc bug applying the leaf
attribute.  But note I doubt it since it is a signal, you should have declared
tst as volatile.

[Bug tree-optimization/70214] [4.9/5/6 regression] pthread_kill is not considered a barrier

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
extern int pthread_kill (pthread_t __threadid, int __signo) __attribute__
((__nothrow__ , __leaf__));

[Bug ipa/70188] [4.9/5/6 Regression] gcc 4.9+ miscompiles code on hppa

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
Created attachment 37952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37952=edit
blk-merge.c preprocessed source

I've added the preprocessed for blk-merge.c.  Although the wrong code appears
to be in blk_bio_segment_split(), The -fno-ipa-sra option didn't fix the
problem.  Further, the problem appears with blk-merge.c compiled at both -O1
and -O2.  Boot is successful when it is compiled at -O0.

Try to find 4.9 regression.  So far, range has been reduced to r220635 to
r221480.

[Bug tree-optimization/70214] [4.9/5/6 regression] pthread_kill is not considered a barrier

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.4.5
Summary|[6 regression] external |[4.9/5/6 regression]
   |call is not considered a|pthread_kill is not
   |barrier |considered a barrier

--- Comment #2 from Andrew Pinski  ---
I tried it with doing my own set/call function and it works.
I suspect this code is undefined.

[Bug tree-optimization/70214] [6 regression] external call is not considered a barrier

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug ipa/70188] [4.9/5/6 Regression] gcc 4.9+ miscompiles code on hppa

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.9.4
Summary|[4.9,5 Regression] gcc 4.9+ |[4.9/5/6 Regression] gcc
   |miscompiles code on hppa|4.9+ miscompiles code on
   ||hppa

[Bug c++/70194] [6 regression] missing -Waddress on constexpr pointer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module subroutine"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug fortran/70040] [6 Regression] ICE in gimplify.c with deferred-length strings

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/70121] [5/6 Regression] spurious warning and crash when returning a reference from lambda

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug c++/70096] [6 Regression] [Invalid codegen] Read of uninitialized value in ref-qualified pointer to member function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug libstdc++/69782] [6 Regression] defining min() macro causes thousand of lines of error messages

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/69739] [4.9/5/6 Regression] ICE during array result, allocatable assignment

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug tree-optimization/69728] [6 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/69603] [5/6 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug target/70208] [6 Regression] Operand size mismatch for `vpextrb' w/ -O3 -mavx -masm=intel

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Arseny Solokha from comment #1)
> Must be a duplicate of PR70049, though.

Yes.

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

[Bug target/70049] [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #5 from Uroš Bizjak  ---
*** Bug 70208 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/70219] [6 Regression] ICE: in delete_move_and_clobber, at lra-constraints.c:5864 with -O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/70218] [5/6 Regression] Illegal access to private fields succeeds with 5/6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4
Summary|Illegal access to private   |[5/6 Regression] Illegal
   |fields succeeds with 5/6|access to private fields
   ||succeeds with 5/6

[Bug c++/70218] Illegal access to private fields succeeds with 5/6

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
struct X {
private:
   int i;
};

struct Y {
  Y (int) { }
};

int
main ()
{
  Y ([] { X x; x.i = 3; return 0; } ());
}


We are mishandling the deferred_access_stack by not correctly pushing/popping
from it.  In cp_parser_lambda_expression we are calling (in order):

  push_deferring_access_checks (dk_no_deferred);
  cp_parser_start_tentative_firewall (parser);
  pop_deferring_access_checks ();
  cp_parser_end_tentative_firewall (parser, start, lambda_expr);

But the order of the last two calls ought to be swapped.

So this fixes it:

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6ae45b0..33f09b8 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9781,8 +9781,6 @@ cp_parser_lambda_expression (cp_parser* parser)
= auto_is_implicit_function_template_parm_p;
   }

-  pop_deferring_access_checks ();
-
   /* This field is only used during parsing of the lambda.  */
   LAMBDA_EXPR_THIS_CAPTURE (lambda_expr) = NULL_TREE;

@@ -9798,6 +9796,8 @@ cp_parser_lambda_expression (cp_parser* parser)

   cp_parser_end_tentative_firewall (parser, start, lambda_expr);

+  pop_deferring_access_checks ();
+
   return lambda_expr;
 }

[Bug rtl-optimization/70219] [6 Regression] ICE: in delete_move_and_clobber, at lra-constraints.c:5864 with -O2

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
Created attachment 37951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37951=edit
testcase that needs only -O1 to reproduce

$ gcc -O testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
 foo(u16 u16_0, u32 u64_1, u128 u128_1, v32u16 v32u64_0, v32u128 v32u128_0,
v32u16 v32u16_1, v32u32 v32u32_1, v32u64 v32u64_1, v32u128 v32u128_1)
 ^~~
testcase.c:9:1: warning: AVX vector argument without AVX enabled changes the
ABI [-Wpsabi]
testcase.c:15:1: internal compiler error: in delete_move_and_clobber, at
lra-constraints.c:5864
 }
 ^
0xa08790 delete_move_and_clobber
/repo/gcc-trunk/gcc/lra-constraints.c:5864
0xa166e8 remove_inheritance_pseudos
/repo/gcc-trunk/gcc/lra-constraints.c:5943
0xa166e8 lra_undo_inheritance()
/repo/gcc-trunk/gcc/lra-constraints.c:6231
0x9fe567 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2333
0x9a4c79 do_reload
/repo/gcc-trunk/gcc/ira.c:5398
0x9a4c79 execute
/repo/gcc-trunk/gcc/ira.c:5582
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/70219] [6 Regression] ICE: in delete_move_and_clobber, at lra-constraints.c:5864 with -O2

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 37950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37950=edit
reduced testcase

[Bug rtl-optimization/70219] New: [6 Regression] ICE: in delete_move_and_clobber, at lra-constraints.c:5864 with -O2

[zsojka at seznam dot cz]

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

Bug ID: 70219
   Summary: [6 Regression] ICE: in delete_move_and_clobber, at
lra-constraints.c:5864 with -O2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

The failing assert has been added in a fix of PR69614.

Compiler output:
$ gcc -O2 testcase.c   
testcase.c: In function 'foo':
testcase.c:5:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
 foo(int u32_0, i128 u128_0, int u16_1, int u64_1, v8si v32u128_0, v8si
v32u32_1, v8si v32u128_1)
 ^~~
testcase.c:5:1: warning: AVX vector argument without AVX enabled changes the
ABI [-Wpsabi]
testcase.c:11:1: internal compiler error: in delete_move_and_clobber, at
lra-constraints.c:5864
 }
 ^
0xa08790 delete_move_and_clobber
/repo/gcc-trunk/gcc/lra-constraints.c:5864
0xa166e8 remove_inheritance_pseudos
/repo/gcc-trunk/gcc/lra-constraints.c:5943
0xa166e8 lra_undo_inheritance()
/repo/gcc-trunk/gcc/lra-constraints.c:6231
0x9fe567 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2333
0x9a4c79 do_reload
/repo/gcc-trunk/gcc/ira.c:5398
0x9a4c79 execute
/repo/gcc-trunk/gcc/ira.c:5582
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-234167-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-234167-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20160313 (experimental) (GCC)

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
Closing

[Bug c++/70035] [5 Regression] Calling a non-virtual member in base-class constructor call with ubsan causes segfault when superclass has virtual member with same name

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Bernd Edlinger from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Fixed for g++ 6+ so far.
> 
> no. this creates a new problem.
> I see now crashes in valid code that uses the std::stringstream
> when -fsanitize=undefined is used.
> Unfortunately I was not able to reduce the test case.
> 
> But what is wrong can be seen with this simple test case:

That is already tracked in PR70147.

[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
We can probably do something in os_defines.h like:

#if __cplusplus < 201103L && __STRICT_ANSI__
#undef _GLIBCXX_USE_C99_STDIO
// etc.
#endif

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Mar 13 17:38:07 2016
New Revision: 234169

URL: https://gcc.gnu.org/viewcvs?rev=234169=gcc=rev
Log:
2016-03-13  Jerry DeLisle  
Jim MacArthur  

PR fortran/69043
* scanner.c (load_file): Check that included file is regular.

PR fortran/69043
* gfortran.dg/include_9.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/include_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
dup of PR 70176 ?

My guess is Cygwin uses a new version of newlib which has stricter C headers
that don't define the C99 functions for __cplusplus < 201103L &&
__STRICT_ANSI__

[Bug c++/70035] [5 Regression] Calling a non-virtual member in base-class constructor call with ubsan causes segfault when superclass has virtual member with same name

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #9 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #8)
> Fixed for g++ 6+ so far.

no. this creates a new problem.
I see now crashes in valid code that uses the std::stringstream
when -fsanitize=undefined is used.
Unfortunately I was not able to reduce the test case.

But what is wrong can be seen with this simple test case:

cat test.cc
#include 

main(int argc, char** argv)
{
  std::stringstream ss;
  ss << "test";
  for (int i=0; i::basic_iostream():
  UBSAN_NULL (this, 2B, 8);
  MEM[(struct  &)this] = {CLOBBER};
  this->D.34679._vptr.basic_istream = 0B;  <= set _vptr to zero
  D.40658 = this->D.34679._vptr.basic_istream; <= D.40658 is null
  D.40659 = D.40658 + 18446744073709551592;<= D.40659 is 0 + -24
  D.40660 = MEM[(long int *)D.40659];  <= will crash if executed
  D.40661 = (sizetype) D.40660;
  D.40662 = this + D.40661;
  D.40662->D.31841._vptr.ios_base = 0B;
  this->D.34680._vptr.basic_ostream = 0B;


However in most of the cases this garbage is removed by optimization.

[Bug c++/70218] New: Illegal access to private fields succeeds with 5/6

[doko at gcc dot gnu.org]

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

Bug ID: 70218
   Summary: Illegal access to private fields succeeds with 5/6
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/816366]

$ cat foo.cc 
#include 
class X {
int i;
};
main() {
X x;
std::thread([] { x.i = 3; });
}

g++-4.9 detects access to X::i which is private. Only happens in the specific
combination of a new thread and the lambda expression. g++-5 and g++-6 accept
this.

$ g++-4.9 -std=gnu++11 foo.cc
foo.cc: In lambda function:
foo.cc:3:9: error: 'int X::i' is private
 int i;
 ^
foo.cc:7:26: error: within this context
 std::thread([] { x.i = 3; });
  ^

[Bug target/70216] [SH] Implement __builtin_trap

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #2)
> 
> I think that # less than 0x20 are reserved by kernel, gdb uses 0x20
> and 0xc3 and gcc uses 0x33 for profiling.  Perhaps 0x54 (ascii 'T')
> or something?

If there are no other opinions, I guess I'll just do that.  I don't have any
better idea.

Basically it's the same question as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272#c2

Emitting a function call into libgcc for __builtin_trap could also be an option
(-mbuiltin-trap=libcall)

[Bug target/70216] [SH] Implement __builtin_trap

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #1)
> For sh4-linux this option should be enabled by default with some useful trap
> number value.  Which trap number should be used in this case?

I think that # less than 0x20 are reserved by kernel, gdb uses 0x20
and 0xc3 and gcc uses 0x33 for profiling.  Perhaps 0x54 (ascii 'T')
or something?

[Bug bootstrap/70211] gcc-6-20160306 fails to build on ARM Linux with in tree ISL due to undefined GMP symbol __gmpn_invert_limb in isl_test

[andrewm.roberts at sky dot com]

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

--- Comment #1 from Andrew Roberts  ---
Looking at the toplevel Makefile.in the gmp targets (maybe-configure-gmp,
configure-gmp etc)
use:
--build=${build_alias} --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}

where as isl, mpfr etc all use:
--build=${build_alias} --host=${host_alias} --target=${target_alias}

Presumably there was a historic reason for this, is it still valid?

As my previous comments say, this seems to have started causing problems on ARM
from GMP 5.1 onwards.

[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use

[dominiq at gcc dot gnu.org]

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

--- Comment #8 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Mar 13 09:48:20 2016
New Revision: 234168

URL: https://gcc.gnu.org/viewcvs?rev=234168=gcc=rev
Log:
2016-03-13  Dominique d'Humieres  

PR fortran/45076
gfortran.dg/prof/prof.exp: New script.
gfortran.dg/prof/dynamic_dispatch_6.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/prof/
trunk/gcc/testsuite/gfortran.dg/prof/dynamic_dispatch_6.f03
trunk/gcc/testsuite/gfortran.dg/prof/prof.exp
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
Cygwin bug https://sourceware.org/bugzilla/show_bug.cgi?id=19817.

[Bug c++/70217] New: Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03

[noloader at gmail dot com]

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

Bug ID: 70217
   Summary: Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a
program with std=c++03
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Cygwin 2.4.1/GCC 5.3.0 can no longer compile a program with std=c++03.

$ uname -r
2.4.1(0.293/5/3)

$ gcc --version
gcc (GCC) 5.3.0

$ cat test.cxx
#include 

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

$ g++ -DNDEBUG -g2 -O2 -std=c++03 test.cxx -o test.exe
In file included from
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/bits/stl_algo.h:59:0,
 from
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/algorithm:62,
 from test.cxx:1:
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:214:11: error:
‘::lldiv_t’ has not been declared
   using ::lldiv_t;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:220:11: error:
‘::_Exit’ has not been declared
   using ::_Exit;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:224:11: error:
‘::llabs’ has not been declared
   using ::llabs;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:226:10: error:
‘lldiv_t’ does not name a type
   inline lldiv_t
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:230:11: error:
‘::lldiv’ has not been declared
   using ::lldiv;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:241:11: error:
‘::atoll’ has not been declared
   using ::atoll;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:242:11: error:
‘::strtoll’ has not been declared
   using ::strtoll;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:243:11: error:
‘::strtoull’ has not been declared
   using ::strtoull;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:245:11: error: ‘::strto
’ has not been declared
   using ::strtof;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:246:11: error:
‘::strtold’ has not been declared
   using ::strtold;
   ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:254:22: error:
‘__gnu_cxx::lldiv_t’ has not been declared
   using ::__gnu_cxx::lldiv_t;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:256:22: error:
‘__gnu_cxx::_Exit’ has not been declared
   using ::__gnu_cxx::_Exit;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:258:22: error:
‘__gnu_cxx::llabs’ has not been declared
   using ::__gnu_cxx::llabs;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:259:22: error:
‘__gnu_cxx::div’ has not been declared
   using ::__gnu_cxx::div;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:260:22: error:
‘__gnu_cxx::lldiv’ has not been declared
   using ::__gnu_cxx::lldiv;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:262:22: error:
‘__gnu_cxx::atoll’ has not been declared
   using ::__gnu_cxx::atoll;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:263:22: error:
‘__gnu_cxx::strtof’ has not been declared
   using ::__gnu_cxx::strtof;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:264:22: error:
‘__gnu_cxx::strtoll’ has not been declared
   using ::__gnu_cxx::strtoll;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:265:22: error:
‘__gnu_cxx::strtoull’ has not been declared
   using ::__gnu_cxx::strtoull;
  ^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:266:22: error:
‘__gnu_cxx::strtold’ has not been declared
   using ::__gnu_cxx::strtold;
  ^

[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03

[noloader at gmail dot com]

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

--- Comment #1 from Jeffrey Walton  ---
Cygwin bug https://sourceware.org/bugzilla/show_bug.cgi?id=19817.

[Bug tree-optimization/70214] [6 regression] external call is not considered a barrier

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|c   |tree-optimization
Summary|external call is not|[6 regression] external
   |considered a barrier|call is not considered a
   ||barrier

--- Comment #1 from Andrew Pinski  ---
Looks like GCC is not treating tst as being able to escape.  That is becaue
my_h escapes, tst  needs to be treated as such also.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[pinskia at gcc dot gnu.org]

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

--- Comment #37 from Andrew Pinski  ---
Note this change also introduces some warnings when compiling the arm64 kernel:

In file included from arch/arm64/crypto/aes-glue.c:17:0:
include/linux/cpufeature.h:48:33: warning: ‘cpu_feature_match_AES’ defined but
not used [-Wunused-const-variable=]
 static struct cpu_feature const cpu_feature_match_ ## x[] = \
 ^
arch/arm64/crypto/aes-glue.c:452:1: note: in expansion of macro
‘module_cpu_feature_match’
 module_cpu_feature_match(AES, aes_init);
 ^~~~


 MODULE_DEVICE_TABLE(cpu, cpu_feature_match_ ## x);  \


This happens when the aes crypto code is compiled in rather than a module.

[Bug fortran/50221] Allocatable string length fails with array assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||brad.finney at humboldt dot edu

--- Comment #10 from Dominique d'Humieres  ---
*** Bug 70215 has been marked as a duplicate of this bug. ***

[Bug fortran/68241] [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

Bug 70215 Summary: segmentation fault with allocate on assign; 32 bit version, 
not 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70215

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/70215] segmentation fault with allocate on assign; 32 bit version, not 64 bit

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Dominique d'Humieres  ---
After some digging, I think it is a duplicate of pr50221.

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