[Bug middle-end/70937] New: [7.0 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 70937
   Summary: [7.0 Regression] ICE: tree code ‘ssa_name’ is not
supported in LTO streams
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

overnight regression in trunk:

> cat bug.f90 
  SUBROUTINE dbcsr_test_read_args(narg, args)
CHARACTER(len=*), DIMENSION(:), &
  INTENT(out) :: args
CHARACTER(len=80) :: line
DO
   args(narg) = line
ENDDO
  END SUBROUTINE dbcsr_test_read_args

> gfortran -flto -c -O0 bug.f90 
bug.f90:8:0: internal compiler error: tree code ‘ssa_name’ is not supported in
LTO streams
   END SUBROUTINE dbcsr_test_read_args

0xa62703 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
../../gcc/gcc/lto-streamer-out.c:676
0xa6338b lto_output_tree(output_block*, tree_node*, bool, bool)
../../gcc/gcc/lto-streamer-out.c:1616
0xa5960d write_global_stream
../../gcc/gcc/lto-streamer-out.c:2415
0xa5960d lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
../../gcc/gcc/lto-streamer-out.c:2462
0xa60fa4 produce_asm_for_decls()
../../gcc/gcc/lto-streamer-out.c:2839
0xacd65f write_lto
../../gcc/gcc/passes.c:2459
0xad08ae ipa_write_summaries_1
../../gcc/gcc/passes.c:2520
0xad08ae ipa_write_summaries()
../../gcc/gcc/passes.c:2580
0x7a6059 ipa_passes
../../gcc/gcc/cgraphunit.c:2310
0x7a6059 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2404
0x7a880d symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2564
Please submit a full bug report,

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[lh_mouse at 126 dot com]

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

--- Comment #2 from lh_mouse  ---
(In reply to Andrew Pinski from comment #1)
> I use relocatable directory feature on Linux but I have not tested 6 yet.  
> This is a driver issue I think ...

I was examining gcc/gcc/incpath.c for problems, though failed to find any, I
think it is worthing mentioning that '-iprefix this_directory_need_not_exist/'
effectively vanished the problem - that is, the order of C and C++ include
paths became correct again.

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|preprocessor|driver

--- Comment #1 from Andrew Pinski  ---
I use relocatable directory feature on Linux but I have not tested 6 yet.  
This is a driver issue I think ...

[Bug preprocessor/70936] New: Hard-coded C++ header paths and relocation problem on Windows

[lh_mouse at 126 dot com]

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

Bug ID: 70936
   Summary: Hard-coded C++ header paths and relocation problem on
Windows
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

The following message is copied from
https://gcc.gnu.org/ml/gcc/2016-05/msg3.html
```

This is a cross-post from gcc-help as there haven't been any replies on
gcc-help since two days ago. Hope someone could help.
```

I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows
today.
Now I have a relocation problem:

Assuming mingw-w64 headers are located in the follow directory,which is, the
native_system_header_dir:
> C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
I have built GCC and it has that hard-coded path.
When I compile something using g++ -v, the headers are searched in the
following paths:
```
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/i686-w64-mingw32
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/backward
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../include
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include-fixed

C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include
End of search list.
```
The C++ headers are searched before any mingw-w64 headers, which is just fine.

However, if I move gcc to another directory, let's say,
C:/this_is_a_new_directory/mingw32/,
then re-compile the same program with g++ -v, the headers are searched in the
following paths:
```
ignoring duplicate directory
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include"
ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include"
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed"
ignoring duplicate directory
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory
"C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../include

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include
 C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1

C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/i686-w64-mingw32
 C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/backward
End of search list.
```
This time the C++ headers are searched after mingw-w64 headers, which causes
the following error:
```
In file included from
C:/MinGW/mingw32/include/c++/6.1.1/ext/string_conversions.h:41:0,
 from
C:/MinGW/mingw32/include/c++/6.1.1/bits/basic_string.h:5402,
 from C:/MinGW/mingw32/include/c++/6.1.1/string:52,
 from
C:/MinGW/mingw32/include/c++/6.1.1/bits/locale_classes.h:40,
 from C:/MinGW/mingw32/include/c++/6.1.1/bits/ios_base.h:41,
 from C:/MinGW/mingw32/include/c++/6.1.1/ios:42,
 from C:/MinGW/mingw32/include/c++/6.1.1/ostream:38,
 from C:/MinGW/mingw32/include/c++/6.1.1/iostream:39,
 from test.cpp:1:
C:/MinGW/mingw32/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No
such file or directory
 #include_next 
 ^
compilation terminated.
```

Do you know how to solve this problem (modifications to gcc source code are
expected)?
Thanks in advance.



--
Best regards,
lh_mouse
2016-05-02

I made some investigation yesterday and here is the result:
```

Diff'ing gcc/libstdc++-v3/include/c_global/cstdlib from gcc-5-branch and
gcc-6-branch gives the following result:
(git diff gcc-5-branch gcc-6-branch -- libstdc++-v3/include/c_global/cstdlib)
```
@@ -69,7 +69,11 @@ namespace std

 #else

-#include 
+// Need to ensure this finds the C library's  not a libstdc++
+// wrapper that might already be installed later in the include search path.
+#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
+#include_next 
+#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

 // Get rid of those macros 

[Bug c++/70925] Vectorized loop segfaults: read exceeds vector boundary

[gentryx at gmx dot de]

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

--- Comment #5 from Andreas Schaefer  ---
@Markus Trippelsdorf interesting, let me check the code once again. Which tool
did you use for this analysis?

[Bug debug/70935] New: [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[asolokha at gmx dot com]

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

Bug ID: 70935
   Summary: [6/7 Regression] ICE: verify_ssa failed (error:
definition in block 9 does not dominate use in block
12) w/ -O3 -g
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 6 and 7 ICE when compiling the following reduced snippet at -O3 (or -Ofast)
w/ -g:

int d0, sj, v0, rp, zi;

void
zn(void)
{
  if (v0 != 0)
{
  int *js, *r3;
  int pm, gc;

  for (gc = 0; gc < 1; ++gc)
{
  sj = 1;
  while (sj != 0)
;
}
  r3 = 
  *js = 
ka:
  for (d0 = 0; d0 < 2; ++d0)
{
  d0 = zi;
  if (zi)
for (pm = 2; pm != 0; --pm)
  ;
}
  while (*r3 != 0)
{
  while (pm)
;
  ++r3;
}
}
  rp = 0;
  goto ka;
}

% gcc-7.0.0-alpha20160501 -c -O3 -g fngq6pkt.c 
fngq6pkt.c: In function 'zn':
fngq6pkt.c:18:11: warning: assignment makes integer from pointer without a cast
[-Wint-conversion]
   *js = 
   ^
fngq6pkt.c:4:1: error: definition in block 9 does not dominate use in block 12
 zn(void)
 ^~
for SSA_NAME: pm.7_34 in statement:
# DEBUG pm => pm.7_34
fngq6pkt.c:4:1: internal compiler error: verify_ssa failed

[Bug libstdc++/70898] Stateful Compare objects are very slow

[gccbugs at jbapple dot com]

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

gccbugs at jbapple dot com changed:

   What|Removed |Added

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

--- Comment #6 from gccbugs at jbapple dot com ---
I'm not sure I agree that this is a duplicate. In particular, 67085 says that
std::priority_queue operations "should not copy comparators". I suggested that
as well in my initial report, but upon a closer reading of the standard, I'm
not sure that would be conformant, since the standard requires
priorityy_queue::push to call std::push_heap, and std::push_heap has to take
its comparator by value.

On the other hand, I do think that copying comparators *fewer* times that
libstdc++ currently does is permitted, and I think it could have a big
performance benefit in some cases.

In particular, though push_heap seems like it must take the comparator by
value, __push_heap is not required to do so. The constructor for
__gnu_cxx::__ops::_Iter_comp_val and the function
__gnu_cxx::__ops::__iter_comp_val also do not have to take their comparators by
value.

[Bug c/70918] Internal compiler error: Illegal instruction

[ljliang1990 at gmail dot com]

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

--- Comment #2 from Liang  ---
Alright Thanks, i'll try to redo the whole LFS.

[Bug target/70928] Load simple float constants via VSX operations on PowerPC

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Can powers of 2 values be generated with a splat followed by a shift?

[Bug target/70934] New: 16-byte atomics are unimplemented on s390x, but __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is defined

[koriakin at 0x04 dot net]

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

Bug ID: 70934
   Summary: 16-byte atomics are unimplemented on s390x, but
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is defined
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koriakin at 0x04 dot net
  Target Milestone: ---

$ cat at128.c
typedef int ti __attribute__((mode(TI)));
ti a, b, c;
int main(void) {
#ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
__sync_val_compare_and_swap(, b, c);
#endif
}
$ gcc at128.c
/tmp/cc1ezNAw.o: In function `main':
at128.c:(.text+0x66): undefined reference to `__sync_val_compare_and_swap_16'
collect2: error: ld returned 1 exit status

[Bug target/70866] powerpc64le -ffixed-cr2 -ffixed-cr3 -ffixed-cr4 ICE

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #2 from Alan Modra  ---
Fixed.

[Bug target/70866] powerpc64le -ffixed-cr2 -ffixed-cr3 -ffixed-cr4 ICE

[amodra at gcc dot gnu.org]

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

--- Comment #1 from Alan Modra  ---
Author: amodra
Date: Tue May  3 23:51:34 2016
New Revision: 235851

URL: https://gcc.gnu.org/viewcvs?rev=235851=gcc=rev
Log:
[RS6000] powerpc64le -ffixed-cr2 -ffixed-cr3 -ffixed-cr4 ICE

gcc/
PR target/70866
* config/rs6000/rs6000.c (rs6000_stack_info): Don't set cr_save_p
when cr2,3,4 are all fixed regs.
gcc/testsuite/
* gcc.target/powerpc/pr70866.c: New.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr70866.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/57193] [4.9/5/6/7 Regression] suboptimal register allocation for SSE registers

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
Author: bernds
Date: Tue May  3 22:48:03 2016
New Revision: 235848

URL: https://gcc.gnu.org/viewcvs?rev=235848=gcc=rev
Log:
PR rtl-optimization/57193
* opts.c (default_options_table): Revert OPT_frename_registers change.
* doc/invoke.texi (-frename-registers, -O2): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c

[Bug c++/70933] New: [7.0 regression] ICE with -Wall on valid code in inchash::add_expr

[j.v.dijk at tue dot nl]

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

Bug ID: 70933
   Summary: [7.0 regression] ICE with -Wall on valid code in
inchash::add_expr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.v.dijk at tue dot nl
  Target Milestone: ---

The reduced testcase at the end of this report makes rev. 235846 of the
compiler ice with -Wall. Maybe related to PR70906.

> g++ -c -Wall declarations.cpp 
declarations.cpp: In instantiation of ‘void test_declarations() [with T =
unsigned int]’:
declarations.cpp:22:30:   required from here
declarations.cpp:17:5: internal compiler error: in add_expr, at tree.c:7928
  T& param = evaluator.declare_parameter("p1")=T(4);
 ^
0x1020896 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7928
0x10202f2 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7997
0x101ff75 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7997
0x101ff75 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7997
0x10202f2 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7997
0x101ff75 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7997
0x10202f2 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
../../gcc-head/gcc/tree.c:7997
0xa9bf68 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc-head/gcc/fold-const.c:2761
0x8ae46a candidate_equal_p
../../gcc-head/gcc/c-family/c-common.c:2926
0x8ae4fb candidate_equal_p
../../gcc-head/gcc/c-family/c-common.c:2926
0x8ae4fb merge_tlist
../../gcc-head/gcc/c-family/c-common.c:2831
0x8b2725 verify_tree
../../gcc-head/gcc/c-family/c-common.c:3135
0x8b66aa verify_sequence_points(tree_node*)
../../gcc-head/gcc/c-family/c-common.c:3159
0x7fa287 finish_expr_stmt(tree_node*)
../../gcc-head/gcc/cp/semantics.c:682
0x699f0d initialize_local_var
../../gcc-head/gcc/cp/decl.c:6428
0x699f0d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-head/gcc/cp/decl.c:6977
0x6cc84f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-head/gcc/cp/pt.c:15216
0x6c8f24 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-head/gcc/cp/pt.c:15105
0x6c9d27 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-head/gcc/cp/pt.c:15290
0x6c697d instantiate_decl(tree_node*, int, bool)
../../gcc-head/gcc/cp/pt.c:22019


jan@linux-pwd6:~/src/gum-cvs/plmathparser/testsuite> cat declarations.cpp 
struct string
{
string(const char*);
};

template 
struct expression_evaluator
{
typedef T result_type;
result_type& declare_parameter(const string& name);
};

template 
void test_declarations()
{
expression_evaluator evaluator;
T& param = evaluator.declare_parameter("p1")=T(4);
}

void foo()
{
test_declarations();
}

[Bug c++/70635] [4.9 Regression] ICE on (and rejects) valid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|paolo at gcc dot gnu.org   |
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |5.4
Summary|[4.9/5 Regression] ICE on   |[4.9 Regression] ICE on
   |(and rejects) valid code on |(and rejects) valid code on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |Segmentation fault (program |Segmentation fault (program
   |cc1plus)|cc1plus)

--- Comment #7 from Paolo Carlini  ---
Fixed for 5.4 too. I'm closing the bug, I don't think we want to fiddle with
gcc-4_9-branch for this kind of issue, at this point.

[Bug c++/70635] [4.9/5 Regression] ICE on (and rejects) valid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May  3 21:44:04 2016
New Revision: 235846

URL: https://gcc.gnu.org/viewcvs?rev=235846=gcc=rev
Log:
/cp
2016-05-03  Paolo Carlini  

PR c++/70635
* pt.c (resolve_typename_type): Fix typos in infinite recursion
avoidance mechanism.

/testsuite
2016-05-03  Paolo Carlini  

PR c++/70635
* g++.dg/parse/pr70635.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/parse/pr70635.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/70932] New: flexible array member with non-trivial destructor

[jens.maurer at gmx dot net]

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

Bug ID: 70932
   Summary: flexible array member with non-trivial destructor
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.maurer at gmx dot net
  Target Milestone: ---

Testcase:

struct A {
  ~A();
};

struct S {
  S() : i(0) { }
  int i;
  A a[];
};


$ g++ -v flex.cc
gcc version 6.1.0 (GCC) 

flex.cc: In constructor ‘S::S()’:
flex.cc:6:12: error: unknown array size in delete


This used to work with gcc 5.x.  (I understand the destructor of A is not
called for a[] here, because the number of elements is unknown.)

[Bug c++/70827] [6/7 regression] dubious use of deleted function in inherited constructor

[jens.maurer at gmx dot net]

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

--- Comment #2 from Jens Maurer  ---
A prominent use case is that std::unique_ptr in the parameter list of an
inherited constructor stops working.

[Bug c++/66561] __builtin_LINE at al. should yield constant expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in 235845 for GCC 7.0.

[Bug c++/66561] __builtin_LINE at al. should yield constant expressions

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue May  3 21:15:28 2016
New Revision: 235845

URL: https://gcc.gnu.org/viewcvs?rev=235845=gcc=rev
Log:
PR c++/66561 - __builtin_LINE at al. should yield constant expressions
PR c++/66639 - declare __func__, __FUNCTION__ & __PRETTY_FUNCTION__ constexpr

gcc/testsuite/ChangeLog:
2016-05-03  Martin Sebor  

PR c++/66561
* c-c++-common/builtin_location.c: New test.
* g++.dg/cpp1y/builtin_location.C: New test.

gcc/cp/ChangeLog:
2016-05-03  Martin Sebor  

PR c++/66561
* tree.c (builtin_valid_in_constant_expr_p): Treat BUILT_IN_FILE,
BUILT_IN_FUNCTION, and BUILT_IN_LINE as constant expressions.

gcc/ChangeLog:
2016-05-03  Martin Sebor  

PR c++/66561
* builtins.c (fold_builtin_FILE): New function.
(fold_builtin_FUNCTION, fold_builtin_LINE): New functions.
(fold_builtin_0): Call them.
* gimplify.c (gimplify_call_expr): Remove the handling of
BUILT_IN_FILE, BUILT_IN_FUNCTION, and BUILT_IN_LINE.

PR c++/66561
* doc/extend.texi (Other Builtins): Update __builtin_FILE,
__builtin_FUNCTION, and __builtin_LINE to reflect they yield
constants.

PR c++/66639
* doc/extend.texi (Function Names as Strings): Update __func__,
__FUNCTION__, __PRETTY_FUNCTION__ to reflect they evaluate to
constants.


Added:
trunk/gcc/testsuite/c-c++-common/builtin_location.c
trunk/gcc/testsuite/g++.dg/cpp1y/builtin_location.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Tue May  3 21:15:28 2016
New Revision: 235845

URL: https://gcc.gnu.org/viewcvs?rev=235845=gcc=rev
Log:
PR c++/66561 - __builtin_LINE at al. should yield constant expressions
PR c++/66639 - declare __func__, __FUNCTION__ & __PRETTY_FUNCTION__ constexpr

gcc/testsuite/ChangeLog:
2016-05-03  Martin Sebor  

PR c++/66561
* c-c++-common/builtin_location.c: New test.
* g++.dg/cpp1y/builtin_location.C: New test.

gcc/cp/ChangeLog:
2016-05-03  Martin Sebor  

PR c++/66561
* tree.c (builtin_valid_in_constant_expr_p): Treat BUILT_IN_FILE,
BUILT_IN_FUNCTION, and BUILT_IN_LINE as constant expressions.

gcc/ChangeLog:
2016-05-03  Martin Sebor  

PR c++/66561
* builtins.c (fold_builtin_FILE): New function.
(fold_builtin_FUNCTION, fold_builtin_LINE): New functions.
(fold_builtin_0): Call them.
* gimplify.c (gimplify_call_expr): Remove the handling of
BUILT_IN_FILE, BUILT_IN_FUNCTION, and BUILT_IN_LINE.

PR c++/66561
* doc/extend.texi (Other Builtins): Update __builtin_FILE,
__builtin_FUNCTION, and __builtin_LINE to reflect they yield
constants.

PR c++/66639
* doc/extend.texi (Function Names as Strings): Update __func__,
__FUNCTION__, __PRETTY_FUNCTION__ to reflect they evaluate to
constants.


Added:
trunk/gcc/testsuite/c-c++-common/builtin_location.c
trunk/gcc/testsuite/g++.dg/cpp1y/builtin_location.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70906] [7 Regression] ice in add_expr, at tree.c:7925

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
--- gcc/tree.c.jj   2016-05-03 10:00:25.0 +0200
+++ gcc/tree.c  2016-05-03 22:56:20.976817150 +0200
@@ -7915,6 +7915,10 @@ add_expr (const_tree t, inchash::hash 
   && integer_zerop (TREE_OPERAND (t, 1)))
