[Bug c++/83662] New: std::aligned_alloc() not available

[nico at josuttis dot de]

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

Bug ID: 83662
   Summary: std::aligned_alloc() not available
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

C++17 is based on C11, which now standardizes aligned_alloc().
However,  does not provide it under namespace std:

#include 

int main()
{
  auto p1 = std::malloc(100); // OK
  auto p2 = aligned_alloc(64, 100);   // OK
  auto p3 = std::aligned_alloc(64, 100);  // ERROR
}

Error:
 prog.cc: In function 'int main()':
 prog.cc:7:18: error: 'aligned_alloc' is not a member of 'std'
   auto p3 = std::aligned_alloc(64, 100);  // ERROR
  ^
 prog.cc:7:18: note: suggested alternative: 'align_val_t'
   auto p3 = std::aligned_alloc(64, 100);  // ERROR
  ^
  align_val_t

[Bug tree-optimization/83661] sincos does not handle sin(2x)

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-unknown-linux-gnu
   Host||x86_64-unknown-linux-gnu
  Build||x86_64-unknown-linux-gnu
   Severity|normal  |enhancement

[Bug tree-optimization/83661] New: sincos does not handle sin(2x)

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 83661
   Summary: sincos does not handle sin(2x)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following test-case:

double f(double x)
{
  return __builtin_sin(2*x) + __builtin_sin(x);
}

optimzied dump with -O2 -funsafe-math-optimizations -ffast-math shows:
;; Function f (f, funcdef_no=0, decl_uid=1952, cgraph_uid=0, symbol_order=0)

   [local count: 1073741825]:
  _1 = __builtin_sin (x_4(D));
  _2 = x_4(D) * 2.0e+0;
  _3 = __builtin_sin (_2);
  _5 = _1 + _3;
  return _5;

Would it be a good idea to enhance sincos pass to recognize the
identity sin(2*x) = 2*sin(x)*cos(x) and thus eliminate one call
to __builtin_sin ?

Writing 2*sin(x)*cos(x) explicitly in the source yields following optimized
dump:

   [local count: 1073741825]:
  sincostmp_8 = __builtin_cexpi (x_5(D));
  _1 = IMAGPART_EXPR ;
  _2 = REALPART_EXPR ;
  _3 = _1 * _2;
  _4 = _3 * 2.0e+0;
  _6 = _2 + _4;
  return _6;

I agree in general that adding math identities like sin(x)**2 + cos(x)**2 = 1
isn't a good idea since user would almost always write the "optimized" version
in practice. However for the above case, would the transform make sense ?

Thanks,
Prathamesh

[Bug target/83660] New: ICE with vec_extract inside expression statement

[zoltan at hidvegi dot com]

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

Bug ID: 83660
   Summary: ICE with vec_extract inside expression statement
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoltan at hidvegi dot com
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64

Compile the following with g++ -mcpu=power7 -S ppc_vec_extract_ice.C
This probably happens with ppc64le as well. -mcpu=power7 is needed to make the
move go through memory, with power8 direct move instruction is used and there
is no coredump.

#include 

typedef __vector unsigned int  uvec32_t  __attribute__((__aligned__(16)));

