[Bug libstdc++/71364] [7 regression] recent tuple changes break range-v3 merge.cpp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.0
   Target Milestone|--- |7.0

[Bug tree-optimization/71366] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-01
   Target Milestone|--- |7.0
Summary|ICE on valid code at -O3 on |[7 Regression] ICE on valid
   |x86_64-linux-gnu:   |code at -O3 on
   |Segmentation fault  |x86_64-linux-gnu:
   ||Segmentation fault
 Ever confirmed|0   |1

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

Program received signal SIGSEGV, Segmentation fault.
0x008f7b16 in vec::length (
this=0xa5a5a5a5a5a5a5a5) at /space/rguenther/src/svn/trunk/gcc/vec.h:453
453   unsigned length (void) const { return m_vecpfx.m_num; }

looks like the loop struct is ggc_freed.

1309  if (canonicalize_loop_induction_variables
1310(loop, false, ul, !flag_tree_loop_ivcanon))
(gdb) l
1311{
1312  /* If we'll continue unrolling, we need to propagate constants
1313 within the new basic blocks to fold away induction variable
1314 computations; otherwise, the size might blow up before the
1315 iteration is complete and the IR eventually cleaned up.  */
1316  if (loop_outer (loop_father) && !loop_father->aux)
1317{
1318  father_stack.safe_push (loop_father);
1319  loop_father->aux = loop_father;

loop_outer (loop) != loop_father here.  That's odd (and unexpected, it will
break the iteration scheme).

[Bug ada/71358] GNAT.Command_Line.Getopt fails if there are no switches

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Jun  1 07:44:10 2016
New Revision: 236976

URL: https://gcc.gnu.org/viewcvs?rev=236976&root=gcc&view=rev
Log:
PR ada/71358
* g-comlin.adb (Display_Section_Help): Do not dereference
Config.Switches if it's null.
(Getopt): Likewise.

Modified:
branches/gcc-6-branch/gcc/ada/ChangeLog
branches/gcc-6-branch/gcc/ada/g-comlin.adb

[Bug ada/71358] GNAT.Command_Line.Getopt fails if there are no switches

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Jun  1 07:43:57 2016
New Revision: 236975

URL: https://gcc.gnu.org/viewcvs?rev=236975&root=gcc&view=rev
Log:
PR ada/71358
* g-comlin.adb (Display_Section_Help): Do not dereference
Config.Switches if it's null.
(Getopt): Likewise.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/g-comlin.adb

[Bug ada/71358] GNAT.Command_Line.Getopt fails if there are no switches

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #5 from Eric Botcazou  ---
Fixed in 6.2 and later.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

--- Comment #10 from jol_indien at yahoo dot fr ---
this patch doesn't do the trick, it detects the VIA Nano CPU as a core2 one.
I guess the problem is that processor is first set to PROCESSOR_GENERIC but the
VIA Nano CPU check (ie CENTAUR vendor + has_ssse3) is inside the
PROCESSOR_PENTIUMPRO switch case instead of default one.
Furthermore, I think the patch is missing the 'has_longmode' check to get sure
we have a x86_64 Nano / Eden x2/x4 CPU.

[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |7.0

[Bug tree-optimization/71366] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

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

[Bug tree-optimization/71359] [7 Regression] ICE at -Os and above in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, vec_safe_length)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Looks like a dup (I commented in the other PR already).

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

[Bug tree-optimization/69184] [6/7 Regression] ICE in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2685

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Let's close it as duplicate then.

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

[Bug tree-optimization/69068] [6/7 Regression] ICE in bb_contains_loop_phi_nodes, at graphite-isl-ast-to-gimple.c:1279

[rguenth at gcc dot gnu.org]

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

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

[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #1 from amker at gcc dot gnu.org ---
It doesn't look like a regression from the dump, I suspect it's because how gcc
handles symbol (arr_1/arr_2) in m32 PIE code.   I will have a look.
BTW, the patch itself is right, it triggers cost model issue again in which
wrong/inaccurate cost gives better result.   I am doing experiments rewriting
the whole cost computation part.

[Bug c++/70735] [5/6/7 Regression] problem combining std::function, generic lambdas and static variables

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #15 from Christophe Lyon  ---
Hi,
The gcc-6-branch version fails:
syntax error in target selector "target c++1y" for " dg-do 2 run { target c++1y
} "

Do you want to keep c++14 instead?

[Bug tree-optimization/71366] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Ok, so it happens that we optimize away the backedge of the loop father when
canonicalizing IVs in the inner loop which appears as

 <>
 # d_9 = PHI<2(7)>

 
 # d_3 = PHI
 if (d_3 >= 0)
   ;
 else
   -> loop latch of outer loop

There is a missed constant propagation from the CCP pass immediately before
cunrolli as well.

So we peel the loop based on undefinedness of a[0][d] in the last iteration.
So we never take the d<0 exit to the latch of the outer loop which in turn
prunes this edge.

In fact it is removed as pointless in remove_redundant_iv_tests (optimized to
1 != 0) and then removed by to_remove edges marked by
gimple_duplicate_loop_to_header_edge via remove_path which in turn adjusts
stuff to eventually unloop outer loops (sth the pass doesn't really expect).
In fact we carefully avoid doing this kind of stuff to the loop we unroll
itself.

[Bug c++/21413] diagnostic for instantiation should also reference the function which it is where the instantiation happens

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||paolo.carlini at oracle dot com
 Resolution|--- |FIXED

--- Comment #8 from Paolo Carlini  ---
AFAICS, 4.7.x already clearly printed the second overload in the error message.

[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  ---
I'm having another look at this, and the last comments added to DR1584 and
coming to the conclusion that gcc probably doesn't need further work, in
particular the patch that I had to revert pointed to a real issue. Other
comments?

[Bug libstdc++/71364] [7 regression] recent tuple changes break range-v3 merge.cpp

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-01
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Ville Voutilainen  ---
I'll do some bisecting and other analysis.

[Bug c++/71368] New: [concepts] ICE on constrained compound requirement

[lucdanton at free dot fr]

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

Bug ID: 71368
   Summary: [concepts] ICE on constrained compound requirement
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

The following produces an ICE on both GCC 6.1 and trunk (rev. 236974):

$ cat main.cpp
struct inner;

template concept bool CompoundReq = requires {
// fine with concrete type in trailing type, i.e. inner& instead of X&
{ X::inner_member() } -> X&;
};

template concept bool Concept = requires {
{ X::outer_member() } -> CompoundReq;
};

struct inner { static inner& inner_member(); };
struct outer { static inner outer_member(); };

int main()
{
// fine
static_assert( CompoundReq );
static_assert( CompoundReq );

// ICE
static_assert( Concept );
}
$ g++-trunk -std=c++1z -fconcepts main.cpp
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)

[Bug c++/71369] New: Compile failure about template function call operator

[jkjeon at etri dot re.kr]

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

Bug ID: 71369
   Summary: Compile failure about template function call operator
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jkjeon at etri dot re.kr
  Target Milestone: ---

Please see the following code:

struct Func {
template 
void operator()() {}
};

template 
void func(Functor functor) {
functor.operator()();
}

int main()
{
func<3>(Func());
}


The gcc 6.1.0 can't compile this code.
On the other hand, the following code is compiled w/o any problem:

struct Func {
template 
void operator()() {}
};

template 
void func(Func functor) {
functor.operator()();
}

int main()
{
func<3>(Func());
}

MSVC 2015 seems to compiles both of the codes successfully, while 
Clang suffers from the same problem.

Thank you.

[Bug c++/66635] g++ ICE when compiling constexpr code with comma operator

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Indeed, but the ICE was real and it's fixed for 5.4.0. I'm adding a testcase
and closing the bug.

[Bug c++/66635] g++ ICE when compiling constexpr code with comma operator

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun  1 09:48:05 2016
New Revision: 236978

URL: https://gcc.gnu.org/viewcvs?rev=236978&root=gcc&view=rev
Log:
2016-06-01  Paolo Carlini  

PR c++/66635
* g++.dg/cpp0x/constexpr-ice16.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice16.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/66635] g++ ICE when compiling constexpr code with comma operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

--- Comment #11 from jol_indien at yahoo dot fr ---
Created attachment 38618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38618&action=edit
patch to properly detect VIA nano CPU + add Nano / Eden x2/x4 families arch
keywords

This patch is more invasive but allows the detection of all x86_64 VIA CPUs via
-march=native or dedicated new arch keywords.
Added CPUs are:
* Eden dual-core (aka eden-x2)
* Eden quad-core (aka eden-x4)
* generic Nano (aka nano)
* Nano 1xxx series (aka nano-1000)
* Nano 2xxx series (aka nano-2000)
* Nano 3xxx series (aka nano-3000)
* Nano dual-core (aka nano-x2)
* Nano quad-core (aka nano-x4)
This might be a first step before adding full support for those CPUs (ie
scheduling infos, ...).

Beware that this patch has only been tested on a Nano U2250 processor;
furthermore, it _does not_ detect properly C7 and Eden 32 bits CPUs (aka Samuel
2, Nehemiah and Esther).

Feel free to adapt it to your own style; or I can try to merge it with the
latest proposed patch.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  1 10:33:35 2016
New Revision: 236980

URL: https://gcc.gnu.org/viewcvs?rev=236980&root=gcc&view=rev
Log:
2016-06-01  Richard Biener  

PR tree-optimization/71311
* match.pd (@0 < @1 && @0 < @2 -> @0 < min(@1,@2)): Add :c and
restrict to non-INTEGER_CST @0.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
  Component|middle-end  |tree-optimization

--- Comment #6 from Richard Biener  ---
The issue is latent again, keeping the bug open to chase the real issue
eventually when I have time to.

[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
I have a version that fails on x86_64 w/ -O2 -floop-nest-optimize:

int ii, nv, fw;
int k2[4];

void
c8 (int *u0)
{
  for (;;)
{
  ii = 0;
  if (ii < 1)
++ii;
  for (;;)
{
  int vn;
  for (vn = 0; vn < 2; ++vn)
{
  int mm;
  for (mm = 0; mm < 4; ++mm)
k2[mm] = nv;
}
  if (ii != 0)
break;
  *u0 = 0;
}
  fw = 0;
}
}

[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-01
 Ever confirmed|0   |1

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Arseny Solokha from comment #3)
> I have a version that fails on x86_64 w/ -O2 -floop-nest-optimize:
> 
> int ii, nv, fw;
> int k2[4];
> 
> void
> c8 (int *u0)
> {
>   for (;;)
> {
>   ii = 0;
>   if (ii < 1)
> ++ii;
>   for (;;)
> {
>   int vn;
>   for (vn = 0; vn < 2; ++vn)
> {
>   int mm;
>   for (mm = 0; mm < 4; ++mm)
> k2[mm] = nv;
> }
>   if (ii != 0)
> break;
>   *u0 = 0;
> }
>   fw = 0;
> }
> }

This fails on me on current trunk on aarch64 as well.
The original testcase ICEs for me on the GCC 6 branch on aarch64 but not on
very latest trunk.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to jol_indien from comment #10)
> this patch doesn't do the trick, it detects the VIA Nano CPU as a core2 one.

Yep, this was by design. There is no VIA entries in the processor entry table,
and core2 would be the correct "something reasonable" HW target.

I will merge together your follow-up patch, and commit the combined patch.

BTW: Can you please send me what to put in the ChangeLog as your name and
e-mail?

[Bug sanitizer/71370] New: asan infinite recursion if gcc configured without tls

[vladimir.simonov at acronis dot com]

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

Bug ID: 71370
   Summary: asan infinite recursion if gcc configured without tls
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.simonov at acronis dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Hi,

If gcc configured x86_64 with --disable-tls below code
crashes in runtime with stack overflow.

#include 
#include 

namespace 
{
  class A
  {
  public:
A() : B(malloc(10))
{
}
~A()
{
  free(B);
}
void* B;
  };

  A C;
}

int main(int argc, char* argv[])
{
  printf("Hello world!\n");
  return 0;
}


Here is gdb log
Program received signal SIGSEGV, Segmentation fault.
__sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1, 20>::Put (
this=this@entry=0x9510a0 <__sanitizer::theDepot>, args=...,
inserted=inserted@entry=0x0)
at
../../../../gcc-5.3.0/libsanitizer/sanitizer_common/sanitizer_stackdepotbase.h:95
95 
../../../../gcc-5.3.0/libsanitizer/sanitizer_common/sanitizer_stackdepotbase.h:
No such file or directory.
(gdb) up 1
#1 0x004ad512 in __emutls_get_address (
obj=obj@entry=0x4dbda0 <__emutls_v._ZN6__lsan15disable_counterE>)
at ../../../gcc-5.3.0/libgcc/emutls.c:159
159 ../../../gcc-5.3.0/libgcc/emutls.c: No such file or directory.
(gdb)
#17245 0x00404d46 in _start ()
(gdb) down
#17244 0x7751caa5 in __libc_start_main () from /lib64/libc.so.6
(gdb)
#17243 0x004a8ccb in __libc_csu_init ()
(gdb)
#17242 _GLOBAL__sub_I_main.cpp(void) ()
at H:/AB2/linex/dsk_supp/test/asan/main.cpp:26
26  H:/AB2/linex/dsk_supp/test/asan/main.cpp: No such file or directory.
(gdb)
#17241 __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535) at H:/AB2/linex/dsk_supp/test/asan/main.cpp:19
19  in H:/AB2/linex/dsk_supp/test/asan/main.cpp
(gdb)
#17240 0x00404cba in (anonymous namespace)::A::A (
this=0x1151d40 <(anonymous namespace)::C>)
at H:/AB2/linex/dsk_supp/test/asan/main.cpp:9
9   in H:/AB2/linex/dsk_supp/test/asan/main.cpp
(gdb)
#17239 0x0047b359 in __interceptor_malloc (size=size@entry=10)
at ../../../../gcc-5.3.0/libsanitizer/asan/asan_malloc_linux.cc:39
39  ../../../../gcc-5.3.0/libsanitizer/asan/asan_malloc_linux.cc: No such
file or directory.
(gdb)
#17238 0x0040b228 in __asan::asan_malloc (size=size@entry=10,
stack=stack@entry=0x7fffdb60)
at ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc:595
595 ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc: No such
file or directory.
(gdb)
#17237 0x0040ab1a in __asan::Allocate (size=,
size@entry=10, alignment=, alignment@entry=8,
stack=stack@entry=0x7fffdb60,
alloc_type=alloc_type@entry=__asan::FROM_MALLOC,
can_fill=can_fill@entry=true)
at ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc:383
383 in ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc
(gdb)
#17236 0x00493db0 in __lsan::DisabledInThisThread ()
at ../../../../gcc-5.3.0/libsanitizer/lsan/lsan_common.cc:33
33  ../../../../gcc-5.3.0/libsanitizer/lsan/lsan_common.cc: No such file or
directory.
(gdb)
#17235 0x004ad512 in __emutls_get_address (
obj=obj@entry=0x4dbda0 <__emutls_v._ZN6__lsan15disable_counterE>)
at ../../../gcc-5.3.0/libgcc/emutls.c:159
159 ../../../gcc-5.3.0/libgcc/emutls.c: No such file or directory.
(gdb)
#17234 0x0047b4c6 in __interceptor_calloc (nmemb=nmemb@entry=34,
size=size@entry=8)
at ../../../../gcc-5.3.0/libsanitizer/asan/asan_malloc_linux.cc:55
55  ../../../../gcc-5.3.0/libsanitizer/asan/asan_malloc_linux.cc: No such
file or directory.
(gdb)
#17233 0x0040b268 in __asan::asan_calloc (nmemb=nmemb@entry=34,
size=size@entry=8, stack=stack@entry=0x7fffd200)
at ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc:601
601 ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc: No such
file or directory.
(gdb)
#17232 0x0040ab1a in __asan::Allocate (size=,
size@entry=272, alignment=, alignment@entry=8,
stack=stack@entry=0x7fffd200,
alloc_type=alloc_type@entry=__asan::FROM_MALLOC,
can_fill=can_fill@entry=false)
at ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc:383
383 in ../../../../gcc-5.3.0/libsanitizer/asan/asan_allocator2.cc
(gdb)
#17231 0x00493db0 in __lsan::DisabledInThisThread ()
at ../../../../gcc-5.3.0/libsanitizer/lsan/lsan_common.cc:33
33  ../../../../gcc-5.3.0/libsanitizer/lsan/lsan_common.cc: No such file or
directory.
(gdb)
#17230 0x004ad512 in __emutls_get_address (
obj=obj@entry