inchash::add_expr (TREE_OPERAND (TREE_OPERAND (t, 0), 0),
   hstate, flags);
+  /* Don't ICE on language specific trees.  */
+  else if ((int) code >= NUM_TREE_CODES
+  && (tclass == tcc_constant || tclass == tcc_exceptional))
+   return;
   else
{
  gcc_assert (IS_EXPR_CODE_CLASS (tclass));

should fix this.

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #17 from Martin Sebor  ---
Unassigning myself since I'm not actively working on it anymore.

[Bug libgomp/60670] omp.h may differ between multilibs

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #14 from Francois-Xavier Coudert  ---
Based on libgfortran build machinery, the following patch should be applied to
libgomp:

Index: libgomp/Makefile.am
===
--- libgomp/Makefile.am (revision 235843)
+++ libgomp/Makefile.am (working copy)
@@ -10,7 +10,7 @@ config_path = @config_path@
 search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir)
\
  $(top_srcdir)/../include

-fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude
+fincludedir =
$(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
 libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include

 vpath % $(strip $(search_path))

[Bug libgomp/60670] omp.h may differ between multilibs

[fxcoudert at gcc dot gnu.org]

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

--- Comment #13 from Francois-Xavier Coudert  ---
Showing how the module files are not found when a non default multilib is
chosen:

$ gfortran a.f90 -fopenmp 
$ gfortran a.f90 -fopenmp -m32
a.f90:1:6:

   use omp_lib
  1
Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such
file or directory
compilation terminated.
$ cat a.f90 
  use omp_lib
  end

[Bug tree-optimization/70396] ICE on valid code at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (in immed_wide_int_const, at emit-rtl.c:606)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Hi.

With the updated version of the compiler, I still get the ICE for:

$ cat tc.ii

void fn1() {
  unsigned *a = 0;
  for (int i; i; ++i) {
unsigned g(a[i] << 8 >> 24);
a[i] = g;
  }
}

$ /home/marxin/bin/gcc2/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus
-fpreprocessed tc.ii -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3
-mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2
-msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx -mno-clzero -mno-pku --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192
-mtune=haswell -quiet -dumpbase tc.ii -O3

tc.ii:7:1: internal compiler error: in immed_wide_int_const, at emit-rtl.c:606
 }
 ^
