[Bug target/71112] [6 Regression] ICE with -fpie on aarch64 ILP32 big-endian

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.2
Summary|ICE with -fpie on aarch64   |[6 Regression] ICE with
   |ILP32 big-endian|-fpie on aarch64 ILP32
   ||big-endian

[Bug target/71112] New: ICE with -fpie on aarch64 ILP32 big-endian

[pinskia at gcc dot gnu.org]

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

Bug ID: 71112
   Summary: ICE with -fpie on aarch64 ILP32 big-endian
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Take:
extern int dbs[100] ;
void f(int *);
int nscd_init (void)
{
  f (dbs);
  return 0;
}

--- CUT 
This ICEs with -mabi=ilp32 -mbig-endian -fpie .
Here is the backtrace that is outputted:
0xae9515 crash_signal
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/toplev.c:333
0x945968 mark_jump_label_1
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:1095
0x945cf9 mark_jump_label_1
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:1219
0x945cf9 mark_jump_label_1
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:1219
0x945cc0 mark_jump_label_1
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:1226
0x945cf9 mark_jump_label_1
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:1219
0x9461d3 mark_all_labels
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:340
0x9461d3 rebuild_jump_labels_1
/data1/src/gcc-cavium/toolchain-6/scripts/../src/gcc/jump.c:75
Please submit a full bug report,

[Bug c++/71111] gcc5 (v5.3.1) - _moddi3: .... error adding symbols: Bad value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Again this is not related to GCC, try the binutils list.

[Bug c++/71111] gcc5 (v5.3.1) - _moddi3: .... error adding symbols: Bad value

[matthew at giassa dot net]

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