[Bug c/71371] New: ICE with OpenMP taskloop and addressable iterator

[jakub at gcc dot gnu.org]

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

Bug ID: 71371
   Summary: ICE with OpenMP taskloop and addressable iterator
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void baz (int *);

void
foo (void)
{
  int i;
  #pragma omp taskloop
  for (i = 0; i < 100; i++)
baz (&i);
}

ICEs with -fopenmp.

[Bug c/71371] ICE with OpenMP taskloop and addressable iterator

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-01
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

--- Comment #13 from jol_indien at yahoo dot fr ---
(In reply to Uroš Bizjak from comment #12)
> I will merge together your follow-up patch, and commit the combined patch.
> 
> BTW: Can you please send me what to put in the ChangeLog as your name and
> e-mail?

I already merged the patches and tested it. It properly detects my Nano server
CPU. I also added code provision (CPU flags tests and comments) for C7 / Eden
detection. I suggest to wait this code to be filled up with reasonable values
before commiting.

My name is Jocelyn Mayer; I usually use my l_ind...@magic.fr e-mail for
contributions.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

--- Comment #14 from jol_indien at yahoo dot fr ---
Created attachment 38619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38619&action=edit
Merged patch to properly detect VIA nano CPU + add Nano / Eden x2/x4 families
arch keywords

This new patch is a merge of the 38608 from Uroš Bizjak and 38618 patches.
It has been tested on VIA Nano U2250 CPU.

[Bug fortran/63859] Fortran OpenACC declare directive

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
Summary|OpenACC DEVICE_RESIDENT |Fortran OpenACC declare
   |clause  |directive

--- Comment #2 from Thomas Schwinge  ---
The status of the Fortran OpenACC declare directive again came up in
,
and needs to be looked into.

[Bug c/48116] -Wreturn-type does not work as advertised

[marbacz at gmail dot com]

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

Marcin Baczyński  changed:

   What|Removed |Added

 CC||marbacz at gmail dot com

--- Comment #10 from Marcin Baczyński  ---
Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00032.html

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to jol_indien from comment #14)
> Created attachment 38619 [details]
> Merged patch to properly detect VIA nano CPU + add Nano / Eden x2/x4
> families arch keywords
> 
> This new patch is a merge of the 38608 from Uroš Bizjak and 38618 patches.
> It has been tested on VIA Nano U2250 CPU.

Looks good, I'll bootstrap and commit this version later today.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[ubizjak at gmail dot com]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to jol_indien from comment #14)
> > Created attachment 38619 [details]
> > Merged patch to properly detect VIA nano CPU + add Nano / Eden x2/x4
> > families arch keywords
> > 
> > This new patch is a merge of the 38608 from Uroš Bizjak and 38618 patches.
> > It has been tested on VIA Nano U2250 CPU.
> 
> Looks good, I'll bootstrap and commit this version later today.

Actually, according to:

+  {"eden-x2", PROCESSOR_K8, CPU_K8,
+   PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3

you should declare all these new processors as PROCESSOR_K8, and move:

+ if (vendor == signature_CENTAUR_ebx)
+   {
+ if (has_sse4_1)
+   /* Nano 3000 | Nano dual / quad core | Eden X4 */
...

this part under

case PROCESSOR_K8.

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

[gk at torproject dot org]

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

--- Comment #12 from Georg Koppen  ---
(In reply to Maxim Ostapenko from comment #10)
> I've build Firefox locally with clang with optimizations disabled
> (CFLAGS="-fsanitize=address -fsanitize-recover=address -O0") and got pretty
> the same backtrace:

What clang version/firefox version and build commands did you use for getting a
clang build that crashes? Using the clang I have on my Debian machine + mozilla
central does not seem to be enough.

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

[m.ostapenko at samsung dot com]

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

--- Comment #13 from Maxim Ostapenko  ---
Created attachment 38620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38620&action=edit
mozconfig

This .mozconfig with current trunk clang 3.9.0. The source code I've downloaded
from here:

$ hg clone https://hg.mozilla.org/mozilla-central/ firefox

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

[gjl at gcc dot gnu.org]

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

--- Comment #8 from Georg-Johann Lay  ---
What about avr_asm_function_rodata_section?  Isn't it possible to filter DECL
and only transform for addr_vect?

[Bug c++/71372] New: GCC Optimization "tree-dse" does not respect access to volatile* upon explicit cast.

[hdu...@tangerine-soft.de]

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

Bug ID: 71372
   Summary: GCC Optimization "tree-dse" does not respect access to
volatile* upon explicit cast.
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hdu...@tangerine-soft.de
  Target Milestone: ---

GCC 6.1. seems to have an issue by using access to storage which __exlicitly__
is casted to an "volatile*" in conjunction with optimization flag –ftree-dse

This issue has been observed with a crosscompiler which is based on the GCC
6.1.0, host: cygwin (32 bit), 
for target architecture m68k.


In order to illustrate the issue see 3 Cases (see details below):

1) Code snippet __without__ any explicit type cast to (volatile*). 
   GCC 6.1.0 with this code produces correct code.

2) Code Snippet __with__ explicit typecast to “volatile short*”. 
   In conjunction with optimization level -O1/2/3/s this creates wrong code.

   The code is wrong that despite the memory location is marked to be volatile*
the 
   very first access does not happen and seems to be optimized away!

3) Code Snippet __with__ explicit typecast to “volatile short*”.

   In conjunction with optimization level -O1/2/3/s but __excluding__
optimization “tree-dse”. 
   Now GCC 6.1.0 generates right code. 

+++
+ Example 1) ) Code snippet __without__ any explicit type cast. 
+ GCC 6.1.0 with this code produces correct code.
+++
// testmodule.cpp