0xa4cf35 immed_wide_int_const(generic_wide_int
const&, machine_mode)
../../gcc/emit-rtl.c:606
0x13929a9 change_zero_ext
../../gcc/combine.c:1
0x13937d8 recog_for_combine
../../gcc/combine.c:11148
0x13a175d try_combine
../../gcc/combine.c:3503
0x13a6fc1 combine_instructions
../../gcc/combine.c:1288
0x13a6fc1 rest_of_handle_combine
../../gcc/combine.c:14348
0x13a6fc1 execute
../../gcc/combine.c:14391

Thanks

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.6.4, 4.7.3
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-05-03
 Ever confirmed|0   |1
Summary|ICE with -g in  |[4.9/5/6/7 Regression] ICE
   |native_encode_initializer,  |with -g in
   |bei dwarf2out.c:17768   |native_encode_initializer,
   ||bei dwarf2out.c:17768
  Known to fail||4.8.5, 4.9.3, 5.3.0, 6.1.0,
   ||7.0

--- Comment #2 from Dominique d'Humieres  ---
The code compiles with 4.6.4 and 4.7.3, but gives an ICE starting with 4.8 up
to trunk (7.0). The change occurred between revision r188694 (2012-06-16,
compiles) and r188914 (2012-06-24, ICE). The only change of dwarf2out.c in this
range is r188874.

[Bug c/70930] New: VLAs in stucts in loop headers are not evaluated each iteration

[ch3root at openwall dot com]

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

Bug ID: 70930
   Summary: VLAs in stucts in loop headers are not evaluated each
iteration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
#include 

int main()
{
  int n, z;

  // (1) `while` with a variably modified array type
  n = 1;
  while ((z = sizeof(char[n])) && n < 10) {
printf("%d ", z);
n++;
  }
  printf("\n");

  // (2) `while` with a variably modified structure type
  n = 1;
  while ((z = sizeof(struct { char a[n]; })) && n < 10) {
printf("%d ", z);
n++;
  }
  printf("\n");

  // (3) an equivalent for the latter with `goto`
  n = 1;
  {
  loop:;
_Bool ctrl_expr = (z = sizeof(struct { char a[n]; })) && n < 10;
if (!ctrl_expr)
  goto after_loop;
{
  printf("%d ", z);
  n++;
}
goto loop;
  }
 after_loop:
  printf("\n");
}
--

Results:

--
$ gcc -std=c11 -Wall -Wextra -O3 test.c && ./a.out
1 2 3 4 5 6 7 8 9 
1 1 1 1 1 1 1 1 1 
1 2 3 4 5 6 7 8 9 
--

gcc version: gcc (GCC) 7.0.0 20160502 (experimental)

The testcase includes three separate tests.

(1) contains a straight VLA in a loop header (inside of sizeof). The output
from this part of the program ("1 2 3 4 5 6 7 8 9 ") shows that it's
reevaluated on each iteration. Fine.

(2) is the same but VLA is wrapped in a struct. The output ("1 1 1 1 1 1 1 1 1
") shows that it's not reevaluated. Not fine.

(3) is AFAICT an equivalent to (2) with respect to blocks, scopes and such. It
works fine.

Thus, it's the combination of loops and VLAs in structs which is broken.

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

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Whereas, these variants compile without problems :


$ cat z2.f90
program p
   type t
  integer :: b(0)
   end type
   type(t), parameter :: z = t([2])
   print *, z
end


$ cat z3.f90
program p
   type t
  integer :: a
  integer :: b(0)
   end type
   type(t), parameter :: z = t(1, 2)
   print *, z
end

[Bug lto/70929] [4.9/5/6/7 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #1 from Jan Hubicka  ---
This patch solves the testcase:
Index: cgraph.c
===
--- cgraph.c(revision 235839)
+++ cgraph.c(working copy)
@@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.
 #include "tree-chkp.h"
 #include "context.h"
 #include "gimplify.h"
+#include "stor-layout.h"

 /* FIXME: Only for PROP_loops, but cgraph shouldn't have to know about this. 
*/
 #include "tree-pass.h"
@@ -3673,25 +3674,24 @@ gimple_check_call_args (gimple *stmt, tr
 {
   for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
{
- tree arg;
  /* If this is a varargs function defer inlining decision
 to callee.  */
  if (!p)
break;
- arg = gimple_call_arg (stmt, i);
+
+ tree arg = gimple_call_arg (stmt, i);
+ tree type = TREE_VALUE (p);
+ if (POINTER_TYPE_P (arg)
+ && pass_by_reference (NULL, TYPE_MODE (type), type, true))
+   type = TREE_TYPE (type);
  if (TREE_VALUE (p) == error_mark_node
  || arg == error_mark_node
- || TREE_CODE (TREE_VALUE (p)) == VOID_TYPE
- || (!types_compatible_p (TREE_VALUE (p), TREE_TYPE (arg))
- && !fold_convertible_p (TREE_VALUE (p), arg)))
+ || TREE_CODE (type) == VOID_TYPE
+ || (!types_compatible_p (type, TREE_TYPE (arg))
+ && !fold_convertible_p (type, arg)))
 return false;
}
 }
-  else
-{
-  if (nargs != 0)
-return false;
-}
   return true;
 }


and may be a resonable fix for release branches (where dropping the  checks
completly seems somewhat risky).
This patch turns:

function not considered for inlining  :3 calls, 7035
freq, 0 count
caller is not optimized   :  313 calls,   313000
freq, 0 count
function body not available   :   169317 calls, 507288718
freq, 0 count
function not inlinable:34230 calls, 14761634
freq, 0 count
function body can be overwritten at link time : 5875 calls,  3060659
freq, 0 count
--param large-function-growth limit reached   : 1310 calls,  4501184
freq, 0 count
--param large-stack-frame-growth limit reached: 5369 calls,  6695641
freq, 0 count
--param max-inline-insns-single limit reached :  131 calls,55952
freq, 0 count
--param max-inline-insns-auto limit reached   :62265 calls, 69467053
freq, 0 count
--param inline-unit-growth limit reached  :39900 calls, 25641347
freq, 0 count
recursive inlining:7 calls,   100428
freq, 0 count
call is unlikely and code size would grow :   624745 calls, 748954066
freq, 0 count
mismatched arguments  :  752 calls,   946732
freq, 0 count
mismatched declarations during linktime optimization:1 calls,  900
freq, 0 count
thunk call:20631 calls, 20631000
freq, 0 count
target specific option mismatch   :   91 calls,88969
freq, 0 count
optimization level attribute mismatch :12371 calls,  3153202
freq, 0 count
callee refers to comdat-local symbols :   20 calls,18065
freq, 0 count
unreachable   :13241 calls,0
freq, 0 count


to:

function not considered for inlining  :3 calls, 7035
freq, 0 count
caller is not optimized   :  313 calls,   313000
freq, 0 count
function body not available   :   169708 calls, 507853259
freq, 0 count
function not inlinable:34230 calls, 14761634
freq, 0 count
function body can be overwritten at link time : 5875 calls,  3060659
freq, 0 count
--param large-function-growth limit reached   : 1310 calls,  4501184
freq, 0 count
--param large-stack-frame-growth limit reached: 5369 calls,  6695641
freq, 0 count
--param max-inline-insns-single limit reached :  131 calls,55952
freq, 0 count
--param max-inline-insns-auto limit reached   :62265 calls, 69467053
freq, 0 count
--param inline-unit-growth limit reached  :39900 calls, 25641347
freq, 0 count
recursive inlining:7 calls,   100428
freq, 0 count
call is unlikely and code size would grow :   624741 calls, 748933088
freq, 0 count
mismatched arguments 

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

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 70931
   Summary: ICE with -g in native_encode_initializer, bei
dwarf2out.c:17768
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Up to now observed only with compile option -g.
Under the hoods possibly related to pr67542.


$ cat z1.f90
program p
   type t
  integer :: a
  integer :: b(0)
   end type
   type(t), parameter :: z = t(1, [2])
   print *, z
end


$ gfortran-6 -g -c z1.f90
internal compiler error: in native_encode_initializer, at dwarf2out.c:17767


$ gfortran-7-20160501 -g z1.f90
internal compiler error: in native_encode_initializer, at dwarf2out.c:17768
0x881dc0 native_encode_initializer
../../gcc/dwarf2out.c:17768
0x881982 native_encode_initializer
../../gcc/dwarf2out.c:17810
0x88ce15 tree_add_const_value_attribute
../../gcc/dwarf2out.c:17852
0x89aaef gen_const_die
../../gcc/dwarf2out.c:21258
0x89aaef gen_decl_die
../../gcc/dwarf2out.c:23404
0x89b82e dwarf2out_decl
../../gcc/dwarf2out.c:23954
0x8b2fc8 dwarf2out_early_global_decl
../../gcc/dwarf2out.c:23627
0x6f9d3b do_traverse_symtree
../../gcc/fortran/symbol.c:3817
0x73eb65 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6328
0x6cabc0 translate_all_program_units
../../gcc/fortran/parse.c:5613
0x6cabc0 gfc_parse_file()
../../gcc/fortran/parse.c:5819
0x70ca32 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:201

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  3 19:30:22 2016
New Revision: 235842

URL: https://gcc.gnu.org/viewcvs?rev=235842=gcc=rev
Log:
PR tree-optimization/70916
* tree-if-conv.c: Include cfganal.h.
(pass_if_conversion::execute): Call connect_infinite_loops_to_exit
and remove_fake_exit_edges around the optimization pass.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> On my environment, the example from comment 0 compiles now without an ICE.

With 6.1.0, I get

[Book15] f90/bug% gfortran pr48776.f90 -std=f95
pr48776.f90:2:18:

 procedure get1
  1
Error: Fortran 2003: PROCEDURE statement at (1)
'
(null):0: confused by earlier errors, bailing out

or

[Book15] f90/bug% gfortran pr48776.f90 -std=f95
pr48776.f90:2:18:

 procedure get1
  1
Error: Fortran 2003: PROCEDURE statement at (1)
pr48776.f90:5:14:

   integer :: h
  1
Error: Procedure 'h' in generic interface 'get' at (1) is neither function nor
subroutine
pr48776.f90:6:13:

   call set1 (get (h))
 1
Error: There is no specific function for the generic 'get' at (1)

So this PR seems to be another instance of non-deterministic error recovery.

[Bug fortran/67542] ICE on initializing type variable with a longer array

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---
If not covered elsewhere, one problem is remaining.
Nondeterministic and depending on used options :


$ cat z4.f90
program p
   character(1), parameter :: a(4) = ['a','b','c','d']
   type t
  integer :: n
  character(2) :: c(3)
   end type
   type(t) :: x = t(4, [a])
   print *, x
end


$ cat z5.f90
program p
   character(1), parameter :: a(4) = ['a','b','c','d']
   type t
  integer :: n
  character(2) :: c(3)
   end type
   type(t) :: x = t(4, [a(1:4)])
   print *, x
end


$ cat z6.f90
program p
   integer :: k
   character(1), parameter :: a(4) = ['a','b','c','d']
   type t
  integer :: n
  character(2) :: c(3)
   end type
   type(t) :: x = t(4, [(a(k),k=1,4)])
   print *, x
end


$ gfortran-6 -O0 -g -Wall -fcheck=all z6.f90
internal compiler error: Segmentation fault


$ gfortran-7-20160501 -g z6.f90
internal compiler error: Segmentation fault
0xbf6ebf crash_signal
../../gcc/toplev.c:333
0x72f8c3 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:4894
0x6f9d3b do_traverse_symtree
../../gcc/fortran/symbol.c:3817
0x73eb65 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6328
0x6cabc0 translate_all_program_units
../../gcc/fortran/parse.c:5613
0x6cabc0 gfc_parse_file()
../../gcc/fortran/parse.c:5819
0x70ca32 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:201

[Bug fortran/67542] ICE on initializing type variable with a longer array

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
The ICE from above is gone a while ago.

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698]