--- Comment #3 from Matthew Giassa  ---
(In reply to Andrew Pinski from comment #1)
> GCC does not provide the linker or load.
> 
> You should report this to Ubuntu.

Will do. Thanks!

Is there a trivial way to drop-in a different `ld' tool temporarily, for
before-and-after testing on the same system?

[Bug rtl-optimization/67483] combine.c sanitizer detects undefined negative left shift

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Fri May 13 23:01:40 2016
New Revision: 236232

URL: https://gcc.gnu.org/viewcvs?rev=236232=gcc=rev
Log:
combine: Don't call extract_left_shift with count < 0 (PR67483)

If the compiled program does a shift by a negative amount, combine will
happily work with that, but it shouldn't then do an undefined operation
in GCC itself.  This patch fixes the first case mentioned in the bug
report (I haven't been able to reproduce the second case, on trunk at
least).


PR rtl-optimization/67483
* combine.c (make_compound_operation): Don't call extract_left_shift
with negative shift amounts.

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

[Bug c++/71111] gcc5 (v5.3.1) - _moddi3: .... error adding symbols: Bad value

[matthew at giassa dot net]

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

Matthew Giassa  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||hjl.tools at gmail dot com
 Resolution|MOVED   |---

--- Comment #2 from Matthew Giassa  ---
Updating CC (hopefully not erroneously) with a dev who was involved in
resolving a remotely similar bug (63784). Need to get some people on the CC
list.

[Bug c++/71111] gcc5 (v5.3.1) - _moddi3: .... error adding symbols: Bad value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
GCC does not provide the linker or load.

You should report this to Ubuntu.

[Bug c++/71111] New: gcc5 (v5.3.1) - _moddi3: .... error adding symbols: Bad value

[matthew at giassa dot net]

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

Bug ID: 7
   Summary: gcc5 (v5.3.1) - _moddi3:  error adding symbols:
Bad value
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew at giassa dot net
CC: matthew at giassa dot net
  Target Milestone: ---
  Host: 4.4.0-21-generic Ubuntu SMP i686 GNU/Linux
Target: (Same as host, x86)

I have a simple project that does some number crunching in C++. The project is
built as a simple standalone shared library, libmx2.so.

There is a second library, libmx2gui.so, which is a Gtk "wrapper" for the
libmx2.so library, providing a means for Gtk apps to have dialogs which act as
the equivalent of the command-line functionality provided by the libmx2.so
library. The GUI library links dynamically against the other library at build
time.

Building on Ubuntu 14.04 LTS with GCCv4.8 worked fine, but after upgrading to
Ubuntu 16.04 LTS and GCCv5 (5.3.1), I get a bizarre error when linking the GUI
library:

__moddi3: invalid version 26897 (max 0)
./lib/libmx2.so: error adding symbols: Bad value

This issue only occurs on 32-bit machines, not on 64-bit machines. Enabling
verbose output via gcc -v provides no additional information. The linker flags
used by both libraries is:

# libmx
LDFLAGS = -Wl,--version-script=exports.map -fvisibility=hidden 
  -fvisibility-inlines-hidden -Wl,-z,defs,-soname,${LIB_OUT_NAME}

# libmx2gui
LDFLAGS = -Wl,-z,defs,-soname,${LIB_OUT_NAME}

Both libraries are linked against their object files via:

@${CXX} ${LDFLAGS} -shared -o ${OUTPUT_LIBRARY_NAME} ${OBJ} ${LIBS}

Where OBJ is a list of the object files, and LIBS is a list of libraries to
link against.

Is there any reason to suspect this is a bug in GCCv5, or is it a poor choice
of link/compiler settings for my libraries?

I've created some additional bare-bones libraries that simply use the API from
libmx2.so, and they too have the same error. My initial guess (an obvious one)
is there's either something wrong with how I'm building libmx2.so, or there's
something wrong with my linking options when having other shared objects link
against it. Still baffled why this only occurs on 32-bit GCC5.

[Bug c++/66093] g++ produces incorrect output on code with constexpr function initializing class with private fields

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
 CC||msebor at gcc dot gnu.org
  Known to work||6.1.0
 Ever confirmed|0   |1
  Known to fail||5.3.0

--- Comment #1 from Martin Sebor  ---
Confirmed with 5.3.0.  GCC 6.1.0 and current trunk produce the expected output.

[Bug c++/63728] Memory exhaustion using constexpr constructors for classes with large array members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
 CC||msebor at gcc dot gnu.org
 Blocks||55004
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Unbounded constexpr can eat up a lot of memory.  Here's a smaller
test case:

$ (cat xx.cpp && ulimit -v $(expr 4096 \* 16) && /build/gcc-trunk-svn/gcc/xg++
-B /build/gcc-trunk-svn/gcc -DNBITS=1 -S -Wall -Wextra  xx.cpp); echo $?
template 
struct S
{
int a [N / (8 * sizeof (int))];
constexpr S (): a () { }
};

S s;
0

$ (ulimit -v $(expr 4096 \* 16) && /build/gcc-trunk-svn/gcc/xg++ -B
/build/gcc-trunk-svn/gcc -DNBITS=1000 -S -Wall -Wextra  xx.cpp); echo
$?virtual memory exhausted: Cannot allocate memory
1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/61039] Using a constexpr's address as a template variable produces an unnecessary warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I believe the warning is intended here (child1 and child2 have external linkage
but their base classes are specializations of templates that depend on (the
address of) objects with internal linkage (constexpr).  That could cause
problems as described in the GCC manual under the -Wsubobject-linkage option.

[Bug c/71110] label "caseN" should be warned about

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
Summary|Failure to detect syntax|label "caseN" should be
   |error with Switch Case  |warned about
   |statement.  |
 Ever confirmed|0   |1
   Severity|minor   |enhancement

--- Comment #1 from Andrew Pinski  ---
case2: is a label.  There is no syntax error here because this is very valid C.
 We should most likely warn about it though or at least have an option to warn
about it.  Confirmed for the warning.

[Bug c/71110] New: Failure to detect syntax error with Switch Case statement.

[iamropo at gmail dot com]

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

Bug ID: 71110
   Summary: Failure to detect syntax error with Switch Case
statement.
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamropo at gmail dot com
  Target Milestone: ---

The Bug is Regarding `case value`. I have commented the bug in the program
below.

#include 

int main()
{

 int n = 0;

 switch(n)
 {

  case 1:
printf("Foo.\n");
break;


  /* The following Syntax Error is not being detected, i.e no space between
  'case' & 2 */

  case2:  
printf("Bar.\n");
break;

  default:
printf("Bruhh.\n");
   }

  return 0;

 }


Thanks, 
Hage Ropo

[Bug c++/60049] Right and left shift undefined behavior not an error in a constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||5.3.0, 6.1.0
 Blocks||55004
 Resolution|--- |FIXED
  Known to fail||4.9.3

--- Comment #1 from Martin Sebor  ---
GCC 4.9.3 still accepts the code, but GCC 5 and 6 reject it (see below).  Test
added in r236225.  Resolving as Fixed.

$ gcc -S -std=c++11 -w xx.cpp
xx.cpp: In function ‘int main()’:
xx.cpp:3:27: error: right operand of shift expression ‘(1 << 33)’ is >= than
the precision of the left operand [-fpermissive]
 constexpr int x1 =  1 << 33 ;
 ~~^
xx.cpp:4:27: error: right operand of shift expression ‘(1 << -1)’ is negative
[-fpermissive]
 constexpr int x2 =  1 << -1 ;
 ~~^
xx.cpp:5:28: error: left operand of shift expression ‘(-1 << 1)’ is negative
[-fpermissive]
 constexpr int x3 =  -1 << 1 ;
 ~~~^~~~
xx.cpp:6:27: error: right operand of shift expression ‘(1 >> 33)’ is >= than
the precision of the left operand [-fpermissive]
 constexpr int x4 =  1 >> 33 ;
 ~~^
xx.cpp:7:27: error: right operand of shift expression ‘(1 >> -1)’ is negative
[-fpermissive]
 constexpr int x5 =  1 >> -1 ;
 ~~^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

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

Bug 60049 Summary: Right and left shift undefined behavior not an error in a 
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60049

   What|Removed |Added

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

[Bug c++/71095] Problem with captureless generic lambda and calling function object with arguments passed by reference

[karol.wozniak at email dot com]

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

Karol Wozniak  changed:

   What|Removed |Added

  Known to work||5.3.1

--- Comment #1 from Karol Wozniak  ---
minimal reproducible example

void foo(int &) {}

int main() {
  int a;
  [](auto &) { foo(static_cast(x)); }(a);
  return 0;
}

$ g++-6 -std=c++14 prog.cc 
prog.cc: In instantiation of ‘main():: [with auto:1 = int]’:
prog.cc:5:14:   required by substitution of ‘template
main()::::operator decltype
(((main()::)0u).operator()(static_cast()))
(*)(auto:1&&)() const [with auto:1 = int]’
prog.cc:5:58:   required from here
prog.cc:5:21: error: invalid initialization of non-const reference of type
‘int&’ from an rvalue of type ‘int’
   [](auto &) { foo(static_cast(x)); }(a);
  ~~~^~~~
prog.cc:1:6: note:   initializing argument 1 of ‘void foo(int&)’
 void foo(int &) {}
  ^~~

[Bug tree-optimization/71109] New: gcc ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[helloqirun at gmail dot com]

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

Bug ID: 71109
   Summary: gcc ICE at -O3 on valid code on x86_64-linux-gnu in
"maybe_record_trace_start"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu in 64-bit mode. 32-bit mode works fine.

It appears to be a 7 regression.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160513 (experimental) [trunk revision 236209] (GCC)


$ gcc-trunk -O3 abc.c -c
abc.c: In function ‘fn2’:
abc.c:26:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2284
 }
 ^
0x827738 maybe_record_trace_start
../../gcc/gcc/dwarf2cfi.c:2284
0x829e30 scan_trace
../../gcc/gcc/dwarf2cfi.c:2462
0x82a66a create_cfi_notes
../../gcc/gcc/dwarf2cfi.c:2616
0x82a66a execute_dwarf2_frame
../../gcc/gcc/dwarf2cfi.c:2974
0x82a66a execute
../../gcc/gcc/dwarf2cfi.c:3454
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.



$ cat abc.c
struct S0 {
  int f0;
  int f1;
  char f2;
  int f3;
  char f4;
  int f5;
  int f6;
  int f7;
  char f8;
} a, c;
struct S1 {
  char f0;
} e;
int *b;
int d;
void fn1();
void fn2() {
  for (; d;) {
fn1(fn2, a);
struct S1 f[3];
int k;
for (;; k++)
  f[k] = e;
  }
}
void fn1(int p1, struct S0 p2, struct S1 p3) {
  p3.f0 = 2;
  for (; p3.f0; p3.f0--) {
struct S0 *g = , *h = 
*h = *g = p2;
*b |= 6;
if (p2.f0)
  break;
  }
}

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Should be fixed now.

[Bug libstdc++/71108] New: to_string is relatively slow

[adrian.wielgosik at gmail dot com]

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

Bug ID: 71108
   Summary: to_string is relatively slow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrian.wielgosik at gmail dot com
  Target Milestone: ---

Currently to_string is implemented in terms of vsnprintf, which makes it close
in performance to the sprintf family. Meanwhile hand-written implementations of
to_string can be up to an order of magnitude faster.

For example, this function is 3-7x faster than 6.1 std::to_string(unsigned int)
in a microbenchmark.

std::string to_string(unsigned int value)
{
char buffer[20];
char *end = std::end(buffer);
char *it = end;

do {
it--;
*it = '0' + value % 10;
value /= 10;
} while (value);

return std::string(it, end);
}

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 13 20:24:22 2016
New Revision: 236222

URL: https://gcc.gnu.org/viewcvs?rev=236222=gcc=rev
Log:
PR bootstrap/71071
* fold-const.c (fold_checksum_tree): Allow modification
of TYPE_ALIAS_SET during folding.

* gcc.dg/pr71071.c: New test.

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

[Bug bootstrap/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|preprocessor|bootstrap

--- Comment #6 from John David Anglin  ---
I think this issue can be resolved by including  instead of
 in system.h when compiling with g++.

However, we currently assume gnu++98 in stage1 and long long support
was not added until c++11.  r235550 introduced a long long variable
which isn't guarded by HAVE_LONG_LONG.  So the change needs fixing.

[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #5 from David Binderman  ---
Something similar at a slightly different line number:

/home/dcb/libreOffice/core/store/source/lockbyte.cxx:895:1: internal compiler
error: in inline_small_functions, at ipa-inline.c:1886
 } // namespace store
 ^
0x15c55e2 inline_small_functions
../../src/trunk/gcc/ipa-inline.c:1886
0x15c55e2 ipa_inline
../../src/trunk/gcc/ipa-inline.c:2441

[Bug c++/10200] [6 Regression] Weird clash with same names in different scopes

[jason at gcc dot gnu.org]

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

--- Comment #38 from Jason Merrill  ---
Author: jason
Date: Fri May 13 19:18:35 2016
New Revision: 236221

URL: https://gcc.gnu.org/viewcvs?rev=236221=gcc=rev
Log:
Fix type-dependence and the current instantiation.

PR c++/10200
PR c++/69753
* pt.c (tsubst_decl): Use uses_template_parms.
(instantiate_template_1): Handle non-dependent calls in templates.
(value_dependent_expression_p): Handle BASELINK, FUNCTION_DECL.
(type_dependent_expression_p): Only consider innermost template args.
(dependent_template_arg_p): Check enclosing class of a template here.
(dependent_template_p): Not here.
(type_dependent_object_expression_p): New.
* typeck.c (finish_class_member_access_expr): Use it.
* parser.c (cp_parser_postfix_expression): Use it.
(cp_parser_postfix_dot_deref_expression): Use it.  Use comptypes
to detect the current instantiation.
(cp_parser_lookup_name): Really implement DR 141.
* search.c (lookup_field_r): Prefer a dependent using-declaration.
(any_dependent_bases_p): Split out from...
* name-lookup.c (do_class_using_decl): ...here.
* call.c (build_new_method_call_1): Use it.
* semantics.c (finish_call_expr): 'this' doesn't make a call dependent.
* tree.c (non_static_member_function_p): Remove.
* typeck2.c (build_x_arrow): Use dependent_scope_p.

Added:
trunk/gcc/testsuite/g++.dg/lookup/member4.C
trunk/gcc/testsuite/g++.dg/lookup/member5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/search.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/template/using14.C

[Bug c++/69753] [6 Regression] bogus: expected primary-expression before ‘>’ token

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Fri May 13 19:18:35 2016
New Revision: 236221

URL: https://gcc.gnu.org/viewcvs?rev=236221=gcc=rev
Log:
Fix type-dependence and the current instantiation.

PR c++/10200
PR c++/69753
* pt.c (tsubst_decl): Use uses_template_parms.
(instantiate_template_1): Handle non-dependent calls in templates.
(value_dependent_expression_p): Handle BASELINK, FUNCTION_DECL.
(type_dependent_expression_p): Only consider innermost template args.
(dependent_template_arg_p): Check enclosing class of a template here.
(dependent_template_p): Not here.
(type_dependent_object_expression_p): New.
* typeck.c (finish_class_member_access_expr): Use it.
* parser.c (cp_parser_postfix_expression): Use it.
(cp_parser_postfix_dot_deref_expression): Use it.  Use comptypes
to detect the current instantiation.
(cp_parser_lookup_name): Really implement DR 141.
* search.c (lookup_field_r): Prefer a dependent using-declaration.
(any_dependent_bases_p): Split out from...
* name-lookup.c (do_class_using_decl): ...here.
* call.c (build_new_method_call_1): Use it.
* semantics.c (finish_call_expr): 'this' doesn't make a call dependent.
* tree.c (non_static_member_function_p): Remove.
* typeck2.c (build_x_arrow): Use dependent_scope_p.

Added:
trunk/gcc/testsuite/g++.dg/lookup/member4.C
trunk/gcc/testsuite/g++.dg/lookup/member5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/search.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/template/using14.C

[Bug c++/58848] constexpr function allows throw

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
The first test case can be reduced to the one below which GCC also accepts. 
But based on my reading of the standard, I think the test case is valid because
the definition (including the initialization) of A<0>::v is never instantiated.
 (See the quotes from the C++ standard below for reference.)

The second test case requires a diagnostic because the constexpr function
called in a constexpr context with an argument that would cause the throw
expression to be evaluated.

I'm resolving this as Invalid (see also bug 70820 for a similar example.)

Quoting from temp.inst:

-1- The implicit instantiation of a class template specialization causes the
implicit instantiation of the declarations, but not of the definitions, ... of
... static data members.

-11-  An implementation shall not implicitly instantiate ... a static data
member of a class template that does not require instantiation.

$ cat xx.cpp && gcc -S -Wall -Wextra -Wpedantic -std=c++11 xx.cpp 
template 
struct A
{
  static constexpr int
  f (int i)
  {
return i ? i : throw 0;
  }

  static const int v = f (0);
};

int i = A<0>::f (0);
$

[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881

[dilyan.palauzov at aegee dot org]

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

Дилян Палаузов  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

--- Comment #4 from Дилян Палаузов  ---
Probably the same problem in a different case:

gcc (GCC) 7.0.0 20160513 (experimental) Copyright (C) 2016 Free Software
Foundation, Inc. This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


I try to compile wxWidgets-3.0.1:


/src/wxWidgets-3.1.0/bk-deps g++ -c -o coredll_gtk_choice.o
-I./.pch/wxprec_coredll -D__WXGTK__  -DWXBUILDING
-I/src/wxWidgets-3.1.0/src/tiff/libtiff -I./src/tiff/libtiff -I./src/jpeg  
-I./src/regex  -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0 -fPIC -DPIC -Wall
-Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual
-Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64
-I/src/wxWidgets-3.1.0/lib/wx/include/gtk3-unicode-3.1 -I./include -pthread
-I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/include/gtk-3.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
-I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-DWX_PRECOMP -pthread -pthread -I/usr/local/include/gio-unix-2.0/
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
-I/usr/local/include -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
-I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-pipe -O3 -fvisibility=hidden -fvisibility-inlines-hidden ./src/gtk/choice.cpp
./src/gtk/choice.cpp:375:1: internal compiler error: in inline_small_functions,
at ipa-inline.c:1881
 }
 ^
DWARF underflow in .debug_info at 4
unrecognized DWARF version in .debug_info at 4
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:28498: recipe for target 'coredll_gtk_choice.o' failed
make: *** [coredll_gtk_choice.o] Error 1

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[cantabile.desu at gmail dot com]

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

--- Comment #3 from Bitterblue  ---
Yes, that works too.

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Presumably this would be the portable equivalent:

int main() {
wchar_t argv[1][6] = {L"a.out"};

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Fri, 13 May 2016, tschwinge at gcc dot gnu.org wrote:

> We could get rid of this heuristic (the property function_glibc_finite_math in
> combination with matching declarations' names) if the target compiler's early
> code transformation stages would accurately "describe" what they're doing, but
> that sounds like having to add some special/new "attributes" to glibc's
> , which sounds more complicated.  I think the heuristic is
> safe enough; symbol names prefixed with an underscore are in the 
> implementation
> namespace.

Even aside from offloading, there is a clear use for extensions to give 
better control over assembler names for different variants of functions: 
the libmvec issues where the vector function variants are not in 
one-to-one correspondence with the scalar function variants.

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Do you have a portable example that doesn't rely on the non-standard wmain(int,
wchar_t) main function? I can't understand that rubbish.

[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> Adding -fpic, I got:
> 
> Reopened, it looks that some sections are not handled correctly.

This is BFD linker bug [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20092

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
I like to avoid touching generic stuff for issues like this one. Please see
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01022.html for a brief outline of
an alternative solution: I think my proposal of performing decl name remapping
in a target-specific IPA pass works nicely for this issue too.

[Bug libstdc++/71107] New: wstring_convert::from_bytes produces wide chars with the wrong byte order

[cantabile.desu at gmail dot com]

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

Bug ID: 71107
   Summary: wstring_convert::from_bytes produces wide chars with
the wrong byte order
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cantabile.desu at gmail dot com
  Target Milestone: ---

This small program illustrates the problem:

#include 
#include 
#include 
#include 

int wmain(int argc, wchar_t **argv) {
std::wstring_convert utf16;

printf("Input bytes:\n");
for (size_t i = 0; i < wcslen(argv[0]) * sizeof(wchar_t); i++)
printf("%x ", (int)((uint8_t *)argv[0])[i]);
printf("\n");

std::string bytes = utf16.to_bytes(argv[0]);

printf("Text after to_bytes: '%s'\n", bytes.c_str());

printf("Bytes after to_bytes:\n");
for (size_t i = 0; i < bytes.size(); i++)
printf("%x ", (int)((const uint8_t *)bytes.c_str())[i]);
printf("\n");

std::wstring wide = utf16.from_bytes(bytes);

printf("Bytes after from_bytes:\n");
for (size_t i = 0; i < wide.size() * sizeof(wchar_t); i++)
printf("%x ", (int)((const uint8_t *)wide.c_str())[i]);
printf("\n");

bytes = utf16.to_bytes(wide);

printf("Text after to_bytes: '%s'\n", bytes.c_str());

printf("Bytes after to_bytes:\n");
for (size_t i = 0; i < bytes.size(); i++)
printf("%x ", (int)((const uint8_t *)bytes.c_str())[i]);
printf("\n");

return 0;
}


Command:
i686-w64-mingw32-g++ -std=c++11 -municode -o test.exe test.cpp -static-libgcc
-static-libstdc++

Output when compiled by GCC 6.1.1:
Input bytes:
5a 0 3a 0 5c 0 74 0 6d 0 70 0 5c 0 74 0 65 0 73 0 74 0 2e 0 65 0 78 0 65 0 
Text after to_bytes: 'Z:\tmp\test.exe'
Bytes after to_bytes:
5a 3a 5c 74 6d 70 5c 74 65 73 74 2e 65 78 65 
Bytes after from_bytes:
0 5a 0 3a 0 5c 0 74 0 6d 0 70 0 5c 0 74 0 65 0 73 0 74 0 2e 0 65 0 78 0 65 
Text after to_bytes: '娀㨀尀琀洀瀀尀琀攀猀琀⸀攀砀攀'
Bytes after to_bytes:
e5 a8 80 e3 a8 80 e5 b0 80 e7 90 80 e6 b4 80 e7 80 80 e5 b0 80 e7 90 80 e6 94
80 e7 8c 80 e7 90 80 e2 b8 80 e6 94 80 e7 a0 80 e6 94 80 


Output when compiled by GCC 5.1.0:
Input bytes:
5a 0 3a 0 5c 0 74 0 6d 0 70 0 5c 0 74 0 65 0 73 0 74 0 2e 0 65 0 78 0 65 0 
Text after to_bytes: 'Z:\tmp\test.exe'
Bytes after to_bytes:
5a 3a 5c 74 6d 70 5c 74 65 73 74 2e 65 78 65 
Bytes after from_bytes:
5a 0 3a 0 5c 0 74 0 6d 0 70 0 5c 0 74 0 65 0 73 0 74 0 2e 0 65 0 78 0 65 0 
Text after to_bytes: 'Z:\tmp\test.exe'
Bytes after to_bytes:
5a 3a 5c 74 6d 70 5c 74 65 73 74 2e 65 78 65 

GCC 5.3.0 is affected too.

Output of `i686-w64-mingw32-g++ -v`:
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/6.1.1/lto-wrapper
Target: i686-w64-mingw32
Configured with: /build/mingw-w64-gcc/src/gcc-6-20160505/configure
--prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl
--enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib
--enable-checking=release   Thread model:
posix
gcc version 6.1.1 20160505 (GCC) 

The system is a 64 bit Arch Linux. This GCC was obtained from the
"mingw-w64-gcc" package from Arch Linux.

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Created attachment 38484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38484=edit
0001-function_glibc_finite_math.patch

(In reply to Alexander Monakov from comment #1)
> Basically I'd say that host compilation environment establishes an ABI
> baseline that the accel environment must follow.

Generally, ACK.

> In your finite-math
> example, the problem exists due to an ABI extension in Glibc (note that the
> custom name could equally happen to be __glibc_log_finite).  You'd see the
> same issue trying to run a new binary on old Glibc systems that didn't have
> that symbol yet, and now Glibc itself is bound to carry that entrypoint
> forever.

ACK.

> And note that the issue is not limited to math symbols either: with
> -D_FORTIFY_SOURCE, plain 'printf' may become '__printf_chk', which would
> also fail to link on Newlib.

ACK, but let's concentrate on the math functions for the moment.

> Is there any actual issue with Fortran functions? [...]

That was meant to be a "motivational example", why users may expect to be able
to use math functions also in offloaded C/C++ regions.

I'm attaching a patch that shows a different approach, instead of adding a lot
of glibc-specific "__[function]_finite" entry points to the nvptx newlib, which
don't belong into there, really.

Basically, we add a new property function_glibc_finite_math
(gcc/coretypes.h:enum function_class), stream that in the target compiler
(gcc/lto-cgraph.c:output_offload_tables), and when reading it back in in the
offloading compilers (gcc/lto-cgraph.c:input_offload_tables), if the offloading
compiler's property doesn't match the of the target compiler, for all
references to external math functions, we 'check whether the assembler name for
"[function]" has been set to "__[function]_finite" [...], and if yes, reset
it'.

We could get rid of this heuristic (the property function_glibc_finite_math in
combination with matching declarations' names) if the target compiler's early
code transformation stages would accurately "describe" what they're doing, but
that sounds like having to add some special/new "attributes" to glibc's
, which sounds more complicated.  I think the heuristic is
safe enough; symbol names prefixed with an underscore are in the implementation
namespace.

What do you think of that?

[Bug tree-optimization/70884] [6/7 regression] 2nd SRA pass confused by load from constant pool

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
That's fine, I didn't assign it to myself for a reason. ;-)

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Started with r235817

[Bug target/71106] New: MIPS: Unaligned load/store instructions are not used to access a variable with an aligned attribute

[andrew.bennett at imgtec dot com]

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

Bug ID: 71106
   Summary: MIPS: Unaligned load/store instructions are not used
to access a variable with an aligned attribute
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.bennett at imgtec dot com
  Target Milestone: ---

Hi,

Currently if we build the following example for MIPS:

int a __attribute__((aligned(1)));

void
foo (void)
{
  a = 0;
}

Using the following command line options:

-mips32r2 -O2 -mno-gpopt

It generates a sw instruction to store the value of 0 to the variable a, when
it should be using a swl/swr instruction sequence because the value of the
aligned attribute is less than the natural alignment of the int type.

.entfoo
.type   foo, @function
foo:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
lui $2,%hi(a)
jr  $31
sw  $0,%lo(a)($2)

.setmacro
.setreorder
.endfoo
.size   foo, .-foo

.comm   a,4,1

[Bug c++/70018] [4.9/5/6 Regression] Possible issue around IPO and C++ comdats discovered as pure/const

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 Regression]  |[4.9/5/6 Regression]
   |Possible issue around IPO   |Possible issue around IPO
   |and C++ comdats discovered  |and C++ comdats discovered
   |as pure/const   |as pure/const

--- Comment #17 from Jan Hubicka  ---
Fixed on trunk so far.

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
Yes, this fixed my problem with mozilla firefox compilation,
Thank you!

[Bug tree-optimization/70884] [6/7 regression] 2nd SRA pass confused by load from constant pool

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Oh, I have not noticed that Eric was already working on this.  In any
event, I've posted my proposed patch to fix this, it is at:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01016.html

[Bug c++/71105] New: [6 regression] lambas with default captures improperly have function pointer conversions

[Casey at Carter dot net]

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

Bug ID: 71105
   Summary: [6 regression] lambas with default captures improperly
have function pointer conversions
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Created attachment 38483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38483=edit
Minimal test case

N4582 [expr.prim.lambda]/7 says:

The closure type for a non-generic lambda-expression with no lambda-capture has
a conversion function to pointer to function with C++ language linkage (7.5)
having the same parameter and return types as the closure type’s function call
operator. ... For a generic lambda with no lambda-capture, the closure type has
a conversion function template to pointer to function. The conversion function
template has the same invented template-parameter-list, and the pointer to
function has the same parameter types, as the function call operator template.
...

So all of:

static_cast([]{});
static_cast([](auto){});
static_cast([](auto x){ return x; });

should compile. These should all be ill-formed since the lambdas have
lambda-captures:

static_cast([i]{});
static_cast([=]{});
static_cast([&]{});
static_cast([i](auto){});
static_cast([=](auto){});
static_cast([&](auto){});
static_cast([i](auto x){ return x; });
static_cast([=](auto x){ return x; });
static_cast([&](auto x){ return x; });

clang (tested 3.4 - 3.9, all versions that implement generic lambdas) diagnoses
all of these conversions as ill-formed; gcc (4.9.0 - 6.1.0, again all versions
that implement generic lambdas) diagnoses only those with explicit captures.

This issue is significant when a library composes function objects via private
inheritance to take advantage of the empty base optimization and it adapts a
(possibly) underconstrained generic lambda to a different/larger valid space of
parameter types. For example, from range-v3:

#include 

template 
struct indirected : F {
indirected(F f) : F(f) {}
template 
auto operator()(I i) -> decltype(std::declval()(*i)) {
return static_cast(*this)(*i);
}
};

int main() {
auto f = [=](auto i) { return i + i; };
auto i = indirected{f};
static_assert(std::is_same())), int>(),
"");
}

This program compiles correctly with the GCC 4.9 and 5 series compilers, 6.1
diagnoses the static_assert line (See
http://melpon.org/wandbox/permlink/yy61pk0iJRfUVBya):

prog.cc: In instantiation of 'main():: [with auto:1 = int*]':
prog.cc:13:24:   required by substitution of 'template
main()::::operator decltype
(((main()::)0u).operator()(static_cast()))
(*)(auto:1)() const [with auto:1 = int*]'
prog.cc:15:63:   required from here
prog.cc:13:37: error: invalid operands of types 'int*' and 'int*' to binary
'operator+'
 auto f = [=](auto i) { return i + i; };
   ~~^~~

[Bug other/71094] Documentation: -fivopts is enabled at -O1+, -Os and -Ofast

[nightstrike at gmail dot com]

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

--- Comment #2 from nightstrike  ---
Is there a different bug that documents that -Q lists -fivopts as enabled for
all levels?

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on arm and aarch64

[Bug tree-optimization/71104] New: [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[nsz at gcc dot gnu.org]

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

Bug ID: 71104
   Summary: [7 Regression] ICE: verify_ssa failed (with vfork /
error: definition in block 3 does not dominate use in
block 7 )
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

found this while cross compiling busybox to aarch64, i think it depends on
vfork being special.

gcc version 7.0.0 20160512
(trunk r236177)

$ cat a.c
struct globals { int helper_pid; };

extern struct globals *const ptr;

void foo(int);
int vfork(void);

void bar(void)
{
 foo(0);
 (*ptr).helper_pid = ({ int pid = vfork(); if (pid < 0) foo(0); pid; });
}
$ aarch64-none-linux-gnu-gcc -c a.c 
a.c: In function 'bar':
a.c:12:1: error: definition in block 3 does not dominate use in block 7
 }
 ^
for SSA_NAME: ptr.0_1 in statement:
# .MEM_12 = VDEF <.MEM_4>
ptr.0_1->helper_pid = _11;
a.c:12:1: internal compiler error: verify_ssa failed
0xd25da2 verify_ssa(bool, bool)
/w/src/gcc/gcc/tree-ssa.c:1039
0xa5be0d execute_function_todo
/w/src/gcc/gcc/passes.c:1971
0xa5c77b execute_todo
/w/src/gcc/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/71073] debug-mode headers should include #pragma GCC system_header directives

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Done

[Bug libstdc++/71073] debug-mode headers should include #pragma GCC system_header directives

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri May 13 14:47:46 2016
New Revision: 236211

URL: https://gcc.gnu.org/viewcvs?rev=236211=gcc=rev
Log:
libstdc++/71073 add system_header pragma to Debug Mode headers

PR libstdc++/71073
* include/debug/bitset: Add #pragma GCC system_header.
* include/debug/deque: Likewise.
* include/debug/list: Likewise.
* include/debug/map: Likewise.
* include/debug/set: Likewise.
* include/debug/string: Likewise.
* include/debug/unordered_map: Likewise.
* include/debug/unordered_set: Likewise.
* include/debug/vector: Likewise.
* include/debug/functions.h: Adjust whitespace.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/bitset
trunk/libstdc++-v3/include/debug/deque
trunk/libstdc++-v3/include/debug/functions.h
trunk/libstdc++-v3/include/debug/list
trunk/libstdc++-v3/include/debug/map
trunk/libstdc++-v3/include/debug/set
trunk/libstdc++-v3/include/debug/string
trunk/libstdc++-v3/include/debug/unordered_map
trunk/libstdc++-v3/include/debug/unordered_set
trunk/libstdc++-v3/include/debug/vector

[Bug fortran/70856] [6/7 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
before icf, we have:
...
  static real(kind=4) A.4[2] = {1.0e+0, 2.0e+0};
  static real(kind=4) A.1[2] = {1.0e+0, 2.0e+0};
...

Then icf does:
...
Semantic equality hit:A.4->A.1
Assembler symbol names:A.4.3435->A.1.3429
Unified; Variable alias has been created.
...

And after icf, we have:
...
  static real(kind=4) A.4[2] = {1.0e+0, 2.0e+0};
  static real(kind=4) A.1[2];
...

What openacc does, is run ipa-pta before and after icf.

The compilation succeeds with -fno-ipa-icf.

[Bug ipa/70760] [6 regression] wrong generated code for std::make_unique with -fipa-pta

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.0
 Resolution|--- |FIXED

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

[Bug target/70941] [5/6 Regression] Test miscompiled with -O2.

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Fri May 13 13:22:42 2016
New Revision: 236210

URL: https://gcc.gnu.org/viewcvs?rev=236210=gcc=rev
Log:
2016-05-13  Richard Biener  

Backport from mainline
2016-04-27  Richard Biener  

PR ipa/70760
* tree-ssa-structalias.c (find_func_aliases_for_call): Use
aggregate_value_p to determine if a function result is
returned by reference.

* g++.dg/ipa/ipa-pta-2.C: New testcase.
* gcc.dg/ipa/ipa-pta-1.c: Adjust.

2016-05-06  Richard Biener  

PR middle-end/70931
* dwarf2out.c (native_encode_initializer): Skip zero-sized fields.

* gfortran.dg/pr70931.f90: New testcase.

2016-05-06  Richard Biener  

PR middle-end/70941
* fold-const.c (split_tree): Always convert to the original type
before negating.

* gcc.dg/torture/pr70941.c: New testcase.

2016-05-06  Jakub Jelinek  

PR middle-end/70941
* gcc.dg/torture/pr70941.c (abort): Remove prototype.
(a, b, c, d): Change type from char to signed char.
(main): Compare against (signed char) -1634678893 instead of
hardcoded -109.  Use __builtin_abort instead of abort.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/ipa-pta-2.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr70941.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70931.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/dwarf2out.c
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug fortran/70931] [4.9/5 Regression] ICE with -g in native_encode_initializer, bei dwarf2out.c:17768

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri May 13 13:22:42 2016
New Revision: 236210

URL: https://gcc.gnu.org/viewcvs?rev=236210=gcc=rev
Log:
2016-05-13  Richard Biener  

Backport from mainline
2016-04-27  Richard Biener  

PR ipa/70760
* tree-ssa-structalias.c (find_func_aliases_for_call): Use
aggregate_value_p to determine if a function result is
returned by reference.

* g++.dg/ipa/ipa-pta-2.C: New testcase.
* gcc.dg/ipa/ipa-pta-1.c: Adjust.

2016-05-06  Richard Biener  

PR middle-end/70931
* dwarf2out.c (native_encode_initializer): Skip zero-sized fields.

* gfortran.dg/pr70931.f90: New testcase.

2016-05-06  Richard Biener  

PR middle-end/70941
* fold-const.c (split_tree): Always convert to the original type
before negating.

* gcc.dg/torture/pr70941.c: New testcase.

2016-05-06  Jakub Jelinek  

PR middle-end/70941
* gcc.dg/torture/pr70941.c (abort): Remove prototype.
(a, b, c, d): Change type from char to signed char.
(main): Compare against (signed char) -1634678893 instead of
hardcoded -109.  Use __builtin_abort instead of abort.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/ipa-pta-2.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr70941.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70931.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/dwarf2out.c
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug ipa/70760] [6 regression] wrong generated code for std::make_unique with -fipa-pta

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Fri May 13 13:22:42 2016
New Revision: 236210

URL: https://gcc.gnu.org/viewcvs?rev=236210=gcc=rev
Log:
2016-05-13  Richard Biener  

Backport from mainline
2016-04-27  Richard Biener  

PR ipa/70760
* tree-ssa-structalias.c (find_func_aliases_for_call): Use
aggregate_value_p to determine if a function result is
returned by reference.

* g++.dg/ipa/ipa-pta-2.C: New testcase.
* gcc.dg/ipa/ipa-pta-1.c: Adjust.

2016-05-06  Richard Biener  

PR middle-end/70931
* dwarf2out.c (native_encode_initializer): Skip zero-sized fields.

* gfortran.dg/pr70931.f90: New testcase.

2016-05-06  Richard Biener  

PR middle-end/70941
* fold-const.c (split_tree): Always convert to the original type
before negating.

* gcc.dg/torture/pr70941.c: New testcase.

2016-05-06  Jakub Jelinek  

PR middle-end/70941
* gcc.dg/torture/pr70941.c (abort): Remove prototype.
(a, b, c, d): Change type from char to signed char.
(main): Compare against (signed char) -1634678893 instead of
hardcoded -109.  Use __builtin_abort instead of abort.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/ipa-pta-2.C
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr70941.c
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70931.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/dwarf2out.c
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-structalias.c

[Bug tree-optimization/70884] [6/7 regression] 2nd SRA pass confused by load from constant pool

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
I'm working on this (using the PR 70719 testcase, though).

[Bug target/71103] New: avr-gcc crashes with unrecognizable insn error

[pitchumani.s at hotmail dot com]

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

Bug ID: 71103
   Summary: avr-gcc crashes with unrecognizable insn error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pitchumani.s at hotmail dot com
  Target Milestone: ---

struct ResponseStruct{  
unsigned char responseLength;
char *response;
};

static char response[5];
struct ResponseStruct something(){
struct ResponseStruct returnValue;
returnValue.responseLength = 5;
returnValue.response = response;
return returnValue;
}

avr-gcc crashes when optimization is enabled for this test case.

$ avr-gcc test.c -mmcu=atmega1280 -O1

test.c: In function 'something':
test.c:12:1: error: unrecognizable insn:
 }
 ^
(insn 6 5 7 2 (set (subreg:QI (reg:PSI 42 [ D.1499 ]) 1)
(subreg:QI (symbol_ref:HI ("response") [flags 0x2] ) 0)) test.c:11 -1
 (nil))
test.c:12:1: internal compiler error: in extract_insn, at recog.c:2287
0xd51195 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/rudran/code/gcc/gcc/rtl-error.c:108

[Bug preprocessor/71102] New: _Pragma("GCC warning ...") should concatenate string literals

[zackw at panix dot com]

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

Bug ID: 71102
   Summary: _Pragma("GCC warning ...") should concatenate string
literals
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zackw at panix dot com
  Target Milestone: ---

Consider

#define warn1(msg) _Pragma (#msg)
#define warn(msg) warn1 (GCC warning msg)
#define lengthy_explanation(name) \
"This is a long explanation about why `" #name "' is deprecated."

#define SYMBOL warn(lengthy_explanation(SYMBOL)) 1

int main(void) { return SYMBOL; }

With gcc (5 and 6), the warning message printed is

test.c:9:13: warning: This is a long explanation about why `

which is obviously not what was wanted.  (The column position of the diagnostic
is also wrong, but that's secondary.)  One could theoretically work around this
by not using string literals in lengthy_explanation() but that risks blowing up
in one's face if any of the words in the explanation happen to be macros (and
also I'm not sure how I would get the quotation marks in there).

n.b. clang gets this right:

test.c:9:25: warning: This is a long explanation about why `SYMBOL' is
  deprecated. [-W#pragma-messages]

[Bug tree-optimization/42587] bswap not recognized for memory

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri May 13 12:27:18 2016
New Revision: 236204

URL: https://gcc.gnu.org/viewcvs?rev=236204=gcc=rev
Log:
2016-05-13  Richard Biener  

PR tree-optimization/42587
* tree-ssa-math-opts.c (perform_symbolic_merge): Handle BIT_FIELD_REF.
(find_bswap_or_nop_1): Likewise.
(bswap_replace): Likewise.

* gcc.dg/optimize-bswapsi-4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/optimize-bswapsi-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug other/71101] ICE in libcpp/line-map.c:linemap_macro_map_lookup very early in offloading compilation lto1 front end

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
That's too early.  You have to wait until locations are applied to the linemap.

So IMHO not a bug but an implementation detail ... (not easy to fix w/o
overhead).

[Bug c++/70737] Invalid C++ code compiles when using explicit template conversions

[matteo at mitalia dot net]

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

Matteo Italia  changed:

   What|Removed |Added

 CC||matteo at mitalia dot net

--- Comment #2 from Matteo Italia  ---
Templates don't seem to have a relevant role here, I found that this simpler
test case exhibits the same problem:

struct A {
explicit operator bool();
operator int();
operator double();
};

bool foo(A& a) {
return a;
}

bool bar(A& a) {
return bool(a);
}

As in Andrea's example, `foo`'s code is not valid, since `operator bool` is
disabled (it's marked as explicit), and it's ambiguous whether `operator int`
or `operator double` should be invoked.

clang correctly refuses to compile this snippet (https://godbolt.org/g/lZa2Qx),
while all gcc>=4.6 (and <=6.1) I tried on gcc.godbolt.org compile `foo` to a
no-op function (`rep ret` on x86), thus leading to garbage being returned:

foo(A&):
rep ret
bar(A&):
jmp A::operator bool()

(https://godbolt.org/g/xmrMGN)
(here -O3 optimizes the tail call and removes some stack setup/cleanup noise,
but the problem is present at all optimization levels)

So, the core of the bug seems to be that gcc discards completely a conversion
that becomes ambiguous once the "obvious" candidate is discarded for being
marked as `explicit`.

The gcc 4 series at least issued a dubious "warning: control reaches end of
non-void function [-Wreturn-type]", from gcc 5 onwards even this warning
disappeared (although, this may save you in this artificial example, in my
original code gcc dropped a conditional assignment to an already-initialized
variable, so the issue was completely silent).

[Bug other/71101] New: ICE in libcpp/line-map.c:linemap_macro_map_lookup very early in offloading compilation lto1 front end

[tschwinge at gcc dot gnu.org]

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

Bug ID: 71101
   Summary: ICE in libcpp/line-map.c:linemap_macro_map_lookup very
early in offloading compilation lto1 front end
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I'm running into an ICE in libcpp/line-map code, when in GDB doing a "call
debug_tree(decl)", very early in a lto1 front end that is reading in an
offloading compilation stream.  That setting will be a bit difficult to
reproduce, but perhaps the following information gives enough clues already? 
(Putting David in CC as he's done a lot of line-map changes recently -- but I'm
not claiming that any of his changes are actually related to this.)

Is it maybe just "too early" to call debug_tree in that situation, or should
that be handled in some way or another?

Breakpoint 2, lto_register_function_decl_in_symtab
(data_in=data_in@entry=0x15832b0, decl=0x76989d20, ix=ix@entry=175) at
[...]/source-gcc/gcc/lto/lto.c:871
871 {

Here I manually call:

(gdb) call debug_tree(decl)
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality
arg-types 
chain >>>
addressable nothrow staticlto1: internal compiler error: in
linemap_macro_map_lookup, at libcpp/line-map.c:984

(Notice the ICE message starting after "addressable nothrow static".)  That's
the following linemap_assert:

/* Given a source location yielded by a macro map, returns that map.
   Since the set is built chronologically, the logical lines are
   monotonic decreasing, and so the list is sorted and we can use a
   binary search.  */

static const line_map_macro *
linemap_macro_map_lookup (struct line_maps *set, source_location line)
{
  unsigned int md, mn, mx;
  const struct line_map_macro *cached, *result;

  if (IS_ADHOC_LOC (line))
line = set->location_adhoc_data_map.data[line &
MAX_SOURCE_LOCATION].locus;

  linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));

Rebuilding that part with "-O0", I see the following backtrace:

#1  0x00fd4373 in linemap_macro_map_lookup
(set=set@entry=0x77ff5000, line=line@entry=2) at
[...]/source-gcc/libcpp/line-map.c:986
#2  0x00fd5131 in linemap_lookup (set=set@entry=0x77ff5000,
line=line@entry=2) at [...]/source-gcc/libcpp/line-map.c:920
#3  0x00fd62c4 in linemap_location_in_system_header_p
(set=0x77ff5000, location=2) at [...]/source-gcc/libcpp/line-map.c:1191
#4  0x009a2202 in print_node (file=0x76e91640
<_IO_2_1_stderr_>, prefix=prefix@entry=0x1105de0 "",
node=node@entry=0x76989d20, indent=indent@entry=0) at
[...]/source-gcc/gcc/print-tree.c:373
#5  0x009a6380 in debug_tree (node=0x76989d20) at
[...]/source-gcc/gcc/print-tree.c:976
#6  
[...]
(gdb) frame 1
#1  0x00fd4373 in linemap_macro_map_lookup
(set=set@entry=0x77ff5000, line=line@entry=2) at
[...]/source-gcc/libcpp/line-map.c:986
986   linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
(gdb) print line
$1 = 2
(gdb) print set
$2 = (line_maps *) 0x77ff5000
(gdb) print *set
$3 = {info_ordinary = {maps = 0x0, allocated = 0, used = 0, cache = 0},
info_macro = {maps = 0x0, allocated = 0, used = 0, cache = 0}, depth = 0,
trace_includes = false, highest_location = 1, highest_line = 1, max_column_hint
= 0, reallocator = 0xa403b0 ,
round_alloc_size = 0x5a9b10 ,
location_adhoc_data_map = {htab = 0x157e550, curr_loc = 0, allocated = 0, data
= 0x0}, builtin_location = 1, seen_line_directive = false, default_range_bits =
5, num_optimized_ranges = 0, num_unoptimized_ranges = 0}
(gdb) call line_table_dump(0,set,-1,-1)
# of ordinary maps:  0
# of macro maps: 0
Include stack depth: 0
Highest location:1

Ordinary line maps


Macro line maps


If that helps any: running through this again, I see "line" is not considered
"IS_ADHOC_LOC":

(gdb) list
974monotonic decreasing, and so the list is sorted and we can use a
975binary search.  */
976
977 static const line_map_macro *
978 linemap_macro_map_lookup (struct line_maps *set, source_location
line)
979 {
980   unsigned int md, mn, mx;
981   const struct line_map_macro *cached, *result;
982
983   if (IS_ADHOC_LOC (line))
(gdb) n
983   if (IS_ADHOC_LOC (line))
(gdb) s
IS_ADHOC_LOC 

[Bug sanitizer/69840] two ASAN help nits

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Andrew Pinski from comment #4)
> Then we have to agree that this code breaks GNU output style.  Or it breaks
> LLVM output style.  It is one or the other, I rather see a way to do this
> dynamically of breaking up the lines (this was done in the past for GCC's
> diagnostic so it definitely can be done).

I like your idea, thus I've created a new version of pull request that directs
the dump output format by a compiler macro (_GNU_HELP_OUTPUT).

Enabling the macro in Makefile.{am,in} would be the only necessary change in
GCC.
Let's see what the LLVM folks will say about the change.

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #7 from Ilya Enkovich  ---
Fixed by r236199.

[Bug target/71097] Additional testsuite failures with -mcmodel=medium

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> You're right, of course: should have kept my mouth shut ;-(
> 
> This leaves us with
> 
> gcc.target/i386/387-12.c

This testcase needs updating, the compilation with -mcmodel just loads directly
from memory to mmx return reg.

> gcc.target/i386/avxfp-1.c
> gcc.target/i386/avxfp-2.c
> gcc.target/i386/ssefp-1.c
> gcc.target/i386/ssefp-2.c

These are interesting. RTL ifcvt pass _.ce1 fails to convert to min/max.

> gcc.target/i386/stack-prot-kernel.c

This testcase already uses -mcmodel=kernel and is overruled by passed
-mcmodel=medium option.

[Bug target/53440] [arm] generic thunk code fails for method which uses '...'

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan  ---
Author: ramana
Date: Fri May 13 09:32:29 2016
New Revision: 236198

URL: https://gcc.gnu.org/viewcvs?rev=236198=gcc=rev
Log:
Fix PR target/53440 - handle generic thunks better for TARGET_32BIT.


This partially fixes PR target/53440 atleast in ARM and
Thumb2 state. I haven't yet managed to get my head around
rewriting the Thumb1 support yet.

Tested on armhf with a bootstrap and regression test
with no regressions.

Queued for stage1 now as it isn't technically a regression.

regards
Ramana


2016-05-13  Ramana Radhakrishnan  

PR target/53440
* config/arm/arm.c (arm32_output_mi_thunk): New.
(arm_output_mi_thunk): Rename to arm_thumb1_mi_thunk. Rework
to split Thumb1 vs TARGET_32BIT functionality.
(arm_thumb1_mi_thunk): New.


* g++.dg/inherit/thunk1.C: Support arm / aarch64.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/inherit/thunk1.C

[Bug c++/71100] [6/7 regression] Internal compiler error while calling a pointer to member function that throws

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
   Target Milestone|--- |6.2
Summary|[6.1 regression] Internal   |[6/7 regression] Internal
   |compiler error while|compiler error while
   |calling a pointer to member |calling a pointer to member
   |function that throws|function that throws
 Ever confirmed|0   |1

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

> ./cc1plus  -quiet t.ii -O2
t.ii: In function 'void f(XX*)':
t.ii:14:12: internal compiler error: in assign_temp, at function.c:961
   (o->*f)();
^
0xd285c3 assign_temp(tree_node*, int, int)
/space/rguenther/src/svn/trunk/gcc/function.c:961
0xb50440 expand_call(tree_node*, rtx_def*, int)
/space/rguenther/src/svn/trunk/gcc/calls.c:2569
0xcccb6c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/space/rguenther/src/svn/trunk/gcc/expr.c:10610
0xcc1633 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/space/rguenther/src/svn/trunk/gcc/expr.c:7962
0xb60525 expand_expr
/space/rguenther/src/svn/trunk/gcc/expr.h:256
0xb68681 expand_call_stmt

[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
   Target Milestone|--- |7.0

[Bug other/71094] Documentation: -fivopts is enabled at -O1+, -Os and -Ofast

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug other/71094] Documentation: -fivopts is enabled at -O1+, -Os and -Ofast

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|Documentation: -fivopts is  |Documentation: -fivopts is
   |enabled at all levels   |enabled at -O1+, -Os and
   ||-Ofast

--- Comment #1 from Richard Biener  ---
-O0 does not enable IVOPTs nor does -Og (this is because the Init(1) is not
effective for them).

Confirmed though for the missing documentation.

[Bug c++/71100] New: [6.1 regression] Internal compiler error while calling a pointer to member function that throws

[ogoffart at kde dot org]

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

Bug ID: 71100
   Summary: [6.1 regression] Internal compiler error while calling
a pointer to member function that throws
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ogoffart at kde dot org
  Target Milestone: ---

This code crashes GCC 6.1 when optimisations are enabled:

---
struct Destr
{ ~Destr(); };

struct XX
{
Destr func() {
throw "throw";
return {};
}
};

inline void call(Destr (XX::*f)(), XX *o)
{
(o->*f)();
}

void f(XX *o) {
call(::func, o);
}
---


Live demo:
http://melpon.org/wandbox/permlink/GyM44dSdEnvqqmZN

[Bug target/71080] Segfault in ix86_in_large_data_p with -fpic -mcmodel={medium, large}

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #4 from Rainer Orth  ---
Fixed for 7.1.

[Bug tree-optimization/42587] bswap not recognized for memory

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
I have a patch to fix the second testcase in comment#3.  Note that the original
testcase still fails to be detected.

[Bug target/71080] Segfault in ix86_in_large_data_p with -fpic -mcmodel={medium, large}

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  ---
Author: ro
Date: Fri May 13 09:08:15 2016
New Revision: 236196

URL: https://gcc.gnu.org/viewcvs?rev=236196=gcc=rev
Log:
Fix SEGV in ix86_in_large_data_p (PR target/71080)

PR target/71080
* config/i386/i386.c (ix86_in_large_data_p): Guard against NULL exp.

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

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/71080] Segfault in ix86_in_large_data_p with -fpic -mcmodel={medium, large}

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-05/msg00944.ht
   ||ml
   Last reconfirmed||2016-05-13
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
Mine, patch posted.

[Bug target/71097] Additional testsuite failures with -mcmodel=medium

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
You're right, of course: should have kept my mouth shut ;-(

This leaves us with

gcc.target/i386/387-12.c
gcc.target/i386/avxfp-1.c
gcc.target/i386/avxfp-2.c
gcc.target/i386/ssefp-1.c
gcc.target/i386/ssefp-2.c
gcc.target/i386/stack-prot-kernel.c

Rainer

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

[rs2740 at gmail dot com]

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

Bug ID: 71099
   Summary: Misleading diagnostic message with 'virtual' used in
out-of-line definitions of class template member
functions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

GCC correctly diagnoses the problem with this ill-formed code:

struct foo {
virtual void f();
};

virtual void foo::f() {}

+ g++ -std=c++14 -Wall -pedantic main.cpp
main.cpp:5:1: error: 'virtual' outside class declaration
 virtual void foo::f() {}
 ^~~

But if `foo` is a template, the error message is significantly less helpful:

template
struct foo {
virtual void f();
};

template
virtual void foo::f() {}

+ g++ -std=c++14 -Wall -pedantic main.cpp
main.cpp:7:1: error: templates may not be 'virtual'
 virtual void foo::f() {}
 ^~~

Clang correctly diagnoses the problem in both cases ("main.cpp:7:1: error:
'virtual' can only be specified inside the class definition").

[Bug target/71097] Additional testsuite failures with -mcmodel=medium

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Uroš Bizjak  ---
> > Many of these are testsuite issues, -mcmodel=medium is incompatible with 
> > -mx32.
> 
> This doesn't apply to the cases I listed: this was a regular
> 
>   -m64 -mcmodel=medium
> 
> testsuite run.

Let's see one example, e.g. pr66470.c:

/* PR target/66470 */
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -mx32 -maddress-mode=long" } */
/* { dg-require-effective-target tls } */

Your testsuite run will pass -O2 -mx32 -maddress-mode=long -mcmodel=medium, so:

~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long -mcmodel=medium pr66470.c 
pr66470.c:1:0: error: code model ‘medium’ not supported in x32 mode
 /* PR target/66470 */

[Bug target/71097] Additional testsuite failures with -mcmodel=medium

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Uroš Bizjak  ---
> Many of these are testsuite issues, -mcmodel=medium is incompatible with 
> -mx32.

This doesn't apply to the cases I listed: this was a regular

-m64 -mcmodel=medium

testsuite run.

Rainer

[Bug target/71097] Additional testsuite failures with -mcmodel=medium

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Many of these are testsuite issues, -mcmodel=medium is incompatible with -mx32.

[Bug libstdc++/71098] New: uniform initialization for nested tuples work in c++11/14 mode but should only work >=c++17

[lts-rudolph at gmx dot de]

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

Bug ID: 71098
   Summary: uniform initialization for nested tuples work in
c++11/14 mode but should only work >=c++17
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

uniform initialization for nested std::tuple works in c++11/14 mode but should
work not before c++17.

The following line compiles without warning/error in --std=c++11/14

std::tuple > t2{{ 1,2.2}};

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Then we need something like:
--- gcc/fold-const.c.jj 2016-05-11 15:15:49.0 +0200
+++ gcc/fold-const.c2016-05-13 10:31:05.693911428 +0200
@@ -12130,7 +12130,8 @@ fold_checksum_tree (const_tree expr, str
   || TYPE_REFERENCE_TO (expr)
   || TYPE_CACHED_VALUES_P (expr)
   || TYPE_CONTAINS_PLACEHOLDER_INTERNAL (expr)
-  || TYPE_NEXT_VARIANT (expr)))
+  || TYPE_NEXT_VARIANT (expr)
+  || TYPE_ALIAS_SET_KNOWN_P (expr)))
 {
   /* Allow these fields to be modified.  */
   tree tmp;
@@ -12140,6 +12141,7 @@ fold_checksum_tree (const_tree expr, str
   TYPE_POINTER_TO (tmp) = NULL;
   TYPE_REFERENCE_TO (tmp) = NULL;
   TYPE_NEXT_VARIANT (tmp) = NULL;
+  TYPE_ALIAS_SET (tmp) = -1;
   if (TYPE_CACHED_VALUES_P (tmp))
{
  TYPE_CACHED_VALUES_P (tmp) = 0;

[Bug target/71097] New: Additional testsuite failures with -mcmodel=medium

[ro at gcc dot gnu.org]

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

Bug ID: 71097
   Summary: Additional testsuite failures with -mcmodel=medium
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

While testing a fix for PR target/71080, I noticed a couple of additional
testsuite failures with -mcmodel=medium.  It turns out that they are already
present
on the gcc-6 branch, i.e. without my patch that triggered the PR above:

FAIL: gcc.target/i386/387-12.c scan-assembler fld1
FAIL: gcc.target/i386/387-12.c scan-assembler fldz
FAIL: gcc.target/i386/avxfp-1.c scan-assembler vmaxsd
FAIL: gcc.target/i386/avxfp-1.c scan-assembler vminsd
FAIL: gcc.target/i386/avxfp-2.c scan-assembler vmaxsd
FAIL: gcc.target/i386/avxfp-2.c scan-assembler vminsd
FAIL: gcc.target/i386/pr52146.c (test for excess errors)
FAIL: gcc.target/i386/pr52698.c (test for excess errors)
FAIL: gcc.target/i386/pr52857-1.c (test for excess errors)
FAIL: gcc.target/i386/pr52857-2.c (test for excess errors)
FAIL: gcc.target/i386/pr53698.c (test for excess errors)
FAIL: gcc.target/i386/pr54157.c (test for excess errors)
FAIL: gcc.target/i386/pr55049-1.c (test for excess errors)
FAIL: gcc.target/i386/pr55093.c (test for excess errors)
FAIL: gcc.target/i386/pr55116-1.c (test for excess errors)
FAIL: gcc.target/i386/pr55116-2.c (test for excess errors)
FAIL: gcc.target/i386/pr55597.c (test for excess errors)
FAIL: gcc.target/i386/pr66470.c (test for excess errors)
FAIL: gcc.target/i386/ssefp-1.c scan-assembler maxsd
FAIL: gcc.target/i386/ssefp-1.c scan-assembler minsd
FAIL: gcc.target/i386/ssefp-2.c scan-assembler maxsd
FAIL: gcc.target/i386/ssefp-2.c scan-assembler minsd
FAIL: gcc.target/i386/stack-prot-kernel.c scan-assembler-not %fs

I haven't even started analysing what's wrong, just want to file the PR so
others aren't surprised.

  Rainer

[Bug rtl-optimization/70904] ICE: Max. number of generated reload insns per insn is achieved (90) with -fno-split-wide-types @ aarch64

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #5 from Jiong Wang  ---
Fixed.

[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

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

--- Comment #3 from Roger Orr  ---
FWIW I'm getting a very similar problem, but at line 1882 - 1 line further on -
when compiling a different source file at -O2.

I haven't managed to reproduce a small test case yet, I can try to do so if it
would be useful and/or if the fix for this problem doesn't also resolve mine.

[Bug tree-optimization/71059] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "vn_nary_op_insert_into"

[rogero at howzatt dot demon.co.uk]

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

--- Comment #4 from Roger Orr  ---
Thanks, fixes the ICE I had.

[Bug libstdc++/71096] New: std::get did not work for nested derived classes from std::tuple if one element is empty

[lts-rudolph at gmx dot de]

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

Bug ID: 71096
   Summary: std::get did not work for nested derived classes from
std::tuple if one element is empty
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

Created attachment 38482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38482=edit
minimum example to compile

If you derive from std::tuple and use this class nested, std::get fails if
there is a empty tuple inside the outside tuple.

Please see code for clarification :-)

#include 

template 
struct TypeContainer : std::tuple
{
};

int main()
{
std::get<0>(TypeContainer>{});
}

Compile fails with:

/opt/linux-gnu_6.1.0/bin/g++ --std=c++14 main.cpp -O0 -g -o go 
main.cpp: In function 'int main()':
main.cpp:10:53: error: no matching function for call to
'get(TypeContainer >)'
 std::get<0>(TypeContainer>{});

...

/opt/linux-gnu_6.1.0/include/c++/6.1.0/tuple|1235 col 5| note:   template
argument deduction/substitution failed:
main.cpp|10 col 53| note:   'std::tuple<_Elements ...>' is an ambiguous base
class of 'TypeContainer >'
||  std::get<0>(TypeContainer>{});
||  ^

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
Created attachment 38481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38481=edit
pre-rpcessed newlib/libc/stdlib/dtoa.c for nvptx-none

I also bisected a nvptx-none "fold check" ICE to be caused/triggered by the
recent r236117:

build-gcc-offload-nvptx-none/gcc/cc1 -fpreprocessed dtoa.i -g -O2
-fno-builtin
 quorem _dtoa_r
[...]/source-gcc/newlib/libc/stdlib/dtoa.c: In function '_dtoa_r':
[...]/source-gcc/newlib/libc/stdlib/dtoa.c:269:2: internal compiler error:
fold check: original tree changed by fold
  "NaN";
  ^

#1  0x0050fe29 in fold_check_failed (ret=,
expr=0x76a4b640) at [...]/source-gcc/gcc/fold-const.c:12099
#2  0x007f4f48 in fold_build2_stat_loc (loc=loc@entry=2147483836,
code=code@entry=TRUTH_ANDIF_EXPR, type=0x768d2690,
op0=op0@entry=0x76a4b640, op1=0x76a4b668) at
[...]/source-gcc/gcc/fold-const.c:12358
#3  0x005d7090 in c_fully_fold_internal
(expr=expr@entry=0x76a4b618, in_init=in_init@entry=false,
maybe_const_operands=maybe_const_operands@entry=0x7fffbf0a,
maybe_const_itself=maybe_const_itself@entry=0x7fffbf0d,
for_int_const=for_int_const@entry=false) at [...]/source-gcc/gcc/c/c-fold.c:457
#4  0x005d521a in c_fully_fold_internal
(expr=expr@entry=0x76a4a4b0, in_init=in_init@entry=false,
maybe_const_operands=maybe_const_operands@entry=0x7fffbf5e,
maybe_const_itself=maybe_const_itself@entry=0x7fffbf5f,
for_int_const=for_int_const@entry=false) at [...]/source-gcc/gcc/c/c-fold.c:482
#5  0x005d840b in c_fully_fold (expr=expr@entry=0x76a4a4b0,
in_init=in_init@entry=false, maybe_const=0x7fffbf5e, maybe_const@entry=0x0)
at [...]/source-gcc/gcc/c/c-fold.c:90
#6  0x00595803 in build_modify_expr
(location=location@entry=45810496, lhs=lhs@entry=0x76a49240,
lhs_origtype=lhs_origtype@entry=0x768e4a80,
modifycode=modifycode@entry=NOP_EXPR, rhs_loc=rhs_loc@entry=45818464,
rhs=, rhs@entry=0x76a4a4b0,
rhs_origtype=rhs_origtype@entry=0x768e4a80) at
[...]/source-gcc/gcc/c/c-typeck.c:5697
#7  0x005a674d in c_parser_expr_no_commas
(parser=parser@entry=0x76995000, after=after@entry=0x0,
omp_atomic_lhs=omp_atomic_lhs@entry=0x0) at
[...]/source-gcc/gcc/c/c-parser.c:6313
#8  0x005a6da5 in c_parser_expression
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:8450
#9  0x005a78aa in c_parser_expression_conv
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:8483
#10 0x005be3da in c_parser_statement_after_labels
(parser=parser@entry=0x76995000, if_p=if_p@entry=0x0,
chain=chain@entry=0x0) at [...]/source-gcc/gcc/c/c-parser.c:5285
#11 0x005c034c in c_parser_compound_statement_nostart
(parser=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4859
#12 0x005c0c3f in c_parser_compound_statement
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4694
#13 0x005bfcfd in c_parser_if_body (if_tinfo=...,
if_p=0x7fffc3ff, parser=0x76995000) at
[...]/source-gcc/gcc/c/c-parser.c:5384
#14 c_parser_if_statement (chain=0x0, if_p=0x0, parser=0x76995000) at
[...]/source-gcc/gcc/c/c-parser.c:5502
#15 c_parser_statement_after_labels (parser=parser@entry=0x76995000,
if_p=if_p@entry=0x0, chain=chain@entry=0x0) at
[...]/source-gcc/gcc/c/c-parser.c:5139
#16 0x005c034c in c_parser_compound_statement_nostart
(parser=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4859
#17 0x005c0c3f in c_parser_compound_statement
(parser=parser@entry=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:4694
#18 0x005c2111 in c_parser_declaration_or_fndef
(parser=parser@entry=0x76995000, fndef_ok=fndef_ok@entry=true,
static_assert_ok=static_assert_ok@entry=true, empty_ok=empty_ok@entry=true,
nested=nested@entry=false, start_attr_ok=start_attr_ok@entry=true,
objc_foreach_object_declaration=objc_foreach_object_declaration@entry=0x0,
omp_declare_simd_clauses=..., omp_declare_simd_clauses@entry=...,
oacc_routine_clauses=oacc_routine_clauses@entry=0x0) at
[...]/source-gcc/gcc/c/c-parser.c:2106
#19 0x005cb797 in c_parser_external_declaration
(parser=0x76995000) at [...]/source-gcc/gcc/c/c-parser.c:1550
#20 0x005cc2aa in c_parser_translation_unit (parser=0x76995000)
at [...]/source-gcc/gcc/c/c-parser.c:1431
#21 c_parse_file () at [...]/source-gcc/gcc/c/c-parser.c:17916
#22 0x00630b43 in c_common_parse_file () at
[...]/source-gcc/gcc/c-family/c-opts.c:1064
#23 0x00ae4e9f in compile_file () at

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Calling get_alias_set cannot be avoided here, it eventually gets called via
reference_alias_ptr_type->component_uses_parent_alias_set_from.

So the solution is to excempt TYPE_ALIAS_SET from the hashing.

[Bug fortran/70856] [6/7 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 12 May 2016, tschwinge at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70856
> 
> Thomas Schwinge  changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org,
>||tschwinge at gcc dot gnu.org,
>||vries at gcc dot gnu.org
> 
> --- Comment #3 from Thomas Schwinge  ---
> I had a cursory look at that one.  Differently from PR70857, the ICE triggers
> here the second time that pass_ipa_pta is run (all_late_ipa_passes), and not
> the first one (which is only active if "-fopenacc" is in effect; Tom CCed for
> your information anyway).  This is "fixed" ;-) by reverting the r233734 
> changes
> for PR69951 "[Bug tree-optimization/69951] wrong code at -O1 and above on
> x86_64-linux-gnu":

I figured out that much already.  Now the question is why/how oacc
ends up making sth different the alias target for the decl.  It may
generate a new alias that has the old decl as target but not the
other way around (which is what the assert detects).

Richard.

> 2016-02-26  Richard Biener  
> 
> PR tree-optimization/69551
> * tree-ssa-structalias.c (get_constraint_for_ssa_var): When
> looking through aliases adjust DECL_PT_UID to refer to the
> ultimate alias target.
> 
> --- gcc/tree-ssa-structalias.c
> +++ gcc/tree-ssa-structalias.c
> @@ -2943,6 +2943,14 @@ get_constraint_for_ssa_var (tree t, vec
> *results, bool address_p)
>if (node && node->alias && node->analyzed)
> {
>   node = node->ultimate_alias_target ();
> + /* Canonicalize the PT uid of all aliases to the ultimate 
> target.
> +???  Hopefully the set of aliases can't change in a way that
> +changes the ultimate alias target.  */
> + gcc_assert ((! DECL_PT_UID_SET_P (node->decl)
> +  || DECL_PT_UID (node->decl) == DECL_UID
> (node->decl))
> + && (! DECL_PT_UID_SET_P (t)
> + || DECL_PT_UID (t) == DECL_UID (node->decl)));
> + DECL_PT_UID (t) = DECL_UID (node->decl);
>   t = node->decl;
> }
>  }
> 
> (gdb) call node->debug()
> A.4.3435/10 (A.4) @0x76a7f800
>   Type: variable definition analyzed
>   Visibility: prevailing_def_ironly artificial
>   References: 
>   Referring: A.1.3429/6 (alias)MAIN__/0 (read)
>   Availability: available
>   Varpool flags: initialized used-by-single-function read-only
> const-value-known
> (gdb) call debug_tree(node->decl)
>   type  type  size 
> unit size 
> align 32 symtab 0 alias set 9 canonical type 0x768e6540
> precision 32
> pointer_to_this >
> type_2 DI
> size 
> unit size 
> align 32 symtab 0 alias set 9 canonical type 0x76a91b28
> domain  0x768d1930 integer(kind=8)>
> DI size  unit size  0x768cdbe8 8>
> align 64 symtab 0 alias set -1 canonical type 0x76a91540
> precision 64 min  max  0x76a886d8
> 1>>
> pointer_to_this >
> readonly constant static ignored DI file ../pr70856-z1.f90 line 3 col > 0
> size  unit size 
> align 64 context  initial  0x76a88c00>>
> (gdb) call debug_tree(t)
>   type  type  size 
> unit size 
> align 32 symtab 0 alias set 9 canonical type 0x768e6540
> precision 32
> pointer_to_this >
> type_2 DI
> size 
> unit size 
> align 32 symtab 0 alias set 9 canonical type 0x76a911f8
> domain  0x768d1930 integer(kind=8)>
> DI size  unit size  0x768cdbe8 8>
> align 64 symtab 0 alias set -1 canonical type 0x76a91540
> precision 64 min  max  0x76a886d8
> 1>>
> pointer_to_this >
> readonly constant static ignored DI file ../pr70856-z1.f90 line 2 col > 0
> size  unit size 
> align 64 context >
> 
>

[Bug c++/71095] New: Problem with captureless generic lambda and calling function object with arguments passed by reference

[karol.wozniak at email dot com]

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

Bug ID: 71095
   Summary: Problem with captureless generic lambda and calling
function object with arguments passed by reference
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karol.wozniak at email dot com
  Target Milestone: ---

#include 

struct do_some_stuff_by_ref {
  template  int operator()(T &...) const { return 42; };
};

int main() {
  { // compiles both
//   g++-5 prog.cc -std=c++14
//   g++-6 prog.cc -std=c++14
do_some_stuff_by_ref callable{};
int a = 0;
[callable](auto &&... x) {
  return callable(std::forward(x)...);
}(a);
  }

  { // compiles both
//g++-5 prog.cc -std=c++14
//g++-6 prog.cc -std=c++14
do_some_stuff_by_ref ignore_me{};
int a = 0;
[ignore_me](auto &&... x) {
  (void)ignore_me;
  do_some_stuff_by_ref callable{};
  return callable(std::forward(x)...);
}(a);
  }

  { // compiles
//g++-5 prog.cc -std=c++14
// fails to compile
//g++-6 prog.cc -std=c++14
// prog.cc:40:22: error: no match for call to ‘(do_some_stuff_by_ref)
(int)’
//return callable(std::forward(x)...);
//   ^
int a = 0;
[](auto &&... x) {
  do_some_stuff_by_ref callable{};
  return callable(std::forward(x)...);
}(a);
  }

  return 0;
}

// $ g++-5 --version
// g++-5 (Debian 5.3.1-17) 5.3.1 20160429
//
// $ g++-6 --version
// g++-6 (Debian 6.1.1-1) 6.1.1 20160430

[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-13
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
mine

[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jan Hubicka  ---
mine

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[guido at trentalancia dot net]

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

--- Comment #6 from guido at trentalancia dot net ---
Reported as a RESOLVED FIXED bug in firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1245076