void fpoke (void *addr, short val, int times, int wait)
{
  volatile unsigned short* FLASH = (volatile unsigned short*)0x2000;

  *(FLASH + 0) = 0xAA;
  *(FLASH + 1) = 0x55;
  *(FLASH + 0) = 0xA0;
}


hdusel@Merlin /cygdrive/w/tmp
$ /opt/gcc-6.1.0-myos/bin/m68k-elf-g++ -O3 testmodule.cpp -c

hdusel@Merlin /cygdrive/w/tmp
$ /opt/gcc-6.1.0-myos/m68k-elf/bin/objdump.exe -d ./testmodule.o

./testmodule.o: file format elf32-m68k

Disassembly of section .text:

 <_Z5fpokePvsii>:
   0:   4e56    linkw %fp,#0
   4:   207c 2000   moveal #536870912,%a0
   a:   4e5eunlk %fp
   c:   7055moveq #85,%d0
   e:   30bc 00aa   movew #170,%a0@
  12:   33c0 2000 0002  movew %d0,2002 <_Z5fpokePvsii+0x2002>
  18:   30bc 00a0   movew #160,%a0@
  1c:   4e75rts

+++
+ Example 2) Code Snippet __with__ explicit typecast to “volatile short*”. 
+ In conjunction with optimization level -O1/2/3/s this creates __wrong code__.
+
+ The __very first__ access to the storage address $2000 is missing!
+ (see remarks in the code snippet, below)
+++
// testmodule.cpp