$ gfortran-6 -g -O0 -Wall -fcheck=all z1.f90
z1.f90:6:15:

type(t) :: x = t(1, ['a'])
   1
Warning: Unused variable ‘x’ declared at (1) [-Wunused-variable]
z1.f90:7:15:

type(t) :: y = t(2, ['a', 'b'])
   1
Warning: Unused variable ‘y’ declared at (1) [-Wunused-variable]

---

$ cat z3.f90
program p
   character(1), parameter :: a(4) = ['a','b','c','d']
   type t
  integer :: n
  character(2) :: c(3)
   end type
   type(t) :: x = t(1, a(1:2))
   type(t) :: y = t(2, a(1:4))
   type(t) :: z = t(3, a)
   print *, x
   print *, y
   print *, z
end

$ gfortran-6 -g -O0 -Wall -fcheck=all z3.f90
$ a.out
   1 a b
   2 a b c
   3 a b c

[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
On my environment, the example from comment 0 compiles now without an ICE.

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.1.1 20160502 [gcc-6-branch revision 235698]

$ gfortran-6 -std=f95 pr48776.f90
pr48776.f90:6:18:

 procedure get1
  1
Error: Fortran 2003: PROCEDURE statement at (1)
pr48776.f90:9:14:

   integer :: h
  1
Error: Procedure ‘h’ in generic interface 'get' at (1) is neither function nor
subroutine
pr48776.f90:10:13:

   call set1 (get (h))
 1
Error: There is no specific function for the generic ‘get’ at (1)

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
A variant that aborts with this message directly :

$ gfortran-6 z1.f90
f951: internal compiler error: in gfc_assign_data_value, at fortran/data.c:449

$ cat z1.f90
program p
   type t
  integer :: n
   end type
   type(t), pointer :: z => null()
   data z%n / 3 /
   print *, z%n
end

---

A minimal change of z1.f90 immediately points to pr50410 :

$ cat z2.f90
program p
   type t
  integer :: n
   end type
   type(t), pointer :: z
   data z%n / 3 /
   print *, z%n
end

$ gfortran-6 z2.f90
f951: internal compiler error: in record_reference, at cgraphbuild.c:64

[Bug c++/70906] [7 Regression] ice in add_expr, at tree.c:7925

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 38407
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38407=edit
Reduced test-case

[Bug target/70928] Load simple float constants via VSX operations on PowerPC

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Short sequences for the rest of -32 to 31 are possible also.  The splats can be
done as follows.

x even, x in [-32,-18] U [16,30]:

  vspltis[bhw]  t, x
  vaddu[bhw]m   y, t, t

x odd, x in [17,31]:

  vspltis[bhw]  t, x-16
  vspltis[bhw]  u, -16
  vsubu[bhw]m   y, t, u

x odd, x in [-31,-17]:

  vspltisw  t, x+16
  vspltisw  u, -16
  vadduwm   y, t, u

These can then again be unpacked and converted to floating point.  This may or
may not be preferable to a load, as the dependency chains start to get a bit
long.

[Bug middle-end/59711] ICE in force_constant_size, at gimplify.c:619 with variably-modified return type

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #8 from Alexander Cherepanov  ---
Seems to be fixed in gcc 6.

[Bug lto/70929] New: [4.9/5/6/7 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[hubicka at gcc dot gnu.org]

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

Bug ID: 70929
   Summary: [4.9/5/6/7 regression] Cross-module inlining for
functions having argument passed by reference is no
longer working.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

$ cat a.C
struct s
{
  int a;
  s() {a=1;}
  ~s() {}
};
int t(struct s s);
int main()
{
  s s;
  int v=t(s);
  if (!__builtin_constant_p (v))
__builtin_abort ();
  return 0;
}
$ cat b.C
struct s
{
  int a;
  s() {a=1;}
  ~s() {}
};
int t(struct s s)
{
  return s.a;
}
$ gcc-4.6 -O3 -flto a.C b.C
$ ./a.out
$ /aux/hubicka/trunk-install/bin/gcc -O3 -flto a.C b.C
$ ./a.out
Aborted

[Bug c/70859] Bad column number in type-generic function errors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c/70859] Bad column number in type-generic function errors

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  3 18:03:42 2016
New Revision: 235832

URL: https://gcc.gnu.org/viewcvs?rev=235832=gcc=rev
Log:
PR c/70859
* input.c (expansion_point_location): New function.
* input.h (expansion_point_location): Declare.

* c-common.c (builtin_function_validate_nargs): Add location
parameter.  Use it.
(check_builtin_function_arguments): Add location and arguments
parameters.  Use them.
* c-common.h (check_builtin_function_arguments): Update declaration.

* c-typeck.c (build_function_call_vec): Pass LOC and ARG_LOC down to
check_builtin_function_arguments.

* call.c (build_cxx_call): Pass location and vNULL down to
check_builtin_function_arguments.

* gcc.dg/pr70859.c: New test.
* gcc.dg/pr70859-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70859-2.c
trunk/gcc/testsuite/gcc.dg/pr70859.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/input.c
trunk/gcc/input.h
trunk/gcc/testsuite/ChangeLog

[Bug target/70928] New: Load simple float constants via VSX operations on PowerPC

[meissner at gcc dot gnu.org]

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

Bug ID: 70928
   Summary: Load simple float constants via VSX operations on
PowerPC
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

With Power8 (and to a lesser extent Power7), we can create simple integer
values in VSX registers without doing a load in a few instructions (for example
-16..15 can be loaded with VSPLTIWS and VUPKHSW). If the code wants to use
these simple constants as floating point values, it is probably cheaper to load
the constants as integers and convert them to floating point, rather than
loading the constant from memory.

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

[palves at redhat dot com]

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

--- Comment #5 from Pedro Alves  ---
There's no ambiguous else in sight, the macro is written that way to avoid
dangling if/else problems, and the indentation is correct.  It very much looks
like a false positive to me.

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16be

[kirillnow at gmail dot com]

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

--- Comment #6 from Кирилл  ---
(In reply to Jonathan Wakely from comment #4)
> If you think there's a bug here please provide a testcase that compiles and
> produces an incorrect result.

Here:
#include 
#include 
#include 
#include 

using namespace std;
//-
/** Extensively tested and works.*/
template string my_utf16_to_utf8(const char *s, size_t sz)
{
  uint32_t ucs=0; sz &= ~1; //odd sizes are rounded down
  string rtv; rtv.resize(sz+sz/2);
  char* o=[0];
  for(const uint8_t *i=(uint8_t*)s, *e=i+sz; i18|0xF0; ++o; *o=(ucs>>12 & 0x3F)|0x80; ++o;
*o=(ucs>>6 & 0x3F)|0x80; ++o; *o=(ucs&0x3F)|0x80;
   }
  else
   { *o=ucs>>12|0xE0; ++o; *o=(ucs>>6&0x3F)|0x80; ++o; *o=(ucs&0x3F)|0x80;
}
 }
else
 {
  if(ucs&(~0x7F)) { *o=ucs>>6|0xC0; ++o; *o=(ucs&0x3F)|0x80; }
  else *o = ucs;
 }
//  if((o-[0]>=rtv.size()) throw range_error("utf16_to_utf8()"); //debug
   }
  rtv.resize(o-[0]); rtv.shrink_to_fit();
  return rtv;
}
//-
template inline std::string std_utf16_to_utf8(const char *s, size_t
sz)
{
  using namespace std; sz &= ~1;
  wstring_convert, char16_t>
conv;
  try
   { return conv.to_bytes((const char16_t*)s, (const char16_t*)(s+sz)); }
  catch(...) { return string{}; }
}
//-
int main(int argc, const char** argv)
{
  static constexpr const uint8_t txt_utf16be[] = {
0x01, 0x31, 0x00, 0x6e, 0x00, 0x74, 0x02, 0x59, 0x00, 0x67, 0x00, 0xe6,
0x00, 0x6c, 0x00, 0xe6, 0x00, 0x6b, 0x00, 0x74, 0x01, 0x31, 0x00, 0x63,
0x00, 0x2c, 0x00, 0x20, 0x00, 0x62, 0x00, 0x61, 0x01, 0x31, 0x00, 0x20,
0x00, 0xf0, 0x02, 0x59, 0x00, 0x20, 0x00, 0x62, 0x00, 0x69, 0x02, 0xd0,
0x00, 0x73, 0x00, 0x74, 0x00, 0x69, 0x00, 0x20, 0x00, 0x62, 0x02, 0x54,
0x01, 0x31, 0x00, 0x7a, 0x00, 0x0a, 0x00, 0x0a, 0x00, 0x6c, 0x01, 0x31,
0x00, 0x72, 0x01, 0x31, 0x00, 0x6b, 0x00, 0x73, 0x00, 0x20, 0x00, 0x74,
0x00, 0x72, 0x00, 0xe6, 0x00, 0x6e, 0x00, 0x73, 0x00, 0x6b, 0x00, 0x72,
0x00, 0x61, 0x01, 0x31, 0x00, 0x62, 0x00, 0x64, 0x00, 0x20, 0x01, 0x31,
0x00, 0x6e, 0x00, 0x74, 0x00, 0x75, 0x00, 0x20, 0x00, 0x69, 0x00, 0x70,
0x00, 0x61, 0x00, 0x20, 0x00, 0x6a, 0x00, 0x75, 0x02, 0xd0, 0x00, 0x73,
0x01, 0x31, 0x00, 0x6e, 0x00, 0x67, 0x00, 0x20, 0x00, 0xe6, 0x00, 0x6e,
0x00, 0x20, 0x00, 0x69, 0x02, 0xd0, 0x00, 0x73, 0x00, 0x74, 0x00, 0x20,
0x00, 0x6d, 0x01, 0x31, 0x00, 0x64, 0x00, 0x6c, 0x02, 0x59, 0x00, 0x6e,
0x00, 0x64, 0x00, 0x73, 0x00, 0x20, 0x00, 0xe6, 0x00, 0x6b, 0x00, 0x73,
0x02, 0x59, 0x00, 0x6e, 0x00, 0x74, 0x00, 0x20, 0x00, 0x62, 0x00, 0x61,
0x01, 0x31, 0x00, 0x20, 0x00, 0x72, 0x02, 0x52, 0x00, 0x62, 0x02, 0x59,
0x00, 0x74, 0x00, 0x20, 0x00, 0x62, 0x00, 0x72, 0x00, 0x65, 0x01, 0x31,
0x00, 0x64, 0x00, 0x69, 0x00, 0x0a, 0x00, 0x0a, 0x00, 0x73, 0x02, 0x52,
0x00, 0x72, 0x00, 0x69, 0x00, 0x20, 0x02, 0x59, 0x00, 0x62, 0x00, 0x61,
0x02, 0x8a, 0x00, 0x74, 0x00, 0x20, 0x00, 0xf0, 0x02, 0x59, 0x00, 0x20,
0x00, 0x6c, 0x00, 0xe6, 0x00, 0x6b, 0x00, 0x20, 0x02, 0x59, 0x00, 0x76,
0x00, 0x20, 0x00, 0x73, 0x00, 0x74, 0x00, 0x72, 0x02, 0x5b, 0x00, 0x73,
0x00, 0x20, 0x01, 0x31, 0x00, 0x6e, 0x00, 0x66, 0x02, 0x54, 0x02, 0xd0,
0x00, 0x6d, 0x00, 0x65, 0x01, 0x31, 0x02, 0x83, 0x02, 0x59, 0x00, 0x6e,
0x00, 0x2c, 0x00, 0x20, 0x00, 0x62, 0x02, 0x8c, 0x00, 0x74, 0x00, 0x20,
0x00, 0x73, 0x01, 0x31, 0x00, 0x6e, 0x00, 0x73, 0x00, 0x20, 0x00, 0xf0,
0x01, 0x31, 0x00, 0x73, 0x00, 0x20, 0x01, 0x31, 0x00, 0x7a, 0x00, 0x20,
0x02, 0x59, 0x00, 0x20, 0x00, 0x72, 0x00, 0xe6, 0x00, 0x70, 0x00, 0x20,
0x01, 0x31, 0x00, 0x74, 0x00, 0x20, 0x00, 0x77, 0x02, 0x8c, 0x00, 0x64,
0x02, 0x59, 0x00, 0x6e, 0x00, 0x74, 0x00, 0x20, 0x00, 0x62, 0x00, 0x69,
0x00, 0x20, 0x00, 0x0a, 0x00, 0x6d, 0x02, 0x8c, 0x02, 0xa7, 0x00, 0x20,
0x00, 0x6a, 0x00, 0x75, 0x02, 0xd0, 0x00, 0x73, 0x00, 0x0a, 0x00, 0x0a,
};
  constexpr size_t txt_sz = (sizeof txt_utf16be)/(sizeof txt_utf16be[0]);
  cout << "My conversion: " << endl;
  cout << my_utf16_to_utf8((char*)txt_utf16be, txt_sz) << endl;
  cout << "Codecvt conversion: " << endl;
  cout << std_utf16_to_utf8((char*)txt_utf16be, txt_sz);
  return 0;
}

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
To fix this in the C FE, we need to pass around boolean saying whether the
location is from_macro_expansion_at...