unsigned get_word(uvec32_t v)
{
return ({const unsigned _B1 = 32;
vec_extract((uvec32_t)v, 2);});
}

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #13 from Alexandre Oliva  ---
We do have such constant propagation on such ports as x86* and arm, but not on
avr.  Presumably (I haven't checked) it has to do with available addressing
modes, and gimple's avoiding, even in MEM_REFs, address expressions that don't
fit its more stringent requirements.

[Bug libffi/83636] libffi/mips/n32: don't .set mips4 for mips r6

[syq at debian dot org]

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

--- Comment #1 from YunQiang Su  ---
and we found a new problem of libffi:

https://github.com/libffi/libffi/pull/401

   /* lui  $12,high(codeloc) */
tramp[2] = 0x3c0c | ((unsigned)codeloc >> 16);
/* jr   $25  */
 +#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
tramp[3] = 0x0328;
 +#else
 +  tramp[3] = 0x0329;
 +#endif
/* ori  $12,low(codeloc)  */
tramp[4] = 0x358c | ((unsigned)codeloc & 0x);
  #else
 @@ -743,7 +747,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
/* ori  $25,low(fn)  */
tramp[10] = 0x3739 | ((unsigned long)fn  & 0x);
/* jr   $25  */
 +#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
tramp[11] = 0x0328;
 +#else
 +  tramp[11] = 0x0329;
 +#endif
/* ori  $12,low(codeloc)  */
tramp[12] = 0x358c | ((unsigned long)codeloc & 0x);

[Bug rtl-optimization/83620] [8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1470: unable to find a register to spill with -flive-range-shrinkage --param=max-sched-ready-insns=0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
I don't see a good rationale behind disallowing 0 for that param.

It'd be interesting to look at the scheduler dumps to see queues the decisions
it makes at the key point.

[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---
No problem Eric.  I'm monitoring on behalf of Florian who'd really like to see
this fixed for gcc-8.

Actually just noticed it still wasn't showing up in the queries.  It didn't
have a target milestone set either, which I've just fixed.

[Bug middle-end/21161] [6/7/8 Regression] "clobbered by longjmp" warning ignores the data flow

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[egallager at gcc dot gnu.org]

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

--- Comment #20 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #19)
> Note you lost the regression marker when this was made a duplicate of 21161.
> So it's unlikely anyone would have looked at it until the next release cycle.
> 
> My understanding from Florian is that at least some of the issues here are
> regressions, so I've added the marker to 21161.

Oops, sorry, thanks for fixing it

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
You know, I wonder if we're missing something bigger here.

ISTM we're potentially missing CSEs in memory addresses as well as forward
propagation opportunities in MEM_REF expressions.

I strongly suspect DOM doesn't look inside a MEM_REF to see if the computed
address is lying around in hash table.

Similarly I wouldn't be surprised if forward propagation misses the opportunity
to eliminate instructions that compute addresses by propagating the constant
offset part into a MEM_REF.

[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass breaks shift result (at least on ia64)

[wilson at gcc dot gnu.org]

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

--- Comment #29 from Jim Wilson  ---
(In reply to Sergei Trofimovich from comment #28)
> 1. Is it directly visible for you from RTL dumps which bits GCC assumes as
> non-zero or you just know RTL invariants? I had to patch gcc locally to
> verify RTL prediction by adding printfs into print_pattern to get the idea
> how it works:

I stepped through combine in gdb to find the problem.

> 2. Does gcc have any validation mode that could have caught this error after
> code generation and checking against RTL invariant?

We have some compile-time and run-time checking code, but nothing that would
catch a problem like this.  We do have the regression testsuite which requires
manually adding testcases that get miscompiled, and hopefully prevents them
from getting miscompiled again.

[Bug c/83656] missing -Wbuiltin-declaration-mismatch on declaration without prototype

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83655,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82922

--- Comment #1 from Eric Gallager  ---
I can't confirm due to bug 83655, but regardless, my preferred solution would
be to fix bug 82922 first.

[Bug c++/83659] New: ICE on compilable C++ code: in tree_to_shwi, at tree.c:6821

[su at cs dot ucdavis.edu]

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

Bug ID: 83659
   Summary: ICE on compilable C++ code: in tree_to_shwi, at
tree.c:6821
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This affects 7.x and the current trunk, and is a regression from 6.4.x. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20180102 (experimental) [trunk revision 256110] (GCC)
$
$ g++-6.4.0 small.cpp
$ icc small.cpp
$ clang++ small.cpp
$
$ g++tk small.cpp
small.cpp: In function ‘int main()’:
small.cpp:7:42: internal compiler error: in tree_to_shwi, at tree.c:6821
   reinterpret_cast < int * > ()[-1] += 1;
  ^
0x11559a2 tree_to_shwi(tree_node const*)
../../gcc-source-trunk/gcc/tree.c:6821
0x703bd7 cxx_fold_indirect_ref
../../gcc-source-trunk/gcc/cp/constexpr.c:3112
0x70bc4b cxx_eval_indirect_ref
../../gcc-source-trunk/gcc/cp/constexpr.c:3215
0x70bc4b cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:4271
0x7126ed cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4769
0x715c06 maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4983
0x729de1 cp_fully_fold(tree_node*)
../../gcc-source-trunk/gcc/cp/cp-gimplify.c:2033
0x90b967 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:5381
0x919111 cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:8067
0x6d66ea build_new_op_1
../../gcc-source-trunk/gcc/cp/call.c:5963
0x6d6fce build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:6047
0x91b133 build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:8263
0x8042a6 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9458
0x80499a cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9586
0x808179 cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:11042
0x81185c cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10858
0x812a1f cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11185
0x812b2f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:11139
0x827f40 cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21681
0x827f40 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21716
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


---


typedef int V __attribute__ ((__vector_size__ (16)));

V a;

int main ()
{ 
  reinterpret_cast < int * > ()[-1] += 1;
  return 0;
}

[Bug libstdc++/83658] New: any::emplace deletes invalid memory when an overloaded operator new() throws

[cohenjon at google dot com]

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

Bug ID: 83658
   Summary: any::emplace deletes invalid memory when an overloaded
operator new() throws
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cohenjon at google dot com
  Target Milestone: ---

Note the following Wandbox: https://wandbox.org/permlink/1emVGP0a09lmd4g2 --
the std::any is still empty after new() throws and so the destructor should be
a no-op.  Instead it calls delete().

__do_emplace sets the manager pointer before attempting to create a new object.
 When new() throws after calling reset(), _M_ptr doesn't point to valid memory.
 When, later, the destructor is called on the any, the manager pointer still is
non-null, so the destructor, via reset(), will trigger the call to
_S_manage(_Op_destroy, ...), calling delete on the invalid _M_ptr.  

I believe setting the manager pointer after calling _S_create() will fix the
issue, since the manager pointer will still be null after _S_create_ propagates
the exception.

[Bug tree-optimization/83655] [8 Regression] ICE on an invalid call to memcpy declared with no prototype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00082.html

[Bug fortran/45689] [F03] Missing transformational intrinsic in the trans_func_f2003 list

[tkoenig at gcc dot gnu.org]

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

Bug 83650 Summary: [6/7/8 Regression]  Wrong simplification in cshift with 
negative shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83650

   What|Removed |Added

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

[Bug fortran/83650] [6/7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/83650] [6/7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan  2 23:03:11 2018
New Revision: 256113

URL: https://gcc.gnu.org/viewcvs?rev=256113=gcc=rev
Log:
2018-01-02  Thomas Koenig  

Backport from 7-branch
PR fortran/83650
* simplify.c (gfc_simplify_cshift): Correct contition for
negative shifts.

2018-01-02  Thomas Koenig  

Backport from 7-branch
PR fortran/83650
* gfortran.dg/simplify_cshift_1.f90: Correct condition.


Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/simplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/simplify_cshift_1.f90

[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass breaks shift result (at least on ia64)

[slyfox at inbox dot ru]

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

--- Comment #28 from Sergei Trofimovich  ---
Thanks all for very insightful comments and sorting out
WORD_REGISTER_OPERATIONS ambiguity! I've understood quite a bit on how RTL does
it's magic.

I still have a few related questions to clarify things:

1. Is it directly visible for you from RTL dumps which bits GCC assumes as
non-zero or you just know RTL invariants? I had to patch gcc locally to verify
RTL prediction by adding printfs into print_pattern to get the idea how it
works:

insn_cost 4 for20: [r347:DI]=r354:DI#0
insn_cost 4 for21: r357:SI=r343:SI<-<0x1

2. Does gcc have any validation mode that could have caught this error after
code generation and checking against RTL invariant?

[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #4 from David Malcolm  ---
(In reply to Jeffrey A. Law from comment #3)
> Adding David who knows the linemap bits.
> 
> David -- Mike has also posted a patch.  See gcc-patches archives Dec 1.

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00073.html

[Bug tree-optimization/83657] New: detect invalid calls to built-ins declared without prototype

[msebor at gcc dot gnu.org]

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

Bug ID: 83657
   Summary: detect invalid calls to built-ins declared without
prototype
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As pointed out in bug 83656, GCC (in C mode) fails to issue
-Wbuiltin-declaration-mismatch for the not-entirely-compatible memcpy
declaration with no prototype in the test case below.  This makes it possible
to not just overlook such declarations in source code but also miss invalid
calls to them as in the following test case.

Independent of the fix for bug 83656, this is a request to also detect and
diagnose such invalid calls, similarly to how Clang diagnoses them.

$ cat d.c && gcc -O2 -S -Wall -Wextra -Wpedantic d.c
#if __cplusplus
extern "C" void* memcpy (...);
#else
void* memcpy ();
#endif

void f (char *d)
{
  memcpy (3, d, "123");   // invalid, should be diagnosed
}


For reference, Clang issues the following warnings:
d.c:5:11: warning: incompatible integer to pointer conversion passing 'int' to
parameter of type 'void *' [-Wint-conversion]
  memcpy (3, d, "123");
  ^
d.c:5:17: warning: incompatible pointer to integer conversion passing 'char
[4]' to parameter of type 'unsigned long' [-Wint-conversion]
  memcpy (3, d, "123");
^
2 warnings generated.

[Bug c/83656] New: missing -Wbuiltin-declaration-mismatch on declaration without prototype

[msebor at gcc dot gnu.org]

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

Bug ID: 83656
   Summary: missing -Wbuiltin-declaration-mismatch on declaration
without prototype
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ issues a -Wbuiltin-declaration-mismatch for the memcpy declaration in the
test case below but GCC does not.  Since -Wstrict-prototypes is disabled by
default even in pedantic mode (see bug 82922) this makes it easy to overlook
such declarations in source code and miss invalid calls to them as in the
following test case:

$ cat d.c && gcc -O2 -S -Wall -Wextra -Wpedantic d.c
#if __cplusplus
extern "C" void* memcpy (...);
#else
void* memcpy ();
#endif

void f (char *d)
{
  memcpy (3, d, "123");
}

[Bug tree-optimization/83655] [8 Regression] ICE on an invalid call to memcpy declared with no prototype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-02
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83603
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/83655] New: [8 Regression] ICE on an invalid call to memcpy declared with no prototype

[msebor at gcc dot gnu.org]

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

Bug ID: 83655
   Summary: [8 Regression] ICE on an invalid call to memcpy
declared with no prototype
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When mecmpy() or strncpy() (and possibly other built-in functions) is declared
without a prototype and called with arguments of the wrong types GCC crashes in
the -Wrestrict pass.  This is a similar but not exactly the same problem as bug
83603 which points out a crash due to a call with an insufficient number of
arguments.

$ cat d.c && gcc -O2 -S -Wall d.c
void* memcpy ();

void f (void)
{
  memcpy (1, 2, "");
}
during GIMPLE pass: wrestrict
d.c: In function ‘f’:
d.c:3:6: internal compiler error: Segmentation fault
 void f (void)
  ^
0xfcd34d crash_signal
/ssd/src/gcc/git/gcc/toplev.c:325
0x7ada8a contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
/ssd/src/gcc/git/gcc/tree.h:3497
0x926f06 wi::extended_tree<128>::extended_tree(tree_node const*)
/ssd/src/gcc/git/gcc/tree.h:5443
0x925d0d generic_wide_int >::generic_wide_int(tree_node const* const&)
/ssd/src/gcc/git/gcc/wide-int.h:749
0x9258f2 wi::to_offset(tree_node const*)
/ssd/src/gcc/git/gcc/tree.h:5395
0xbfdfe3 builtin_memref
/ssd/src/gcc/git/gcc/gimple-ssa-warn-restrict.c:393
0xc04286 check_bounds_or_overlap(gcall*, tree_node*, tree_node*, tree_node*,
tree_node*, bool)
/ssd/src/gcc/git/gcc/gimple-ssa-warn-restrict.c:1720
0xc041a0 check_call
/ssd/src/gcc/git/gcc/gimple-ssa-warn-restrict.c:1691
0xbfd0a6 before_dom_children
/ssd/src/gcc/git/gcc/gimple-ssa-warn-restrict.c:106
0x1b6127f dom_walker::walk(basic_block_def*)
/ssd/src/gcc/git/gcc/domwalk.c:308
0xbfd12a execute
/ssd/src/gcc/git/gcc/gimple-ssa-warn-restrict.c:120
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/83541] Missed optimization with int overflow

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Richard Biener from comment #3)
> I've deliberately avoided doing this ... (turning SSA propagator UNDEFINED
> into a random value rather than keeping it effectively VARYING during
> propagation/simplification stage).  CCP is the only pass that even tries
> to handle arithmetic with UNDEF somehow.
> 
> The case in question could be teached to both EVRP and DOM (you need those
> conditional equivalences).

I am not sure if we can handle uninitialized variables and impossible values
(result of an overflow) together, they don't have the same properties. (I am
not saying that is what you suggested, just that I am too confused about UNDEF)

> Note that our constant folding machinery simply computes stuff in twos
> complement as it lacks a way to say "undefined".

The constant stuff has TREE_OVERFLOW. We usually drop_tree_overflow, but for
instance gimple_resimplify* could insert __builtin_unreachable() in seq (or
something similar if having __builtin_unreachable in the middle of a bb causes
trouble). Of course, important passes would then ignore this folding because
they don't want any extra insn :-( Maybe a way to say impossible would be nice,
I don't know if reusing error_mark_node would make sense.

> How useful would this be in practice?  Apart from breaking some invalid code
> in unexpected ways?

I don't believe the breaking would be particularly bad. We already exploit the
same information in VRP, it just shows up in different forms, sometimes by
letting you fold a condition, other times by creating an empty range, and it is
quite inconsistent to exploit it in one case and not the other. Replacing an
empty range with an arbitrary singleton as we do likely already breaks some
invalid code, and replacing an empty range with varying has the weird effect
that a tighter range gives less optimizations than a wider range.

__builtin_unreachable() often back-propagates a bit through trivial statements
and removes a branch, or reduces a PHI. The threader cannot handle everything.
Of course, it is hard to guess the true impact... I hit the VR_EMPTY case
regularly, but there is a strong bias in the code I look at ;-)

[Bug middle-end/83654] -fstack-clash-protection probes below the stack pointer for VLA with constant size

[fw at gcc dot gnu.org]

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

--- Comment #2 from Florian Weimer  ---
I forgot to add a compiler barrier to f2 for the executable test case, so it is
not strictly equivalent.

With it, valgrind reports:

==375147== Invalid read of size 4
==375147==at 0x8048403: f2 (in /root/build-32/a.out)
==375147==by 0x80482CA: main (in /root/build-32/a.out)
==375147==  Address 0xfebb3d0c is on thread 1's stack
==375147==  4 bytes below stack pointer

valgrind warns about the final probe.  Here's the disassembly with addresses:

080483e0 :
 80483e0:   55  push   %ebp
 80483e1:   89 e5   mov%esp,%ebp
 80483e3:   83 ec 08sub$0x8,%esp
 80483e6:   8d 84 24 00 f0 ff fflea-0x1000(%esp),%eax
 80483ed:   39 c4   cmp%eax,%esp
 80483ef:   74 12   je 8048403 
 80483f1:   81 ec 00 10 00 00   sub$0x1000,%esp
 80483f7:   83 8c 24 fc 0f 00 00orl$0x0,0xffc(%esp)
 80483fe:   00 
 80483ff:   39 c4   cmp%eax,%esp
 8048401:   75 ee   jne80483f1 
 8048403:   83 4c 24 fc 00  orl$0x0,-0x4(%esp)
 8048408:   83 ec 0csub$0xc,%esp
 804840b:   50  push   %eax
 804840c:   e8 bf ff ff ff  call   80483d0 
 8048411:   c9  leave  
 8048412:   c3  ret

[Bug libfortran/83649] Large reads fail

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #5 from Dominique d'Humieres  ---
> Yes, assigning to myself. So it works on macOS. Did you also test whether
> it fails without the patch?

Yes, it did fail without the patch.

> Another question is whether the current value of MAX_CHUNK is optimal,
> or whether some smaller value might be better.

First I feared that MAX_CHUNK was too large by one, but this was not the case.

[Bug c/83586] [8 regression] Invalid -Wformat-truncation on stdio2.h

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The -Wformat-truncation warning relies on optimization to detect sizes and
ranges of sprintf arguments.  As optimizations improve the warning will detect
more instances of possible overflows.

I don't know what the source code looks like (we ask for a preprocessing
translation unit to reproduce errors) but the text of the warning suggests that
snprintf is being called to format a string of an unknown length stored in an
array of 128 chars into a buffer that has at most 126 bytes of space left,
allowing for the function to truncate the directive's output.  Below is a test
case that reproduces a similar warning with GCC 8.  GCC 7 doesn't diagnose it
because of bug 79538.  The solution to avoid the warning is to either a)
provide a buffer of sufficient size, or b) constrain the length of the string
argument to the %s directive to avoid the possible truncation, or c) handle the
truncation by using the snprintf return value to take some action (something
GCC doesn't optimize away).

Please either confirm whether this is what's going on in LinuxGamepad.cpp or
provide a preprocessing translation unit of the file that reproduces the
warning so it can be analyzed.

$ cat d.c && gcc -O2 -S -Wall -Wextra d.c
void f (char *d, unsigned long x)
{
  extern char a[128];

  x >>= 4;

  __builtin_snprintf (d, 128, "%lx %s", x, a);
}
d.c: In function ‘f’:
d.c:7:36: warning: ‘%s’ directive output may be truncated writing up to 127
bytes into a region of size between 112 and 126 [-Wformat-truncation=]
   __builtin_snprintf (d, 128, "%lx %s", x, a);
^~  ~
d.c:7:3: note: ‘__builtin_snprintf’ output between 3 and 144 bytes into a
destination of size 128
   __builtin_snprintf (d, 128, "%lx %s", x, a);
   ^~~

[Bug middle-end/83654] -fstack-clash-protection probes below the stack pointer for VLA with constant size

[fw at gcc dot gnu.org]

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

--- Comment #1 from Florian Weimer  ---
I forgot to mention that I used “-O2 -fstack-clash-protection”, but there's a
valgrind warning with -O0, too.

[Bug middle-end/83654] New: -fstack-clash-protection probes below the stack pointer for VLA with constant size

[fw at gcc dot gnu.org]

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

Bug ID: 83654
   Summary: -fstack-clash-protection probes below the stack
pointer for VLA with constant size
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43010=edit
const-vla.c

On i386, the reproducer compiles to:

f2:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$8, %esp
leal-4096(%esp), %eax
cmpl%eax, %esp
je  .L5
.L7:
subl$4096, %esp
orl $0, 4092(%esp)
cmpl%eax, %esp
jne .L7
.L5:
orl $0, -4(%esp)

The final probe accesses memory below the stack pointer.  i386 does not have a
red zone, so this results in a valgrind warning:

==375071== Invalid read of size 4
==375071==at 0x80482EE: main (in /root/build-32/a.out)
==375071==  Address 0xfeb83d0c is on thread 1's stack
==375071==  4 bytes below stack pointer

I don't think this issue is observable without valgrind, so the severity is
low.  However, it affects glibc's getaddrinfo implementation, so it seems
worthwhile addressing this.

The issue might not be target-specific.  x86-64 results in similar code, but
valgrind won't warn because of the red zone.

[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function

[law at redhat dot com]

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

--- Comment #19 from Jeffrey A. Law  ---
Note you lost the regression marker when this was made a duplicate of 21161. 
So it's unlikely anyone would have looked at it until the next release cycle.

My understanding from Florian is that at least some of the issues here are
regressions, so I've added the marker to 21161.

[Bug libfortran/83649] Large reads fail

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #4 from Janne Blomqvist  ---
Yes, assigning to myself. So it works on macOS. Did you also test whether it
fails without the patch?

It'd be nice to have some test results on win64 as well, but I guess we have
noone to run those. At least with the patch it shouldn't be worse than with
trunk.

Another question is whether the current value of MAX_CHUNK is optimal, or
whether some smaller value might be better..

[Bug c/83653] New: GCC fails to remove a can't-happen call on ia64

[matthew at wil dot cx]

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

Bug ID: 83653
   Summary: GCC fails to remove a can't-happen call on ia64
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew at wil dot cx
  Target Milestone: ---

Created attachment 43009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43009=edit
Gzipped preprocessed source

This is an excerpt from the Linux kernel, with some patches that I'm preparing
to go in.  The 0day build-bot reports a problem with an undefined
__bad_increment_for_ia64_fetch_and_add.

I can reproduce the problem by taking the attached preprocessed source and
compiling it with gcc -O2 -o shmem.o -c shmem.i and then running nm shmem.o
|grep __bad

Manually inlining page_ref_sub() in the included test-case makes the problem go
away, as does simply deleting the call to page_ref_sub() (at line 50756).

Command line:   gcc -Wp,-MD,mm/.shmem.o.d  -nostdinc -isystem
/usr/lib/gcc/ia64-linux-gnu/4.6/include -I./arch/ia64/include
-I./arch/ia64/include/generated  -I./include -I./arch/ia64/include/uapi
-I./arch/ia64/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__
-DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE
-DHAVE_SERIALIZE_DIRECTIVE -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89
-Wno-unused-but-set-variable -fno-PIE -pipe -ffixed-r13
-mfixed-range=f12-f15,f32-f127 -falign-functions=32 -frename-registers
-fno-optimize-sibling-calls -fno-delete-null-pointer-checks -O2
-DCC_HAVE_ASM_GOTO -Wframe-larger-than=2048 -fno-stack-protector
-fomit-frame-pointer -fno-var-tracking-assignments -g
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fno-stack-check -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init  -mconstant-gp  -DKBUILD_BASENAME='"shmem"' 
-DKBUILD_MODNAME='"shmem"' -c -o mm/.tmp_shmem.o mm/shmem.c

[Bug preprocessor/83602] [8 Regression] ICE in cpp_macro_definition_location(cpp_hashnode*) on invalid code

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Sorry about the breakage.

Patch looks reasonable to me.  Maybe cpp_macro_definition_location should gain
an assertion that CPP_HASHNODE_VALUE_IDX (node) == NTV_MACRO ?

[Bug c++/83652] New: template substitution fails on operator

[sameer.varyani at gmail dot com]

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

Bug ID: 83652
   Summary: template substitution fails on operator
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sameer.varyani at gmail dot com
  Target Milestone: ---

Created attachment 43008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43008=edit
testcase

template substitution failure in the attached code resulting in following
error:

test.cpp: In function ‘int main()’:
test.cpp:34:4: error: invalid conversion from ‘int’ to ‘Enum_t’ [-fpermissive]
  b ^= somedef;

Also broken in gcc 6.2.0

This code is confirmed to be working with clang+ and VS++15.

[Bug fortran/45689] [F03] Missing transformational intrinsic in the trans_func_f2003 list

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan  2 18:14:04 2018
New Revision: 256088

URL: https://gcc.gnu.org/viewcvs?rev=256088=gcc=rev
Log:
2017-01-02  Thomas Koenig  

PR fortran/45689
* intrinsic.c (add_function): Add gfc_simplify_maxloc and
gfc_simplify_minloc to maxloc and minloc, respectively.
* intrinsic.h: Add prototypes for gfc_simplify_minloc
and gfc_simplify_maxloc.
* simplify.c (min_max_chose): Adjust prototype.  Modify function
to have a return value which indicates if the extremum was found.
(is_constant_array_expr): Fix typo in comment.
(simplify_minmaxloc_to_scalar): New function.
(simplify_minmaxloc_nodim): New function.
(new_array): New function.
(simplify_minmaxloc_to_array): New function.
(gfc_simplify_minmaxloc): New function.
(simplify_minloc): New function.
(simplify_maxloc): New function.

2017-01-02  Thomas Koenig  

PR fortran/45689
* gfortran.dg/minloc_4.f90: New test case.
* gfortran.dg/maxloc_4.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/maxloc_4.f90
trunk/gcc/testsuite/gfortran.dg/minloc_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/simplify.c

[Bug c++/83556] [7/8 Regression] ICE in gimplify_expr, at gimplify.c:12004

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  2 18:07:41 2018
New Revision: 256087

URL: https://gcc.gnu.org/viewcvs?rev=256087=gcc=rev
Log:
PR c++/83556
* tree.c (replace_placeholders_r): Pass NULL as last argument to
cp_walk_tree instead of d->pset.  If non-TREE_CONSTANT and
non-PLACEHOLDER_EXPR tree has been seen already, set *walk_subtrees
to false and return.
(replace_placeholders): Pass NULL instead of  as last argument
to cp_walk_tree.

* g++.dg/cpp0x/pr83556.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/pr83556.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/tree.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/83556] [7/8 Regression] ICE in gimplify_expr, at gimplify.c:12004

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  2 18:04:19 2018
New Revision: 256086

URL: https://gcc.gnu.org/viewcvs?rev=256086=gcc=rev
Log:
PR c++/83556
* tree.c (replace_placeholders_r): Pass NULL as last argument to
cp_walk_tree instead of d->pset.  If non-TREE_CONSTANT and
non-PLACEHOLDER_EXPR tree has been seen already, set *walk_subtrees
to false and return.
(replace_placeholders): Pass NULL instead of  as last argument
to cp_walk_tree.

* g++.dg/cpp0x/pr83556.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr83556.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83650] [6/7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan  2 18:01:31 2018
New Revision: 256085

URL: https://gcc.gnu.org/viewcvs?rev=256085=gcc=rev
Log:
2018-01-02  Thomas Koenig  

PR fortran/83650
* simplify.c (gfc_simplify_cshift): Correct contition for
negative shifts.

2018-01-02  Thomas Koenig  

PR fortran/83650
* gfortran.dg/simplify_cshift_1.f90: Correct condition.


Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/simplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/simplify_cshift_1.f90

[Bug other/83497] CPU2000 172.mgrid starts failing with r254730

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen  ---
(In reply to Pat Haugen from comment #0)
> mgrid started failing (output miscompare) with r254730. The following
> options demonstrate the failure "-O3 -mcpu=power6 -ffast-math".

Incomplete option set, -m32 is also required.

[Bug fortran/45689] [F03] Missing transformational intrinsic in the trans_func_f2003 list

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan  2 17:51:26 2018
New Revision: 256084

URL: https://gcc.gnu.org/viewcvs?rev=256084=gcc=rev
Log:
2018-01-02  Thomas Koenig  

PR fortran/45689
PR fortran/83650
* simplify.c (gfc_simplify_cshift): Re-implement to allow full
range of arguments.

2018-01-02  Thomas Koenig  

PR fortran/45689
PR fortran/83650
* gfortran.dg/simplify_cshift_1.f90: Correct erroneous case.
* gfortran.dg/simplify_cshift_4.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/simplify_cshift_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/simplify_cshift_1.f90

[Bug libfortran/83649] Large reads fail

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-02
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Should it be marked as ASSIGNED? IMO worth a back port (otherwise it should be
closed as FIXED).

[Bug fortran/83650] [6/7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jan  2 17:51:26 2018
New Revision: 256084

URL: https://gcc.gnu.org/viewcvs?rev=256084=gcc=rev
Log:
2018-01-02  Thomas Koenig  

PR fortran/45689
PR fortran/83650
* simplify.c (gfc_simplify_cshift): Re-implement to allow full
range of arguments.

2018-01-02  Thomas Koenig  

PR fortran/45689
PR fortran/83650
* gfortran.dg/simplify_cshift_1.f90: Correct erroneous case.
* gfortran.dg/simplify_cshift_4.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/simplify_cshift_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/simplify_cshift_1.f90

[Bug rtl-optimization/83565] [7/8 regression] RTL combine pass breaks shift result (at least on ia64)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #27 from Jeffrey A. Law  ---
WORD_REGISTER_OPERATIONS says the operations in integral modes smaller than a
word are performed on the entire register (ie a word).

I think WORD_REGISTER_OPERATIONS is fairly intuitive when it comes to
arithmetic and logicals. For arith/logicals I would find myself agreeing with
Eric in c#25.

However, I think it's not as clear for shifts/rotates.

On the PA (which defines WORD_REGISTER_OPERATIONS) we have 32bit
deposit/extract  which are used for various shifts.  The 32bit extract/deposit
instructions set the low 32 bits in the expected way, but leave the upper bits
undefined.  So I suspect PA and IA-64 have similar behavior (big surprise).

One could argue that WORD_REGISTER_OPERATIONS should apply to just arith and
logicals.  One could also argue that it should apply to shifts in which case
ports like the PA and IA-64 probably shouldn't define WORD_REGISTER_OPERATIONS.

If we were to argue that WORD_REGISTER_OPERATIONS should apply to just
arith/logicals, then the PA would need to be audited for cases where we might
implement an arith operation using shifts (deposit/extract instructions).

And just to be clear here.  I don't think the PA or IA-64 ought to drive
decisions in this area.  They're both dead architectures -- but others may have
similar properties.


Note none of this touches on what are the high bits of a paradoxical subreg,
which are undefined in RTL.  So I'm in partial agreement with Jim c#11 as well.

[Bug c++/83592] [8 Regression] Annoying -Wparentheses warnings

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
IOW:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10866,10 +10866,11 @@ grokdeclarator (const cp_declarator *declarator,

   inner_declarator = declarator->declarator;

-  /* We don't want to warn in parmeter context because we don't
+  /* We don't want to warn in parameter context because we don't
 yet know if the parse will succeed, and this might turn out
 to be a constructor call.  */
   if (decl_context != PARM
+ && decl_context != TYPENAME
  && declarator->parenthesized != UNKNOWN_LOCATION
  /* If the type is class-like and the inner name used a
 global namespace qualifier, we need the parens.

[Bug c++/83592] [8 Regression] Annoying -Wparentheses warnings

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I'm wondering if simply disabling the warning in TYPENAME would make sense (it
suppresses the warning).

[Bug other/83497] CPU2000 172.mgrid starts failing with r254730

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  ---
(In reply to Richard Biener from comment #2)
> 
> As far as I see the miscompare is -0.8 vs. 0.18 so it doesn't look like a
> precision issue to me.  Does it only happen for power6 / bigendian?
> 

Yes, the failure is only for -mcpu=power6. I don't have a copy of CPU2000 that
runs on powerpc64le, so can't say for sure if it's a big endian issue only.

I will do some further digging on the failure.

[Bug c++/83644] ICE using type alias from recursive decltype in noexcept or return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/82190] Possibly latent miscompilation issue on ppc64le-linux-gnu for memcpy-bi.c with -fweb -fno-optimize-strlen

[acsawdey at gcc dot gnu.org]

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

--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Jan  2 17:02:17 2018
New Revision: 256083

URL: https://gcc.gnu.org/viewcvs?rev=256083=gcc=rev
Log:
Add missing changelog entry:

2017-12-12  Aaron Sawdey  

PR target/82190
* config/rs6000/rs6000-string.c (expand_block_compare,
expand_strn_compare): Fix set_mem_size() calls.



Modified:
trunk/gcc/ChangeLog

[Bug c++/83644] ICE using type alias from recursive decltype in noexcept or return type

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan  2 17:02:14 2018
New Revision: 256082

URL: https://gcc.gnu.org/viewcvs?rev=256082=gcc=rev
Log:
PR c++/83644
* g++.dg/cpp1z/pr83644.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/pr83644.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83651] New: [7.2 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

Bug ID: 83651
   Summary: [7.2 regression] 20% slowdown of linux kernel AES
cipher
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Following the discussion on PR83356, I did some more performance analysis of
the AES code with various compiler versions, by running the in-kernel crypto
selftest (kvm -kernel linux/arch/x86/boot/bzImage -append "tcrypt.mode=200
tcrypt.sec=1 console=ttyS0"  -nographic -serial mon:stdio), which showed a very
clear slowdown at gcc-7.2 (dated 20171130) compared to 7.1, all numbers are in
cycles/byte for AES256+CBC on a 3.1GHz AMD Threadripper, lower numbers are
better:

default  ubsan patchedpatched+ubsan
gcc-4.3.6 -O214.9   14.9 
gcc-4.6.4 -O215.0   15.8 
gcc-4.9.4 -O215.520.7   15.9 20.9
gcc-5.5.0 -O215.647.3   86.4 48.8
gcc-6.3.1 -O214.649.4   94.3 50.9
gcc-7.1.1 -O213.554.6   15.2 52.0
gcc-7.2.1 -O216.8   124.7   92.0 52.2
gcc-8.0.0 -O214.656.6   15.3 53.5
gcc-7.1.1 -O114.653.8
gcc-7.2.1 -O115.555.9
gcc-8.0.0 -O115.050.7
clang-5 -O1  21.758.3
clang-5 -O2  15.549.1
handwritten asm  16.4

The 'patched' columns are with '-ftree-pre and -ftree-sra' disabled in the
sources, which happened to help on gcc-7.2.1 for performance and to work around
PR83356 but made things worse for most other cases.

For better reproducibility, I tried doing the same with the libressl
implementation of the same cipher, which also has interesting but unfortunately
very different results:

gcc-5.5.0 -O249.0
gcc-6.3.1 -O248.8
gcc-7.1.1 -O259.7
gcc-7.2.1 -O260.3
gcc-8.0.0 -O259.6

gcc-5.5.0 -O159.5
gcc-6.3.1 -O148.5
gcc-7.1.1 -O151.6
gcc-7.2.1 -O151.6
gcc-8.0.0 -O151.6

The source code is apparently derived from a common source, but has evolved in
different ways, and the version from the kernel appears to be much faster
overall. In both cases, we see a ~20% degradation between gcc-6.3.1 and
gcc-7.2.1, but gcc-7.1.1 happens to produce the best results for the kernel
version and very bad results for the libressl sources. The stack consumption
problem from PR83356 does not appear with the libressl sources. I have not
managed to run a ubsan-enabled libressl binary for testing.

To put this in context, both libressl and Linux come with architecture-specific
versions using SIMD registers for most architectures, and those tend to be much
faster, but the C version is used on old x86 CPUs and minor architectures that
lack SIMD registers or an AES implementation for them.

If there is enough interest in addressing the slowdown, it should be possible
to create a version of the kernel AES implementation that can be run in user
space, as the current method of reproducing the results is fairly tedious.

[Bug fortran/83650] [6/7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|7.4 |6.5

--- Comment #2 from Thomas Koenig  ---
Patch for gcc-7:

Index: fortran/simplify.c
===
--- fortran/simplify.c  (Revision 256009)
+++ fortran/simplify.c  (Arbeitskopie)
@@ -1991,7 +1991,9 @@ gfc_simplify_cshift (gfc_expr *array, gfc_expr *sh
   mpz_clear (size);

   /* Adjust shft to deal with right or left shifts. */
-  shft = shft < 0 ? 1 - shft : shft;
+  shft = shft % sz;
+  if (shft < 0)
+   shft += sz;

   /* Special case: Shift to the original order!  */
   if (sz == 0 || shft % sz == 0)
Index: testsuite/gfortran.dg/simplify_cshift_1.f90
===
--- testsuite/gfortran.dg/simplify_cshift_1.f90 (Revision 256009)
+++ testsuite/gfortran.dg/simplify_cshift_1.f90 (Arbeitskopie)
@@ -23,12 +23,12 @@ program foo
v = cshift(c, 2)
if (any(b /= v)) call abort

-   ! Special cases shift = 0, size(a), 1-size(a)
+   ! Special cases shift = 0, size(a), size(a)
b = cshift([1, 2, 3, 4, 5], 0)
if (any(b /= a)) call abort
b = cshift([1, 2, 3, 4, 5], size(a))
if (any(b /= a)) call abort
-   b = cshift([1, 2, 3, 4, 5], 1-size(a))
+   b = cshift([1, 2, 3, 4, 5], -size(a))
if (any(b /= a)) call abort

! simplification of array arg.

[Bug c++/83592] [8 Regression] Annoying -Wparentheses warnings

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-02
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Started with r253446.

[Bug c++/83644] ICE using type alias from recursive decltype in noexcept or return type

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Reduced to:
namespace std {
template  bool is_invocable_v;
}
template  auto compose(F) {
  [](auto... objs) noexcept(std::is_invocable_v){};
}

auto f() { compose(3); }

[Bug target/83641] -fstack-clash-protection generates incorrect CFI on i386

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
So the issue here is when we have a noreturn function we use a push/pop
sequence to probe the top of the stack.

The generic dwarf2 CFI bits interpret the pop as restoring the value of the
popped register.  But that's not strictly correct if the register is also
callee-saved (which implies that it'll be set later by the body of the
function).

Of course the push/pop sequence is not needed in this case since the callee
register save acts as a probe.  This is a known, relatively minor,
inefficiency.

The good news is the bogus CFI issue is a strict subset of the performance
issue and thus if we fix the performance issue, the codegen issue gets resolved
at the same time.  I expect to have this fixed within the next couple hours.

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[petr.spacek at nic dot cz]

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

--- Comment #19 from Petr Špaček  ---
Sure, I would be happy with any version, thank you!

For people who want to generate code coverage reports for parallel executions,
beware of https://github.com/linux-test-project/lcov/issues/37.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[sergey.shalnov at intel dot com]

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

--- Comment #20 from sergey.shalnov at intel dot com ---
Richard,
I did quick static analysis for your latest patch.
Using command line “-g -Ofast -mfpmath=sse -funroll-loops -march=znver1” your
latest patch 
doesn’t affects the issue I discussed but it affects costs for first loop. 
I thought the loop costs should be calculated in other place (tree-vect-loop.c)
but as I can see everything is interconnected.

The SLP block we discussed remains with the same statistic:
  Vector inside of basic block cost: 64
  Vector prologue cost: 32
  Vector epilogue cost: 0
  Scalar cost of basic block: 256
note: Basic block will be vectorized using SLP

First loop was:
note: Cost model analysis:.
  Vector inside of loop cost: 5392
  Vector prologue cost: 48
  Vector epilogue cost: 0
  Scalar iteration cost: 464
  Scalar outside cost: 0
  Vector outside cost: 48
  prologue iterations: 0
  epilogue iterations: 0
note: cost model: the vector iteration cost = 5392 divided by the scalar
iteration cost = 464 is greater or equal to the vectorization factor = 4.

Became:
note: Cost model analysis:
  Vector inside of loop cost: 5392
  Vector prologue cost: 192
  Vector epilogue cost: 0
  Scalar iteration cost: 464
  Scalar outside cost: 0
  Vector outside cost: 192
  prologue iterations: 0
  epilogue iterations: 0
note: cost model: the vector iteration cost = 5392 divided by the scalar
iteration cost = 464 is greater or equal to the vectorization factor = 4.

Sergey

[Bug target/83641] -fstack-clash-protection generates incorrect CFI on i386

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
Note this is specific to x86/x86_64 noreturn functions.  No other targets are
potentially affected.

[Bug target/83641] -fstack-clash-protection generates incorrect CFI on i386

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-02
 Ever confirmed|0   |1

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  ---
> I don't see the distinction here.  Ia64 has instructions that operate on
> 32-bit values too, like cmp4.

The distinction is precisely what WORD_REGISTER_OPERATIONS conveys.  On SPARC
and MIPS for example, for a 32-bit operation in 64-bit mode, the entire 64-bit
register is modified and the upper bits contain well defined bits.

> On sparc, given this testcase
> int
> sub (int i, int j, int k)
> {
>   return i + j + k;
> }
> the compiler generates
> sub:
>   add %o0, %o1, %o0
>   add %o0, %o2, %o0
>   jmp %o7+8
>sra%o0, 0, %o0
> Note that the add instruction operates on the entire 64-bit register, and
> after the first add, we no longer have a valid 32-bit value, because there
> might have been an overflow.  This is why we need the sra at the end to
> sign-extend the return value, because we know that the upper 32-bits are
> don't care bits.

No, the upper bits are well defined by the SPARC-V9 architecture.

> If you take a paradoxical subreg of a SImode reg after an add instruction,
> you can't make any assumptions about the upper 32-bits of the value in the
> register.  Exactly the same as ia64.

No, you know what the bits are on SPARC and MIPS for example if you know the
contents of the entire 64-bit register before the addition.

> I do see that the fact that sparc has 32-bit shift instructions defined
> means the testcase that fails on ia64 will not fail on sparc.  But if we
> rely on that for the WORD_REGISTER_OPERATIONS definition, then it gets even
> messier than it already is.

I agree that we may need to do something for operations that don't have a clear
meaning when "extended" to the full work though.

Let me give it some thought...

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #26 from Eric Botcazou  ---
Investigating.

[Bug fortran/83650] [6/7/8 Regression] Wrong simplification in cshift with negative shifts

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
  Known to work||5.5.0
Summary|[7/8 Regression]  Wrong |[6/7/8 Regression]  Wrong
   |simplification in cshift|simplification in cshift
   |with negative shifts|with negative shifts
  Known to fail||6.4.0, 7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Likely r230726 or r230832.

[Bug target/83641] -fstack-clash-protection generates incorrect CFI on i386

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ipa/83532] [8 Regression] ICE in apply_scale, at profile-count.h:955

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug tree-optimization/83541] Missed optimization with int overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-02
Version|tree-ssa|8.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I've deliberately avoided doing this ... (turning SSA propagator UNDEFINED
into a random value rather than keeping it effectively VARYING during
propagation/simplification stage).  CCP is the only pass that even tries
to handle arithmetic with UNDEF somehow.

The case in question could be teached to both EVRP and DOM (you need those
conditional equivalences).

Note that our constant folding machinery simply computes stuff in twos
complement
as it lacks a way to say "undefined".

How useful would this be in practice?  Apart from breaking some invalid code in
unexpected ways?

[Bug fortran/83650] [7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-02
 Blocks||45689
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug 45689] [F03] Missing transformational intrinsic in the trans_func_f2003
list

[Bug fortran/83650] New: [7/8 Regression] Wrong simplification in cshift with negative shifts

[tkoenig at gcc dot gnu.org]

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

Bug ID: 83650
   Summary: [7/8 Regression]  Wrong simplification in cshift with
negative shifts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Discovered investigating a "failure" in my current work on the
cshift patch:

program main
  integer, dimension(5), parameter :: b = [1,2,3,4,5]
  integer, dimension(5) :: a = [1,2,3,4,5]
  print *,cshift(a, -4)
  print *,cshift(b, -4)
end program main

yields:

   2   3   4   5   1
   1   2   3   4   5

The first result (run-time) is correct.

I will fix this with my upcoming 8 patch for cshift, but it
will still be necessary to correct this on the previous branches.
Should be rather easy.

[Bug tree-optimization/83544] Missed optimization opportunity for constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-02
 Ever confirmed|0   |1

[Bug target/83554] [8 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:41274 with -mmitigate-rop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/83555] Unnecessary null check when static_cast is used with references.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
missed opitmization in the C++ FE.

[Bug tree-optimization/83563] [8 Regression] [graphite] ICE: Segmentation fault (in instantiate_scev_r)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/83580] [6/7/8 Regression] Wrong code caused by vectorization

[rguenth at gcc dot gnu.org]

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

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

[Bug tree-optimization/83573] [6/7/8 Regression] invalid access introduced in predcom

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug c++/81860] [7 Regression] Call to undefined inline function involving inheriting constructors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[7/8 Regression] Call to|[7 Regression] Call to
   |undefined inline function   |undefined inline function
   |involving inheriting|involving inheriting
   |constructors|constructors

