[Bug testsuite/68917] test suite failure for builtin-bitops-1.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
by the way, did you have also trouble to build the
libgcc multilib configuration or did you --disable-multilib?
this seems completely broken too...

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Mon, 21 Dec 2015, mpolacek at gcc dot gnu.org wrote:

> int
> read1 (_Atomic S p)
> {
>   S s = p;
>   return s.x;

That's fine.

> read2 (_Atomic S *p)
> {
>   S *s = p;

No, assignment / initialization etc. between pointer types differing in 
_Atomic in their target types is not permitted.

You need to do e.g.

  S s = *p;
  return s.x;

(which involves an atomic load of the whole structure).

> void
> write2 (_Atomic S *p, int x)
> {
>   S *s = p;
>   s->x = x;

Again, not valid.  Storing atomically to a member of an atomic structure 
probably requires a compare-exchange loop.

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
FWIW, I think it would make sense to diagnose some of the constructs for other
reasons besides accessing a member (of an atomic struct).  For example, in
write1(), the function is most likely not going to do what its author or caller
expects:  i.e., it updates a copy of the argument, not the original.  It makes
no sense (in this case) for the argument to be atomic since it clearly is not
shared with other threads.  So GCC should probably warn about it, and could
also treat it as non-atomic and emit better code (the latter part is the
subject of bug 68622).

How to write2() depends on whether the function is intended to initialize the
argument or simply assign to it.  If the former, either

  atomic_init (p, s);

or

  atomic_store_explicit (p, s, memory_order_relaxed);

would work.  Obviously, without knowing more about the context in which it's
called we can't tell which alternative is appropriate.  Which makes me wonder
if how the function accesses an atomic object referenced by its argument should
be made part of the interface (e.g., via some attribute).

[Bug testsuite/68917] test suite failure for builtin-bitops-1.c

[gang.chen.5i5j at gmail dot com]

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

--- Comment #2 from Chen Gang  ---
(In reply to Bernd Edlinger from comment #1)
> does something like this help?
> 

Oh, sorry for replying late.

I shall try to give a test within this month.

Thanks. :-)


> Index: tilegx.md
> ===
> --- tilegx.md (Revision 231696)
> +++ tilegx.md (Arbeitskopie)
> @@ -1799,13 +1799,16 @@
>  
>  (define_expand "clzsi2"
>[(set (match_dup 2)
> -(ashift:DI (match_operand:SI 1 "reg_or_0_operand" "")
> + (zero_extend:DI (match_operand:SI 1 "reg_or_0_operand" "")))
> +   (set (match_dup 2)
> + (ashift:DI (match_dup 2)
> (const_int 32)))
> -   (set (subreg:DI (match_operand:SI 0 "register_operand" "") 0)
> - (clz:DI (match_dup 2)))]
> +   (set (match_dup 2)
> + (clz:DI (match_dup 2)))
> +   (set (match_operand:SI 0 "register_operand" "")
> + (subreg:SI (match_dup 2) 0))]
> ""
> {
> - operands[1] = simplify_gen_subreg (DImode, operands[1], SImode, 0);
>   operands[2] = gen_reg_rtx (DImode);
> })

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

--- Comment #18 from Steve Ellcey  ---
I think there is still a difference in our configurations.  If you add '-v' to
the compile line when compiling the test program what do you see?  Specifically
what does COLLECT_GCC_OPTIONS show?  Mine has:

COLLECT_GCC_OPTIONS='-c' '-O2' '-g' '-march=mips32r2' '-v' '-mllsc' '-mplt'
'-mips32r2' '-mno-shared' '-EL' '-mabi=32'

I suspect yours is different.  I have tried adding some other options like
-mabicalls and -mexplicit-relocs to get output that looks more like yours but I
haven't succeeded in getting an exact match.

[Bug other/69006] Extraneous newline emitted between error messages in GCC 6

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-21
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug other/69006] New: Extraneous newline emitted between error messages in GCC 6

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 69006
   Summary: Extraneous newline emitted between error messages in
GCC 6
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

GCC 6, compared to GCC 5, now emits an extra newline between error
messages.

$ cat error.c
int x = a;
int y = b;

$ gcc-5 error.c
error.c:1:9: error: ‘a’ undeclared here (not in a function)
 int x = a;
 ^
error.c:2:9: error: ‘b’ undeclared here (not in a function)
 int y = b;
 ^
$ gcc-6 error.c
error.c:1:9: error: ‘a’ undeclared here (not in a function)
 int x = a;
 ^

error.c:2:9: error: ‘b’ undeclared here (not in a function)
 int y = b;
 ^
Started with r229884: Reimplement diagnostic_show_locus, introducing
rich_location classes.

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Nick Clifton from comment #5)
> Created attachment 37099 [details]
> Initialise the t_icode field of the sri structure created by copy_cost.

>   Please could you try out the uploaded patch.
> 
>   I am currently running regression tests, but if it passes, and it works
> for you, then I will submit it for review.

Thanks Nick. Your patch fixes the problem.

[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
 CC||ygribov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Libstdc++ uses -frandom-seed=snprintf_lite.lo so I'd prefer if the incorrect
documentation change was simply reverted. I don't see any approval for that
change on the mailing list, but maybe I failed to find it.

[Bug c++/67257] [5/6 regression] Internal compiler error in retrieve_specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/66921] [4.9/5/6 Regression] failure to determine size of static constexpr array that is nested within a templated class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/68993] MERGE does not evaluate its arguments

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #5 from Joost VandeVondele  
---
(In reply to Steve Kargl from comment #4)
> 
> I would urge anyone trying to be clever to use clear syntax:
> 

https://github.com/hfp/libxsmm/commit/cc308fc5debe6151157a4fa9efacc7aa03351283

is what we used indeed, but it is not quite as concise as one would like.

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #26 from Jack Howarth  ---
Created attachment 37100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37100=edit
proposed patch to suppress PR66848 on darwin

The attached proposed patch suppresses PR66848 on darwin until either the
underlying bug in the v6.6 based boehm-gc is fixed or boehm-gc in gcc is
rebased on 7.2 or later which doesn't suffer from this bug.

[Bug fortran/68993] MERGE does not evaluate its arguments

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Mon, Dec 21, 2015 at 08:29:57PM +, Joost.VandeVondele at mat dot ethz.ch
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993
> 
> --- Comment #5 from Joost VandeVondele  ethz.ch> ---
> (In reply to Steve Kargl from comment #4)
> > 
> > I would urge anyone trying to be clever to use clear syntax:
> > 
> 
> https://github.com/hfp/libxsmm/commit/cc308fc5debe6151157a4fa9efacc7aa03351283
> 
> is what we used indeed, but it is not quite as concise as one would like.
> 

Interesting project.  I may need to take a closer look at it.

I agree that the suggested syntax is not concise.  In your particular
case, you could write 

 cpa = C_NULL_PTR
 IF (PRESENT(pa)) cpa = C_LOC(pa)

instead of

 IF (PRESENT(pa)) THEN
   cpa = C_LOC(pa)
 ELSE
   cpa = C_NULL_PTR
 END IF

This would reduce your code from 15 lines to 6 lines.  I'll note that
in some testing where I had a similar code structure the former
(ie., 2-line example) was slower than the latter (5-line example).

It is unfortanute that Fortran does not have a ternary operator.
This is a good example where it might be nice to have

cpa = present(pa) ? c_loc(pa) : c_null_ptr

where the TRUE or FALSE choice is only evaluated based on the condition.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #19 from Aurelien Jarno  ---
Please find below the output produced by gcc when compiling with -v

Reading specs from /home/aurel32/work/mips-gcc/build/./gcc/specs
COLLECT_GCC=/home/aurel32/work/mips-gcc/build/./gcc/xgcc
Target: mipsel-linux-gnu
Configured with: /home/aurel32/git/gcc/configure --enable-languages=c
--prefix=/usr --target=mipsel-linux-gnu
--includedir=/usr/mipsel-linux-gnu/include
Thread model: posix
gcc version 5.3.1 20151221 (GCC)
COLLECT_GCC_OPTIONS='-v' '-B' '/home/aurel32/work/mips-gcc/build/./gcc/' '-O2'
'-g' '-o' 'test.o' '-c' '-march=mips32r2' '-mllsc' '-mips32r2' '-mno-shared'
'-EL' '-mabi=32'
 /home/aurel32/work/mips-gcc/build/./gcc/cc1 -quiet -v -iprefix
/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/
-isystem /home/aurel32/work/mips-gcc/build/./gcc/include -isystem
/home/aurel32/work/mips-gcc/build/./gcc/include-fixed test.c -mel -quiet
-dumpbase test.c -march=mips32r2 -mllsc -mips32r2 -mno-shared -mabi=32
-auxbase-strip test.o -g -O2 -version -o /tmp/cc4pCfly.s
GNU C11 (GCC) version 5.3.1 20151221 (mipsel-linux-gnu)
compiled by GNU C version 5.3.1 20151207, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/include-fixed"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/include-fixed"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/aurel32/work/mips-gcc/build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux-gnu/5.3.1/../../../../mipsel-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/aurel32/work/mips-gcc/build/./gcc/include
 /home/aurel32/work/mips-gcc/build/./gcc/include-fixed
End of search list.
GNU C11 (GCC) version 5.3.1 20151221 (mipsel-linux-gnu)
compiled by GNU C version 5.3.1 20151207, GMP version 6.1.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e3226672ebc300cae5ef5d0d012ad534

[Bug target/69007] New: [6 regression] test cases gcc.dg/vect/vect-reduc-dot-s8a.c fails starting with r231815

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 69007
   Summary: [6 regression] test cases
gcc.dg/vect/vect-reduc-dot-s8a.c fails starting with
r231815
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

It fails on both little and big endian on power8.  I tried this on an x86
machine and it succeeds.


PASS: gcc.dg/vect/vect-reduc-dot-s8a.c (test for excess errors)
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c execution test
FAIL: gcc.dg/vect/vect-reduc-dot-s8a.c scan-tree-dump-times vect
"vect_recog_dot_prod_pattern: detected" 1
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c scan-tree-dump-times vect
"vect_recog_widen_mult_pattern: detected" 1
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects (test for excess
errors)
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vect_recog_widen_mult_pattern: detected" 1
PASS: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1


Also gcc.dg/vect/vect-reduc-dot-u8a.c:

PASS: gcc.dg/vect/vect-reduc-dot-u8a.c (test for excess errors)
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c execution test
FAIL: gcc.dg/vect/vect-reduc-dot-u8a.c scan-tree-dump-times vect
"vect_recog_dot_prod_pattern: detected" 1
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c -flto -ffat-lto-objects (test for excess
errors)
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/vect-reduc-dot-u8a.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1
PASS: gcc.dg/vect/vect-reduc-dot-u8a.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1

[Bug c++/69008] New: gcc emits unneeded memory access when passing trivial structs by value (ARM)

[gcc at bobbyperu dot info]

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

Bug ID: 69008
   Summary: gcc emits unneeded memory access when passing trivial
structs by value (ARM)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at bobbyperu dot info
  Target Milestone: ---

gcc is emitting unneeded memory accesses in this code snippet.
Trivial structs up to 16 bytes are passed in r0-r3, no need for stack.

struct Trivial {
int i1;
int i2;
};

int foo(Trivial t)
{
return t.i1 + t.i2;
}

gcc on armv7:
$ g++ arm.cpp -O2 -mabi=aapcs -c -S && cat arm.s
  sub sp, sp, #8
  add r3, sp, #8
  stmdb   r3, {r0, r1}
  ldmia   sp, {r0, r3}
  add r0, r0, r3
  add sp, sp, #8
  bx  lr

clang:
$ clang++ arm.cpp -O2 -mabi=aapcs -c -S && cat arm.s

add r0, r0, r1
bx  lr

[Bug libstdc++/64132] [5/6 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[lixin.fnst at cn dot fujitsu.com]

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

--- Comment #8 from li xin  ---
(In reply to li xin from comment #7)
> (In reply to li xin from comment #6)
> > The LSB test cases also Failed.
> > /22_locale/messages/members/char/2.cc 1
> > /22_locale/messages/members/char/wrapped_env.cc 1
> > /22_locale/messages/members/char/wrapped_locale.cc 1 are Failed.
> > 
> > They are pass on gcc-4.9.3.
> > and fail on gcc-5.1 and gcc-5.2
> 
> The output is as following:
> 2.cc:54: void test02(): Assertion `s01 == "s'il vous pla�t"' failed.
> DejaGNUTest.command_output_1:

Those three cases are Failed on gcc-5.3 too.

[Bug target/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm*-*-*
  Component|c++ |target
   Severity|normal  |enhancement

[Bug tree-optimization/68761] -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519

[nheghathivhistha at gmail dot com]

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

David Kredba  changed:

   What|Removed |Added

 CC||nheghathivhistha at gmail dot 
com

--- Comment #3 from David Kredba  ---
Another testcase from https://bugs.gentoo.org/show_bug.cgi?id=568908 found by 
Hunter Allen using g++ --std=c++17 -g.

namespace std {
inline namespace __cxx11 {}
template  class allocator;
namespace __cxx11 {
template >
class basic_string;
typedef basic_string string;
}
template  class allocator {
public:
  template  struct rebind { typedef allocator other; };
};
template  struct __alloctr_rebind {
  typedef typename _Alloc::template rebind<_Tp>::other __type;
};
template  struct allocator_traits {
  typedef decltype(0) pointer;
  template 
  using rebind_alloc = typename __alloctr_rebind<_Alloc, _Tp>::__type;
};
}

namespace __gnu_cxx {
template 
struct __alloc_traits : std::allocator_traits<_Alloc> {
  typedef std::allocator_traits<_Alloc> _Base_type;
  template  struct rebind {
typedef typename _Base_type::template rebind_alloc<_Tp> other;
  };
};
}
namespace std {
namespace __cxx11 {
template  class basic_string {
  typedef
  typename __gnu_cxx::__alloc_traits<_Alloc>::template
rebind<_CharT>::other
  _Char_alloc_type;
  typedef __gnu_cxx::__alloc_traits<_Char_alloc_type> _Alloc_traits;

public:
  typedef _Char_alloc_type allocator_type;
  typedef typename _Alloc_traits::pointer pointer;
  struct _Alloc_hider {
_Alloc_hider(pointer, _Alloc);
  } _M_dataplus;
  pointer _M_local_data();
  allocator_type _M_get_allocator();
  basic_string(const basic_string &)
  : _M_dataplus(_M_local_data(), _M_get_allocator()) {}
  basic_string(_CharT *, _Alloc __a = _Alloc())
  : _M_dataplus(_M_local_data(), __a) {}
};
}
}

auto vglambda = [](auto printer) {
  return [=](auto &&... ts) { return [=] { printer(ts...); }; };
};
main()

{
  vglambda([](auto, auto, auto) {})(std::string(""), "", "");
}

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
The footnote to 6.5.2.3/5 says "Members can be safely accessed using a
non-atomic object which is assigned to or from the atomic object."  Does it
mean that the following is OK?

typedef struct
{
  int x;
} S;

int
read1 (_Atomic S p)
{
  S s = p;
  return s.x;
}

int
read2 (_Atomic S *p)
{
  S *s = p;
  return s->x;
}

void
write1 (_Atomic S p, int x)
{
  S s = p;
  s.x = x;
}

void
write2 (_Atomic S *p, int x)
{
  S *s = p;
  s->x = x;
}

[Bug libfortran/68987] [5/6 Regression] double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #2 from Jerry DeLisle  ---
I will investigate this one. Thanks for report.

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
(In reply to Marek Polacek from comment #4)
> The footnote to 6.5.2.3/5 says "Members can be safely accessed using a
> non-atomic object which is assigned to or from the atomic object."  Does it
> mean that the following is OK?

Yes, I think this is how this language construct is supposed to be used.

> void
> write1 (_Atomic S p, int x)
> {
>   S s = p;
>   s.x = x;
> }
> 
> void
> write2 (_Atomic S *p, int x)
> {
>   S *s = p;
>   s->x = x;
> }

Should be:

void
write2 (_Atomic S *p, int x)
{
  S s = {.x = x};
  *p = s;
}

write1 is a bit nonsensical.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle  ---
(In reply to Bill Schmidt from comment #22)
> Jerry, thanks very much for investigating.  Given all the discussion here I
> agree with XFAILing this test for all powerpc.  However, it does appear to
> be one of those intermittent failures, so we'll have to put up with the
> occasional XPASS in our test results.

OK, I will set the test case. Occasional xpass seems odd to me. Let me know
when you see it, maybe its some unitialized bits???

[Bug libstdc++/68982] [6 Regression] Missing explicit qualification for std::forward in functional

[rogero at howzatt dot demon.co.uk]

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

--- Comment #5 from Roger Orr  ---
Thank you ;-)

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #6 from Marek Polacek  ---
Eh, yeah, thanks.

So I think mine but this will likely need to wait till January.

[Bug c/68994] GCC doesn't issue any diagnostic for missing end-of-line marker

[tvr.bc.32 at gmail dot com]

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

l3x  changed:

   What|Removed |Added

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

--- Comment #1 from l3x  ---
Found a duplicate: #14331.

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

[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"

[tvr.bc.32 at gmail dot com]

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

l3x  changed:

   What|Removed |Added

 CC||tvr.bc.32 at gmail dot com

--- Comment #21 from l3x  ---
*** Bug 68994 has been marked as a duplicate of this bug. ***

[Bug c++/67669] Wrong works fwrite or fread or both

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #5 from TC  ---
I can reproduce this with both MSYS2/MinGW64 GCC 5.2.0 and Clang 3.7+libc++, so
not a GCC problem. This also reproduces with Visual Studio 2015.

This is likely caused by a bug in Microsoft's C runtime library.

Presumably Borland C++ Builder has its own C runtime.

[Bug go/68562] morestack misaligns stack on x86_64

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
 CC||cmang at google dot com
  Component|libgcc  |go
   Assignee|unassigned at gcc dot gnu.org  |ian at airs dot com
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
Only affects "go".

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Adjusted testcase for testsuite purposes:

static const float a[3] = { 1, 2, 3 };
int b = 3;

__attribute__((noinline, noclone)) void
bar (int x)
{
  if (x != b++)
__builtin_abort ();
}

void
foo (float *x, int y)
{
  int i;
  for (i = 0; i < 2 * y; ++i)
{
  if (i < y)
x[i] = a[i];
  else
{
  bar (i);
  x[i] = a[i - y];
}
}
}

int
main ()
{
  float x[10];
  unsigned int i;
  for (i = 0; i < 10; ++i)
x[i] = 1337;
  foo (x, 3);
  for (i = 0; i < 10; ++i)
if (x[i] != (i < 6 ? (i % 3) + 1 : 1337))
  __builtin_abort ();
  return 0;
}

[Bug c++/68998] [5 Regression] Wrong code generated regarding constexpr arrays

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
 CC||trippels at gcc dot gnu.org
  Known to work||6.0
Summary|Wrong code generated|[5 Regression] Wrong code
   |regarding constexpr arrays  |generated regarding
   ||constexpr arrays
 Ever confirmed|0   |1
  Known to fail||5.3.1
   Severity|critical|normal

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. Only 5.3 is affected.
Strangely it doesn't happens when using -O2.

[Bug c++/67669] Wrong works fwrite or fread or both

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Markus Trippelsdorf  ---
Closing.

[Bug go/68562] morestack misaligns stack on x86_64

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
This happens with glibc trunk. The dynamic linker now uses SSE instructions
internally and as a result segfaults when the stack is misaligned.

[Bug libstdc++/68982] [6 Regression] Missing explicit qualification for std::forward in functional

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Dec 21 14:16:36 2015
New Revision: 231881

URL: https://gcc.gnu.org/viewcvs?rev=231881=gcc=rev
Log:
Rename test file that had incorrect bug number

PR libstdc++/68982
testsuite/20_util/function_objects/mem_fn/68276.cc: Rename to ...
testsuite/20_util/function_objects/mem_fn/68982.cc: Correct bug number.

Added:
trunk/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/68982.cc
  - copied, changed from r231880,
trunk/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/68276.cc
Removed:
trunk/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/68276.cc
Modified:
trunk/libstdc++-v3/ChangeLog

[Bug tree-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Looks like a RA issue to me.
At least, on -m32 -O3 -march=x86-64 compiled:
short a;
int b = 1, f;
char c, e = 1;
long long d;

static short
foo ()
{
  unsigned g, h = 0;
  int i = 0 || d * (b | e);
  char j = a << i, l = a;
  short k;
  int m = -b;
  if (m < b)
{
  k = m = b;
  g = (k || l) / (b / e);
  if (b)
__builtin_printf ("foo=%lld\n", (long long) a);
}
  a = b = m;
  if (j || e)
{
  h = g;
  i = m;
  g = j * k / (i - d);
  if (m)
b = j && b;
  e = b * (h & d) || g;
}
  b = i;
  char n = e || h | d;
  e = i < d & k / n;
  return f;
}

int
main ()
{
  if (foo ())
if (c)
 lab:
  goto lab;
  return 0;
}

we in *.ira still have correct:
(insn 30 28 31 2 (parallel [
(set (reg/v:SI 103 [ m ])
(neg:SI (reg:SI 91 [ b.2_7 ])))
(clobber (reg:CC 17 flags))
]) pr68990-4.c:13 463 {*negsi2_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 31 30 32 2 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 91 [ b.2_7 ])
(reg/v:SI 103 [ m ]))) pr68990-4.c:14 7 {*cmpsi_1}
 (nil))
(jump_insn 32 31 33 2 (set (pc)
(if_then_else (le (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref 56)
(pc))) pr68990-4.c:14 631 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCGC 17 flags)
(int_list:REG_BR_PROB 5000 (nil)))
and
31:r91  l0   mem
13:r103 l0 3
but LRA turns that into:
(insn 256 207 208 2 (set (reg:SI 1 dx [orig:91 b.2_7 ] [91])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -28 [0xffe4])) [5 %sfp+-4 S4 A32]))
pr68990-4.c:13 86 {*movsi_internal}
 (nil))
(insn 208 256 30 2 (set (reg/v:SI 3 bx [orig:103 m ] [103])
(reg:SI 1 dx [orig:91 b.2_7 ] [91])) pr68990-4.c:13 86
{*movsi_internal}
 (nil))
(insn 30 208 286 2 (parallel [
(set (reg/v:SI 3 bx [orig:103 m ] [103])
(neg:SI (reg/v:SI 3 bx [orig:103 m ] [103])))
(clobber (reg:CC 17 flags))
]) pr68990-4.c:13 463 {*negsi2_1}
 (nil))
(insn 286 30 210 2 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -28 [0xffe4])) [5 %sfp+-4 S4 A32])
(reg:SI 3 bx [orig:91 b.2_7 ] [91])) pr68990-4.c:13 86
{*movsi_internal}
 (nil))
(insn 210 286 31 2 (set (reg:SI 3 bx [orig:91 b.2_7 ] [91])
(reg:SI 1 dx [orig:91 b.2_7 ] [91])) pr68990-4.c:14 86
{*movsi_internal}
 (nil))
(insn 31 210 32 2 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 3 bx [orig:91 b.2_7 ] [91])
(reg:SI 3 bx [orig:91 b.2_7 ] [91]))) pr68990-4.c:14 7 {*cmpsi_1}
 (nil))
(jump_insn 32 31 33 2 (set (pc)
(if_then_else (le (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref 56)
(pc))) pr68990-4.c:14 631 {*jcc_1}
 (int_list:REG_BR_PROB 5000 (nil))
 -> 56)
which is just wrong, instead of comparing m < b it suddenly compares b < b.

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
This is gdb session:

(gdb) r
Starting program: /space/homedirs/uros/test/a.out 

Program aborted. Backtrace:
#0  0x204D927
#1  0x204FCDF
#2  0x2120937
#3  0x12AB7 in foo_ at save_1.f90:11 (discriminator 3)
#4  0x12C1F in baz_ at save_1.f90:24

Program received signal SIGABRT, Aborted.
0x02290008 in raise () from /lib/libc.so.6.1
(gdb) bt
#0  0x02290008 in raise () from /lib/libc.so.6.1
#1  0x02291ae4 in abort () from /lib/libc.so.6.1
#2  0x0204fcb0 in ?? () from
/usr/lib/gcc/alpha-unknown-linux-gnu/4.9.3/libgfortran.so.3
#3  0x02120938 in _gfortran_abort () from
/usr/lib/gcc/alpha-unknown-linux-gnu/4.9.3/libgfortran.so.3
#4  0x00012ab8 in foo (b=) at save_1.f90:11
#5  0x00012c20 in baz () at save_1.f90:24
#6  0x0001273c in MAIN__ () at save_1.f90:27
#7  main (argc=, argv=) at save_1.f90:29
#8  0x02278464 in __libc_start_main () from /lib/libc.so.6.1
#9  0x000127a8 in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) f 4
#4  0x00012ab8 in foo (b=) at save_1.f90:11
11if (i .ne. 26 .or. j .ne. 131) call abort
(gdb) p i
$1 = 0
(gdb) p j
$2 = 131

As can be seen, "i" gets clobbered.

The difference starts with foo in f90.250r.sched1, where we now have:

;;   ==
;;   -- basic block 3 from 10 to 121 -- before reload
;;   ==

;;0--> b  0: i  17 r82=`*$LC0'
;;1--> b  0: i  16 r81=`s.894'
;;2--> b  0: i  10 r77=`i.892'
;;3--> b  0: i  20 r88=[r82+0xf&0xfff8]
;;4--> b  0: i  19 r84=[r82+0x8&0xfff8]
;;5--> b  0: i  22 r90=r82&0x7
;;5--> b  0: i  18 r83=[r82&0xfff8]
;;6--> b  0: i  27 r87=r88<<0x40-r82&0x7<<0x3
;;6--> b  0: i  43 r106=[r81+0xf&0xfff8]
;;7--> b  0: i  24 r86=r84<<0x40-r82&0x7<<0x3
;;7--> b  0: i  31 r92=[r82+0x10&0xfff8]
;;8--> b  0: i  26 r84=zxt(r84,0x40,r82<<0x3)
;;8--> b  0: i  32 r93=[r82+0x13&0xfff8]
;;9--> b  0: i  28 r87={(r90==0)?0:r87}
;;9--> b  0: i  44 r105=[r81&0xfff8]
;;   10--> b  0: i  23 r83=zxt(r83,0x40,r82<<0x3)
;;   10--> b  0: i  40 r101=[r82+0x14&0xfff8]
;;   11--> b  0: i  25 r86={(r90==0)?0:r86}
;;   11--> b  0: i  13 r79=`j.893'
;;   12--> b  0: i  30 r84=r84|r87
;;   13--> b  0: i  29 r83=r83|r86
;;   14--> b  0: i  46 r104=unspec[r84,0x40,r81] 3
;;   15--> b  0: i  51 r106=unspec[r106,0x40,r81] 4
;;   16--> b  0: i  48 r103=unspec[r83,0x40,r81] 3
;;   17--> b  0: i  47 r84=r84< b  0: i  53 r106=r106|r104
;;   18--> b  0: i  55 [r81+0xf&0xfff8]=r106
;;   19--> b  0: i  33 r94=r82+0x10
;;   20--> b  0: i  50 r103=r103|r84
;;   20--> b  0: i  56 [r81+0x8&0xfff8]=r103
;;   21--> b  0: i  34 r95=zxt(r92,0x20,r94<<0x3)
;;   21--> b  0: i  58 r109=[r81+0x13&0xfff8]
;;   22--> b  0: i  35 r96=r93&0x7fff<<0x40-r94&0x7<<0x3
;;   22--> b  0: i  59 r108=[r81+0x10&0xfff8]
;;   23--> b  0: i  60 r112=r81+0x10
;;   24--> b  0: i  38 r99=r95|r96
;;   25--> b  0: i  61 r111=unspec[r99,0x20,r112] 3
;;   26--> b  0: i  63 r109=unspec[r109,0x20,r112] 4
;;   27--> b  0: i  62 r110=zxn(r99#0)< b  0: i  64 r108=!0x< b  0: i  65 r109=r109|r111
;;   29--> b  0: i  67 [r81+0x13&0xfff8]=r109
;;   30--> b  0: i  66 r108=r108|r110
;;   30--> b  0: i  68 [r81+0x10&0xfff8]=r108
;;   31--> b  0: i  41 r102=r82+0x14
;;   31--> b  0: i  69 r114=[r81+0x14&0xfff8]
;;   32--> b  0: i  42 r100#0=zxt(r101,0x8,r102<<0x3)
;;   33--> b  0: i  70 r113=r81+0x14
;;   34--> b  0: i  49 r83=r83< b  0: i  52 r105=!0x< b  0: i  71 r114=!0xff< b  0: i  72 r115=zxn(r100)< b  0: i  78 $18=0x3
;;   39--> b  0: i  79 $17=0x20
;;   40--> b  0: i  80 $16=r81+0x15
;;   41--> b  0: i  11 r78=0x1a
;;   41--> b  0: i  12 [r77]=r78
;;   42--> b  0: i  14 r80=0x83
;;   42--> b  0: i  15 [r79]=r80
;;   43--> b  0: i  54 r105=r105|r83
;;   43--> b  0: i  57 

[Bug target/1078] Problems with attributes documentation

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #7 from sandra at gcc dot gnu.org ---
Problems (1) and (2) have been corrected.  Documentation for "no_stack_limit"
and "com_interface" is still missing, but "common" and "init_priority" are now
documented.

Since the list of attributes and targets has changed greatly over the past 15
years I think the list of attributes missing documentation in the initial PR is
not very useful any more  better to scan the current code and fix problems
immediately if possible rather than let the list sit for another 15 years.  :-)

[Bug middle-end/68999] New: [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

Bug ID: 68999
   Summary: [6 Regression]: FAIL:
gfortran.fortran-torture/execute/save_1.f90 execution
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: alphaev68-linux-gnu

Recent testsuite failure on alphaev68-linux-gnu [1]:

FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2
-fbounds-check 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2
-fomit-frame-pointer -finline-functions 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
-ftree-vectorize -mmax 

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg01618.html

[Bug c++/68983] [6 Regression] ICE: in store_field, at expr.c:6659

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The first added hunk has been:
   /* Except for initialization of full bytes from a CONSTRUCTOR, which
  we will handle specially below.  */
   && !(TREE_CODE (exp) == CONSTRUCTOR
&& bitsize % BITS_PER_UNIT == 0))
but that does not cover this case, where the bitsize is a multiple of
BITS_PER_UNIT (and exp is not a CONSTRUCTOR), yet it is still a constructor
store of a struct that with padding is 64 bits into a target that is only 40
bits.

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/68761] -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Please report that into a separate PR, this one is graphite related, your is
some C++17 C++ FE bug.  What is going on is that cp_genericize_r first converts
changes a by-reference RESULT_DECL into INDIRECT_REF of it, and then (dunno if
because of tree sharing or some constexpr stuff) at some point that IL is
passed again to cp_genericize_r again and again performs the same change, so we
in the end have two nested INDIRECT_REFs and the types don't match any longer.

[Bug libstdc++/66693] [C++17] std::tuple_size fails with const std::array

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Dec 21 11:22:16 2015
New Revision: 231875

URL: https://gcc.gnu.org/viewcvs?rev=231875=gcc=rev
Log:
PR libstdc++/66693.

* include/std/tuple (tuple_element, tuple_size, tuple_element_t,
__tuple_element_t): Move to...
* include/std/utility: ...here.
* testsuite/20_util/pair/astuple/astuple.cc: Adjust.
* testsuite/20_util/pair/astuple/astuple_cpp14.cc: New.
* testsuite/20_util/tuple/tuple_element.cc: Adjust.
* testsuite/20_util/tuple/tuple_element_t.cc: Likewise.
* testsuite/20_util/tuple/tuple_size.cc: Likewise.
* testsuite/23_containers/array/tuple_interface/tuple_element.cc:
Likewise.
* testsuite/23_containers/array/tuple_interface/tuple_element_cpp14.cc:
New.
* testsuite/23_containers/array/tuple_interface/tuple_size.cc: Adjust.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/astuple/astuple_cpp14.cc
   
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_cpp14.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/include/std/utility
trunk/libstdc++-v3/testsuite/20_util/pair/astuple/astuple.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/tuple_element.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/tuple_element_t.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/tuple_size.cc
   
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element.cc
   
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_size.cc

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[nickc at gcc dot gnu.org]

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

--- Comment #9 from Nick Clifton  ---
Author: nickc
Date: Mon Dec 21 08:23:35 2015
New Revision: 231873

URL: https://gcc.gnu.org/viewcvs?rev=231873=gcc=rev
Log:
PR 66827
* regex.c (EXTRACT_NUMBER): Cast sign byte to unsigned before left
shifting.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/regex.c

[Bug c++/68998] [5 Regression] Wrong code generated regarding constexpr arrays

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Testcase usable for testsuite:
template 
struct A { T v[N]; };

constexpr A 
foo ()
{
  A  a {};
  a.v[1] = 1;
  a.v[0] = 1;
  return a;
}

constexpr A  a = foo ();

int
main ()
{
  int k = 0;
  for (int i = 0; i < 2; i++)
for (int j = 0; j < a.v[i]; j++)
  k++;
  if (k != 2)
__builtin_abort ();
}

This got fixed on the trunk with r226949.
I'm surprised by the regression marker, as this seems to be broken since
r217663 when C++14 constexpr support has been added (before that it has been
rejected).
That said, it is a wrong-code bug, so maybe the r226949 change is backportable.
 Jason?

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r193104 (at least, r193100 is good, r193111 is bad).

[Bug c++/68998] New: Wrong code generated regarding constexpr arrays

[likan_999.student at sina dot com]

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

Bug ID: 68998
   Summary: Wrong code generated regarding constexpr arrays
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: likan_999.student at sina dot com
  Target Milestone: ---

The following code generates wrong result:

#include 
using namespace std;

template  struct ArrayHolder { T v[N]; };

constexpr ArrayHolder makeArray() {
  ArrayHolder a{};
  a.v[1] = 1;
  a.v[0] = 1;
  return a;
}
constexpr ArrayHolder arr = makeArray();

int main() {
  cout << arr.v[0] << endl;
  for (int i = 0; i < 2; i++) {
for (int j = 0; j < arr.v[i]; j++) {
  cout << "i = " << i << ", j = " << j << endl;
}
  }
}



Result:
[hidden] g++ -std=c++14 c.cpp && ./a.out 
1
i = 1, j = 0


Expected Result:
1
i = 0, j = 0
i = 1, j = 0


I am using priority 'critical' because it generates wrong code, silently, so it
is very bad.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Bug 66827 Summary: [6 Regression] left shifts of negative value warnings due to 
C++14 switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Introduced in r231478:

PR ipa/61886
PR middle-end/25140
* tree-ssa-alias.c (ptr_deref_may_alias_decl_p): Use compare_base_decls
(nonoverlapping_component_refs_of_decl_p): Update sanity check.
(decl_refs_may_alias_p): Use compare_base_decls.
* alias.c: Include cgraph.h
(rtx_equal_for_memref_p): Use rtx_equal_for_memref_p.
(compare_base_decls): New function.
(base_alias_check): Likewise.
(memrefs_conflict_p): Likewise.
(nonoverlapping_memrefs_p): Likewise.
* alias.h (compare_base_decls): Declare.

* gcc.c-torture/execute/alias-2.c: New testcase.

I will prepare some more analysis later. Author of the above commit CC'd.

[Bug bootstrap/68992] [6 Regression] bootstrap error on s390x-linux-gnu with r231848

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Fixed with:
https://gcc.gnu.org/viewcvs?rev=231876=gcc=rev

[Bug tree-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Note you may need -march=x86-64 to reproduce.

Started with r228231:

commit 3ef16338b7f4970607d1d0b9c8228bfe3aeeca94
Author: ienkovich 
Date:   Tue Sep 29 09:32:40 2015 +

gcc/

PR target/65105
* config/i386/i386.c: Include dbgcnt.h.
...

[Bug c++/69001] New: g++ --std=c++17 -g internal compiler error: in create_tmp_var, at gimple-expr.c:519

[nheghathivhistha at gmail dot com]

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

Bug ID: 69001
   Summary: g++ --std=c++17 -g internal compiler error: in
create_tmp_var, at gimple-expr.c:519
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com
  Target Milestone: ---

Created attachment 37094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37094=edit
Original source file from Gentoo Bugzilla

Found by Hunter Allen and reported at the Gentoo Bugzilla
as https://bugs.gentoo.org/show_bug.cgi?id=568908.

As requested in PR68761 by Jakub Jelinek I am opening this standalone report.


Creduced case:

namespace std {
inline namespace __cxx11 {}
template  class allocator;
namespace __cxx11 {
template >
class basic_string;
typedef basic_string string;
}
template  class allocator {
public:
  template  struct rebind { typedef allocator other; };
};
template  struct __alloctr_rebind {
  typedef typename _Alloc::template rebind<_Tp>::other __type;
};
template  struct allocator_traits {
  typedef decltype(0) pointer;
  template 
  using rebind_alloc = typename __alloctr_rebind<_Alloc, _Tp>::__type;
};
}

namespace __gnu_cxx {
template 
struct __alloc_traits : std::allocator_traits<_Alloc> {
  typedef std::allocator_traits<_Alloc> _Base_type;
  template  struct rebind {
typedef typename _Base_type::template rebind_alloc<_Tp> other;
  };
};
}
namespace std {
namespace __cxx11 {
template  class basic_string {
  typedef
  typename __gnu_cxx::__alloc_traits<_Alloc>::template
rebind<_CharT>::other
  _Char_alloc_type;
  typedef __gnu_cxx::__alloc_traits<_Char_alloc_type> _Alloc_traits;

public:
  typedef _Char_alloc_type allocator_type;
  typedef typename _Alloc_traits::pointer pointer;
  struct _Alloc_hider {
_Alloc_hider(pointer, _Alloc);
  } _M_dataplus;
  pointer _M_local_data();
  allocator_type _M_get_allocator();
  basic_string(const basic_string &)
  : _M_dataplus(_M_local_data(), _M_get_allocator()) {}
  basic_string(_CharT *, _Alloc __a = _Alloc())
  : _M_dataplus(_M_local_data(), __a) {}
};
}
}

auto vglambda = [](auto printer) {
  return [=](auto &&... ts) { return [=] { printer(ts...); }; };
};
main()

{
  vglambda([](auto, auto, auto) {})(std::string(""), "", "");
}

[Bug tree-optimization/68761] -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519

[nheghathivhistha at gmail dot com]

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

--- Comment #5 from David Kredba  ---
(In reply to Jakub Jelinek from comment #4)
> Please report that into a separate PR, this one is graphite related, your is
> some C++17 C++ FE bug.  What is going on is that cp_genericize_r first
> converts changes a by-reference RESULT_DECL into INDIRECT_REF of it, and
> then (dunno if because of tree sharing or some constexpr stuff) at some
> point that IL is passed again to cp_genericize_r again and again performs
> the same change, so we in the end have two nested INDIRECT_REFs and the
> types don't match any longer.

Thank you, opened as PR69001.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Mon Dec 21 13:02:12 2015
New Revision: 231879

URL: https://gcc.gnu.org/viewcvs?rev=231879=gcc=rev
Log:
libstdc++/68276 consistently qualify std::forward

PR libstdc++/68276
* include/std/functional (__invoke_impl, _Mem_fn::operator()): Qualify
std::forward.
testsuite/20_util/function_objects/mem_fn/68276.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/68276.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug libstdc++/68982] [6 Regression] Missing explicit qualification for std::forward in functional

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This was fixed at r231879 but I put the wrong bug ID in the changelog so the
commit got logged on Bug 68276. Oops.

[Bug bootstrap/68992] [6 Regression] bootstrap error on s390x-linux-gnu with r231848

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||krebbel at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
Caused by a small thinko in:
https://gcc.gnu.org/viewcvs?rev=231813=gcc=rev

Should be fixed by now. Bootstrap is still running.

[Bug c++/69000] New: regression: internal compiler error: Segmentation fault

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69000
   Summary: regression: internal compiler error: Segmentation
fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

Created attachment 37093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37093=edit
ice-example.cpp: Example program demonstrating the fault

I've an ICE (segfault) with gcc trunk that compiles without fault using gcc
5.3.0 and earlier.

I attach a stripped down example that fails with the same symptoms as the
original source file.


On Redhat Linux 2.6.32-573.3.1.el6.x86_64 using gcc-trunnk as at 2015-12-11:

0xcfe20f crash_signal
../../gcc/toplev.c:334
0x93ab64 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3252
0x93ab64 symbol_table::decl_assembler_name_hash(tree_node const*)
../../gcc/symtab.c:80
0x93fe20 symtab_node::get_for_asmname(tree_node const*)
../../gcc/symtab.c:924
0x93ff6d symtab_node::verify_base()
../../gcc/symtab.c:994
0x940aef symtab_node::verify()
../../gcc/symtab.c:1172
0x940bef symtab_node::verify_symtab_nodes()
../../gcc/symtab.c:1190
0x9533bb symtab_node::checking_verify_symtab_nodes()
../../gcc/cgraph.h:602
0x9533bb symbol_table::compile()
../../gcc/cgraphunit.c:2364
0x955932 symbol_table::compile()
../../gcc/cgraphunit.c:2520
0x955932 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2546

It also fails on wandbox http://melpon.org/wandbox/
using 'gcc HEAD 6.0.0 20151220' showing a slightly different call stack:

Start
prog.cc:16:1: internal compiler error: Segmentation fault
 }
 ^

0xaa1bbf crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:334
0xccc002 make_decl_rtl(tree_node*)
/home/heads/gcc/gcc-source/gcc/varasm.c:1350
0xccf57b assemble_variable(tree_node*, int, int, int)
/home/heads/gcc/gcc-source/gcc/varasm.c:2144
0xcd3400 varpool_node::assemble_decl()
/home/heads/gcc/gcc-source/gcc/varpool.c:583
0x7af053 output_in_order
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2220
0x7af3bd symbol_table::compile()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2457
0x7b1432 symbol_table::compile()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2527
0x7b1432 symbol_table::finalize_compilation_unit()
/home/heads/gcc/gcc-source/gcc/cgraphunit.c:2553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
1
Finish

[Bug c++/66808] tree check fail in symbol_table::decl_assembler_name_hash

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The duped PR started to ICE with r225192, let me check this one.

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Executing on host:
/space/homedirs/uros/gcc-build-fast/gcc/testsuite/gfortran/../../gfortran
-B/space/homedirs/uros/gcc-build-fast/gcc/testsuite/gfortran/../../
-B/space/homedirs/uros/gcc
-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90
 -fno-diagnostics-show-caret -fdiagnost
ics-color=never  -w  -O3 -g  
-B/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs
-L/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./lib
gfortran/.libs
-L/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs
-L/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libatomic/.libs
 -
lm-o /space/homedirs/uros/gcc-build-fast/gcc/testsuite/gfortran/save_1.x   
(timeout = 300)
spawn /space/homedirs/uros/gcc-build-fast/gcc/testsuite/gfortran/../../gfortran
-B/space/homedirs/uros/gcc-build-fast/gcc/testsuite/gfortran/../../
-B/space/homedirs/uros/gcc-build-fast/a
lphaev68-unknown-linux-gnu/./libgfortran/
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90
-fno-diagnostics-show-caret -fdiagnostics-color=neve
r -w -O3 -g
-B/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs
-L/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs
-L/
space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs
-L/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libatomic/.libs
-lm -o /space/homedi
rs/uros/gcc-build-fast/gcc/testsuite/gfortran/save_1.x
PASS: gfortran.fortran-torture/execute/save_1.f90 compilation,  -O3 -g 
Setting LD_LIBRARY_PATH to
.:/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs:/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfort
ran/.libs:/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libatomic/.libs:/space/homedirs/uros/gcc-build-fast/gcc:.:/space/homedirs/uros/gcc-build-fast/alphaev68-unknown
-linux-gnu/./libgfortran/.libs:/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libgfortran/.libs:/space/homedirs/uros/gcc-build-fast/alphaev68-unknown-linux-gnu/./libato
mic/.libs:/space/homedirs/uros/gcc-build-fast/gcc
spawn [open ...]

Program aborted. Backtrace:
#0  0x12c73 in bar_
at
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90:17
#1  0x12c73 in baz_
at
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90:24
#2  0x1281b in MAIN__
at
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90:27
#3  0x1281b in main
at
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/save_1.f90:29
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution,  -O3 -g

[Bug libstdc++/68995] [4.9/5/6 Regression] Including both and can cause ADL problems in std::function SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Dec 21 13:02:18 2015
New Revision: 231880

URL: https://gcc.gnu.org/viewcvs?rev=231880=gcc=rev
Log:
libstdc++/68995 qualify calls to __callable_functor

PR libstdc++/68995
* include/std/functional (_function_handler, function): Qualify
__callable_functor.
* testsuite/20_util/function/68995.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/function/68995.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug tree-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|wrong code at -O3 on|[6 Regression] wrong code
   |x86_64-pc-linux-gnu in  |at -O3 on
   |32-bit mode.|x86_64-pc-linux-gnu in
   ||32-bit mode.
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, let me bisect.

[Bug c++/69000] regression: internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/66808] tree check fail in symbol_table::decl_assembler_name_hash

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #5 from Markus Trippelsdorf  ---
*** Bug 69000 has been marked as a duplicate of this bug. ***

[Bug c++/69000] regression: internal compiler error: Segmentation fault

[rogero at howzatt dot demon.co.uk]

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

--- Comment #2 from Roger Orr  ---
Thanks: apologies that my bugzilla-fu failed to find the duplicate.

[Bug c++/69001] g++ --std=c++17 -g internal compiler error: in create_tmp_var, at gimple-expr.c:519

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
What is going on is that cp_genericize_r first converts changes a by-reference
RESULT_DECL into INDIRECT_REF of it, and then (dunno if because of tree sharing
or some constexpr stuff) at some point that IL is passed again to
cp_genericize_r again and again performs the same change, so we in the end have
two nested INDIRECT_REFs and the types don't match any longer.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Oops, that was meant to be for Bug 68982

[Bug c++/66808] tree check fail in symbol_table::decl_assembler_name_hash

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 37095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37095=edit
gcc6-pr66808.patch

Untested fix.  My understanding is that the tsubst_decl code just in some cases
does not expect a local VAR_DECL template to have DECL_LANG_SPECIFIC set and
doesn't clear some fields in it.  For the __thread var DECL_LANG_SPECIFIC it is
created to hold the GNU TLS bit.

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[fw at gcc dot gnu.org]

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

--- Comment #2 from Florian Weimer  ---
(In reply to Martin Sebor from comment #1)
> I actually wouldn't want to see GCC start issuing warnings for this code
> because it has well-defined semantics there.

Unfortunately, the generated code is truly abysmal, for example:

read1:
pushq   %rbp
movq%rsp, %rbp
movl%edi, -32(%rbp)
movl-32(%rbp), %eax
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
popq%rbp
ret

read2:
pushq   %rbp
movq%rsp, %rbp
movq%rdi, -24(%rbp)
movq-24(%rbp), %rax
movl(%rax), %eax
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
popq%rbp
ret

> initialized using one of the ATOMIC_VAR_INIT() or atomic_init() macros

I don't see this qualification in 6.5.2.3/5.  I don't think this issue is
touched in your blog post at all.

[Bug gcov-profile/69004] New: -fprofile-use stage fails on ARM

[tulipawn at gmail dot com]

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

Bug ID: 69004
   Summary: -fprofile-use stage fails on ARM
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Hi,

I'd managed to build the C program in question on x86 Linux using the same
compiler version (gcc 4.9.3) with the exact steps so I expected to repeat the
procedure on armv7 (Odroid C1, Ubuntu 14.04) as well, however I'm getting this
error:

`error: corrupted value profile: value profile counter` 

and so on during the profile-use stage. 

Steps used:

1. -O3 -fprofile-generate -ftest-coverage and -lgcov
2. run the program
3. -O3 -fprofile-use and -lgcov

If you're interested in looking into this, please advise on how to provide more
debug info.

Thanks

[Bug c++/69005] New: [5/6 Regression] infinite(?) recursion in template instantiations

[redi at gcc dot gnu.org]

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

Bug ID: 69005
   Summary: [5/6 Regression] infinite(?) recursion in template
instantiations
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Reduced from https://bugzilla.redhat.com/show_bug.cgi?id=1293086

This used to compile with 5.1 and earlier. Needs C++11 or later.

namespace std
{
  struct true_type { static constexpr bool value = true; };
  struct false_type { static constexpr bool value = false; };

  template struct enable_if { using type = T; };
  template<> struct enable_if { };

  template struct is_same : false_type { };
  template struct is_same : true_type { };

  template
struct conditional
{
  using type = If;
};

  template
struct conditional
{
  using type = Else;
};

  template
struct __and_
: conditional::type
{ };

  template
struct __or_
: conditional::type
{ };

  template
struct __not_
: conditional::type
{ };

  template
T declval();
}

  template class function;

  template
class function<_Res(_Arg)>
{
  typedef _Res _Signature_type(_Arg);

  template
using _Invoke
= decltype(std::declval<_Functor&>()(std::declval<_Arg>()));

  // Used so the return type convertibility checks aren't done when
  // performing overload resolution for copy construction/assignment.
  template
using _NotSelf = std::__not_>;

  template
using _Callable
  = std::__and_<_NotSelf<_Functor>,
   std::is_same<_Invoke<_Functor>, _Res>>;

  template
using _Requires = typename std::enable_if<_Cond::value, _Tp>::type;

public:
  function() noexcept { }

  function(const function&) { }

  template, void>>
function(_Functor) { }

  _Res operator()(_Arg) const;
};

struct Foo {
  using Func = function;

  static const Func DefaultFunc;

  Func CurrentFunc = DefaultFunc;
};

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
I actually wouldn't want to see GCC start issuing warnings for this code
because it has well-defined semantics there.  It is true that the standard says
accessing an atomic object that hasn't been initialized using one of the
ATOMIC_VAR_INIT() or atomic_init() macros is undefined but that's a historical
accident caused by an incomplete integration of atomic types into the C11 core
language.  It's on my to do list to submit an issue for the next WG14 meeting
to have the requirement removed.

The details of why this code is safe in all known implementations are explained
in my upcoming blog entry.  If you see problems with it or have concerns please
let me know before it's published! :)

[Bug c++/66808] tree check fail in symbol_table::decl_assembler_name_hash

[rogero at howzatt dot demon.co.uk]

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

--- Comment #8 from Roger Orr  ---
Thank you.
I've tested the fix and it successfully compiles works both the sample program
uploaded to my duplicate pr69000 and also my original presenting case.

[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Dec 21 15:15:50 2015
New Revision: 231882

URL: https://gcc.gnu.org/viewcvs?rev=231882=gcc=rev
Log:
PR tree-optimization/65337
* tree-ssa-pre.c (eliminate): Also clean up abnormal edges if need be.

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

[Bug tree-optimization/65337] [5 regression] LTO bootstrap failure with Ada enabled

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[5/6 Regression]|[5 regression] LTO
   |bootstrap-lto gnat1 |bootstrap failure with Ada
   |linktime ICE:   |enabled
   |gcc/ada/exp_aggr.adb:6570:0 |
   |: internal compiler error:  |
   |in forward_edge_to_pdom, at |
   |tree-ssa-dce.c:1086 |

--- Comment #15 from Eric Botcazou  ---
The bootstrap works again on mainline.

[Bug lto/69003] New: Undefined reference with gcc -r incremental linking

[sirl at gcc dot gnu.org]

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

Bug ID: 69003
   Summary: Undefined reference with gcc -r incremental linking
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37096=edit
Testcase, use 'gmake all'.

The attached testcase doesn't link with gcc-6 r231874 on x86_64-linux-gnu:

gcc-6 -flto -fuse-linker-plugin -O2 -fno-common -Wall -Wextra -c file1.c
gcc-6 -flto -fuse-linker-plugin -O2 -fno-common -Wall -Wextra -c file2.c
file3.c
gcc-6 -flto -fuse-linker-plugin -O2 -fno-common -Wall -Wextra -DSTATICMODE -c
file3.c -o file3s.o
g++-6 -flto -fuse-linker-plugin  -r -nostdlib -o lib1.lib file1.o file3.o
g++-6 -flto -fuse-linker-plugin  -r -nostdlib -o lib2.lib file2.o file3s.o
g++-6 -flto -fuse-linker-plugin  -O2 -o testexe lib1.lib lib2.lib
lib2.lib: In function `t1':
(.text+0x23): undefined reference to `mode.lto_priv.0'
collect2: error: ld returned 1 exit status

The testcase links fine without LTO.

[Bug tree-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I think the problem is:
** Pseudos coalescing #1: **

  Coalescing move 5:r91(91)-r103(103) (freq=1)
 Removing move 5 (freq=1)
deleting insn with uid = 5.
 Make unique value for inheritance r256
 Make unique value for inheritance r257
 Make unique value for inheritance r258
 Make unique value for inheritance r259
 Make unique value for inheritance r260
 Make unique value for inheritance r262
 Make unique value for inheritance r264
Coalesced Moves = 1

in the other spot where insn 5 is it is perhaps possible to coalesce the two
pseudos, but not at the
  int m = -b;
  if (m < b)
comparison, where it breaks it.

[Bug tree-optimization/68990] [6 Regression] wrong code at -O3 on x86_64-pc-linux-gnu in 32-bit mode.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
BTW, with -mno-stv -O3 the testcase passes, and while the *.stv pass actually
doesn't do anything at all on this testcase, that switch already changes
expansion in a couple of places so no wonder that the RA makes different
decisions.

And, I haven't managed to create a testcase that would abort vs. return 0 from
main for good vs. bad, even other fail defining a stdarg function like printf
didn't help.  Do, unless somebody comes up with one, guess we'll need a
dg-output directive and try to match what is printed (without the newline in
there).

[Bug go/68980] [6 regression] ps -o cmd in gotest isn't portable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'd actually say that ps -o pid,ppid,comm would be better even on Linux, I
think it really wants to look for the process named sleep, rather than some
arbitrary command with sleep just as an argument or path component etc.
There is a risk that you kill some other command, that would say have arguments
/usr/bin/some_command sleep 12345
if $alarmpid is 12345.

[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Has this been applied or is it going to be for GCC 6?

[Bug c/69002] New: C front end should warn about undefined access to atomic structure or union

[fw at gcc dot gnu.org]

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

Bug ID: 69002
   Summary: C front end should warn about undefined access to
atomic structure or union
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

The following code currently compiles without warnings (apart from the
-Wunused-but-set-parameter warning), but the standard says in 6.5.2.3/5 that
this results in undefined behavior.

typedef _Atomic struct
{
  int x;
} S;


int
read1 (S p)
{
  return p.x;
}

int
read2 (S *p)
{
  return p->x;
}

void
write1 (S p, int x)
{
  p.x = x;
}

void
write2 (S *p, int x)
{
  p->x = x;
}

(Plus the same test for union instead of struct.)

[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dj at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Kai or DJ, is the patch ok for trunk/gcc 5?
Is that header always available if
#if defined (_WIN32) && !defined (__CYGWIN__)
or should it be guarded say by
#ifdef HAVE_WINCRYPT_H
and wincrypt.h added to AC_CHECK_HEADERS in configure?
The ChangeLog entry is wrong, libssp/ prefix shouldn't be there and on the
other side this PR should be mentioned there, but that is something that can be
trivially changed by the committer.
I can commit it if anybody from the GCC maintainers that know something about
Windows acks it.

[Bug fortran/68993] MERGE does not evaluate its arguments

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Mon, Dec 21, 2015 at 07:20:59AM +, Joost.VandeVondele at mat dot ethz.ch
wrote:
> I believe there was some confusion about the second testcase.
> The real question
> is if this is valid in all cases:
> 
> MERGE(C_NULL_PTR, C_LOC(pc), .NOT.PRESENT(pc)))
> 
> and I believe it is not, because all arguments might be evaluated. However, it
> is also OK not to evaluate all arguments for the reasons quoted.
> 

Yes, there is confusion.  I suspect the answer is the code is conforming
except when it isn't.  For example, IABS(I) is conforming for all 
values on a 2-complements system except for the value -huge(I)-1.

I would urge anyone trying to be clever to use clear syntax:

   if (present(pc)) then
  do stuff with pc
   else
  do stuff with c_null_ptr
   end if

[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
It hasn't, but I'll do it for GCC 6 so people who care about the resulting size
can use the non-verbose option

[Bug debug/68860] [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 37097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37097=edit
gcc6-pr68860-lto.patch

I've noticed that the new tests still fail with LTO.
It seems the reason is that LTO ignores DECL_HAS_DEBUG_ARGS_P etc., so this
stuff is just lost.
I've added some changes so that this is streamed, but it seems that is not
enough, DECL_ORIGIN of the decls is wrong, so it isn't used anyway.
BTW, Honza, why is:
  if (code == VAR_DECL
  && DECL_HAS_DEBUG_EXPR_P (t))
visit (DECL_DEBUG_EXPR (t));
used in hash_tree?  Depends on what the function is used for, if it is for code
generation or something like that, better it should not depend on the debug
info stuff...

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[aurelien at aurel32 dot net]

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

--- Comment #17 from Aurelien Jarno  ---
Created attachment 37098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37098=edit
output log with cselib.c patched

Please find attached the output with your cselib.c patch. Sorry for the delay.

If you want I can also try to setup a virtual machine image that can be used to
reproduce the problem.

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-21
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.1.0, 6.0

--- Comment #3 from Martin Sebor  ---
You're right.  I misunderstood the problem you are pointing out.  Not the
initialization but the access to a member of an atomic struct (I still haven't
paged the initialization stuff out of my brain.)  I agree that access to a
member of an atomic struct deserves a diagnostic (sorry for confusing things!)
and confirm the absence of it in currently supported GCC versions.

[Bug c++/67339] [5/6 Regression] Segfault when parsing a typename involving a template-alias

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[nickc at redhat dot com]

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

--- Comment #5 from Nick Clifton  ---
Created attachment 37099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37099=edit
Initialise the t_icode field of the sri structure created by copy_cost.

Hi Markus,

  Please could you try out the uploaded patch.

  I am currently running regression tests, but if it passes, and it works for
you, then I will submit it for review.

Cheers
  Nick