But dunno, do we really want to *not* warn for this? :(

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16be

[kirillnow at gmail dot com]

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

--- Comment #5 from Кирилл  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Кирилл from comment #2)
> > ...
> > Just realized its wrong endianness problem. 
> > codecvt_utf8_utf16 should assume utf16be by default, right? Apparently, no.
> 
> No. It works with the native endianness of the system, if I understand the
> spec correctly. i.e. it's for converting between UTF-8 and in-memory UTF-16
> sequences using the native endianness. But the spec is a total mess.

It makes no sense, because you can explicitly specify little_endian in the
template parameters, but not big_endian.

[Bug libgomp/60670] omp.h may differ between multilibs

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||fxcoudert at gcc dot gnu.org

--- Comment #12 from Francois-Xavier Coudert  ---
The Fortran module files are not installed in the right place, and that leads
to error upon compilation of valid user code (not finding the module files).

$ ls /usr/local/gfortran/lib/**/libgomp.dylib
/usr/local/gfortran/lib/i386/libgomp.dylib
/usr/local/gfortran/lib/libgomp.dylib

$ ls /usr/local/gfortran/lib/**/omp_lib.mod  
/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0/finclude/omp_lib.mod


It’s because the Makefile machinery is wrong. libgomp/Makefile.am has:

fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude

while the corresponding libgfortran has:

fincludedir =
$(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude

notice the extra $(MULTISUBDIR).

[Bug libgomp/53600] Fatal Error: Can't open module file 'omp_lib.mod' for reading at (1).

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from Francois-Xavier Coudert  ---
These two bugs are unrelated: comment #1 is about user code not compiling, and
is probably related to the compilation architecture (Makefile? script?)

The original bug was reported in 2012 and has not been confirmed there. cygwin
binaries from other sources are fine, so I am closing this for now.

Please reopen with additional information if someone can still see and
reproduce the bug.

[Bug target/70927] avx512dq instructions emitted even with -mavx512vl -mno-avx512dq

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 38406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38406=edit
gcc7-pr70927.patch

Untested fix.

[Bug target/70927] avx512dq instructions emitted even with -mavx512vl -mno-avx512dq

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-03
 CC||kyukhin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |6.2
 Ever confirmed|0   |1

[Bug target/70927] New: avx512dq instructions emitted even with -mavx512vl -mno-avx512dq

[jakub at gcc dot gnu.org]

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

Bug ID: 70927
   Summary: avx512dq instructions emitted even with -mavx512vl
-mno-avx512dq
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#include 

void
f1 (__m128 x, __m128 y)
{
  register __m128 a __asm ("xmm16"), b __asm ("xmm17");
  a = x; b = y;
  asm volatile ("" : "+v" (a), "+v" (b));
  a = _mm_and_ps (a, b);
  asm volatile ("" : "+v" (a));
}

void
f2 (__m128d x, __m128d y)
{
  register __m128d a __asm ("xmm16"), b __asm ("xmm17");
  a = x; b = y;
  asm volatile ("" : "+v" (a), "+v" (b));
  a = _mm_and_pd (a, b);
  asm volatile ("" : "+v" (a));
}

void
f3 (__m256 x, __m256 y)
{
  register __m256 a __asm ("xmm16"), b __asm ("xmm17");
  a = x; b = y;
  asm volatile ("" : "+v" (a), "+v" (b));
  a = _mm256_and_ps (a, b);
  asm volatile ("" : "+v" (a));
}

void
f4 (__m256d x, __m256d y)
{
  register __m256d a __asm ("xmm16"), b __asm ("xmm17");
  a = x; b = y;
  asm volatile ("" : "+v" (a), "+v" (b));
  a = _mm256_and_pd (a, b);
  asm volatile ("" : "+v" (a));
}

emits with -O2 -mavx512vl -mno-avx512dq various AVX512DQ instructions.

[Bug c/63944] [DR#413] Partial overriding of nonconstant struct/union initializers with designated initializers

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
That's using the extension of allowing compound literals in static 
initializers.  Given that extension, we should fix such cases as well.

[Bug c/63944] [DR#413] Partial overriding of nonconstant struct/union initializers with designated initializers

[ch3root at openwall dot com]

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

--- Comment #5 from Alexander Cherepanov  ---
Not sure this is relevant to static/automatic distinction mentioned above but
the following code uses a static struct, is accepted by gcc and exposes the
problem:

--
#include 

static struct s {
  struct sub {
int x, y;
  } sub;
} s = (struct s){ (struct sub){1, 2}, .sub.y = 3 };

int main()
{
  printf("%d %d\n", s.sub.x, s.sub.y);
}
--

[Bug tree-optimization/69196] [5/6/7 Regression] code size regression with jump threading at -O2

[law at redhat dot com]

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

--- Comment #26 from Jeffrey A. Law  ---
I'm planning to keep it open until I add the code to factor FSM path clones
with differing entry edges into a single FSM path clone.  At that time we'll
want to look at this (and other) BZs to ensure that we've got the tuning nailed
down.

[Bug c/63944] [DR#413] Partial overriding of nonconstant struct/union initializers with designated initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
This might be a hard nut to crack, but I'll give it a shot.

[Bug rtl-optimization/70890] [7 regression] r235660 miscompiles stage2 compiler on ia64

[amodra at gcc dot gnu.org]

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

--- Comment #7 from Alan Modra  ---
Author: amodra
Date: Tue May  3 14:43:35 2016
New Revision: 235825

URL: https://gcc.gnu.org/viewcvs?rev=235825=gcc=rev
Log:
PR70890, stage2 miscompilation

PR rtl-optimization/70890
* ira.c (combine_and_move_insns): When moving def_insn, remove
equivs on use_insn.

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

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2016-04-29 00:00:00 |2016-05-03
 Ever confirmed|0   |1

--- Comment #16 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to H.J. Lu from comment #14)
> 
> > We need to disable
> > 
> > define_split
> >   [(set (match_operand 0 "any_fp_register_operand")
> > (float_extend (match_operand 1 "memory_operand")))]
> >   "reload_completed
> >&& (GET_MODE (operands[0]) == TFmode
> >|| GET_MODE (operands[0]) == XFmode
> >|| GET_MODE (operands[0]) == DFmode)"
> >   [(set (match_dup 0) (match_dup 2))]
> > {
> > 
> > for SF->DF.
> Why? This splitter will eventually result in a move of 0.0 to a SSE register.

This splitter is placed before the one we want.  We have quite
a few similar splitters far apart and we lose the track.  This
patch:

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 940dc20..dc46b16 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3615,6 +3615,35 @@
 FAIL;
 })

+;; Break partial reg stall for cvtss2sd.
+
+(define_split
+  [(set (match_operand:DF 0 "register_operand")
+(float_extend:DF
+  (match_operand:SF 1 "nonimmediate_operand")))]
+  "TARGET_SSE2 && TARGET_SSE_MATH
+   && TARGET_SSE_PARTIAL_REG_DEPENDENCY
+   && epilogue_completed
+   && optimize_function_for_speed_p (cfun)
+   && SSE_REG_P (operands[0])
+   && (!SSE_REG_P (operands[1])
+   || REGNO (operands[0]) != REGNO (operands[1]))
+   && (!EXT_REX_SSE_REG_P (operands[0])
+   || TARGET_AVX512VL)"
+  [(set (match_dup 0)
+(vec_merge:V2DF
+  (float_extend:V2DF
+(vec_select:V2SF
+  (match_dup 1)
+  (parallel [(const_int 0) (const_int 1)])))
+  (match_dup 0)
+  (const_int 1)))]
+{
+  operands[0] = lowpart_subreg (V2DFmode, operands[0], DFmode);
+  operands[1] = lowpart_subreg (V4SFmode, operands[1], SFmode);
+  emit_move_insn (operands[0], CONST0_RTX (V2DFmode));
+})
+
 (define_split
   [(set (match_operand 0 "any_fp_register_operand")
(float_extend (match_operand 1 "memory_operand")))]

works for me.

[Bug c/70921] Initializer for sub-sub-object overrides whole initializer for sub-object

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
See my suggestions in bug 63944 of possible approaches for a fix.

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

[Bug c/63944] [DR#413] Partial overriding of nonconstant struct/union initializers with designated initializers

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #3 from Joseph S. Myers  ---
*** Bug 70921 has been marked as a duplicate of this bug. ***

[Bug preprocessor/70917] out-of-date documentation for character set support and environment variables

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Cf what I said in :

I think we should clearly update the documentation to reflect reality 
regarding source file encoding, and leave it strictly for wrappers such as 
"c99" to specify -finput-charset= options rather than leaving open the 
possibility that GCC's own default might change in future.

[Bug c++/70906] [7 Regression] ice in add_expr, at tree.c:7925

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Having the same issue in Inkscape, reduction has been started.

Martin

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu  ---
(In reply to Bernd Schmidt from comment #19)
> > This splitter is placed before the one we want.  We have quite
> > a few similar splitters far apart and we lose the track.  This
> > patch:
> > 
> > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> > index 940dc20..dc46b16 100644
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -3615,6 +3615,35 @@
> >  FAIL;
> >  })
> >  
> > +;; Break partial reg stall for cvtss2sd.
> > +
> > +(define_split
> > +  [(set (match_operand:DF 0 "register_operand")
> > +(float_extend:DF
> ...]
> 
> > works for me.
> 
> Did you mean to move the existing one rather than add a copy?

Yes.

> I don't know what you're trying to tell me with the two followup messages
> after this.

We should exam those split/peephole patterns to check if their placements
and conditions are correct.

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[bernds at gcc dot gnu.org]

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

--- Comment #19 from Bernd Schmidt  ---
> This splitter is placed before the one we want.  We have quite
> a few similar splitters far apart and we lose the track.  This
> patch:
> 
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 940dc20..dc46b16 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -3615,6 +3615,35 @@
>  FAIL;
>  })
>  
> +;; Break partial reg stall for cvtss2sd.
> +
> +(define_split
> +  [(set (match_operand:DF 0 "register_operand")
> +(float_extend:DF
...]

> works for me.

Did you mean to move the existing one rather than add a copy?

I don't know what you're trying to tell me with the two followup messages after
this.

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  ---
There are

;; %%% Kill these when call knows how to work out a DFmode push earlier.
(define_split
  [(set (match_operand:DF 0 "push_operand")
(float_extend:DF (match_operand:SF 1 "fp_register_operand")))]
  "reload_completed"
  [(set (reg:P SP_REG) (plus:P (reg:P SP_REG) (const_int -8))) 
   (set (mem:DF (reg:P SP_REG)) (float_extend:DF (match_dup 1)))])

define_split
  [(set (match_operand:DF 0 "register_operand")
(float_extend:DF
  (match_operand:SF 1 "nonimmediate_operand")))]
  "TARGET_USE_VECTOR_FP_CONVERTS
   && optimize_insn_for_speed_p ()
   && reload_completed && SSE_REG_P (operands[0])
   && (!EXT_REX_SSE_REG_P (operands[0])
   || TARGET_AVX512VL)"

;; It's more profitable to split and then extend in the same register.
(define_peephole2
  [(set (match_operand:DF 0 "register_operand")
(float_extend:DF
  (match_operand:SF 1 "memory_operand")))]
  "TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS
   && optimize_insn_for_speed_p ()
   && SSE_REG_P (operands[0])"
  [(set (match_dup 2) (match_dup 1))
   (set (match_dup 0) (float_extend:DF (match_dup 2)))]
  "operands[2] = gen_rtx_REG (SFmode, REGNO (operands[0]));")

[Bug target/67763] [SH] Redirect conditional branches

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
A similar case in compiler/cg.c:

L52:
mov.l   @r9+,r8
tst r8,r8
bf/s.L57
cmp/eq  r11,r9
bra .L69
nop
.align 1
.L54:
mov.l   @r8,r8
tst r8,r8
bt/s.L69
cmp/eq  r11,r9
.L57:
mov.l   @(4,r8),r0
cmp/eq  #3,r0
bf  .L54
jsr @r10
mov r8,r4
mov.l   @r8,r8
tst r8,r8
bf/s.L57
cmp/eq  r11,r9
.align 2
.L69:   
bf  .L52
mov.l   .L66,r4

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
For float_truncate,

(define_split
  [(set (match_operand:SF 0 "register_operand")
(float_truncate:SF
  (match_operand:DF 1 "nonimmediate_operand")))]
  "TARGET_USE_VECTOR_FP_CONVERTS
   && optimize_insn_for_speed_p ()
   && reload_completed && SSE_REG_P (operands[0])
   && (!EXT_REX_SSE_REG_P (operands[0])
   || TARGET_AVX512VL)"

;; It's more profitable to split and then extend in the same register.
(define_peephole2
  [(set (match_operand:SF 0 "register_operand")
(float_truncate:SF
  (match_operand:DF 1 "memory_operand")))]
  "TARGET_SPLIT_MEM_OPND_FOR_FP_CONVERTS
   && optimize_insn_for_speed_p ()
   && SSE_REG_P (operands[0])"
  [(set (match_dup 2) (match_dup 1))
   (set (match_dup 0) (float_truncate:SF (match_dup 2)))]
  "operands[2] = gen_rtx_REG (DFmode, REGNO (operands[0]));")

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #14)

> We need to disable
> 
> define_split
>   [(set (match_operand 0 "any_fp_register_operand")
> (float_extend (match_operand 1 "memory_operand")))]
>   "reload_completed
>&& (GET_MODE (operands[0]) == TFmode
>|| GET_MODE (operands[0]) == XFmode
>|| GET_MODE (operands[0]) == DFmode)"
>   [(set (match_dup 0) (match_dup 2))]
> {
> 
> for SF->DF.
Why? This splitter will eventually result in a move of 0.0 to a SSE register.

[Bug target/70903] [4.9/5/6/7 Regression] wrong code with bfi @ aarch64 with -Os

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Basically at expand time we're expanding:

  vector(32) unsigned char _4;
  unsigned char _5;
  _3 = {65535, _2};
  _4 = VIEW_CONVERT_EXPR(_3);
  _5 = BIT_FIELD_REF <_4, 8, 8>;

and we're getting:
(insn 17 16 18 (set (subreg:DI (reg:OI 91 [ D.2757 ]) 0)
(const_int 65535 [0x])) bfi.c:7 -1
 (nil))

(insn 18 17 19 (set (subreg:DI (reg:OI 91 [ D.2757 ]) 8)
(subreg:DI (reg/v:OI 84 [ x ]) 0)) bfi.c:7 -1
 (nil))

(insn 19 18 20 (set (subreg:DI (reg:QI 94) 0)
(zero_extract:DI (subreg:DI (reg:OI 91 [ D.2757 ]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8]))) bfi.c:7 -1
 (nil))

(insn 20 19 21 (set (reg:DI 95)
(subreg:DI (reg:QI 94) 0)) bfi.c:7 -1
 (nil))


the various RTL optimizers propagate the 65535 through the subregs and
zero-extracts and it ends up as -1 (0x) in reg 95.

I'm not sure what path during expand expands this operation, but the subreg on
insn 20 is probably wrong, as we do care about the bits beyond QImode, we want
a zero_extend.

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #12)

> I still see:
> 
>   vcvtss2sd   (%ecx,%eax,4), %xmm5, %xmm5
> 
> without vxorpd.

Maybe vxorpd gets scheduled away from the insn? What is the name of the
pattern?

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to H.J. Lu from comment #12)
> 
> > I still see:
> > 
> > vcvtss2sd   (%ecx,%eax,4), %xmm5, %xmm5
> > 
> > without vxorpd.
> 
> Maybe vxorpd gets scheduled away from the insn? What is the name of the
> pattern?

We need to disable

define_split
  [(set (match_operand 0 "any_fp_register_operand")
(float_extend (match_operand 1 "memory_operand")))]
  "reload_completed
   && (GET_MODE (operands[0]) == TFmode
   || GET_MODE (operands[0]) == XFmode
   || GET_MODE (operands[0]) == DFmode)"
  [(set (match_dup 0) (match_dup 2))]
{

for SF->DF.

[Bug c++/70925] Vectorized loop segfaults: read exceeds vector boundary

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
Looks invalid:

libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:117: runtime error: store to
misaligned address 0x022081ec for type 'double', which requires 8 byte
alignment
0x022081ec: note: pointer points here
  01 01 01 01 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:287: runtime error: store to
misaligned address 0x02208692 for type 'struct Coord', which requires 4
byte alignment
0x02208692: note: pointer points here
 00 e8  88 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
00  00 00 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:113: runtime error: store to
misaligned address 0x0220876a for type 'struct CoordBox', which requires 4
byte alignment
0x0220876a: note: pointer points here
 05 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
00  00 00 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:120: runtime error: store to
misaligned address 0x0220891a for type 'unsigned int', which requires 4
byte alignment
0x0220891a: note: pointer points here
 0a 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
00  00 00 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:117: runtime error: load of
misaligned address 0x022081ec for type 'const double', which requires 8
byte alignment
0x022081ec: note: pointer points here
  01 01 01 01 00 00 00 00  00 c0 7b 40 00 00 00 00  00 d0 7b 40 00 00 00 00  00
e0 7b 40 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:435:38: runtime error: reference
binding to misaligned address 0x02208692 for type 'const struct Coord',
which requires 4 byte alignment
0x02208692: note: pointer points here
 00 e8  88 40 02 00 00 00 05 00  00 00 05 00 00 00 03 00  00 00 05 00 00 00 05
00  00 00 04 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:435:20: runtime error: load of
misaligned address 0x02208692 for type 'const struct Coord', which requires
4 byte alignment
0x02208692: note: pointer points here
 00 e8  88 40 02 00 00 00 05 00  00 00 05 00 00 00 03 00  00 00 05 00 00 00 05
00  00 00 04 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:118: runtime error:
reference binding to misaligned address 0x0220876a for type 'const struct
CoordBox', which requires 4 byte alignment
0x0220876a: note: pointer points here
 05 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 1e 00  00 00 14 00 00 00 0a
00  00 00 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:93: runtime error: load of
misaligned address 0x0220876a for type 'const struct CoordBox', which
requires 4 byte alignment
0x0220876a: note: pointer points here
 05 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 1e 00  00 00 14 00 00 00 0a
00  00 00 00 00 00 00
  ^ 
libgeodecomp4/src/libgeodecomp/misc/testcell.h:415:120: runtime error: load of
misaligned address 0x0220891a for type 'const unsigned int', which requires
4 byte alignment
0x0220891a: note: pointer points here

[Bug c++/70926] New: Libiberty Demangler segfaults (5)

[boehme.marcel at gmail dot com]

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

Bug ID: 70926
   Summary: Libiberty Demangler segfaults (5)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boehme.marcel at gmail dot com
  Target Milestone: ---

A write access violation on destination operand in the libiberty demangler
causes its host applications to crash. There are also two other read access
violations on source operand that are caused by the same problem (overflow when
parsing a number).

How to reproduce:
$valgrind c++filt 0__Ot2m02R5T50
==86038== Invalid read of size 1
==86038==at 0x752150: do_type (cplus-dem.c:3729)
==86038==by 0x7640F5: do_arg (cplus-dem.c:4239)
==86038==by 0x7659D7: demangle_args (cplus-dem.c:4528)
==86038==by 0x778425: demangle_signature (cplus-dem.c:1645)
==86038==by 0x784701: internal_cplus_demangle (cplus-dem.c:1204)
==86038==by 0x74F572: cplus_demangle (cplus-dem.c:887)
==86038==by 0x406251: demangle_it (cxxfilt.c:62)
==86038==by 0x40582E: main (cxxfilt.c:227)

$ valgrind c++filt 0__GT500_
==10196== Invalid read of size 8
==10196==at 0x7519A7: do_type (cplus-dem.c:3623)
==10196==by 0x763DB5: do_arg (cplus-dem.c:4249)
==10196==by 0x76568F: demangle_args (cplus-dem.c:4538)
==10196==by 0x778825: demangle_signature (cplus-dem.c:1653)
==10196==by 0x784961: internal_cplus_demangle (cplus-dem.c:1210)
==10196==by 0x74F582: cplus_demangle (cplus-dem.c:893)
==10196==by 0x406251: demangle_it (cxxfilt.c:62)
==10196==by 0x40582E: main (cxxfilt.c:227)

$ valgrind c++filt __t2m05B50_
==13052== Invalid read of size 8
==13052==at 0x7541FF: do_type (cplus-dem.c:3798)
==13052==by 0x76B2B3: demangle_template.constprop.15 (cplus-dem.c:2241)
==13052==by 0x7761B7: demangle_signature (cplus-dem.c:1573)
==13052==by 0x784811: internal_cplus_demangle (cplus-dem.c:1210)
==13052==by 0x74F582: cplus_demangle (cplus-dem.c:893)
==13052==by 0x406251: demangle_it (cxxfilt.c:62)
==13052==by 0x40582E: main (cxxfilt.c:227)

Analysis: The demangler reads sometimes the value of an array index from the
mangled string. Now, it is checked whether it exceeds the array length.
However, the parsing can cause an overflow and the index is negative.

This vulnerability was found with a more efficient version of AFL.
I am preparing a patch.

[Bug c++/70925] Vectorized loop segfaults: read exceeds vector boundary

[gentryx at gmx dot de]

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

--- Comment #3 from Andreas Schaefer  ---
Output of -v below:

gentryx@neuromancer ~ $ LANG=en g++-5.3.0 test_lfa_lgd.ii -v -o test -O3
-march=native -fno-strict-aliasing -fwrapv -std=c++11 && ./test
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-5.3.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.3.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--enable-lto --without-isl --enable-libsanitizer
Thread model: posix
gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5) 
COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-O3' '-march=native'
'-fno-strict-aliasing' '-fwrapv' '-std=c++11' '-shared-libgcc'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1plus -fpreprocessed
test_lfa_lgd.ii -march=broadwell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2
-msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx
-mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd
-mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq
-mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb
-mno-pcommit -mno-mwaitx --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=6144 -mtune=generic -quiet -dumpbase test_lfa_lgd.ii
-auxbase test_lfa_lgd -O3 -std=c++11 -version -fno-strict-aliasing -fwrapv
-fstack-protector-strong -o /tmp/ccM4vnw7.s
GNU C++11 (Gentoo 5.3.0 p1.0, pie-0.6.5) version 5.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.3
warning: MPFR header version 3.1.3-p4 differs from library version 3.1.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (Gentoo 5.3.0 p1.0, pie-0.6.5) version 5.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.3
warning: MPFR header version 3.1.3-p4 differs from library version 3.1.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 920cffacca9080f34bc3ca7962bbc82b
COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-O3' '-march=native'
'-fno-strict-aliasing' '-fwrapv' '-std=c++11' '-shared-libgcc'
 /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/as
-v --64 -o /tmp/ccab7hZd.o /tmp/ccM4vnw7.s
GNU assembler version 2.25.1 (x86_64-pc-linux-gnu) using BFD version (Gentoo
2.25.1 p1.1) 2.25.1
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'test' '-O3' '-march=native'
'-fno-strict-aliasing' '-fwrapv' '-std=c++11' '-shared-libgcc'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/collect2 -plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccOcRXvk.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
test /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crt1.o

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Bernd Schmidt from comment #10)
> Looks to me like epilogue_completed would be a good predicate. I'll put the
> following in a bootstrap, let me know if you're OK with this patch.
> 
> Index: i386.md
> ===
> --- i386.md   (revision 235808)
> +++ i386.md   (working copy)
> @@ -5196,12 +5196,13 @@ (define_split
>  
>  ;; Break partial reg stall for cvtsd2ss.
>  
> -(define_peephole2
> +(define_split
>[(set (match_operand:SF 0 "register_operand")
>  (float_truncate:SF
> (match_operand:DF 1 "nonimmediate_operand")))]
>"TARGET_SSE2 && TARGET_SSE_MATH
> && TARGET_SSE_PARTIAL_REG_DEPENDENCY
> +   && epilogue_completed
> && optimize_function_for_speed_p (cfun)
> && SSE_REG_P (operands[0])
> && (!SSE_REG_P (operands[1])
> @@ -5223,13 +5224,14 @@ (define_peephole2
>  
>  ;; Break partial reg stall for cvtss2sd.
>  
> -(define_peephole2
> +(define_split
>[(set (match_operand:DF 0 "register_operand")
>  (float_extend:DF
>(match_operand:SF 1 "nonimmediate_operand")))]
>"TARGET_SSE2 && TARGET_SSE_MATH
> && TARGET_SSE_PARTIAL_REG_DEPENDENCY
> +   && epilogue_completed
> && optimize_function_for_speed_p (cfun)
> && SSE_REG_P (operands[0])
> && (!SSE_REG_P (operands[1])
> || REGNO (operands[0]) != REGNO (operands[1]))

I still see:

vcvtss2sd   (%ecx,%eax,4), %xmm5, %xmm5

without vxorpd.

[Bug target/70903] [4.9/5/6/7 Regression] wrong code with bfi @ aarch64 with -Os

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Although, that seems to be exposing something else that's fishy, looking at the
combine dumps I see it combining:
(insn 19 42 20 2 (set (subreg:DI (reg:QI 94) 0)
(const_int 255 [0xff])) bfi.c:7 50 {*movdi_aarch64}
 (nil))
(insn 20 19 21 2 (set (reg:DI 95)
(subreg:DI (reg:QI 94) 0)) bfi.c:7 50 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:QI 94)
(expr_list:REG_EQUAL (const_int 255 [0xff])
(nil

into:

(insn 20 19 21 2 (set (reg:DI 95)
(const_int -1 [0x])) bfi.c:7 50 {*movdi_aarch64}
 (expr_list:REG_EQUAL (const_int 255 [0xff])
(nil)))

That's where the -1 comes from. Need to see why the reg94 := 255 was
represented that way (with a subreg)

[Bug tree-optimization/70841] reassoc fails to handle FP division

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #2 from kugan at gcc dot gnu.org ---
Created attachment 38405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38405=edit
prototype patch

Untested prototype patch.

[Bug target/70903] [4.9/5/6/7 Regression] wrong code with bfi @ aarch64 with -Os

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
-fno-rerun-cse-after-loop "fixes" the tescase. cse2 is where it starts to go
wrong

[Bug target/70903] [4.9/5/6/7 Regression] wrong code with bfi @ aarch64 with -Os

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-03
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-03
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think this is the x + x -> 2 * x canonicalization we now perform.  That's bad
when the target cannot vectorize integer multiplication.

We have vect_recog_mult_pattern that should have triggered here but that
only tries replacement with LSHIFT_EXPR rather than also a simple plus
for 2 * x.

Likely caused by

2016-04-26  Marc Glisse  

* genmatch.c (write_predicate): Add ATTRIBUTE_UNUSED.
* fold-const.c (fold_binary_loc): Remove 2 transformations
superseded by match.pd.
* match.pd (x+x -> x*2): Generalize to integers.

[Bug c++/70925] Vectorized loop segfaults: read exceeds vector boundary

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Please show the output when you append -v to the command-line (to tell us
what -march=native expands to for you)

[Bug rtl-optimization/70467] Useless "and [esp],-1" emitted on AND with uint64_t variable

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  3 11:45:04 2016
New Revision: 235816

URL: https://gcc.gnu.org/viewcvs?rev=235816=gcc=rev
Log:
PR rtl-optimization/70467
* config/i386/predicates.md (x86_64_hilo_int_operand,
x86_64_hilo_general_operand): New predicates.
* config/i386/constraints.md (Wd): New constraint.
* config/i386/i386.md (mode attr di): Use Wd instead of e.
(general_hilo_operand): New mode attr.
(add3, sub3): Use 
instead of .
(*add3_doubleword, *sub3_doubleword): Use
x86_64_hilo_general_operand instead of .

* gcc.target/i386/pr70467-3.c: New test.
* gcc.target/i386/pr70467-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70467-3.c
trunk/gcc/testsuite/gcc.target/i386/pr70467-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  3 11:43:06 2016
New Revision: 235815

URL: https://gcc.gnu.org/viewcvs?rev=235815=gcc=rev
Log:
PR tree-optimization/70916
* tree-if-conv.c (constant_or_ssa_name): Removed.
(fold_build_cond_expr): Use is_gimple_val instead of
constant_or_ssa_name.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-if-conv.c

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  3 11:38:38 2016
New Revision: 235814

URL: https://gcc.gnu.org/viewcvs?rev=235814=gcc=rev
Log:
PR tree-optimization/70916
* tree-vect-patterns.c (vect_recog_mask_conversion_pattern): Give up
if COND_EXPR rhs1 is neither SSA_NAME nor COMPARISON_CLASS_P.

* gcc.c-torture/compile/pr70916.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70916.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  3 11:37:25 2016
New Revision: 235813

URL: https://gcc.gnu.org/viewcvs?rev=235813=gcc=rev
Log:
PR target/49244
* tree-ssa-ccp.c: Include stor-layout.h and optabs-query.h.
(optimize_atomic_bit_test_and): New function.
(pass_fold_builtins::execute): Use it.
* optabs.def (atomic_bit_test_and_set_optab,
atomic_bit_test_and_complement_optab,
atomic_bit_test_and_reset_optab): New optabs.
* internal-fn.def (ATOMIC_BIT_TEST_AND_SET,
ATOMIC_BIT_TEST_AND_COMPLEMENT, ATOMIC_BIT_TEST_AND_RESET): New ifns.
* builtins.h (expand_ifn_atomic_bit_test_and): New prototype.
* builtins.c (expand_ifn_atomic_bit_test_and): New function.
* internal-fn.c (expand_ATOMIC_BIT_TEST_AND_SET,
expand_ATOMIC_BIT_TEST_AND_COMPLEMENT,
expand_ATOMIC_BIT_TEST_AND_RESET): New functions.
* doc/md.texi (atomic_bit_test_and_set@var{mode},
atomic_bit_test_and_complement@var{mode},
atomic_bit_test_and_reset@var{mode}): Document.
* config/i386/sync.md (atomic_bit_test_and_set,
atomic_bit_test_and_complement,
atomic_bit_test_and_reset): New expanders.
(atomic_bit_test_and_set_1,
atomic_bit_test_and_complement_1,
atomic_bit_test_and_reset_1): New insns.

* gcc.target/i386/pr49244-1.c: New test.
* gcc.target/i386/pr49244-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr49244-1.c
trunk/gcc/testsuite/gcc.target/i386/pr49244-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.h
trunk/gcc/config/i386/sync.md
trunk/gcc/doc/md.texi
trunk/gcc/internal-fn.c
trunk/gcc/internal-fn.def
trunk/gcc/optabs.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug c++/70925] Vectorized loop segfaults: read exceeds vector boundary

[gentryx at gmx dot de]

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

Andreas Schaefer  changed:

   What|Removed |Added

 CC||gentryx at gmx dot de

--- Comment #1 from Andreas Schaefer  ---
Created attachment 38404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38404=edit
Preprocessed source file for bug reproduction

Compression was necessary as original file is 5MB in size.

[Bug c++/70925] New: Vectorized loop segfaults: read exceeds vector boundary

[gentryx at gmx dot de]

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

Bug ID: 70925
   Summary: Vectorized loop segfaults: read exceeds vector
boundary
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gentryx at gmx dot de
  Target Milestone: ---

I've stumbled across a case where may vectorize a loop and the resulting
assembly will cause a segfault when the read operation exceeds a vector
boundary. Only happens with -O3 and -march=native.

Tested compilers:

icpc 15.0.6:   works
clang++ 3.8.0: works
g++-4.7.4: works
g++-4.8.5: works
g++-4.9.3: fails
g++-5.3.0: fails

System: Gentoo Linux (observed on other systems, too), Intel Core i7-6700HQ

Command line: g++-5.3.0 test_lfa_lgd.ii -o test -O3  -fno-strict-aliasing
-fwrapv -std=c++11 && ./test

Output: Segmentation fault. GDB disassembly of the segfault site:

=> 0x00406612 <+22514>: vmovapd (%r11,%rcx,1),%ymm0
   0x00406618 <+22520>: add$0x1,%rdi
   0x0040661c <+22524>: vmovups %xmm0,(%rsi,%rcx,1)
   0x00406621 <+22529>: vextractf128 $0x1,%ymm0,0x10(%rsi,%rcx,1)
   0x00406629 <+22537>: add$0x20,%rcx
   0x0040662d <+22541>: cmp%rdi,%r12
   0x00406630 <+22544>: ja 0x406612 

Please let me know if I can provide any further details.

[Bug fortran/70854] ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> $ make check-fortran RUNTESTFLAGS="--target_board=unix/-finit-local-zero"
> ...
> # of expected passes38678
> # of unexpected failures293
> # of expected failures  45
> # of unresolved testcases   14
> # of unsupported tests  407

On a patched trunk (7.0) I get

# of expected passes38954
# of unexpected failures53
# of expected failures  45
# of unresolved testcases   14
# of unsupported tests  396

none of the unexpected failures being related to this PR.

[Bug c++/70868] Assigning constructed temporary of class with nontrivial constructor uses unnecessary temporary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug rtl-optimization/70687] Undefined shift in change_zero_ext in combine.c

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug rtl-optimization/70687] Undefined shift in change_zero_ext in combine.c

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue May  3 10:29:55 2016
New Revision: 235811

URL: https://gcc.gnu.org/viewcvs?rev=235811=gcc=rev
Log:
PR 70687: Use wide_int in combine.c:change_zero_ext

PR 70687 reports a case where combine.c mishandles integer modes
wider than unsigned HOST_WIDE_INT.  I don't have a testcase since
the PR is just pointing out the hole.

Also, I think a ZERO_EXTEND of a vector mode could in principle satisfy
the subreg condition but wouldn't be equivalent to an AND.  E.g.:

  (zero_extend:V4DI (subreg:V4SI (reg:V4DI R) 0))

Tested on x86_64-linux-gnu.

gcc/
PR rtl-optimization/70687
* combine.c (change_zero_ext): Check for scalar modes.  Use wide_int
instead of unsigned HOST_WIDE_INT.

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

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gccbugs at jbapple dot com

--- Comment #8 from Jonathan Wakely  ---
*** Bug 70898 has been marked as a duplicate of this bug. ***

[Bug libstdc++/70898] Stateful Compare objects are very slow

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Ah, then it's a dup of PR 67085 (which I had incorrectly marked as a dup of
51965).

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

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Marc pointed out this isn't the same issue as 51965, so reopening.

[Bug libstdc++/70898] Stateful Compare objects are very slow

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #3)
> This is being tracked as PR 51965

PR 51965 seems to be about extra copies of the values, while this one is more
about extra copies of compare objects (then there are also extra copies of
iterators).

[Bug rtl-optimization/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Bernd Schmidt from comment #10)
> Looks to me like epilogue_completed would be a good predicate. I'll put the
> following in a bootstrap, let me know if you're OK with this patch.

I was testing exactly the same patch ;)

So, patch preapproved after the usual test cycle.

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

[palves at redhat dot com]

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

--- Comment #3 from Pedro Alves  ---
> I noticed that this triggers with C++, but not with C.  (GDB recently 
> switched > to building as C++ program by default.)

I've built trunk now (gcc version 7.0.0 20160503), and I now get the same
warning on both C and C++.

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16be

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
If you think there's a bug here please provide a testcase that compiles and
produces an incorrect result.

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16be

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Кирилл from comment #2)
> ...
> Just realized its wrong endianness problem. 
> codecvt_utf8_utf16 should assume utf16be by default, right? Apparently, no.

No. It works with the native endianness of the system, if I understand the spec
correctly. i.e. it's for converting between UTF-8 and in-memory UTF-16
sequences using the native endianness. But the spec is a total mess.