[Bug c++/61341] ICE for variadic templates: tsubst at cp/pt.c:11313, tree check: expected class ‘expression’, have ‘type’ (integer_type)

[su at cs dot ucdavis.edu]

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

Zhendong Su  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #4 from Zhendong Su  ---
This still fails for the current trunk. Below is another almost the same, but
slightly simpler test: 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160707 (experimental) [trunk revision 238117] (GCC) 
$ 
$ clang++-3.8 -c -std=c++11 small.cpp
$ 
$ g++-trunk -c small.cpp
small.cpp: In substitution of ‘template int f(A...)
[with T = ]’:
small.cpp:4:28:   required from here
small.cpp:4:28: internal compiler error: tree check: expected class
‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3528
 int a = f (A < int, int >());
^
0x105fd87 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9802
0x5d8171 expr_check
../../gcc-source-trunk/gcc/tree.h:3199
0x5d8171 tree_operand_check
../../gcc-source-trunk/gcc/tree.h:3528
0x70513f tree_operand_check
../../gcc-source-trunk/gcc/tree.h:3144
0x70513f unify_pack_expansion
../../gcc-source-trunk/gcc/cp/pt.c:19216
0x7085c8 unify
../../gcc-source-trunk/gcc/cp/pt.c:20014
0x70734a unify
../../gcc-source-trunk/gcc/cp/pt.c:19910
0x707e96 unify
../../gcc-source-trunk/gcc/cp/pt.c:20006
0x5d8680 try_class_unification
../../gcc-source-trunk/gcc/cp/pt.c:19010
0x70711f unify
../../gcc-source-trunk/gcc/cp/pt.c:20044
0x7035bd unify_one_argument
../../gcc-source-trunk/gcc/cp/pt.c:18337
0x7046d4 unify_pack_expansion
../../gcc-source-trunk/gcc/cp/pt.c:19248
0x706139 type_unification_real
../../gcc-source-trunk/gcc/cp/pt.c:18431
0x713ce4 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc-source-trunk/gcc/cp/pt.c:17856
0x67468b add_template_candidate_real
../../gcc-source-trunk/gcc/cp/call.c:3110
0x6753bc add_template_candidate
../../gcc-source-trunk/gcc/cp/call.c:3188
0x6753bc add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5361
0x6779b9 perform_overload_resolution
../../gcc-source-trunk/gcc/cp/call.c:4045
0x679eae build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-source-trunk/gcc/cp/call.c:4122
0x818000 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


--


template < typename ... T > struct A {};
template < typename ... T > int f (A < T, T ... > ...);

int a = f (A < int, int >());

[Bug c++/71821] New: ICE on invalid C++11 code (incorrect argument for alignas): unexpected expression ‘f’ of kind template_id_expr

[su at cs dot ucdavis.edu]

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