void fpoke (void *addr, short val, int times, int wait)
{
  volatile unsigned short* FLASH = (volatile unsigned short*)0x2000;

  *(volatile unsigned short*)(FLASH + 0) = 0xAA; // this line will be optimized
away! Why?
  *(volatile unsigned short*)(FLASH + 1) = 0x55;
  *(volatile unsigned short*)(FLASH + 0) = 0xA0;
}

hdusel@Merlin /cygdrive/w/tmp
$ /opt/gcc-6.1.0-myos/bin/m68k-elf-g++ -O3 testmodule.cpp -c

hdusel@Merlin /cygdrive/w/tmp
$ /opt/gcc-6.1.0-myos/m68k-elf/bin/objdump.exe -d ./testmodule.o

./testmodule.o: file format elf32-m68k

Disassembly of section .text:

 <_Z5fpokePvsii>:
   0:   4e56    linkw %fp,#0
   4:   7055moveq #85,%d0
   6:   4e5eunlk %fp
   8:   33c0 2000 0002  movew %d0,2002 <_Z5fpokePvsii+0x2002>
   e:   303c 00a0   movew #160,%d0
  12:   33c0 2000   movew %d0,2000 <_Z5fpokePvsii+0x2000>
  18:   4e75rts

+++
+ Example 3) Code Snippet __with__ explicit typecast to “volatile short*”. 
+ In conjunction with optimization level -O1/2/3/s but __excluding__
optimization “tree-dse”. 
+ Now GCC 6.1.0 creates right code. 
+++
// testmodule.cpp (The same as on Issue 2)

void fpoke (void *addr, short val, int times, int wait)
{
  volatile unsigned short* FLASH = (volatile unsigned short*)0x2000;

  *(volatile unsigned short*)(FLASH + 0) = 0xAA;
  *(volatile unsigned short*)(FLASH + 1) = 0x55;
  *(volatile unsigned short*)(FLASH + 0) = 0xA0;
}

hdusel@Merlin /cygdrive/w/tmp
$ /opt/gcc-6.1.0-myos/bin/m68k-elf-g++ -O3 -fno-tree-dse testmodule.cpp -c

hdusel@Merlin /cygdrive/w/tmp
$ /opt/gcc-6.1.0-myos/m68k-elf/bin/objdump.exe -d ./testmodule.o

./testmodule.o: file format elf32-m68k


Disassembly of section .text:

 <_Z5fpokePvsii>:
   0:   4e56    linkw %fp,#

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

[senthil.thecoder at gmail dot com]

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

--- Comment #9 from Senthil Kumar Selvaraj  
---
For both kinds of invocation (mergeable constants and jump tables), the decl
passed is current_function_decl. And that looks right from the documentation
for the target hook.

I'll submit another patch for trunk that adds a new SECCAT_RODATA_JUMPTABLE to
enum section_category, and then passes the section_category down to the target
hook. avr_asm_function_rodata_section can then choose to return the correct
section based on the category.

What do you think?

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

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  1 13:08:24 2016
New Revision: 236989

URL: https://gcc.gnu.org/viewcvs?rev=236989&root=gcc&view=rev
Log:
2016-06-01  Richard Biener  

PR tree-optimization/71261
* tree-vect-patterns.c (check_bool_pattern): Gather a hash-set
of stmts successfully put in the bool pattern.  Remove
single-use restriction.
(adjust_bool_pattern_cast): Add cast at the use site via the
pattern def sequence.
(adjust_bool_pattern): Remove recursion, maintain a hash-map
of patterned defs.  Use the pattern def seqence instead of
multiple independent patterns.
(sort_after_uid): New qsort compare function.
(adjust_bool_stmts): New function to process stmts in the bool
pattern in IL order.
(vect_recog_bool_pattern): Adjust.
* tree-if-conv.c (ifcvt_split_def_stmt): Remove.
(ifcvt_walk_pattern_tree): Likewise.
(stmt_is_root_of_bool_pattern): Likewise.
(ifcvt_repair_bool_pattern): Likewise.
(tree_if_conversion): Do not call ifcvt_repair_bool_pattern.

* gcc.dg/torture/vect-bool-1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/vect-bool-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c
trunk/gcc/tree-vect-patterns.c

[Bug c++/71372] GCC Optimization "tree-dse" does not respect access to volatile* upon explicit cast.

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I've seen a similar bug being reported recently and was not able to confirm on
x86_64 so I made it target specific (IIRC it was mingw or cygwin).

GCC certainly honors volatile here (on x86_64-linux).

I can only guess that alignment and bitfield expansion may play a role.

[Bug c++/71372] [6/7 Regression] GCC Optimization "tree-dse" does not respect access to volatile* upon explicit cast.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-01
   Target Milestone|--- |6.2
Summary|GCC Optimization "tree-dse" |[6/7 Regression] GCC
   |does not respect access to  |Optimization "tree-dse"
   |volatile* upon explicit |does not respect access to
   |cast.   |volatile* upon explicit
   ||cast.
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Oh, confirmed on x86_64.  Only happens when compiling with the C++ frontend!

[Bug c++/71372] [6/7 Regression] GCC Optimization "tree-dse" does not respect access to volatile* upon explicit cast.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
sounds vaguely similar to PR 70848.
That also triggers only with g++

[Bug c++/71372] [6/7 Regression] GCC Optimization "tree-dse" does not respect access to volatile* upon explicit cast.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #4 from Richard Biener  ---
So pre gimplification we have

(gdb) p debug_generic_expr (0x769fcbe0)
*FLASH
(gdb) p ((tree)0x769fcbe0)->base.volatile_flag 
$5 = 0

thus somehow the INDIRECT_REF misses the TREE_THIS_VOLATILE flag.

So it is cp_fold folding

 
unit size 
align 16 symtab 0 alias set -1 canonical type 0x769ee7e0 precision
16 min  max 
pointer_to_this >
side-effects volatile
 ^^

via

