[Bug tree-optimization/71077] [7 Regression] gcc -lto raises ICE

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/69675] [6/7 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Can someone confirm this still fails on 6.1 and trunk w/ newer isl? I cannot
reproduce it any more w/ isl 0.17.1.

[Bug target/54882] build fails for rl78-elf building libstdc++

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #3 from Oleg Endo  ---
GCC 5 branch can be built out of the box for RL78.  GCC 6 branch has the
problem of PR 71135, but otherwise is also fine.  Can we close this?

[Bug libstdc++/71337] New: temp_directory_path(error_code&) shouldn't throw from !exists(p) || !is_directory(p)

[eric at efcs dot ca]

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

Bug ID: 71337
   Summary: temp_directory_path(error_code&) shouldn't throw from
!exists(p) || !is_directory(p)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Most of the time these two function will not throw. However if 'p' points to a
directory that the user doesn't have permission to read then they will.

For example:

create_directories("/tmp/foo/bar");
permissions("/tmp/foo", perms::none);
setenv("TMPDIR", "/tmp/foo/bar", 1);
std::error_code ec;
temp_directory_path(ec); // THROWS!

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

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
I suppose the test is sensitive to branching cost like ssa-thread-11.c is so it
should probably inherit the target selector of ssa-thread-11.c, namely

/* { dg-do compile { target { ! { logical_op_short_circuit || { m68k*-*-*
mep*-*-* bfin*-*-* v850*-*-* moxie*-*-* m32c*-*-* fr30*-*-* mcore*-*-* frv-*-*
h8300-*-* m32r-*-* mn10300-*-* msp430-*-* pdp11-*-* rl78-*-* rx-*-* vax-*-*} }
} } } */

[Bug target/71336] New: Suboptimal x86 code generated for "(a & 1) ? (CST1 + CST2) : CST1"

[ppalka at gcc dot gnu.org]

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

Bug ID: 71336
   Summary: Suboptimal x86 code generated for "(a & 1) ? (CST1 +
CST2) : CST1"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat test.c
int test(int a) {
return a & 1 ? 7 : 3;
}
$ gcc -O2 -o- -S test.c
test:
.LFB0:
.cfi_startproc
andl$1, %edi
cmpl$1, %edi
sbbl%eax, %eax
andl$-4, %eax
addl$7, %eax
ret
.cfi_endproc

The optimal code would look like

andl$1, %edi
leal3(,%rdi,4), %eax
ret

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

[chengniansun at gmail dot com]

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

Bug ID: 71335
   Summary: wrong code at -O2 and -O3 in 32-bit and 64-bit modes
on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$: 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 20160529 (experimental) [trunk revision 236861] (GCC)
$: gcc-trunk small.c -O3 -m64 ; timeout -s 9 2 ./a.out
Killed
$: gcc-trunk small.c -O2 -m64 ; timeout -s 9 2 ./a.out
Killed
$: gcc-trunk small.c -Os -m64 ; timeout -s 9 2 ./a.out
$: cat small.c
int a;
int main() {
  int b = 0;
  while (a < 0 || b) {
b = 0;
for (; b < 9; b++)
  ;
  }
  return 0;
}
$:

[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 #7 from jol_indien at yahoo dot fr ---
Created attachment 38595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38595&action=edit
patch to properly detect VIA nano CPU against gcc git repository as for Sun May
29 17:29:42 2016 +

Patch update after submission to gcc-patches mailing list.

[Bug c++/71099] Misleading diagnostic message with 'virtual' used in out-of-line definitions of class template member functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||paolo.carlini at oracle dot com
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |7.0

--- Comment #1 from Paolo Carlini  ---
Mine.

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

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu  ---
As of r236857, on x86-64, I still got

Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/416.gamess/build/build_base_lnx32e-gcc./make.err'
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/454.calculix/build/build_base_lnx32e-gcc./make.err'
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/481.wrf/build/build_base_lnx32e-gcc./make.err'
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/416.gamess/build/build_peak_lnx32e-gcc./make.err'
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/454.calculix/build/build_peak_lnx32e-gcc./make.err'
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/git/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/481.wrf/build/build_peak_lnx32e-gcc./make.err'

They all have

internal compiler error: Segmentation fault
0xbdd7df crash_signal
../../src-trunk/gcc/toplev.c:333
0x955a29 bb_seq_addr
../../src-trunk/gcc/gimple.h:1655
0x955a29 gsi_start_bb
../../src-trunk/gcc/gimple-iterator.h:129
0x955a29 gsi_for_stmt(gimple*)
../../src-trunk/gcc/gimple-iterator.c:617
0xd7834a insert_stmt_after
../../src-trunk/gcc/tree-ssa-reassoc.c:1323
0xd79573 build_and_add_sum
../../src-trunk/gcc/tree-ssa-reassoc.c:1392
0xd7b87e rewrite_expr_tree_parallel
../../src-trunk/gcc/tree-ssa-reassoc.c:4128
0xd83719 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5339
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
0xd833c7 reassociate_bb
../../src-trunk/gcc/tree-ssa-reassoc.c:5391
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake[3]: *** [umat_single_crystal.o] Error 1

[Bug jit/71334] gccjit's sized integers have different underlying types than stdint.h

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't see why this is an issue.  for LP64 targets, long unsigned int and long
long unsigned int are the same size.  For gccjit, just uses the GCC internal
definition of compatible.  That is long unsigned int and long long unsigned int
are compatible types.

Internally GCC there is a size_t type which is distant from the underlying type
but is compatible with that type.



Why do you think they should be the same?  Remember GCCJIT is not about C
language specifications but rather a GCC internal representation.

[Bug jit/71334] New: gccjit's sized integers have different underlying types than stdint.h

[b.r.longbons at gmail dot com]

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

Bug ID: 71334
   Summary: gccjit's sized integers have different underlying
types than stdint.h
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

Created attachment 38594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38594&action=edit
Utility to print underlying types of GCC vs GCCJIT

When constructed from size + signedness, gccjit should return the same
underlying types as  uses, but doesn't.

Additionally, it appears to return some completely distinct type for size_t,
rather than following the typedef.

Actual output of the attached tool:

underlying size_t: gcc long unsigned int, gccjit unknown
underlying uint32_t: gcc unsigned int, gccjit unsigned int
underlying uint64_t: gcc long unsigned int, gccjit long long unsigned int

[Bug inline-asm/71086] miscompiled inline-asm + alternative constraints + __builtin_expect + always_inline

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
This was fixed by r218623.

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

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun May 29 20:50:32 2016
New Revision: 236863

URL: https://gcc.gnu.org/viewcvs?rev=236863&root=gcc&view=rev
Log:
PR target/71245
* config/i386/sync.md (define_peephole2 atomic_storedi_fpu):
New peepholes to remove unneeded fild/fistp pairs.
(define_peephole2 atomic_loaddi_fpu): Ditto.

testsuite/ChangeLog:

PR target/71245
* gcc.target/i386/pr71245-1.c: New test.
* gcc.target/i386/pr71245-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr71245-1.c
trunk/gcc/testsuite/gcc.target/i386/pr71245-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sync.md
trunk/gcc/testsuite/ChangeLog

[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 #8 from Georg Koppen  ---
Looking at the stack trace again. It says "Memory access at offset 112
underflows this variable" yet ASan reports stack-buffer-overflow. I am
confused. Shouldn't it report a stack-buffer-underflow then?

[Bug c++/71215] Compile error when using in-class initialization of template class attributes (c++11)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0
   Severity|blocker |normal

--- Comment #1 from Paolo Carlini  ---
Then, since this isn't a regression, we should simply resolve the bug as fixed.
By the way, the issue is (was) well known, but at the moment I can't remember
the bug #, sorry.

[Bug c++/71333] Broken Python extension produced

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That typically happens if the code invokes undefined behavior in the loop.
Try e.g. to compile it with -fsanitize=undefined and/or -fsanitize=address or
-fno-aggressive-loop-optimizations.

[Bug c++/70824] [6/7 Regression] cc1plus consumes all available memory on specific template code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Paolo Carlini  ---
In the constant_value_1 loop, instantiate_non_dependent_or_null turns the
DECL_INITIAL of the decl which is a CONSTRUCTOR:

 

[Bug c++/70824] [6/7 Regression] cc1plus consumes all available memory on specific template code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
At some point cxx_eval_constant_expression under case VAR_DECL calls
decl_constant_value with a t like:

 

[Bug c++/71332] Passing non-copyable type by reference to variadic generic lambda after a copyable type by value results in a compile-time error

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095.

The ... is (incorrectly) being parsed as C-style varargs, which then triggers
the error.

[Bug inline-asm/71086] miscompiled inline-asm + alternative constraints + __builtin_expect + always_inline

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Created attachment 38593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38593&action=edit
standalone test case

Standalone test case in C.  Compile with -O1 on x86_64.  Wrong-code reproduces
with gcc-4.9.3 and 4.8.5, but not with 4.7.4, 5.3, 6.1, or trunk.

I'm assuming the inline asm (from the original report) is correct...

[Bug tree-optimization/69067] [6/7 Regression] ICE in get_def_bb_for_const, at graphite-isl-ast-to-gimple.c:1995

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02273.html

[Bug c++/71333] New: Broken Python extension produced

[yesint4 at yahoo dot com]

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

Bug ID: 71333
   Summary: Broken Python extension produced
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yesint4 at yahoo dot com
  Target Milestone: ---

When compiling Pteros library (https://sourceforge.net/projects/pteros/) g++
5.3.1 produces broken Python extension module, which causes segfaults when
used. The same code works fine with g++ 4.8 and with clang (any version).

Compiler makes something completely wrong when compiling call to Python API
function PyArray_FROM_OT at line 115 of this file:
https://sourceforge.net/p/pteros/code/ci/experimental/tree/include/pteros/python/bindings_util.h

The whole "if" block enclosing this line is executed infinitely like if it is
an infinite "while" loop, not "if".

[Bug target/71331] target-tilegx: nested-function-4.c: r10 is conflict which is both in function frame and in parameter.

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

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

--- Comment #1 from Chen Gang  ---

Oh, lucky enough! The diff below should be OK for this issue.

diff --git a/gcc/config/tilegx/tilegx.c b/gcc/config/tilegx/tilegx.c
index 06c832c..bc41105 100644
--- a/gcc/config/tilegx/tilegx.c
+++ b/gcc/config/tilegx/tilegx.c
@@ -5510,18 +5510,28 @@ tilegx_function_profiler (FILE *file, int labelno
ATTRIBUTE_UNUSED)
   if (flag_pic)
 {
   fprintf (file,
+  "\tst\tsp, r10\n"
+  "\taddi\tsp, sp, -8\n"
   "\t{\n"
   "\tmove\tr10, lr\n"
   "\tjal\tplt(%s)\n"
-  "\t}\n", MCOUNT_NAME);
+  "\t}\n"
+  "\taddi\tsp, sp, 8\n"
+  "\tld\tr10, sp\n",
+  MCOUNT_NAME);
 }
   else
 {
   fprintf (file,
+  "\tst\tsp, r10\n"
+  "\taddi\tsp, sp, -8\n"
   "\t{\n"
   "\tmove\tr10, lr\n"
   "\tjal\t%s\n"
-  "\t}\n", MCOUNT_NAME);
+  "\t}\n"
+  "\taddi\tsp, sp, 8\n"
+  "\tld\tr10, sp\n",
+  MCOUNT_NAME);
 }

   tilegx_in_bundle = false;

[Bug c++/71332] New: Passing non-copyable type by reference to variadic generic lambda after a copyable type by value results in a compile-time error

[vittorio.romeo at outlook dot com]

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

Bug ID: 71332
   Summary: Passing non-copyable type by reference to variadic
generic lambda after a copyable type by value results
in a compile-time error
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

Created attachment 38592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38592&action=edit
Minimal code example

* Example on gcc.godbolt.org:
https://godbolt.org/g/HxMq0K

* Related StackOverflow question:
http://stackoverflow.com/questions/37508217

---

I've encountered a situation where passing a non-copyable type (by reference)
to a variadic generic lambda after a copyable type (by copy) causes a
compilation error on `g++` (both on `5.3` and `6.1`) but not on `clang++`.

int main()
{
auto f = [](auto&&...)
{
};

non_copyable nc;

f(nc); // ok on both compilers
f(nc, int{}); // ok on both compilers
f(int{}, nc); // error only on gcc 
} 

`g++` gives the following error for the `f(int{}, nc)` call: 

x.cpp: In function ‘void test()’:
x.cpp:19:19: error: use of deleted function
‘non_copyable::non_copyable(const non_copyable&)’
 f(int{}, nc);
^
x.cpp:8:5: note: declared here
 non_copyable(const non_copyable&) = delete;
 ^~~~

It seems that if the first argument is passed by copy, all the other arguments
are passed by copy as well. This looks like a bug, because using an
hand-written callable object that should be equivalent to the lambda works on
both compilers:

// should be equivalent to `[](auto&&...){ }`
struct do_nothing
{
template 
constexpr auto operator()(Ts&&...) const noexcept
{
}
};

// ...

do_nothing{}(nc); // ok on both compilers
do_nothing{}(nc, int{}); // ok on both compilers
do_nothing{}(int{}, nc); // ok on both compilers

There seems to be an inconsistency between callable objects and generic
variadic lambdas on `g++`.

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 71105 Summary: [6/7 regression] lambdas with default captures improperly 
have function pointer conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71105

   What|Removed |Added

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

[Bug c++/71105] [6/7 regression] lambdas with default captures improperly have function pointer conversions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #5 from Paolo Carlini  ---
Fixed trunk and 6.2.

[Bug c++/71105] [6/7 regression] lambdas with default captures improperly have function pointer conversions

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun May 29 08:29:46 2016
New Revision: 236861

URL: https://gcc.gnu.org/viewcvs?rev=236861&root=gcc&view=rev
Log:
/cp
2016-05-29  Paolo Carlini  

PR c++/71105
* lambda.c (maybe_add_lambda_conv_op): Early return also when
LAMBDA_EXPR_DEFAULT_CAPTURE_MODE != CPLD_NONE.

/testsuite
2016-05-29  Paolo Carlini  

PR c++/71105
* g++.dg/cpp0x/lambda/lambda-conv11.C: New.
* g++.dg/cpp1y/lambda-conv1.C: Likewise.
* g++.dg/cpp1y/lambda-conv2.C: Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c

[Bug c++/71105] [6/7 regression] lambdas with default captures improperly have function pointer conversions

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun May 29 08:27:07 2016
New Revision: 236860

URL: https://gcc.gnu.org/viewcvs?rev=236860&root=gcc&view=rev
Log:
/cp
2016-05-29  Paolo Carlini  

PR c++/71105
* lambda.c (maybe_add_lambda_conv_op): Early return also when
LAMBDA_EXPR_DEFAULT_CAPTURE_MODE != CPLD_NONE.

/testsuite
2016-05-29  Paolo Carlini  

PR c++/71105
* g++.dg/cpp0x/lambda/lambda-conv11.C: New.
* g++.dg/cpp1y/lambda-conv1.C: Likewise.
* g++.dg/cpp1y/lambda-conv2.C: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv11.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/lambda-conv1.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/lambda-conv2.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/lambda.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71105] [6/7 regression] lambdas with default captures improperly have function pointer conversions

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun May 29 08:05:30 2016
New Revision: 236859