--- Comment #7 from Marek Polacek  ---
Done.

[Bug tree-optimization/83573] [6/7/8 Regression] invalid access introduced in predcom

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83580] [6/7/8 Regression] Wrong code caused by vectorization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Mine.

[Bug c++/81860] [7/8 Regression] Call to undefined inline function involving inheriting constructors

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan  2 15:05:09 2018
New Revision: 256076

URL: https://gcc.gnu.org/viewcvs?rev=256076=gcc=rev
Log:
PR c++/81860
* g++.dg/cpp0x/inh-ctor30.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor30.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/83585] [8 Regression] Assembler messages: Error: can't resolve `.text' {.text section} - `.LCOLDB0' {.text.unlikely section}

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c/83586] [8 regression] Invalid -Wformat-truncation on stdio2.h

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |8.0

[Bug c++/83592] [8 Regression] Annoying -Wparentheses warnings

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |8.0

[Bug ipa/83594] [8 Regression] ICE: in function_and_variable_visibility, at ipa-visibility.c:640 with __attribute__((noipa))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83593] [8 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/83644] ICE using type alias from recursive decltype in noexcept or return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-02
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
On it.

[Bug tree-optimization/83605] [6/7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug tree-optimization/83603] [8 Regression] ICE in builtin_memref at gcc/gimple-ssa-warn-restrict.c:238

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug ipa/83619] [8 Regression] ICE in inliner: caller edge count does not match BB count

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug rtl-optimization/83621] [8 Regression] ICE: in simplify_subreg, at simplify-rtx.c:6293 with -O -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/83629] [7/8 Regression] ICE: in decompose_normal_address, at rtlanal.c:6329 with -O2 -fPIC -frename-registers --param=sched-autopref-queue-depth=nnn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

[Bug tree-optimization/83640] [8 Regression] ICE in generic_overlap, at gimple-ssa-warn-restrict.c:814

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/83644] ICE using type alias from recursive decltype in noexcept or return type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This got fixed on the trunk with r251433.  We should add the testcase to the
testsuite.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #43 from rguenther at suse dot de  ---
On Tue, 2 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #41 from rguenther at suse dot de  ---
> [...]
> >> Unfortunately not: it's really the section index pointing to the
> >> non-existing (i.e. eliminated) .gnu.debuglto_.debug_info section.
> >
> > But that section shouldn't be eliminated :/
> 
> IIUC it has been renamed to .debug_info:
> 
> * input object (cp_lto_pr42987_0.o):
> 
> Section Header[9]:  sh_name: .gnu.debuglto_.debug_info
> sh_addr:  0   sh_flags:   0
> sh_size:  0x3d4   sh_type:[ SHT_PROGBITS ]
> sh_offset:0x7fb   sh_entsize: 0
> sh_link:  0   sh_info:0
> sh_addralign: 0x1   
> 
> * output object (ccw3tETddebugobjtem):
> 
> Section Header[2]:  sh_name: .debug_info
> sh_addr:  0   sh_flags:   0
> sh_size:  0x3d4   sh_type:[ SHT_PROGBITS ]
> sh_offset:0x84d   sh_entsize: 0
> sh_link:  0   sh_info:0
> sh_addralign: 0x1   
> 
> without adapting section indices in .symtab.

Yes.  It should have retained [9] as section index.  Hmmm - you
have the patch removing sections in your tree?  I guess you need
to adapt (aka remap) the first_shndx section index I added with
the patch for the hpux ld issue.

> Besides, there's also a dangling
> 
> Section Header[6]:  sh_name: .rel.gnu.debuglto_.debug_info
> sh_addr:  0   sh_flags:   0
> sh_size:  0x8 sh_type:[ SHT_REL ]
> sh_offset:0x11c8  sh_entsize: 0x8 (1 entry)
> sh_link:  5   sh_info:9
> sh_addralign: 0x4   
> 
> in the output object.

that should have been used as the reloc section for the new section 2.
I see sh_info is still 9, it should be 2.  That's eventually
missing handling in the section removal patch.

I've committed the hpux fix so in case you re-base the patch and
fix up the first_shndx issue please attach the rebased one.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #41 from rguenther at suse dot de  ---
[...]
>> Unfortunately not: it's really the section index pointing to the
>> non-existing (i.e. eliminated) .gnu.debuglto_.debug_info section.
>
> But that section shouldn't be eliminated :/

IIUC it has been renamed to .debug_info:

* input object (cp_lto_pr42987_0.o):

Section Header[9]:  sh_name: .gnu.debuglto_.debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x3d4   sh_type:[ SHT_PROGBITS ]
sh_offset:0x7fb   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

* output object (ccw3tETddebugobjtem):

Section Header[2]:  sh_name: .debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x3d4   sh_type:[ SHT_PROGBITS ]
sh_offset:0x84d   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

without adapting section indices in .symtab.

Besides, there's also a dangling

Section Header[6]:  sh_name: .rel.gnu.debuglto_.debug_info
sh_addr:  0   sh_flags:   0
sh_size:  0x8 sh_type:[ SHT_REL ]
sh_offset:0x11c8  sh_entsize: 0x8 (1 entry)
sh_link:  5   sh_info:9
sh_addralign: 0x4   

in the output object.

Rainer

[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The ICE goes away with -gno-statement-frontiers, perhaps if sel-sched is
unfixable we should disable statement frontiers in addition to
var-tracking-assignments that we already disable for sel-sched.

[Bug c++/81860] [7/8 Regression] Call to undefined inline function involving inheriting constructors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed by r251426.  I'll add the test at least.  I think it's worth it because I
see no lambdas in the testcase.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #41 from rguenther at suse dot de  ---
On Tue, 2 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #39 from Richard Biener  ---
> [...]
> >> * On x86, of the previous 32 ld: fatal: has invalid sh_info errors, 16
> >>   are now gone.
> >> 
> >>   However, I've many (1284 in g++.log) instances of
> >> 
> >> ld: warning: symbol .symtab[2] has invalid section index; ignored:
> >> (file /var/tmp//ccyttLYbdebugobjtem value=9);
> >> 
> >>   Those links end with
> >> 
> >> ld: fatal: file /var/tmp//ccyttLYbdebugobjtem: section
> >> [6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 9
> >> 
> >>   and ld SEGVing, again in the ld -r step.
> >> 
> >>   The warnings are from symtab entries like
> >> 
> >> Symbol Table Section:  .symtab
> >>   index  value size  type bind oth ver shndx name
> >> [0]  00  NOTY LOCL  D0 UNDEF 
> >> [1]  00  FILE LOCL  D0 ABS   pr42987_0.C
> >> [2]  00  NOTY LOCL  D0 9 
> >> 
> >>   and section 9 doesn't exist, where the input object (cp_lto_pr42987_0.o)
> >> has
> >
> > Just guessing that it maybe doesn't like NOTYPE on local defs?  I would
> 
> I don't think so.  With your patch, the affected symbols are SECT
> instead of LOCL, otherwise no difference.
> 
> > expect that before the partial link step that section 9 would exist.
> 
> It does indeed as I mentioned (cp_lto_pr42987_0.o is the input object
> corresponding to ccyttLYbdebugobjtem).
> 
> > Does
> >
> > Index: libiberty/simple-object-elf.c
> > ===
> > --- libiberty/simple-object-elf.c   (revision 256070)
> > +++ libiberty/simple-object-elf.c   (working copy)
> > @@ -1400,9 +1400,9 @@ simple_object_elf_copy_lto_debug_section
> >gnu_lto - strings);
> >   ELF_SET_FIELD (type_functions, ei_class, Sym,
> >  ent, st_shndx, Elf_Half, 
> > SHN_UNDEF);
> > + *st_info = ELF_ST_INFO (bind, STT_NOTYPE);
> > }
> >   *st_other = other;
> > - *st_info = ELF_ST_INFO (bind, STT_NOTYPE);
> >   ELF_SET_FIELD (type_functions, ei_class, Sym,
> >  ent, st_value, Elf_Addr, 0);
> >   ELF_SET_FIELD (type_functions, ei_class, Sym,
> >
> > fix these errors?
> 
> Unfortunately not: it's really the section index pointing to the
> non-existing (i.e. eliminated) .gnu.debuglto_.debug_info section.

But that section shouldn't be eliminated :/