unary:

  loc = EXPR_LOCATION (x);
  op0 = cp_fold_maybe_rvalue (TREE_OPERAND (x, 0), rval_ops);

  if (op0 != TREE_OPERAND (x, 0))
{
  if (op0 == error_mark_node)
x = error_mark_node;
  else
x = fold_build1_loc (loc, code, TREE_TYPE (x), op0);
^^^

but forgetting to re-apply TREE_THIS_VOLATILE.  This probably seriously breaks
volatile support.

[Bug tree-optimization/70848] [6/7 Regression] g++ arm-none-eabi ignores volatile qualifier

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
Analyzed in dup.

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

[Bug c++/71372] [6/7 Regression] GCC Optimization "tree-dse" does not respect access to volatile* upon explicit cast.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hendrikborghorst@googlemail
   ||.com

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

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[uros at gcc dot gnu.org]

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

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jun  1 13:44:37 2016
New Revision: 236991

URL: https://gcc.gnu.org/viewcvs?rev=236991&root=gcc&view=rev
Log:
PR target/67310
* config/i386/driver-i386.c (host_detect_local_cpu): Correctly
detect processor family for signature_CENTAUR_ebx.
: Pass c3, winchip2 or winchip-c6 for
signature_CENTAUR_ebx.
: Pass c3-2 for signature_CENTAUR_ebx.
: Pass x86-64 for has_longmode.


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

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak  ---
I have committed the bugfix part of the patch [1] to mainline SVN, and will
backport it to other release branches.

The addition of new VIA CPUs is not a regression fix, so the patch will be
applied to mainline only. Please post the patch to the gcc-patches@ mailing
list, following the usual contribution rules [2].

[1] https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00044.html
[2] https://gcc.gnu.org/contribute.html

[Bug tree-optimization/71366] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71366] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jun  1 14:05:22 2016
New Revision: 236993

URL: https://gcc.gnu.org/viewcvs?rev=236993&root=gcc&view=rev
Log:
2016-06-01  Richard Biener  

PR tree-optimization/71366
* tree-ssa-loop-ivcanon.c (edges_to_remove): New global.
(unloop_loops): Move removing edges here ...
(try_unroll_loop_completely): ... from here.
(try_peel_loop): ... and here.
(tree_unroll_loops_completely_1): Track parent loops via
bitmap of header BBs.
(tree_unroll_loops_completely): Adjust for that.

* gcc.dg/torture/pr71366-1.c: New testcase.
* gcc.dg/torture/pr71366-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71366-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr71366-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug middle-end/71371] ICE with OpenMP taskloop and addressable iterator

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  1 14:24:02 2016
New Revision: 236994

URL: https://gcc.gnu.org/viewcvs?rev=236994&root=gcc&view=rev
Log:
PR middle-end/71371
* gimplify.c (gimplify_omp_for): Temporarily clear gimplify_omp_ctxp
around creation of the temporary.

* c-c++-common/gomp/pr71371.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr71371.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

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

[gjl at gcc dot gnu.org]

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

--- Comment #10 from Georg-Johann Lay  ---
Well, then we should remove TARGET_ASM_FUNCTION_RODATA_SECTION implementation
altogether (it's weird, not only because it patches flag_data_sections), same
for ASM_OUTPUT_ADDR_VEC_ELT.

Instead implement ASM_OUTPUT_ADDR_VEC and do the whole addr_vec stuff by hand:

1) switch to correct section: if -ffunction-sections is on, cook up a section
like .progmem.gcc_sw_table., otherwise just
.progmem.gcc_sw_table

1) Alternatively, just emit .pushsection and .popsection around the jump table.

2) Output alignment .p2align.  The original alignment from
ASM_OUTPUT_BEFORE_CASE_LABEL might be too early (wrong section), so that the
alignment must be output again.  ASM_OUTPUT_BEFORE_CASE_LABEL is no more
needed.

3) Output the jump table, see final.c for how to iterate.

Anyway, we might consider putting the jump table into .text section.  Since
PR63223 we can handle jump-tables at any location, there is no need for having
it in .progmem (which is supposed to reside in the lowest 64k).  And for Tiny
targets, where .rodata is the best place, JUMP_TABLES_IN_TEXT_SECTION can just
return 0.

[Bug middle-end/71371] ICE with OpenMP taskloop and addressable iterator

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun  1 14:29:04 2016
New Revision: 236995

URL: https://gcc.gnu.org/viewcvs?rev=236995&root=gcc&view=rev
Log:
PR middle-end/71371
* gimplify.c (gimplify_omp_for): Temporarily clear gimplify_omp_ctxp
around creation of the temporary.

* c-c++-common/gomp/pr71371.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/gomp/pr71371.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/71156] PURE interface/definition inconsistency: accepts invalid, rejects valid

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Wed Jun  1 14:30:00 2016
New Revision: 236996

URL: https://gcc.gnu.org/viewcvs?rev=236996&root=gcc&view=rev
Log:
2016-06-01  Paul Thomas  

PR fortran/71156
* decl.c (copy_prefix): Add checks that the module procedure
declaration prefixes are compliant with the interface. Invert
order of existing elemental and pure checks.
* resolve.c (resolve_fl_procedure): Invert order of elemental
and pure errors.

2016-06-01  Paul Thomas  

PR fortran/71156
* gfortran.dg/submodule_14.f08: Add missing recursive prefix
to the module procedure declaration.
* gfortran.dg/submodule_16.f08: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_16.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/submodule_14.f08

[Bug middle-end/71371] ICE with OpenMP taskloop and addressable iterator

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 6.2+.

[Bug middle-end/71373] New: Handle more OMP_CLAUSE_* in nested function decomposition

[tschwinge at gcc dot gnu.org]

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

Bug ID: 71373
   Summary: Handle more OMP_CLAUSE_* in nested function
decomposition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

We don't handle several OMP_CLAUSE_* in nested function decomposition
(gcc/tree-nested.c), which will result in ICEs.

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

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay  ---
well, IIRC for Tiny .rodata is still a part of .data and not part of .text?  If
this is still the case, then on Tiny the best place for jump tables is also
.text.

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Isn't this generally a problem of the whole folder, not just cp_fold?
I mean, if you have say
MEM[&MEM[p, CST1], CST2]
and the outer MEM_REF has e.g. TREE_THIS_VOLATILE, TREE_THIS_NOTRAP,
TREE_SIDE_EFFECTS, TREE_READONLY, TREE_CONSTANT set on it, and you call fold on
it, then I don't see what would preserve those bits (not sure if all of them
are applicable).
I see just
  switch (TREE_CODE_LENGTH (code))
{
case 1:
  op0 = TREE_OPERAND (t, 0);
  tem = fold_unary_loc (loc, code, type, op0);
  return tem ? tem : expr;
case 2:
  op0 = TREE_OPERAND (t, 0);
  op1 = TREE_OPERAND (t, 1);
  tem = fold_binary_loc (loc, code, type, op0, op1);
  return tem ? tem : expr;
case 3:
  op0 = TREE_OPERAND (t, 0);
  op1 = TREE_OPERAND (t, 1);
  op2 = TREE_OPERAND (t, 2);
  tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
  return tem ? tem : expr;
without really trying to preserve anything.  Similarly to this cp_fold has
similar problem, c_fully_fold* will work more often than cp_fold, because it
always goes through build instead of fold_build*, followed by copying over of
TREE_THIS_VOLATILE and various other flags, and only then calls fold on the
whole result, so just for the tem != NULL cases above can drop the flags, but
in cp_fold it always calls fold_build* without copying flags over.

Now, the question is, if what we should do here and cp_fold is not fold at all
for TREE_THIS_VOLATILE (in cp_fold then just build and copy over flags), or
fold, check if the result of the folding is still e.g. tcc_reference, and just
set the flag on the result if it has been set before.

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

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from Bill Seurer  ---
I tried it and it indeed appears to be fixed.  Thanks!

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Jun  1 17:06:50 2016
New Revision: 237003

URL: https://gcc.gnu.org/viewcvs?rev=237003&root=gcc&view=rev
Log:
2016-06-01  Jerry DeLisle  

PR fortran/52393
* io.c (match_io): For READ, try to match a default character
expression. If found, set the dt format expression to this,
otherwise go back and try control list.

PR fortran/52393
* gfortran.dg/fmt_read_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_read_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71335] [7 Regression] wrong code at -O2 and -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
Sigh.  I see what's going on.  Definitely mine.