Bug ID: 71821
   Summary: ICE on invalid C++11 code (incorrect argument for
alignas): unexpected expression ‘f’ of kind
template_id_expr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It affects all versions since 4.8.x, and is rejected by 4.7.x and before (as
alignas wasn't yet unsupported). 


$ g++-trunk -v  
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160707 (experimental) [trunk revision 238117] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp:4:10: internal compiler error: unexpected expression ‘f’ of kind
template_id_expr
 alignas (f < int >) char c;
  ^
0x8acd4c cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:4153
0x8b1ca9 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4211
0x79f4cd cp_parser_std_attribute_spec
../../gcc-source-trunk/gcc/cp/parser.c:24164
0x79f4cd cp_parser_std_attribute_spec_seq
../../gcc-source-trunk/gcc/cp/parser.c:24204
0x7a450f cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12575
0x7adc01 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12304
0x7ae051 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12251
0x7b6cc0 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12148
0x7b5794 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12027
0x7b5ac8 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4329
0x7b5ac8 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37505
0x919b92 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


---


template < typename > constexpr int f () {  return 4; }

// should be: alignas (f < int >()) char c;
alignas (f < int >) char c;

[Bug fortran/67757] ICE after "ambiguous reference"

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
This appears to be fixed on 6 and 7.  Please check.

[Bug target/71800] GCC generates invalid instruction (stxsiwx) with -mcpu=power7

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #1 from Bill Seurer  ---
FWIW this started with r237864

[Bug fortran/71783] [5/6/7 Regression ] ICE on valid code in gimplify_var_or_parm_decl at gimplify.c:1801

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||brad.finney at humboldt dot edu

--- Comment #4 from kargl at gcc dot gnu.org ---
*** Bug 71782 has been marked as a duplicate of this bug. ***

[Bug fortran/71782] [5/6/7 Regression] internal compiler error: in gimplify_var_or_parm_decl

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
dup

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

Re: 10 x 1036778084 = ??

[Jim Wilson]

On 07/07/2016 10:07 PM, Nobby-Hirand wrote:

I have just find strange answer, 10 x 1036778084 = 1777846248??


Your target has 32-bit integers.  The value 1036778084 is close to the 
largest representable value.  Multiplying by anything larger than 2 
causes an overflow, and the result gets truncated.  Try using %x to 
print hex values to see what is wrong.  Or use long long instead of int 
to get 64-bit values.


FYI With a more recent gcc version, you can compile with 
-fsanitize=undefined and get this:


weathertop:2044$ ./a.out
tmp.c:11:5: runtime error: signed integer overflow: 10 * 1036778084 
cannot be represented in type 'int'


FYI gcc-bugs@gcc.gnu.org is used for output from our bugzilla database. 
 You shouldn't send email to this address.  You should either send 
email to gcc-help or file a bug at https://gcc.gnu.org/bugzilla/


Jim

[Bug fortran/68426] Simplification of SPREAD with a derived type element causes ICE

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jul  8 22:24:44 2016
New Revision: 238186

URL: https://gcc.gnu.org/viewcvs?rev=238186=gcc=rev
Log:
2016-07-08  Steven G. Kargl  

PR fortran/68426
* simplify (gfc_simplify_spread): Adjust locus.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c

[Bug c++/71820] New: ICE on valid C++ code: in arg_assoc_type, at cp/name-lookup.c:5583

[su at cs dot ucdavis.edu]

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

Bug ID: 71820
   Summary: ICE on valid C++ code: in arg_assoc_type, at
cp/name-lookup.c:5583
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++ code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It appears to affect all versions since at least as early as 4.4.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160707 (experimental) [trunk revision 238117] (GCC)
$
$ clang++-3.8 -c small.cpp
$
$ g++-trunk -c small.cpp
small.cpp: In substitution of ‘template void f1(__typeof__ (f(f0)))
[with T = int]’:
small.cpp:13:16:   required from here
small.cpp:8:24: internal compiler error: in arg_assoc_type, at
cp/name-lookup.c:5583
 void f1 (__typeof__ (f (f0 < T >))) {}
 ~~~^~~
0x8778d2 arg_assoc_type
../../gcc-source-trunk/gcc/cp/name-lookup.c:5583
0x877866 arg_assoc_args
../../gcc-source-trunk/gcc/cp/name-lookup.c:5594
0x877866 arg_assoc_type
../../gcc-source-trunk/gcc/cp/name-lookup.c:5566
0x8770cd arg_assoc
../../gcc-source-trunk/gcc/cp/name-lookup.c:5665
0x877298 arg_assoc
../../gcc-source-trunk/gcc/cp/name-lookup.c:5653
0x87c6d1 arg_assoc_args_vec
../../gcc-source-trunk/gcc/cp/name-lookup.c:5609
0x87c6d1 lookup_arg_dependent_1
../../gcc-source-trunk/gcc/cp/name-lookup.c:5714
0x87c6d1 lookup_arg_dependent(tree_node*, tree_node*, vec*)
../../gcc-source-trunk/gcc/cp/name-lookup.c:5742
0x815644 perform_koenig_lookup(cp_expr, vec*, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2244
0x6e542e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:16590
0x6d6c2f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15868
0x6ea34a tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:13569
0x6f8752 tsubst_arg_types
../../gcc-source-trunk/gcc/cp/pt.c:12559
0x6f8b4c tsubst_function_type
../../gcc-source-trunk/gcc/cp/pt.c:12694
0x6e9fb7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:13416
0x713b1d fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc-source-trunk/gcc/cp/pt.c:17795
0x67468b add_template_candidate_real
../../gcc-source-trunk/gcc/cp/call.c:3110
0x6753bc add_template_candidate
../../gcc-source-trunk/gcc/cp/call.c:3188
0x6753bc add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5361
0x6779b9 perform_overload_resolution
../../gcc-source-trunk/gcc/cp/call.c:4045
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


int f (int);
int f (void (*) (int, int));

template < typename T >
void f0 (T x, __typeof__ (f (x)) y) {}

template < typename T >
void f1 (__typeof__ (f (f0 < T >))) {}

int main ()
{ 
  f0 < int > (0, 0);
  f1 < int > (0);
  return 0;
}

[Bug fortran/71783] [5/6/7 Regression ] ICE on valid code in gimplify_var_or_parm_decl at gimplify.c:1801

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
The solution turns that fixes the ICE turns out to be reasonably simple: We
were missing a charlen for the allocatable case.

What I do not yet understand is why this code was reached in the first place;
the temporary assignment should never happen for this case.

Index: frontend-passes.c
===
--- frontend-passes.c   (Revision 237949)
+++ frontend-passes.c   (Arbeitskopie)
@@ -665,12 +665,10 @@ create_var (gfc_expr * e, const char *vname)
 {
   gfc_expr *length;

+  symbol->ts.u.cl = gfc_new_charlen (ns, NULL);
   length = constant_string_length (e);
   if (length)
-   {
- symbol->ts.u.cl = gfc_new_charlen (ns, NULL);
- symbol->ts.u.cl->length = length;
-   }
+   symbol->ts.u.cl->length = length;
   else
symbol->attr.allocatable = 1;
 }

Toon, does this fix the ICE for you as well?

[Bug tree-optimization/50417] regression: memcpy with known alignment

[npl at chello dot at]

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

--- Comment #17 from npl at chello dot at ---
I got interrupted by a colleague at work, part 2 of the ramblings...

Everything you could argue against memcpy beeing replaced by simpler
instructions, doesnt change that the same issue persists with the
__builtin_memcpy function, which is explicitely saying you want the
optimizations.

A pointer to a uint32 can be assumed to be proper aligned, CREATING such a
pointer thats not aligned is already undefined behaviour by the standard (the
compiler could zero out bits for example). I dont think that what happens
afterwards with something that shouldn`t exist in the first place is an
argument against optimizing proper code.

Further, I lack a consistent way of dealing with potential aliasing pointers.
Using memcpy seems the sanest way, simply because its standards compliant,
supported everywhere and your code wont mysteriously break once you use LTO or
higher optimization settings.
Compilers can reliably detect this and replace memcpy since years (ignoring
this issue, which I would consider a bug), so there is no draw back. Its a
feature common pretty much everywhere, and a valid recommendation in many
discussions related to the topic.

Consider the example below for illustration, FIXEDMEMCPY is how the plain
memcpy should work and already does work for archs with unaligned access.
(I had planned to post the code for 32bit x86, but the assembly is rather ugly,
amd64 would work with "unsigned long" and "unsigned long long").

I already ran in such issues, when different software components define their
own fixedwidth types. Its a practical issue where pointing to paragraphs of the
standard dont help, unless you provide a proper solution with it. The
FIXEDMEMCPY hack is fine for gcc but compilerspecific.

In short:
* Optimizing memcpy to simple instructions is a reality and expected, the
behaviour (slow code) on arm (and other archs with req. alignment) is a
unwelcome oddity
* memcpy is one of the few ways to deal with aliasing, and the most standards
compliant. (theres unions too, but thats not standards compliant)
* I dont see a problem in replacing standard functions (and __builtin_memcpy
has the same issue)
* I dont see a problem in expecting a correctly aligned pointer, and doing
undefined behaviour if the pointer could cause undefined behaviour.



typedef unsigned uint32_t;
typedef unsigned long uint32_alt;
_Static_assert(sizeof(uint32_t) == sizeof(uint32_alt), "you picked a bad
architecture or typedefs for this example");

#define FIXEDMEMCPY(a, b, s) __builtin_memcpy(__builtin_assume_aligned(a,
__alignof__(*a)), __builtin_assume_aligned(b, __alignof__(*b)), s)
unsigned breakme(uint32_t *ptr, uint32_alt *ptr2, uint32_t a)
{
/* normally in different compilation units, but LTO doesnt care */
*ptr = 0;
*ptr2 = a;
return *ptr;
}

unsigned fixme(uint32_t *ptr, uint32_alt *ptr2, uint32_t a)
{
/* fixes aliasing, but should be as fast as simple accesses */
uint32_t val = 0;
FIXEDMEMCPY(ptr, , 4);
FIXEDMEMCPY(ptr2 , , 4);
uint32_t val2;
FIXEDMEMCPY(, ptr, 4);
return val2;
}

 :
   0:   e3a03000mov r3, #0
   4:   e5803000str r3, [r0]
   8:   e1a3mov r0, r3 // Oops: retval = 0
   c:   e5812000str r2, [r1]
  10:   e12fff1ebx  lr

0014 :
  14:   e3a03000mov r3, #0
  18:   e5803000str r3, [r0]
  1c:   e5812000str r2, [r1]
  20:   e590ldr r0, [r0] // The load thats missing above
  24:   e24dd010sub sp, sp, #16 // Time for another 
  28:   e28dd010add sp, sp, #16 // Bugreport ?
  2c:   e12fff1ebx  lr

[Bug rtl-optimization/71621] [7 Regression] ICE in assign_by_spills, at lra-assigns.c:1417 (error: unable to find a register to spill) w/ -O2 -mavx2 -ftree-vectorize

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Jul  8 20:29:12 2016
New Revision: 238178

URL: https://gcc.gnu.org/viewcvs?rev=238178=gcc=rev
Log:
2016-07-08  Vladimir Makarov  

PR rtl-optimization/71621
* lra-constraints.c (process_alt_operands): Check combination of
reg class and mode.

2016-07-08  Vladimir Makarov  

PR rtl-optimization/71621
* gcc.target/i386/pr71621-1.c: New.
* gcc.target/i386/pr71621-2.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr71621-1.c
trunk/gcc/testsuite/gcc.target/i386/pr71621-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71606] [4.9/5/6 Regression] ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Jul  8 20:22:22 2016
New Revision: 238174

URL: https://gcc.gnu.org/viewcvs?rev=238174=gcc=rev
Log:
Do not consider COMPLEX_TYPE as fold_convertible_p

Backported from mainline
2016-07-08  Martin Liska  

PR middle-end/71606
* fold-const.c (fold_convertible_p): As COMPLEX_TYPE
folding produces SAVE_EXPRs, thus return false for the type.
Backported from mainline
2016-07-08  Martin Liska  

* gcc.dg/torture/pr71606.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr71606.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/fold-const.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71606] ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|[4.9/5/6 Regression] ICE on |ICE on -O2 and above on
   |-O2 and above on|x86_64-linux-gnu (internal
   |x86_64-linux-gnu (internal  |compiler error: in
   |compiler error: in  |get_expr_operands, at
   |get_expr_operands, at   |tree-ssa-operands.c:882)
   |tree-ssa-operands.c:882)|

--- Comment #8 from Martin Liška  ---
Fixed on all active branches.

[Bug middle-end/71606] [4.9/5/6 Regression] ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri Jul  8 20:21:02 2016
New Revision: 238173

URL: https://gcc.gnu.org/viewcvs?rev=238173=gcc=rev
Log:
Do not consider COMPLEX_TYPE as fold_convertible_p

Backported from mainline
2016-07-08  Martin Liska  

PR middle-end/71606
* fold-const.c (fold_convertible_p): As COMPLEX_TYPE
folding produces SAVE_EXPRs, thus return false for the type.
Backported from mainline
2016-07-08  Martin Liska  

* gcc.dg/torture/pr71606.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr71606.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71606] [4.9/5/6 Regression] ICE on -O2 and above on x86_64-linux-gnu (internal compiler error: in get_expr_operands, at tree-ssa-operands.c:882)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Jul  8 20:20:23 2016
New Revision: 238172

URL: https://gcc.gnu.org/viewcvs?rev=238172=gcc=rev
Log:
Do not consider COMPLEX_TYPE as fold_convertible_p

Backported from mainline
2016-07-08  Martin Liska  

PR middle-end/71606
* fold-const.c (fold_convertible_p): As COMPLEX_TYPE
folding produces SAVE_EXPRs, thus return false for the type.
Backported from mainline
2016-07-08  Martin Liska  

* gcc.dg/torture/pr71606.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr71606.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71784] [6/7 Regression] ICE on invalid code in push_access_scope, at cp/pt.c:229

[mct_ancs at yahoo dot com]

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

--- Comment #10 from Ela  ---

>  ... actually I made it simpler, in order to get to
>  the root of it:
> 
>  ---  CORRECTION  -
#include 
using std::cout;


#include 

template
class A{
  public:
  void f()  & ;
  void f() && ;
  void g()  ;
  void g(int)  ;
};
>  ---
#include "e.hh"

  template
   void A::f()  & { std::cout << "lvalue object\n" ; }
  template
   void A::f() && { std::cout << "rvalue object\n" ; }

  template
   void A::g()   { std::cout << "lvalue object\n" ; }
  template
   void A::g(int x)  { std::cout << "rvalue object\n" ; }

extern template class A ;
//extern template class A ;
//template void  A::f(float const&)  & ;
//template void  A::f() && ;

template  void A::f() &;
//template void  A::f() && ;


template  void A::g() ;
template  void A::g(int) ;
>  ---
#include 
#include "e.hh"
using std::cout;


int main(){

  A   a;
   a.f(); // lvalue
//  A().f(); // rvalue
   a.g(); // lvalue
   a.g(3); // lvalue
}
>  ---

[Bug c++/71784] [6/7 Regression] ICE on invalid code in push_access_scope, at cp/pt.c:229

[mct_ancs at yahoo dot com]

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

--- Comment #9 from Ela  ---
(In reply to Ela from comment #8)
> (In reply to Martin Liška from comment #7)
> 
> > Same as the origin, it's obviously an invalid code.
> 
>   Tested on all Clang-3.8 C++11,14,17 - it works.
> 
>   gcc-6.1.0 is a bit more explicit in some sense:
>- class instantiation w/ external leaves all
>  members non-inst.
>- the missing function in the call (in main() )
>  is written as some mangle, and not in_clear
>  (as it would be with other functions - that
>  one can add for test)
>- thus seems as a lack of internal repres. or
>  something.
> 
>   Else please enlighten me on the correct syntax.


 ... actually I made it simpler, in order to get to
 the root of it:

 --
#include 
using std::cout;


template
class A{
  public:
  template
  void f(U const&)  & ;
  template
  void f(U const&) && ;
};


  template
  template
   void A::f(U const& x)  & { std::cout << "lvalue object\n" ; }
  template
  template
   void A::f(U const& x) && { std::cout << "rvalue object\n" ; }

template class A ;
template void A::f(int const&) & ;
template void A::f(int const&) &&;


int main(){

  A   a;
   a.f(2);  
  A().f(1); 

}

[Bug c++/71784] [6/7 Regression] ICE on invalid code in push_access_scope, at cp/pt.c:229

[mct_ancs at yahoo dot com]

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

--- Comment #8 from Ela  ---
(In reply to Martin Liška from comment #7)

> Same as the origin, it's obviously an invalid code.

  Tested on all Clang-3.8 C++11,14,17 - it works.

  gcc-6.1.0 is a bit more explicit in some sense:
   - class instantiation w/ external leaves all
 members non-inst.
   - the missing function in the call (in main() )
 is written as some mangle, and not in_clear
 (as it would be with other functions - that
 one can add for test)
   - thus seems as a lack of internal repres. or
 something.

  Else please enlighten me on the correct syntax.

[Bug c++/71811] gcc6/c++/functional:1726:40: internal compiler error: in assign_temp, at function.c:961

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
Also see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=71210 (thanks JJ).

[Bug fortran/71799] [7 Regression] ICE in DO loop code emission (gfc_resolve_iterator)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-08
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Internal error from 4.8 up to trunk (7.0).

[Bug fortran/71770] gfortran: internal compiler error: Segmentation fault (program f951)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-08
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
> Did you read the initial error message and follow 
> the direction?  This parts seems very important
> (and you're possibly wasting gfortran maintainer's
> time).

Without answer the PR will be closed as INVALID.

[Bug bootstrap/71816] [7 Regression] bootstrap broken on multiple targets

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
Bootstrap is proceeding with r238077.

[Bug bootstrap/71816] [7 Regression] bootstrap broken on multiple targets

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arm-linux-gnueabihf,|arm-linux-gnueabihf,
   |powerpc-linux-gnu,  |powerpc-linux-gnu,
   |sparc-sun-solaris2.*,   |sparc-sun-solaris2.*,
   |powerpc-ibm-aix*|powerpc-ibm-aix*, s390
 CC||rguenth at gcc dot gnu.org
Summary|[7 Regression] bootstrap|[7 Regression] bootstrap
   |broken on   |broken on multiple targets
   |armhf-linux-gnuabihf|

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Seems to have started with r238078

[Bug bootstrap/71816] [7 Regression] bootstrap broken on armhf-linux-gnuabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
*** Bug 71819 has been marked as a duplicate of this bug. ***

[Bug bootstrap/71819] [7 regression] Bootstrap fail on S/390 32 bit starting with r238078

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

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

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

[Bug target/71297] [7 regression] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
Fixed.

[Bug bootstrap/71819] New: [7 regression] Bootstrap fail on S/390 32 bit starting with r238078

[krebbel at gcc dot gnu.org]

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

Bug ID: 71819
   Summary: [7 regression] Bootstrap fail on S/390 32 bit starting
with r238078
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Reghunt found that this failed occurred first after r238078

There appear to be two errors in the build output:

/home/andreas/bisect/build/./prev-gcc/xg++
-B/home/andreas/bisect/build/./prev-gcc/
-B/home/andreas/bisect/gcc-238078-install/s390-ibm-linux-gnu/bin/ -nostdinc++
-B/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/src/.libs
-B/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/include/s390-ibm-linux-gnu
 -I/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/include 
-I/home/andreas/gcc/libstdc++-v3/libsupc++
-L/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/src/.libs
-L/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I/home/andreas/bisect/../gcc/gcc -I/home/andreas/bisect/../gcc/gcc/build
-I/home/andreas/bisect/../gcc/gcc/../include 
-I/home/andreas/bisect/../gcc/gcc/../libcpp/include  \
-o build/gencodes.o /home/andreas/bisect/../gcc/gcc/gencodes.c
/home/andreas/bisect/../gcc/gcc/genattrtab.c: In function 'rtx_def*
simplify_and_tree(rtx, rtx_def**, int, int)':
/home/andreas/bisect/../gcc/gcc/genattrtab.c:2131:1: error: non-trivial
conversion at assignment
 simplify_and_tree (rtx exp, rtx *pterm, int insn_code, int insn_index)
 ^
struct rtx_def *
int
# VUSE <.MEM_49>
pretmp_132 = MEM[(union u *)exp_106 + 8B];
/home/andreas/bisect/../gcc/gcc/genattrtab.c:2131:1: error: non-trivial
conversion at assignment
struct rtx_def *
int
# VUSE <.MEM_49>
pretmp_141 = MEM[(union u *)_16 + 8B];



/home/andreas/bisect/build/./prev-gcc/xg++
-B/home/andreas/bisect/build/./prev-gcc/
-B/home/andreas/bisect/gcc-238078-install/s390-ibm-linux-gnu/bin/ -nostdinc++
-B/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/src/.libs
-B/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/include/s390-ibm-linux-gnu
 -I/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/include 
-I/home/andreas/gcc/libstdc++-v3/libsupc++
-L/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/src/.libs
-L/home/andreas/bisect/build/prev-s390-ibm-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I/home/andreas/bisect/../gcc/gcc -I/home/andreas/bisect/../gcc/gcc/build
-I/home/andreas/bisect/../gcc/gcc/../include 
-I/home/andreas/bisect/../gcc/gcc/../libcpp/include  \
-o build/gencheck.o /home/andreas/bisect/../gcc/gcc/gencheck.c
0x11538b3 verify_gimple_in_cfg(function*, bool)
/home/andreas/bisect/../gcc/gcc/tree-cfg.c:5212
0xfbb427 execute_function_todo
/home/andreas/bisect/../gcc/gcc/passes.c:1964
0xfba2b3 do_per_function
/home/andreas/bisect/../gcc/gcc/passes.c:1648
0xfbb677 execute_todo
/home/andreas/bisect/../gcc/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [build/genattrtab.o] Error 1
make[3]: *** Waiting for unfinished jobs

[Bug target/71297] [7 regression] ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Jul  8 15:42:47 2016
New Revision: 238168

URL: https://gcc.gnu.org/viewcvs?rev=238168=gcc=rev
Log:
[gcc]

2016-07-08  Bill Schmidt  

PR target/71297
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Allow standard error handling to take over when a wrong number
of arguments is presented to __builtin_vec_ld () or
__builtin_vec_st ().

[gcc/testsuite]

2016-07-08  Bill Schmidt  

PR target/71297
* gcc.target/powerpc/pr71297.c: New.


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

[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize

[helloqirun at gmail dot com]

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

--- Comment #8 from Qirun Zhang  ---
(In reply to alahay01 from comment #7)
> Fixed.
> 
> Additional issue found by Qirun has been raised as PR 71818

Hi Alan, Sorry that I missed your previous message..

[Bug target/71806] PowerPC -mcpu=power9 enables __float128 without an explicit -mfloat128

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
Closed.

[Bug target/71806] PowerPC -mcpu=power9 enables __float128 without an explicit -mfloat128

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Fixed on trunk, subversion id 238161.  Fixed on GCC 6.2 branch, subversion id
238165.

[Bug target/71806] PowerPC -mcpu=power9 enables __float128 without an explicit -mfloat128

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Fri Jul  8 14:51:44 2016
New Revision: 238165

URL: https://gcc.gnu.org/viewcvs?rev=238165=gcc=rev
Log:
Back port from trunk

[gcc]
2016-07-08  Michael Meissner  

PR target/71806
* config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Do not
enable -mfloat128-hardware by default.
(ISA_3_0_MASKS_IEEE): New macro to give all of the VSX options
that IEEE 128-bit hardware support needs.
* config/rs6000/rs6000.c (rs6000_option_override_internal): If
-mcpu=power9 -mfloat128, enable -mfloat128-hardware by default.
Use ISA_3_0_MASKS_IEEE as the set of options that IEEE 128-bit
floating point requires.
* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mfloat128 and -mfloat128-hardware changes.

[gcc/testsuite]
2016-07-08  Michael Meissner  

PR target/71806
* gcc.target/powerpc/p9-lxvx-stxvx-3.c: Add -mfloat128 option.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000-cpus.def
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/doc/invoke.texi
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c

[Bug target/71806] PowerPC -mcpu=power9 enables __float128 without an explicit -mfloat128

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Fri Jul  8 14:49:37 2016
New Revision: 238164

URL: https://gcc.gnu.org/viewcvs?rev=238164=gcc=rev
Log:
[gcc]
2016-07-08  Michael Meissner  

PR target/71806
* config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Do not
enable -mfloat128-hardware by default.
(ISA_3_0_MASKS_IEEE): New macro to give all of the VSX options
that IEEE 128-bit hardware support needs.
* config/rs6000/rs6000.c (rs6000_option_override_internal): If
-mcpu=power9 -mfloat128, enable -mfloat128-hardware by default.
Use ISA_3_0_MASKS_IEEE as the set of options that IEEE 128-bit
floating point requires.
* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mfloat128 and -mfloat128-hardware changes.

[gcc/testsuite]
2016-07-08  Michael Meissner  

PR target/71806
* gcc.target/powerpc/p9-lxvx-stxvx-3.c: Add -mfloat128 option.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-cpus.def
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c

[Bug tree-optimization/50417] regression: memcpy with known alignment

[npl at chello dot at]

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

--- Comment #16 from npl at chello dot at ---
rguenther: Funny enough, I am using memcpy because thats the only standard
conform way to move data around that might be aliased. And I use this often to
parse binary streams from a network.

I think you are missing some key points, first that gcc readily replaces
functions it knows - which can be disabled at will. On x86, for all those
samples the call WILL BE replaced. (And in C++, RVO is explicitly allowed for
example)
So its pointless to discuss whether or not gcc should provide builtins (atleast
in the context of this bug). Instead talk about the replacing feature that
seems to work inconsistent / suboptimal.


One more sample to demonstrate this (all compiled with O2):

#include 
int foo_ptr(const int *s)
{
/* nope */
int v;
memcpy(, s, sizeof(v));
return v;
}

int foo_ref(const int )
{
/* nope */
int v;
memcpy(, , sizeof(v));
return v;
}

int foo_refloc(const int )
{
/* This actually works */
int b = s;
int v;
memcpy(, , sizeof(v));
return v;
}

int foo_badalias(const char *s)
{
/* Nope, but then THIS shouldnt be be replaced by a aligned load */
int v;
memcpy(, (int *)s, sizeof(v));
return v;
}

int foo_badalias2(const char *s)
{
/* That works, but is undefined behaviour (casting from a pointer with
less alignment)! */
int v = *(int *)s;
return v;
}

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Yes, and I'm still planning to fix it.

(And I still think using exceptions in iostreams is dumb in the first place).

[Bug bootstrap/71816] [7 Regression] bootstrap broken on armhf-linux-gnuabihf

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|arm-linux-gnueabihf,|arm-linux-gnueabihf,
   |powerpc-linux-gnu   |powerpc-linux-gnu,
   ||sparc-sun-solaris2.*
 CC||ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
Same on Solaris/SPARC.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
if-conversion builds

  _51 = LOOP_VECTORIZED (3, 4);

but

new phi replacement stmt
prephitmp_63 = prephitmp_62 != 0 ? _3 : prephitmp_62;
Degenerate phi!
prephitmp_52 = PHI <3(6)>
Degenerate phi!
prephitmp_54 = PHI 
Applying pattern match.pd:865, generic-match.c:429
Removing basic block 5
basic block 5, loop depth 1
 pred:
 succ:


Removing basic block 6
basic block 6, loop depth 1
 pred:
 succ:


Merging blocks 17 and 11
Merging blocks 4 and 24
Merging blocks 21 and 22
gimple_simplified to if (1 != 0)
Applying pattern match.pd:853, gimple-match.c:164
Applying pattern match.pd:2618, gimple-match.c:57412
Removing basic block 23
basic block 23, loop depth 1
 pred:   21
goto ;
 succ:   19


fix_loop_structure: fixing up loops for function
fix_loop_structure: removing loop 4


so there is no loop 4 in the end ...


Before if-conversion the IL has

  :
  # prephitmp_52 = PHI <3(6)>
  # prephitmp_54 = PHI 
  if (prephitmp_52 != 0)

which likely messes things up.  copyprop leaves us with this unpropagated
constant by means of stmt folding during SSA substitution phase.


We are generally not fixing up a LOOP_VECTORIZED call when loops vanish
as we assume that doesn't happen between if-conversion and vectorization.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
OK.  I'm busy wrapping up some things before a vacation, but I'll plan to look
into this when I get back.

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Doesn't sanitize anything for

int main()  
{   
  int i, j; 
  memcpy (, (int *)((char *) + 1), 4);  
  return 0; 
}

but note that the cast to (int *) is already removed during early folding
and you end up with GENERIC

  memcpy ((void *) , (const void *) ( + 1), 4);

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Fri, 8 Jul 2016, wschmidt at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71815
> 
> --- Comment #1 from Bill Schmidt  ---
> Interesting.  How do we enable/disable code hoisting?  I don't see a 
> documented
> option for this.

It's not yet committed.  You can try the patch at
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00360.html

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Fri, 8 Jul 2016, olegendo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
> 
> --- Comment #13 from Oleg Endo  ---
> (In reply to rguent...@suse.de from comment #12)
> > 
> > No, because the access is performed as 'int'.
> 
> > 
> > >  Why should memcpy be any different?
> > 
> > Because the memcpy stmt doesn't constitute a memory access but a function
> > call.
> 
> Yeah, that might be how things are handled internally.  But that doesn't mean
> the optimization in question can't / shouldn't be done.  GCC does even more
> "evil" things with function calls such as replacing printf with puts,
> propagating arguments into functions, inlining...  So ... uhm ... I'm afraid I
> don't get the point.

The point is the only reason you can do the optimization (on all targets)
is that C standard rule about pointer types (casting).

GCCs implementation details will make the application of the optimization
quite unreliable as well.

I've repeatedly said that I think relying on that part of the C standard
with respect to undefinedness would be a bad thing from a QOI perspective.
But I've changed my mind in the past - does -fsanitize=alignment
instrument pointer types/casts?

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Interesting.  How do we enable/disable code hoisting?  I don't see a documented
option for this.

[Bug fortran/71730] [5/6/7 Regression] ICE when character length specification uses an undefined variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.9.3
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-07-08
 Ever confirmed|0   |1
Summary|ICE when character length   |[5/6/7 Regression] ICE when
   |specification uses an   |character length
   |undefined variable  |specification uses an
   ||undefined variable
  Known to fail||5.4.0, 6.1.0, 7.0

--- Comment #2 from Dominique d'Humieres  ---
Likely caused by revision r229287 (pr67805). This is fixed by the patch in
comment 1, but array_constructor_2[67].f03 need to be updated and
bounds_check_strlen_2.f90 is failing.

[Bug tree-optimization/50417] regression: memcpy with known alignment

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  ---
(In reply to rguent...@suse.de from comment #12)
> 
> No, because the access is performed as 'int'.

> 
> >  Why should memcpy be any different?
> 
> Because the memcpy stmt doesn't constitute a memory access but a function
> call.

Yeah, that might be how things are handled internally.  But that doesn't mean
the optimization in question can't / shouldn't be done.  GCC does even more
"evil" things with function calls such as replacing printf with puts,
propagating arguments into functions, inlining...  So ... uhm ... I'm afraid I
don't get the point.

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 8 Jul 2016, olegendo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
> 
> --- Comment #11 from Oleg Endo  ---
> (In reply to rguent...@suse.de from comment #10)
> > 
> > What makes the parameter type special?  Would
> > 
> > void test (const int *a, int *b)
> > {
> >   std::memcpy ((char *)b, (char *)a, t);
> > }
> > 
> > be invalid to optimize to an aligned copy in your eyes?
> 
> I think it's perfectly valid to optimize this case.  It could as well be
> something like:
> 
> void test (const int *a, int *b)
> {
>   a[100] = 1;
>   b[200] = 2;
> 
>   std::memcpy ((char *)b, (char *)a, t);
> }
> 
> where a[100] and b[200] both would result in 32 bit accesses, not 4x1 byte or
> something, because the base pointer is assumed to be int aligned.

No, because the access is performed as 'int'.

>  Why should memcpy be any different?

Because the memcpy stmt doesn't constitute a memory access but a function call.

[Bug tree-optimization/50417] regression: memcpy with known alignment

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
(In reply to rguent...@suse.de from comment #10)
> 
> What makes the parameter type special?  Would
> 
> void test (const int *a, int *b)
> {
>   std::memcpy ((char *)b, (char *)a, t);
> }
> 
> be invalid to optimize to an aligned copy in your eyes?

I think it's perfectly valid to optimize this case.  It could as well be
something like:

void test (const int *a, int *b)
{
  a[100] = 1;
  b[200] = 2;

  std::memcpy ((char *)b, (char *)a, t);
}

where a[100] and b[200] both would result in 32 bit accesses, not 4x1 byte or
something, because the base pointer is assumed to be int aligned.  Why should
memcpy be any different?

[Bug tree-optimization/60172] [4.9/5/6/7 Regression] ARM performance regression from trunk@207239

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
For GCC 6 we now have a DCE right before RTL expansion so what's the status of
this bug for GCC6/7?

[Bug c++/63151] [5/6/7 regression] Accessibility error when brace-constructing base class with protected defaulted constructor and member variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/67239] [6/7 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
Is this fixed on trunk?

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug preprocessor/69869] [4.9/5/6/7 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ipa/70583] [6/7 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-08
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed also on x86_64 IIRC.

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Fri, 8 Jul 2016, olegendo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
> 
> --- Comment #9 from Oleg Endo  ---
> (In reply to rguent...@suse.de from comment #8)
> > 
> > But there is no good reasoning that can be applied that it is a valid
> > transform.  What does clang do when s is void * and you cast that to
> > uint32_t *?  Note that memcpy prototype takes a void * argument.
> 
> Does it matter whether there's a void* in between or not?
> 
> If we do a *(int32_T*)(void*)(int32_t*)p on a strict alignment target, it will
> result in a 32 bit mem access.

No, changing the pointer type doesn't change the access - how the access
is implemented depends on memcpy.

> GCC knows memcpy and its semantics well enough so propagating the target's
> alignment rules into memcpy is most likely going to be a safe and sane thing 
> to
> do.  So at least cases like 
> 
> void test (const int* a, int* b)
> {
>   std::memcpy (b, a, 4);
> }
> 
> should work.  Shouldn't it?

What makes the parameter type special?  Would

void test (const int *a, int *b)
{
  std::memcpy ((char *)b, (char *)a, t);
}

be invalid to optimize to an aligned copy in your eyes?

Yes, I know that C standard rule about pointer type casting, 6.3.2.3/7
in C11, but I guess that if we'd start to derive alignment from
this undefinedness we are going to break a lot of code.  To GCC
what matters is actual accesses, not just pointer conversions
which are all stripped anyway which makes the following testcase
not optimizable (easily)

void test (const char *a, char *b)  
{   
  std::memcpy ((int *)b, (int *)a, 4);
}

[Bug c++/70768] [6/7 Regression] Increased compilation time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/53429] libstdc++ should guarantee not to expose complex::{imag,real} so it supports both C++98 and C++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jeffrey Yasskin from comment #3)
> Richard, I'm not asking that it be possible to link together code compiled
> in C++98 and C++11 mode. I'm asking that gcc be able to build in C++11 mode
> at all.

Even if we build GCC in C++11 (or C++14) mode, some pieces of libstdc++ get
built with -std=gnu++98 explicitly. That's why they're in the
libstdc++-v3/src/c++98 directory.

> If libstdc++.so exposed the c++98 version of complex::real(), then
> all C++11 programs that used complex would be potentially broken.

I don't think this is true now, because those functions are abi-tagged for
C++11 and later, so C++11 programs would not use the symbols exported from the
library (assuming such symbols existed, and if they did the check-abi testsuite
target would fail for our primary targets, so we'd notice and it wouldn't just
happen silently due to bad luck and different inlining decisions).

So I think this was fixed for 4.8.0 by r193445, but please reopen if I'm
missing something and a potential problem still exists.

> Another way to fix this would, of course, be to either expose a
> configuration option to build libstdc++.so in C++11 mode or to install two
> different .so files in parallel, but doing that seems unnecessarily hostile
> to users when it would be pretty easy to guarantee that the one .so works
> for both versions of the language.

We definitely don't want two libs.

[Bug c++/70781] [6/7 Regression] ICE on invalid C++ code with lambda expressions on x86_64-linux-gnu in finish_expr_stmt, at cp/semantics.c:677

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog, rejects-valid
   Priority|P3  |P2

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/70869] [6 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||7.0
Summary|[6/7 Regression] internal   |[6 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault on array |Segmentation fault on array
   |of pointer to function  |of pointer to function
   |members |members
  Known to fail|7.0 |

[Bug tree-optimization/50417] regression: memcpy with known alignment

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
(In reply to rguent...@suse.de from comment #8)
> 
> But there is no good reasoning that can be applied that it is a valid
> transform.  What does clang do when s is void * and you cast that to
> uint32_t *?  Note that memcpy prototype takes a void * argument.

Does it matter whether there's a void* in between or not?

If we do a *(int32_T*)(void*)(int32_t*)p on a strict alignment target, it will
result in a 32 bit mem access.

GCC knows memcpy and its semantics well enough so propagating the target's
alignment rules into memcpy is most likely going to be a safe and sane thing to
do.  So at least cases like 

void test (const int* a, int* b)
{
  std::memcpy (b, a, 4);
}

should work.  Shouldn't it?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/70942] [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/71066] [4.9/5/6/7 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/71067] [4.9/5/6/7 Regression] ICE on data initialization with insufficient value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[boris at kolpackov dot net]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #13 from Boris Kolpackov  ---
This is getting pretty bad since recent versions of most distributions
(Debian/Ubuntu, Fedora) now have _GLIBCXX_USE_CXX11_ABI set to 1 by default
while their libstdc++ still throws "old ABI" ios::failure.

This (i.e., the #define in functexcept.cc), BTW, is still in GCC 6.1.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P2

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/71115] [4.9/5/6 Regression] Missing warning: excess elements in struct initializer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71117] [6/7 Regression] Overeager application of conversion to function pointer during overload resolution of call to function object

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71164] [6/7 Regression] tree check fail at cp/pt.c:12961

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71121] [6/7 Regression] Spurious warning: "the address of [...] will never be NULL [-Waddress]"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71166] [7 Regression] ICE with nested constexpr/initializer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.2.0
Summary|[6/7 Regression] ICE with   |[7 Regression] ICE with
   |nested  |nested
   |constexpr/initializer   |constexpr/initializer

--- Comment #9 from Richard Biener  ---
Yes.  And we should have added a testcase.

[Bug c++/71166] [7 Regression] ICE with nested constexpr/initializer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71236] [5/6/7 Regression] ICE on invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71251] [5/6/7 regression] ICE on invalid code, with unusual template name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71274] [5/6/7 Regression] deprecated static const member of struct raises warning without use

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

[Bug c++/71290] [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P2

[Bug target/71321] [6/7 Regression] x86: worse code for uint8_t % 10 and / 10

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/71342] [6/7 Regression][RL78] set1 / clr1 with !addr16 sometimes doesn't work

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/71350] [4.9/5/6/7 regression] ICE on trailing return type declaration with initializer list

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71495] [6/7 Regression] Spurious "note: initializing argument ... of ..." without any warning/error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||easyhack
   Priority|P3  |P2

[Bug tree-optimization/71264] [4.9/5 Regression] ICE in convert_move

[bmei at broadcom dot com]

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

--- Comment #17 from Bingfeng Mei  ---
OK, I will skip the vectorization check on our port then. Thanks.

[Bug tree-optimization/71264] [4.9/5 Regression] ICE in convert_move

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Fri, 8 Jul 2016, bmei at broadcom dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264
> 
> Bingfeng Mei  changed:
> 
>What|Removed |Added
> 
>  CC||bmei at broadcom dot com
> 
> --- Comment #15 from Bingfeng Mei  ---
> Hi, Richard, I updated to the latest patches. But our target still failed in
> the same way as other people reported. footype gets V4QI instead of SI because
> we have it supported in vector_mode_supported_p. Thus the following error.
> 
>  not vectorized: vector stmt in loop:temp_14 = VIEW_CONVERT_EXPR(_8);
> 
> I guess your patch in vect_init_vector is supposed to fix this. But the
> execution doesn't even hit vect_init_vector.

The patch wasn't supposed to make this case vectorized but fix the ICE.
On targets where the vector mode is not supported it happens to also
vectorize it.

Making the vectorizer deal with existing vector types is a much harder
task (I tried for a few hours but failed, there are too many rough
spots to fix)

[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 8 Jul 2016, npl at chello dot at wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
> 
> npl at chello dot at changed:
> 
>What|Removed |Added
> 
>  CC||npl at chello dot at
> 
> --- Comment #7 from npl at chello dot at ---
> This seems to affect even the most trivial cases. I ran the following code 
> witn
> arm gcc 4.8.4, 4.9.2 and 5.3.0:
> 
> #include 
> #include 
> 
> uint32_t foo_noalign(const uint32_t *s) {
> uint32_t v;
> memcpy(, s, sizeof(v));
> return v;
> }
> 
> uint32_t foo(const uint32_t *s) {
> uint32_t v;
> memcpy(, __builtin_assume_aligned(s, 4), sizeof(v));
> return v;
> }
> 
> Which generates the following code:
> 
>  :
>0:   e92d4007push{r0, r1, r2, lr}
>4:   e3a02004mov r2, #4
>8:   e1a01000mov r1, r0
>c:   e08d0002add r0, sp, r2
>   10:   ebfebl  0 
>   14:   e59d0004ldr r0, [sp, #4]
>   18:   e28dd00cadd sp, sp, #12
>   1c:   e49de004pop {lr}; (ldr lr, [sp], #4)
>   20:   e12fff1ebx  lr
> 
> 0024 :
>   24:   e590ldr r0, [r0]
>   28:   e12fff1ebx  lr
> 
> Thats really, really bad. clang has no problems generating the optimal code.

But there is no good reasoning that can be applied that it is a valid
transform.  What does clang do when s is void * and you cast that to
uint32_t *?  Note that memcpy prototype takes a void * argument.

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[zsojka at seznam dot cz]

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

--- Comment #19 from Zdenek Sojka  ---
Target milestone 4.9.4 is not set.

[Bug tree-optimization/71264] [4.9/5 Regression] ICE in convert_move

[bmei at broadcom dot com]

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

Bingfeng Mei  changed:

   What|Removed |Added

 CC||bmei at broadcom dot com

--- Comment #15 from Bingfeng Mei  ---
Hi, Richard, I updated to the latest patches. But our target still failed in
the same way as other people reported. footype gets V4QI instead of SI because
we have it supported in vector_mode_supported_p. Thus the following error.

 not vectorized: vector stmt in loop:temp_14 = VIEW_CONVERT_EXPR(_8);

I guess your patch in vect_init_vector is supposed to fix this. But the
execution doesn't even hit vect_init_vector.

[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961

[dominik.stras...@onespin-solutions.com]

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

--- Comment #5 from dominik.stras...@onespin-solutions.com ---
Works after applying the patch in my non-reduced test case, too.

Thanks

[Bug tree-optimization/50417] regression: memcpy with known alignment

[npl at chello dot at]

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

npl at chello dot at changed:

   What|Removed |Added

 CC||npl at chello dot at

--- Comment #7 from npl at chello dot at ---
This seems to affect even the most trivial cases. I ran the following code witn
arm gcc 4.8.4, 4.9.2 and 5.3.0:

#include 
#include 

uint32_t foo_noalign(const uint32_t *s) {
uint32_t v;
memcpy(, s, sizeof(v));
return v;
}

uint32_t foo(const uint32_t *s) {
uint32_t v;
memcpy(, __builtin_assume_aligned(s, 4), sizeof(v));
return v;
}

Which generates the following code:

 :
   0:   e92d4007push{r0, r1, r2, lr}
   4:   e3a02004mov r2, #4
   8:   e1a01000mov r1, r0
   c:   e08d0002add r0, sp, r2
  10:   ebfebl  0 
  14:   e59d0004ldr r0, [sp, #4]
  18:   e28dd00cadd sp, sp, #12
  1c:   e49de004pop {lr}; (ldr lr, [sp], #4)
  20:   e12fff1ebx  lr

0024 :
  24:   e590ldr r0, [r0]
  28:   e12fff1ebx  lr

Thats really, really bad. clang has no problems generating the optimal code.

[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0

[sulitsrc at 163 dot com]

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

--- Comment #4 from sulit  ---
ok

[Bug c/71812] gcc6/c++/functional:1726:40: internal compiler error: in assign_temp, at function.c:961

[noloader at gmail dot com]

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

--- Comment #6 from Jeffrey Walton  ---
(In reply to Richard Biener from comment #3)
> Duplicate of PR71811?

My bad... That's the same bug report.

When attempting to include the preprocessed source file in the original report,
I kept getting "Gateway Timeout" errors. Apparently one of them got enough
processing to create the report before the error was reported.

Jelinek's potential dup at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=71210
appears to be the duplicate.