URL: https://gcc.gnu.org/viewcvs?rev=236859&root=gcc&view=rev
Log:
/cp
2016-05-29  Paolo Carlini  

PR c++/71105
* lambda.c (maybe_add_lambda_conv_op): Early return also when
LAMBDA_EXPR_DEFAULT_CAPTURE_MODE != CPLD_NONE.

/testsuite
2016-05-29  Paolo Carlini  

PR c++/71105
* g++.dg/cpp0x/lambda/lambda-conv11.C: New.
* g++.dg/cpp1y/lambda-conv1.C: Likewise.
* g++.dg/cpp1y/lambda-conv2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv11.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-conv1.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-conv2.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/71331] New: target-tilegx: nested-function-4.c: r10 is conflict which is both in function frame and in parameter.

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

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

Bug ID: 71331
   Summary: target-tilegx: nested-function-4.c: r10 is conflict
which is both in function frame and in parameter.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gang.chen.5i5j at gmail dot com
  Target Milestone: ---

Created attachment 38591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38591&action=edit
The related insns for nested-function-4.c

The nest function:

extern void abort(void);

void foo(int i)
{
  void bar(void)
  {
if (i != 2)
  abort ();
  }

  bar();
}

int main(void)
{
  foo (2);
  return 0;
}


The command:

/upstream/build-gcc-tile/gcc/xgcc -B/upstream/build-gcc-tile/gcc/
./nested-func-4.c -fno-diagnostics-show-caret -fdiagnostics-color=never -pg
-I/upstream/release-tile/usr/include -fno-asynchronous-unwind-tables -m64
-mcpu=tilegx -mcmodel=large -mlittle-endian -L /upstream/release-tile/lib -lm
-o ./nested-func-4.exe -save-temps -fdump-final-insns=./insns.s


The asm output:

  1 .file   "nested-func-4.c"
  2 .text
  3 .align 8
  4 .type   bar.1690, @function
  5 bar.1690:
  6 {
  7 mover10, lr
  8 jal __mcount
  9 }
 10 st  sp, lr
 11 mover29, r52
 12 mover52, sp
 13 addir28, sp, -40
 14 addisp, sp, -48
 15 st  r28, r52
 16 addir27, r52, -8
 17 st  r27, r29
 18 
 19 mover12, r10
 20 addir11, r52, -24
 21 st  r11, r10
 22 ld4sr10, r12
 23 xorir10, r10, 2; bfextu r10, r10, 0, 31; cmpeqi r10, r10, 0
 24 bnezr10, .L3
 25 moveli  r10, hw2_last(abort)
 26 shl16insli  r10, r10, hw1(abort)
 27 shl16insli  r10, r10, hw0(abort)
 28 jalrr10
 29 .L3:
 30 nop
 31 ld  lr, r52
 32 addir28, r52, -8
 33 ld  r29, r28
 34 
 35 movesp, r52
 36 mover52, r29
 37 jrp lr
 38 .size   bar.1690, .-bar.1690
 39 .align 8
 40 .global foo
 41 .type   foo, @function
 42 foo:
 43 {
 44 mover10, lr
 45 jal __mcount
 46 }
 47 st  sp, lr
 48 mover29, r52
 49 mover52, sp
 50 addir28, sp, -56
 51 addisp, sp, -64
 52 st  r28, r52
 53 addir27, r52, -8
 54 st  r27, r29
 55 
 56 mover10, r0
 57 addxi   r11, r10, 0
 58 addir10, r52, -36
 59 st4 r10, r11
 60 mover11, r52
 61 addir10, r52, -32
 62 addir10, r10, 8
 63 st  r10, r11
 64 addir10, r52, -32
 65 addir11, r52, -36
 66 ld4sr11, r11
 67 st4 r10, r11
 68 addir10, r52, -32
 69 moveli  r11, hw2_last(bar.1690)
 70 shl16insli  r11, r11, hw1(bar.1690)
 71 shl16insli  r11, r11, hw0(bar.1690)
 72 jalrr11
 73 nop
 74 ld  lr, r52
 75 addir28, r52, -8
 76 ld  r29, r28
 77 
 78 movesp, r52
 79 mover52, r29
 80 jrp lr
 81 .size   foo, .-foo
 82 .align 8
 83 .global main
 84 .type   main, @function
 85 main:
 86 {
 87 mover10, lr
 88 jal __mcount
 89 }
 90 st  sp, lr
 91 mover29, r52
 92 mover52, sp
 93 addir28, sp, -24
 94 addisp, sp, -32
 95 st  r28, r52
 96 addir27, r52, -8
 97 st  r27, r29
 98 
 99 movei   r0, 2
100 moveli  r10, hw2_last(foo)
101 shl16insli  r10, r10, hw1(foo)
102 shl16insli  r10, r10, hw0(foo)
103 jalrr10
104 movei   r10, 0
105 mover0, r10
106 ld  lr, r52
107 addir28, r52, -8
108 ld  r29, r28
109 
110 movesp, r52
111 mover52, r29
112 jrp lr
113 .size   main, .-main
114 .ident  "GCC: (GNU) 7.0.0 20160529 (experimental)"
115 .section.note.GNU-stack,"",@progbits