[Bug fortran/71156] PURE interface/definition inconsistency: accepts invalid, rejects valid

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Wed Jun  1 18:46:11 2016
New Revision: 237004

URL: https://gcc.gnu.org/viewcvs?rev=237004&root=gcc&view=rev
Log:
2016-06-01  Paul Thomas  

PR fortran/71156
* decl.c (copy_prefix): Add checks that the module procedure
declaration prefixes are compliant with the interface. Invert
order of existing elemental and pure checks.
* resolve.c (resolve_fl_procedure): Invert order of elemental
and pure errors.

2016-06-01  Paul Thomas  

PR fortran/71156
* gfortran.dg/submodule_14.f08: Add missing recursive prefix
to the module procedure declaration.
* gfortran.dg/submodule_16.f08: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_16.f08
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_14.f08

[Bug libfortran/71363] Issue when sizeof(double) = sizeof(long double)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Paul Mustiere from comment #0)
> Hello,
> 
> I am building the GNU toolchain for Android with support for Fortran, and
> encountered an issue when targeting x86 for the runtime library.
> 
> Note: I'm using the toolchain sources provided by Google, but as far as I
> can tell the Fortran part is simply 4.9 since they are not trying to build
> with Fortran.
> 
> In intrisics/cshift0.c, I get a 'duplicate case value'
> (http://paste.ubuntu.com/16861425/). As far as I can tell:
> 
> - GFC_DTYPE_REAL_16 is defined (but not GFC_DTYPE_REAL_10), hence
> GFC_REAL_16 is defined as long double.
> - sizeof(long double) = sizeof(double) = 8, which causes the duplicate case.
> 
> I find a workaround which consists of detecting both sizes in mk-kinds-h.sh
> and checking that they are not equal before defining GFC_REAL_16. The rest
> of the toolchain compiles fine, but I am not sure it's ideal.
> Also, I'm curious as to why Fortran seems to be fine with real (kind=16) but
> C doesn't seem to be able to hold variables that big.
> 
> I know I'm not using the regular GNU toolchain but any help is appreciated.
> 
> Cheers,
> Paul Mustiere

Unless you can reproduce the problem with sources from head (aka 7.0),
the 6-branch, or 5-branch, I afraid you are on your own.  If you can
reproduce the problem with "official" source feel free to re-open the
bug report.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

jol_indien at yahoo dot fr changed:

   What|Removed |Added

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

--- Comment #19 from jol_indien at yahoo dot fr ---
(In reply to Uroš Bizjak from comment #18)
> I have committed the bugfix part of the patch [1] to mainline SVN, and will
> backport it to other release branches.

Great, thanks for this !

> The addition of new VIA CPUs is not a regression fix, so the patch will be
> applied to mainline only. Please post the patch to the gcc-patches@ mailing
> list, following the usual contribution rules [2].

OK, I'll do this way.
Then this bug can be considered closed now.

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
In resolution file we have:
1
q.o 5
200 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z3foov
212 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z3foov.arch_core2
215 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z3foov.resolver
222 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z13_Z3foov.ifuncv
224 7c41b073ca657863 PREVAILING_DEF main

which seems to miss the fact that _Z13_Z3foov.ifuncv is magic (I believe
because it is the resolver that should be used to find proper implementation). 
I suppose linker has no way to tell us, because ifuncs are not streamed to LTO
symtab.  How exactly the ifuncs are represented in normal ELF?

[Bug target/71186] PowerPC64: Autovectorised code hits ICE with -O3 -mpower9 -mlra

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Wed Jun  1 20:09:35 2016
New Revision: 237006

URL: https://gcc.gnu.org/viewcvs?rev=237006&root=gcc&view=rev
Log:
[gcc]
2016-05-31  Michael Meissner  

PR target/71186
* config/rs6000/vsx.md (xxspltib__nosplit): Add alternatives
for loading up all 0's or all 1's.

[gcc/testsuite]
2016-05-31  Michael Meissner  

PR target/71186
* gcc.target/powerpc/pr71186.c: New test.

Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md   
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000)   
(revision 236935)
+++ gcc/config/rs6000/vsx.md(.../gcc/config/rs6000) (working copy)
@@ -776,8 +776,8 @@ (define_insn "xxspltib_v16qi"
   [(set_attr "type" "vecperm")])

 (define_insn "xxspltib__nosplit"
-  [(set (match_operand:VSINT_842 0 "vsx_register_operand" "=wa")
-   (match_operand:VSINT_842 1 "xxspltib_constant_nosplit" "wE"))]
+  [(set (match_operand:VSINT_842 0 "vsx_register_operand" "=wa,wa")
+   (match_operand:VSINT_842 1 "xxspltib_constant_nosplit" "jwM,wE"))]
   "TARGET_P9_VECTOR"
 {
   rtx op1 = operands[1];

[gcc]
2016-05-31  Michael Meissner  

* config/rs6000/vsx.md (vsx_splat_, V2DI/V2DF): Simplify
alternatives, eliminating preferred register class.  Add support
for the MTVSRDD instruction in ISA 3.0.
(vsx_splat_v4si_internal): Use splat_input_operand instead of
reg_or_indexed_operand.
(vsx_splat_v4sf_internal): Likewise.

[gcc/testsuite]
2016-05-31  Michael Meissner  

* gcc.target/powerpc/p9-splat-4.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/p9-splat-4.c
trunk/gcc/testsuite/gcc.target/powerpc/pr71186.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug target/71186] PowerPC64: Autovectorised code hits ICE with -O3 -mpower9 -mlra

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Fixed in subversion id 237006.

[Bug ipa/71374] New: ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[su at cs dot ucdavis.edu]

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

Bug ID: 71374
   Summary: ICE on valid code at -O1 and above on
x86_64-linux-gnu: in extract_constrain_insn, at
recog.c:2190
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk (and
5.x and 6.x) at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit
modes.  

This is a regression from 4.9.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160601 (experimental) [trunk revision 236978] (GCC)
$
$ gcc-trunk -O0 -c small.c
$ gcc-4.9 -O1 -c small.c
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:5:1: error: unrecognizable insn:
 }
 ^
(insn 10 4 15 2 (parallel [
(set (reg:SI 2 cx [89])
(asm_operands:SI ("") ("=&c") 0 [
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
]
 [  
(asm_input:DI ("0q") small.c:4)
(asm_input:DI ("2") small.c:4)
]
 [] small.c:4))
(set (reg:SI 5 di [90])
(asm_operands:SI ("") ("=&D") 1 [
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
]
 [  
(asm_input:DI ("0q") small.c:4)
(asm_input:DI ("2") small.c:4)
]
 [] small.c:4))
(set (reg:SI 4 si [orig:88 p2 ] [88])
(asm_operands:SI ("") ("=&S") 2 [
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
]
 [  
(asm_input:DI ("0q") small.c:4)
(asm_input:DI ("2") small.c:4)
]
 [] small.c:4))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) small.c:4 -1
 (nil))
small.c:5:1: internal compiler error: in extract_constrain_insn, at
recog.c:2190
0xb56908 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-source-trunk/gcc/rtl-error.c:108
0xb56939 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-source-trunk/gcc/rtl-error.c:116
0xb24c3d extract_constrain_insn(rtx_insn*)
../../gcc-source-trunk/gcc/recog.c:2190
0xa4756f check_rtl
../../gcc-source-trunk/gcc/lra.c:2022
0xa4b379 lra(_IO_FILE*)
../../gcc-source-trunk/gcc/lra.c:2432
0xa01be9 do_reload
../../gcc-source-trunk/gcc/ira.c:5384
0xa01be9 execute
../../gcc-source-trunk/gcc/ira.c:5568
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.
$





int a, b, c;
extern inline void fn1 (void *p1, void *p2)
{ 
  __asm__ ("": "=&c" (a), "=&D" (b), "=&S" (c):"0q" (p2), "2" (p2));
}

[Bug target/71375] New: Failure on startup on rs6000-ibm-aix{4.3|5.1.0}

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 71375
   Summary: Failure on startup on rs6000-ibm-aix{4.3|5.1.0}
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---
Target: rs6000-ibm-aix4.3, rs6000-ibm-aix5.1.0

The following two configurations in contrib/config-list.mk are failing for me
in trunk:
  rs6000-ibm-aix4.3
  rs6000-ibm-aix5.1.0

with:

$ ./xgcc -B. -xc -c /dev/null
: internal compiler error: in altivec_init_builtins, at
config/rs6000/rs6000.c:16675
0xe03044 altivec_init_builtins
../../src/gcc/config/rs6000/rs6000.c:16675
0xe03044 rs6000_init_builtins
../../src/gcc/config/rs6000/rs6000.c:15935
0x63a3b2 c_define_builtins
../../src/gcc/c-family/c-common.c:5208
0x63a3b2 c_common_nodes_and_builtins()
../../src/gcc/c-family/c-common.c:5656
0x5873c9 c_init_decl_processing()
../../src/gcc/c/c-decl.c:3934
0x5d4028 c_objc_common_init()
../../src/gcc/c/c-objc-common.c:58
0x57793d lang_dependent_init
../../src/gcc/toplev.c:1755
0x57793d do_compile
../../src/gcc/toplev.c:1973


This appears to be an unhandled "mode0" value in this switch:


16645 /* Initialize the abs* operators.  */
16646 d = bdesc_abs;
16647 for (i = 0; i < ARRAY_SIZE (bdesc_abs); i++, d++)
16648   {
16649 machine_mode mode0;
16650 tree type;
16651   
16652 mode0 = insn_data[d->icode].operand[0].mode;
16653   
16654 switch (mode0)
[...snip...]
16674   default:
16675 gcc_unreachable ();

mode0 appears to be VOIDmode:

(gdb) p mode0
$1 = 

(gdb) p insn_data[d->icode].operand[0].mode
$3 = VOIDmode

[Bug c/70688] bogus OpenACC data clause errors involving reductions

[cesar at gcc dot gnu.org]

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

--- Comment #1 from cesar at gcc dot gnu.org ---
Created attachment 38621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38621&action=edit
new test case

This issue has been resolved in trunk r236678. I forgot to include a PR tag in
the ChangeLog entry. 

To verify the fix, I modified the original test case to make it executable in
the libgomp test suite. Furthermore, I changed parallel regions to parallel
loop regions so that the reduction yields sane results with multiple gangs.
I'll commit this test case to trunk with the proper PR tag in the ChangeLog
entry before I close this issue.

[Bug c/70688] bogus OpenACC data clause errors involving reductions

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Jun  1 20:37:44 2016
New Revision: 237011

URL: https://gcc.gnu.org/viewcvs?rev=237011&root=gcc&view=rev
Log:
PR c/70688
* pr70688.c: New file.


Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr70688.c
Modified:
trunk/libgomp/ChangeLog

[Bug c/70688] bogus OpenACC data clause errors involving reductions

[cesar at gcc dot gnu.org]

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

--- Comment #3 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Jun  1 20:40:10 2016
New Revision: 237012

URL: https://gcc.gnu.org/viewcvs?rev=237012&root=gcc&view=rev
Log:
PR c/70688
* pr70688.c: New file.


Added:
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr70688.c
Modified:
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug c/70688] bogus OpenACC data clause errors involving reductions

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from cesar at gcc dot gnu.org ---
Fixed in r237011.

[Bug c++/71376] New: __cpp_noexcept_function_type feature test macro not defined.

[eric at efcs dot ca]

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

Bug ID: 71376
   Summary: __cpp_noexcept_function_type feature test macro not
defined.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

GCC has recently implemented "noexcept as part of the type system" but the
feature test macro is not defined.

Reproducer:

void foo() noexcept {}

int main() {
auto fn = &foo;
#if !defined(__cpp_noexcept_function_type)
static_assert(noexcept(fn()) == false, "");
 #else
static_assert(noexcept(fn()), "");
#endif
}

[Bug c/70883] inconsistent error message for calls to __builtin_add_overflow with too few arguments

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Standalone patch requested and posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00093.html

[Bug c++/71243] Implicitly defined assignment operator is not constexpr even though it should be

[michele.caini at gmail dot com]

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

Michele Caini  changed:

   What|Removed |Added

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

--- Comment #3 from Michele Caini  ---
Works on debian sid (unstable), g++ v5.3.1-20. It seems to be fixed somehow.
I've not been able to find a ticket to which to link this one.

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

[michele.caini at gmail dot com]

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

Michele Caini  changed:

   What|Removed |Added

Version|5.3.1   |6.1.0

--- Comment #4 from Michele Caini  ---
Confirmed on GCC v6.1.0

[Bug c++/71377] New: SFINAE expression compiles, but it should not because of 14.5.5p8

[michele.caini at gmail dot com]

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

Bug ID: 71377
   Summary: SFINAE expression compiles, but it should not because
of 14.5.5p8
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

Consider the following code:

#include 
#include 

templateM)>* =
nullptr>
struct S: public S { };

template
struct S { };

int main() {
S<0, 1> c{};
}

I thought erroneously it is a clang bug, for it refused to compile it.
Instead, it seems to be a bug of GCC that accepts to compile it.
The code should be rejected because of 14.5.5p8:
http://eel.is/c++draft/temp.class.spec#8

This is the discussion on stackoverflow from which I got the ref to the
standard (thanks to the one that pointed my mistake out):
http://stackoverflow.com/a/37579096/4987285

[Bug target/71201] PowerPC XXPERM instruction fails on ISA 3.0 system.

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Wed Jun  1 23:23:42 2016
New Revision: 237021

URL: https://gcc.gnu.org/viewcvs?rev=237021&root=gcc&view=rev
Log:
[gcc]
2016-06-01  Michael Meissner  

Back port from trunk
2016-05-23  Michael Meissner  

PR target/71201
* config/rs6000/altivec.md (altivec_vperm__internal): Drop
ISA 3.0 xxperm fusion alternative.
(altivec_vperm_v8hiv16qi): Likewise.
(altivec_vperm__uns_internal): Likewise.
(vperm_v8hiv4si): Likewise.
(vperm_v16qiv8hi): Likewise.

Back port from trunk
2016-05-23  Michael Meissner  
Kelvin Nilsen  

* config/rs6000/rs6000.c (rs6000_expand_vector_set): Generate
vpermr/xxpermr on ISA 3.0.
(altivec_expand_vec_perm_le): Likewise.
* config/rs6000/altivec.md (UNSPEC_VPERMR): New unspec.
(altivec_vpermr__internal): Add VPERMR/XXPERMR support for
ISA 3.0.

[gcc/testsuite]
2016-06-01  Michael Meissner  

Back port from trunk
2016-05-23  Michael Meissner  
Kelvin Nilsen  

* gcc.target/powerpc/p9-permute.c: Run test on big endian as well
as little endian.

Back port from trunk
2016-05-23  Michael Meissner  
Kelvin Nilsen  

* gcc.target/powerpc/p9-vpermr.c: New test for ISA 3.0 vpermr
support.

[gcc]
2016-06-01  Michael Meissner  

Back port from trunk
2016-05-24  Michael Meissner  

* config/rs6000/altivec.md (VParity): New mode iterator for vector
parity built-in functions.
(p9v_ctz2): Add support for ISA 3.0 vector count trailing
zeros.
(p9v_parity2): Likewise.
* config/rs6000/vector.md (VEC_IP): New mode iterator for vector
parity.
(ctz2): ISA 3.0 expander for vector count trailing zeros.
(parity2): ISA 3.0 expander for vector parity.
* config/rs6000/rs6000-builtin.def (BU_P9_MISC_1): New macros for
power9 built-ins.
(BU_P9_64BIT_MISC_0): Likewise.
(BU_P9_MISC_0): Likewise.
(BU_P9V_AV_1): Likewise.
(BU_P9V_AV_2): Likewise.
(BU_P9V_AV_3): Likewise.
(BU_P9V_AV_P): Likewise.
(BU_P9V_VSX_1): Likewise.
(BU_P9V_OVERLOAD_1): Likewise.
(BU_P9V_OVERLOAD_2): Likewise.
(BU_P9V_OVERLOAD_3): Likewise.
(VCTZB): Add vector count trailing zeros support.
(VCTZH): Likewise.
(VCTZW): Likewise.
(VCTZD): Likewise.
(VPRTYBD): Add vector parity support.
(VPRTYBQ): Likewise.
(VPRTYBW): Likewise.
(VCTZ): Add overloaded vector count trailing zeros support.
(VPRTYB): Add overloaded vector parity support.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
overloaded vector count trailing zeros and parity instructions.
* config/rs6000/rs6000.md (wd mode attribute): Add V1TI and TI for
vector parity support.
* config/rs6000/altivec.h (vec_vctz): Add ISA 3.0 vector count
trailing zeros support.
(vec_cntlz): Likewise.
(vec_vctzb): Likewise.
(vec_vctzd): Likewise.
(vec_vctzh): Likewise.
(vec_vctzw): Likewise.
(vec_vprtyb): Add ISA 3.0 vector parity support.
(vec_vprtybd): Likewise.
(vec_vprtybw): Likewise.
(vec_vprtybq): Likewise.
* doc/extend.texi (PowerPC AltiVec Built-in Functions): Document
the ISA 3.0 vector count trailing zeros and vector parity built-in
functions.

[gcc/testsuite]
2016-06-01  Michael Meissner  

Back port from trunk
2016-05-24  Michael Meissner  

* gcc.target/powerpc/p9-vparity.c: New file to check ISA 3.0
vector parity built-in functions.
* gcc.target/powerpc/ctz-3.c: New file to check ISA 3.0 vector
count trailing zeros automatic vectorization.
* gcc.target/powerpc/ctz-4.c: New file to check ISA 3.0 vector
count trailing zeros built-in functions.

[gcc]
2016-06-01  Michael Meissner  

Back port from trunk
2016-05-24  Michael Meissner  

* config/rs6000/altivec.md (VNEG iterator): New iterator for
VNEGW/VNEGD instructions.
(p9_neg2): New insns for ISA 3.0 VNEGW/VNEGD.
(neg2): Add expander for V2DImode added in ISA 2.07, and
support for ISA 3.0 VNEGW/VNEGD instructions.

[gcc/testsuite]
2016-06-01  Michael Meissner  

Back port from trunk
2016-05-24  Michael Meissner  

* gcc.target/powerpc/p9-vneg.c: New test for ISA 3.0 VNEGW/VNEGD
instructions.



Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/ctz-3.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/ctz-4.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/p9-vneg.c
branches/gcc-6-branch/g

[Bug tree-optimization/71328] [7 Regression] ice in verify_jump_thread

[chengniansun at gmail dot com]

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

Chengnian Sun  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #2 from Chengnian Sun  ---
A much smaller test case.


int a, b, c;
void fn1() {
  unsigned char d = 3;
  if (d > 11)
  lbl_596:
  c = 0;
  while (!d)
b = b;
  unsigned char e = e || d;
  d = e;
  if (a)
d = d || a;
  goto lbl_596;
}

[Bug c++/71378] New: A compilable file fails to compile when ASAN options are specified

[asankau at millenniumit dot com]

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

Bug ID: 71378
   Summary: A compilable file fails to compile when ASAN options
are specified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asankau at millenniumit dot com
  Target Milestone: ---

Created attachment 38622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38622&action=edit
compressed "FGConfig.ii" file. Had to compress since file is 5 MB which is
larger than File size limit: 1000 KB

Mentioned file is compiled when ASAN options are NOT specified.
But gives below internal compiler error when ASAN options (fsanitize=address
-static-libasan) are specified.


/home/asankau/exch_7/app_ATS_MarketDataGateway/git_src/core/FGConfig.cpp:2284:1:
internal compiler error: in tree_to_uhwi, at tree.h:3668
 }
 ^
0x9a4012 tree_to_uhwi
../.././gcc/tree.h:3668
0x9a4012 asan_add_global
../.././gcc/asan.c:2202
0x9a44bc add_string_csts
../.././gcc/asan.c:2359
0xe64487 htab_traverse_noresize
../.././libiberty/hashtab.c:776
0x9a433b asan_finish_file()
../.././gcc/asan.c:2420
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Command : 
/usr/local/gcc-4.9.3/bin/g++ -std=c++11 -ggdb -m64 -D BIG_ENDIAN=1  -Wall
-Wshadow -Wpointer-arith -Wcast-qual -D _LARGEFILE_SOURCE -D LITTLE_ENDIAN=0
-fno-strict-aliasing -D RM3_ORA_VERSION=12 -D _REENTRANT -include relman.h
-fPIC -fsanitize=address -stati
c-libasan  [Set of base libraries]  -c -o FGConfig.o
/home/asankau/exch_7/app_ATS_MarketDataGateway/git_src/core/FGConfig.cpp

Version : 
/usr/local/gcc-4.9.3/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.9.3/bin/g++
COLLECT_LTO_WRAPPER=/x02/usr/local/gcc-4.9.3/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc-4.9.3
--with-gmp=/usr/local/gcc-4.9.3/gmp-5.1.2/
--with-mpfr=/usr/local/gcc-4.9.3/mpfr-3.1.2/
--with-mpc=/usr/local/gcc-4.9.3/mpc-1.0.1/
Thread model: posix
gcc version 4.9.3 (GCC)

[Bug fortran/71156] PURE interface/definition inconsistency: accepts invalid, rejects valid

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  ---
Fixed on trunk and 6-branch.

Thanks for the report

Paul