[Bug tree-optimization/71518] [6 Regression] wrong code at -O3 on x86_64-linux-gnu in 64-bit mode (not in 32-bit mode)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #11 from Uroš Bizjak  ---
Fixed.

[Bug c++/72707] [5/6 regression] local anonymous union member hides names in the same scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 regression] local|[5/6 regression] local
   |anonymous union member  |anonymous union member
   |hides names in the same |hides names in the same
   |scope   |scope

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 22 08:53:56 2016
New Revision: 243883

URL: https://gcc.gnu.org/viewcvs?rev=243883&root=gcc&view=rev
Log:
PR bootstrap/78817
* vec.h (vec::safe_grow_cleared): Revert
2016-12-15 change.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/vec.h

[Bug c++/77830] internal compiler error: in output_constructor_regular_field, at varasm.c:4968, when using constexpr (with testcase)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #22 from Jakub Jelinek  ---
Fixed.

[Bug c++/78897] [6/7 Regression] ICE: in output_constructor_regular_field, at varasm.c:5019

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.4
Summary|ICE: in |[6/7 Regression] ICE: in
   |output_constructor_regular_ |output_constructor_regular_
   |field, at varasm.c:5019 |field, at varasm.c:5019
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r234636.  We have several very similar PRs, I bet this is a dup of
one of them.

[Bug c++/78897] [6/7 Regression] ICE: in output_constructor_regular_field, at varasm.c:5019

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Please notice that I've reduced this from a ICE on invalid posted on Reddit:

markus@x4 /tmp % cat const.ii
constexpr void *operator new(long unsigned int, void *where) { return where; }

class Optional {
public:
  explicit constexpr Optional() : _value{0} {}

  constexpr Optional(const Optional &o) : _dummy{0} {
new (&this->_value) int(o._value);
  }

private:
  union {

char _dummy;
int _value;
  };
};

int main() {
  constexpr Optional opt1{};
  constexpr Optional opt2{opt1};
}

markus@x4 /tmp % g++ const.ii
const.ii: In function ‘int main()’:
const.ii:21:22: internal compiler error: in complete_ctor_at_level_p, at
expr.c:6022
   constexpr Optional opt2{opt1};
  ^~~~
0xa2db7d complete_ctor_at_level_p(tree_node const*, long, tree_node const*)
/home/markus/gcc/gcc/expr.c:6022
0xa2df01 categorize_ctor_elements_1
/home/markus/gcc/gcc/expr.c:5973
0xa2ddd0 categorize_ctor_elements_1
/home/markus/gcc/gcc/expr.c:5911
0xaefbcc gimplify_init_constructor
/home/markus/gcc/gcc/gimplify.c:4622
0xaf1216 gimplify_modify_expr_rhs
/home/markus/gcc/gcc/gimplify.c:5063
0xaf7f89 gimplify_modify_expr
/home/markus/gcc/gcc/gimplify.c:5399
0xae65e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/markus/gcc/gcc/gimplify.c:11185
0xae9b18 gimplify_stmt(tree_node**, gimple**)
/home/markus/gcc/gcc/gimplify.c:6460
0xaf5ba0 gimplify_and_add(tree_node*, gimple**)
/home/markus/gcc/gcc/gimplify.c:435
0xaf5ba0 gimplify_decl_expr
/home/markus/gcc/gcc/gimplify.c:1651
0xae656a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/markus/gcc/gcc/gimplify.c:11380
0xae9b18 gimplify_stmt(tree_node**, gimple**)
/home/markus/gcc/gcc/gimplify.c:6460
0xae5778 gimplify_cleanup_point_expr
/home/markus/gcc/gcc/gimplify.c:6211
0xae5778 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/markus/gcc/gcc/gimplify.c:11560
0xae9b18 gimplify_stmt(tree_node**, gimple**)
/home/markus/gcc/gcc/gimplify.c:6460
0xae6d6b gimplify_statement_list
/home/markus/gcc/gcc/gimplify.c:1704
0xae6d6b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/markus/gcc/gcc/gimplify.c:11612
0xae9b18 gimplify_stmt(tree_node**, gimple**)
/home/markus/gcc/gcc/gimplify.c:6460
0xaeace5 gimplify_bind_expr
/home/markus/gcc/gcc/gimplify.c:1277
0xae587a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/markus/gcc/gcc/gimplify.c:11384

Not sure if this is cased by the same underlying bug.

[Bug c++/78896] [C++17] Segmentation fault occurs when use variable initialized using structured binding with capture-by-ref lambda

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|Segmentation fault occurs   |[C++17] Segmentation fault
   |when use variable   |occurs when use variable
   |initialized using   |initialized using
   |structured binding with |structured binding with
   |capture-by-ref lambda   |capture-by-ref lambda
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is interesting.
In [dcl.decomp]/4, there doesn't seem to be enough restrictions:
"Otherwise, all of E’s non-static data members shall be public direct members
of E or of the same unambiguous
public base class of E, E shall not have an anonymous union member, and the
number of elements in the
identifier-list shall be equal to the number of non-static data members of E.
Designating the non-static data
members of E as m 0 , m 1 , m 2 , ... (in declaration order), each v i is the
name of an lvalue that refers to the
member m i of e and whose type is cv T i , where T i is the declared type of
that member; the referenced type is
cv T i ."
It doesn't even say that E must be a class type (but what else can have
non-static data members).
And a lambda-expression has a class type [expr.prim.lambda]/4
"The type of the lambda-expression (which is also the type of the closure
object) is a unique, unnamed
non-union class type — called the closure type — whose properties are described
below. This class type is not
an aggregate type (8.6.1). The closure type is declared in the smallest block
scope, class scope, or namespace
scope that contains the corresponding lambda-expression. [ Note: This
determines the set of namespaces
and classes associated with the closure type (3.4.2). The parameter types of a
lambda-declarator do not
affect these associated namespaces and classes. — end note ]"

so this effectively allows taking apart the implementation defined non-static
data members of the lambda type.  Shall that be allowed?  Does the standard say
anything about the members of the lambda class type (i.e. can we e.g. declare
all of them to be private and reject the testcase from this reason)? Other
implementation defined types that could have similar weird effects are e.g.
va_list.

#include 
void foo (int x, ...) {
  va_list ap;
  va_start (ap, x);
  auto [b, c, d, e] { *ap };
  va_end (ap);
}

On x86_64-linux with -m32, both g++ and clang++ correctly reject this, because
type of *ap is char.  With -m64, g++ rejects this with:
pr78896-2.C: In function ‘void foo(int, ...)’:
pr78896-2.C:5:8: error: cannot decompose non-array non-class type
‘__va_list_tag’
   auto [b, c, d, e] { *ap };
^~~~
because we do not consider __va_list_tag a class type, just an implementation
created record type.  clang++ actually accepts this with -m64.

[Bug tree-optimization/78895] [6 Regression] wrong code with -O1 when setting union twice since 6.3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.4
Summary|[6 regression] wrong code   |[6 Regression] wrong code
   |with -O1 when setting union |with -O1 when setting union
   |twice since 6.3 |twice since 6.3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:

union U { int i; _Bool b; };

void __attribute__((noinline, noclone))
foo (union U u)
{
  if (u.b)
__builtin_abort ();
}

int
main ()
{
  union U u;
  u.i = 10;
  u.b = 0;
  foo (u);
  return 0;
}

It is fre1 that removes the u.b = 0; store.  Doesn't fail on the trunk, testing
now if it ever failed on trunk this fall.

[Bug c++/78826] jump bypasses non-POD

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 Ever confirmed|0   |1

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> It seems like the first character is being swallowed somewhere ...

Moreover the EOF is supposed to be an EOR?

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

[e...@sf-mail.de]

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

--- Comment #13 from Rolf Eike Beer  ---
6.2.0 also broken, 5.4.0 is fine.

[Bug c++/78894] [7 Regression] [c++17] ICE for std::list template deduction from std:: initializer_list

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|[c++17] ICE for std::list   |[7 Regression] [c++17] ICE
   |template deduction from |for std::list template
   |std:: initializer_list  |deduction from std::
   ||initializer_list

--- Comment #1 from Jakub Jelinek  ---
Started with r240756 - P0091R2.
Reduced testcase for the ICE (with -std=c++17):

struct A
{
  A ();
};
template 
struct C
{
  C (int, const T &, const A & = A ());
};

C a = { 0, 0 };

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
ICE started with r211318.

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Note that clang++ rejects this in all C++ modes.  So, are reference types
really allowed in anonymous unions?  If they are valid, the ICE is because the
VAR_DECL b has REFERENCE_TYPE, but also has DECL_VALUE_EXPR which has type int
rather than int &.

Untested:

--- gcc/cp/decl2.c.jj   2016-11-15 16:18:49.0 +0100
+++ gcc/cp/decl2.c  2016-12-22 11:59:14.656688431 +0100
@@ -1510,6 +1510,10 @@ build_anon_union_vars (tree type, tree o
  TREE_STATIC (decl) = TREE_STATIC (base);
  DECL_EXTERNAL (decl) = DECL_EXTERNAL (base);

+ if (TREE_CODE (TREE_TYPE (field)) == REFERENCE_TYPE
+ && REFERENCE_REF_P (ref))
+   ref = TREE_OPERAND (ref, 0);
+
  SET_DECL_VALUE_EXPR (decl, ref);
  DECL_HAS_VALUE_EXPR_P (decl) = 1;

fixes the ICE, even
template 
int foo() {
  union {
int a;
int &b = a;
  };
  a = 1;
  auto c = b + 1;
  return c;
}
template 
T bar() {
  union {
T a;
T &b = a;
  };
  a = 1;
  auto c = b + 1;
  return c;
}
template 
T baz() {
  union {
T a;
U b = a;
  };
  a = 1;
  auto c = b + 1;
  return c;
}
int a = foo ();
int b = bar ();
int c = baz ();
compiles.  But it doesn't make sense to spend further time on this until it is
clear if it is valid or not.

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
'_GLOBAL__sub_D_65535_0_sha1_ce_glue.c' to 
'_GLOBAL__sub_D_65535_0___odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table'
difference is a non-issue, the symbol name for the static dtors includes name
of the first symbol, which can change any time.  The symbol is local anyway.

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #7 from Jakub Jelinek  ---
Note, since r243441 -fsanitize-use-after-scope is enabled by default only for
-fsanitize=address, not for -fsanitize=kernel-address, so for kernel one has to
enable it manually.  So marking as fixed instead.

[Bug middle-end/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec 22 11:48:39 2016
New Revision: 243884

URL: https://gcc.gnu.org/viewcvs?rev=243884&root=gcc&view=rev
Log:
PR middle-end/78858
* c-c++-common/ubsan/pr78858.c: New test.
* gcc.dg/nonnull-5.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr78858.c
trunk/gcc/testsuite/gcc.dg/nonnull-5.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Should be fixed with r243874.

[Bug bootstrap/78859] [7 Regression] profiledbootstrap failure caused by -Werror=nonnull

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Should be fixed with r243874, if not, please reopen.

[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This probably needs to go to upstream compiler-rt first.  Also, it would be
cleaner not to define SI_MEMMEM to 1 on Windows and move the comment there.

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[syq at debian dot org]

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

YunQiang Su  changed:

   What|Removed |Added

 CC||syq at debian dot org

--- Comment #6 from YunQiang Su  ---
With revert some change, with patch:

Index: gcc-7-7-20161217/src/gcc/combine.c
===
--- gcc-7-7-20161217.orig/src/gcc/combine.c
+++ gcc-7-7-20161217/src/gcc/combine.c
@@ -9972,13 +9972,13 @@ reg_nonzero_bits_for_combine (const_rtx
  (DF_LR_IN (ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb),
   REGNO (x)
 {
-  /* Note that, even if the precision of last_set_mode is lower than that
-of mode, record_value_for_reg invoked nonzero_bits on the register
-with nonzero_bits_mode (because last_set_mode is necessarily integral
-and HWI_COMPUTABLE_MODE_P in this case) so bits in nonzero_bits_mode
-are all valid, hence in mode too since nonzero_bits_mode is defined
-to the largest HWI_COMPUTABLE_MODE_P mode.  */
-  *nonzero &= rsp->last_set_nonzero_bits;
+  unsigned HOST_WIDE_INT mask = rsp->last_set_nonzero_bits;
+
+  if (GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION (mode))
+   /* We don't know anything about the upper bits.  */
+   mask |= GET_MODE_MASK (mode) ^ GET_MODE_MASK (rsp->last_set_mode);
+
+  *nonzero &= mask;
   return NULL;
 }

[Bug fortran/78865] ICE in create_tmp_var, at gimple-expr.c:473

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that gfc_conv_procedure_call changes the type of the sub
function
from one returning void to one returning int:
  /* If there are alternate return labels, function type should be
 integer.  Can't modify the type in place though, since it can be shared
 with other functions.  For dummy arguments, the typing is done to
 this result, even if it has to be repeated for each call.  */
  if (has_alternate_specifier
  && TREE_TYPE (TREE_TYPE (TREE_TYPE (se->expr))) != integer_type_node)
{
  if (!sym->attr.dummy)
{
  TREE_TYPE (sym->backend_decl)
= build_function_type (integer_type_node,
  TYPE_ARG_TYPES (TREE_TYPE (sym->backend_decl)));
  se->expr = gfc_build_addr_expr (NULL_TREE, sym->backend_decl);
}
  else
TREE_TYPE (TREE_TYPE (TREE_TYPE (se->expr))) = integer_type_node;
}

While this can work for implicitly defined subroutine calls, if
sym->backend_decl
is actually merged with the subroutine definition, changing it afterwards just
doesn't work.  Either it should be diagnosed as bug earlier (noting that caller
expects alternate return, but callee does not), or at least it shouldn't change
the type of the function, but do something different (even just generate
__builtin_trap instead of the call).

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[syq at debian dot org]

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

--- Comment #7 from YunQiang Su  ---
(In reply to YunQiang Su from comment #6)
> With revert some change, with patch:
> 
> Index: gcc-7-7-20161217/src/gcc/combine.c
> ===
> --- gcc-7-7-20161217.orig/src/gcc/combine.c
> +++ gcc-7-7-20161217/src/gcc/combine.c
> @@ -9972,13 +9972,13 @@ reg_nonzero_bits_for_combine (const_rtx
>   (DF_LR_IN (ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb),
>REGNO (x)
>  {
> -  /* Note that, even if the precision of last_set_mode is lower than
> that
> -of mode, record_value_for_reg invoked nonzero_bits on the register
> -with nonzero_bits_mode (because last_set_mode is necessarily
> integral
> -and HWI_COMPUTABLE_MODE_P in this case) so bits in nonzero_bits_mode
> -are all valid, hence in mode too since nonzero_bits_mode is defined
> -to the largest HWI_COMPUTABLE_MODE_P mode.  */
> -  *nonzero &= rsp->last_set_nonzero_bits;
> +  unsigned HOST_WIDE_INT mask = rsp->last_set_nonzero_bits;
> +
> +  if (GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
> (mode))
> +   /* We don't know anything about the upper bits.  */
> +   mask |= GET_MODE_MASK (mode) ^ GET_MODE_MASK (rsp->last_set_mode);
> +
> +  *nonzero &= mask;
>return NULL;
>  }

This can make it buildable now.

[Bug tree-optimization/78899] New: [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.

[ysrumyan at gmail dot com]

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

Bug ID: 78899
   Summary: [7 Regression] Vestorized loop with optmized mask
stores motion is completely deleted after r242520.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

Created attachment 40395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40395&action=edit
test-case to reproduce - compile with -Ofast -mavx2 -fopenmp

We noticed a huge regression on avx2 and knl machines on couple improtant
benchmarks. The issue can be reproduced with attached test-case.
Before given revision produced assembly contains vptest and vpmaskmovd
instructions but after this revision newly created basic blocks which are
created for sinking masked stores are deleted:
grep 'block 22' test.c.156t.vect
test.c:11:15: note: Create new block 22 to sink mask stores.test.c:11:15: note:
Move stmt to created bb
Removing basic block 22 

Attached test-case must be compiled with -Ofast -mavx2 -fopenmp options to
reproduce.

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  ---
Author: gjl
Date: Thu Dec 22 12:42:35 2016
New Revision: 243885

URL: https://gcc.gnu.org/viewcvs?rev=243885&root=gcc&view=rev
Log:
gcc/testsuite/
PR testsuite/52641
* gcc.dg/pr35258.c (main) : Use an integer value that has
at least a size of 4.
* gcc.dg/Walloca-1.c (foo1): Use alloca with 3 (instead of 9).
* gcc.dg/graphite/pr46185.c: Require int32plus, size32plus.
* gcc.dg/graphite/isl-ast-op-select.c: Same.
* gcc.dg/graphite/pr42205-1.c: Require int32plus.
* gcc.dg/graphite/pr42221.c: Same.
* gcc.dg/tree-ssa/pr65136.c: Same.
* gcc.dg/tree-ssa/sra-20.c: Same.
* gcc.dg/graphite/scop-0.c: Require size32plus.
* gcc.dg/graphite/scop-22.c: Same.
* gcc.dg/graphite/scop-3.c: Same.
* gcc.dg/graphite/scop-dsyr2k.c: Same.
* gcc.dg/graphite/scop-dsyrk.c: Same.
* gcc.dg/graphite/scop-mvt.c: Same.
* gcc.dg/graphite/scop-sor.c: Same.
* gcc.dg/tree-ssa/pr68529-3.c: Same.
* gcc.dg/tree-ssa/pr66449.c [long != pointer]: Use intptr_t if.
* gcc.dg/tree-ssa/pr70919.c [int <= 2]: Use 32-bit int as needed.
* gcc.dg/tree-ssa/pr71408.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-8.c (f2) [long != pointer]: Use
uintptr_t instead of long for int representation of address.
* gcc.dg/tree-ssa/tailcall-7-run.c: Require trampolines.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Walloca-1.c
trunk/gcc/testsuite/gcc.dg/graphite/isl-ast-op-select.c
trunk/gcc/testsuite/gcc.dg/graphite/pr42205-1.c
trunk/gcc/testsuite/gcc.dg/graphite/pr42221.c
trunk/gcc/testsuite/gcc.dg/graphite/pr46185.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-0.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-22.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-3.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-dsyr2k.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-dsyrk.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-mvt.c
trunk/gcc/testsuite/gcc.dg/graphite/scop-sor.c
trunk/gcc/testsuite/gcc.dg/pr35258.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr65136.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66449.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68529-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr70919.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71408.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-20.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/tailcall-7-run.c

[Bug fortran/78865] [5/6/7 Regression] ICE in create_tmp_var, at gimple-expr.c:473

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|ICE in create_tmp_var, at   |[5/6/7 Regression] ICE in
   |gimple-expr.c:473   |create_tmp_var, at
   ||gimple-expr.c:473

--- Comment #3 from Jakub Jelinek  ---
The warning likely should go into compare_actual_formal
(the case where for f->sym == NULL there is no arg->label or vice versa).
For the actual fix, dunno if the Fortran FE has some flag that sym is a
definition rather than just implicit declaration, if not, it can be discovered
e.g. from sym->backend_decl - if it has DECL_INITIAL non-NULL, or DECL_RESULT
non-NULL, then we are looking certainly for a definition, which is too late to
be changed.

Started most likely with r162557 (r162550 doesn't ICE, r162560 ICEs).

[Bug target/78900] New: ICE in gcc.target/powerpc/signbit-3.c

[acsawdey at gcc dot gnu.org]

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

Bug ID: 78900
   Summary: ICE in gcc.target/powerpc/signbit-3.c
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: meissner at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-*

Regtesting for -mcpu=power9 turned this up. Version tested is gcc-6-branch
revision 243723.

/home/sawdey/src/gcc/gcc-6-branch/build/gcc/xgcc
-B/home/sawdey/src/gcc/gcc-6-branch/build/gcc/
/home/sawdey/src/gcc/gcc-6-branch/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/signbit-3.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -mcpu=power7 -O2
-mfloat128 -lm -Wl,-rpath=/tmp/lib64  -lm   -mcpu=power9  -o ./signbit-3.exe

/home/sawdey/src/gcc/gcc-6-branch/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/signbit-3.c:
In function 'test_signbit_gpr.isra.1':
/home/sawdey/src/gcc/gcc-6-branch/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/signbit-3.c:111:1:
internal compiler error: in rs6000_split_signbit, at
config/rs6000/rs6000.c:23106
0x109de9f3 rs6000_split_signbit(rtx_def*, rtx_def*)
../../gcc-6-branch/gcc/config/rs6000/rs6000.c:23106
0x10b535cb gen_split_119(rtx_insn*, rtx_def**)
../../gcc-6-branch/gcc/config/rs6000/rs6000.md:4626
0x10c6ceb3 split_12
../../gcc-6-branch/gcc/config/rs6000/rs6000.md:4625
0x10c71287 split_15
../../gcc-6-branch/gcc/config/rs6000/rs6000.md:330
0x10c71287 split_insns(rtx_def*, rtx_insn*)
../../gcc-6-branch/gcc/config/rs6000/rs6000.md:411
0x10391e87 try_split(rtx_def*, rtx_insn*, int)
../../gcc-6-branch/gcc/emit-rtl.c:3658
0x10631cbb split_insn
../../gcc-6-branch/gcc/recog.c:2865
0x10637d37 split_all_insns()
../../gcc-6-branch/gcc/recog.c:2955
0x10637dbb rest_of_handle_split_after_reload
../../gcc-6-branch/gcc/recog.c:3891
0x10637dbb execute
../../gcc-6-branch/gcc/recog.c:3920
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/78901] New: internal compiler error: verify_gimple failed

[h2+bugs at fsfe dot org]

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

Bug ID: 78901
   Summary: internal compiler error: verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Created attachment 40396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40396&action=edit
intermediate file for test_basic_aggregate

Looks related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78777 , but since
I am on a newer snapshot I wanted to report the following errors we are seeing
in nightly builds of the SeqAn template library.


% g++7 --version
g++7 (FreeBSD Ports Collection) 7.0.0 20161218 (experimental)


% uname -a
FreeBSD celegans.imp.fu-berlin.de 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0
r306420: Thu Sep 29 01:43:23 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

% cd /home/mi/h4nn3s/devel/seqan_local-build/release/tests/basic &&
/usr/local/libexec/ccache/g++7   -DSEQAN_DISABLE_VERSION_CHECK
-DSEQAN_ENABLE_TESTING=1 -DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1
-DSEQAN_HAS_OPENMP=1 -DSEQAN_HAS_ZLIB=1 -D_FILE_OFFSET_BITS=64
-D_GLIBCXX_USE_C99=1 -D_LARGEFILE_SOURCE
-I/home/mi/h4nn3s/devel/seqan_local/include  -fdiagnostics-color -save-temps 
-W -Wall -pedantic -fstrict-aliasing -Wstrict-aliasing -fopenmp -O3
-DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o
CMakeFiles/test_basic_aggregate.dir/test_basic_aggregate.cpp.o -c
/home/mi/h4nn3s/devel/seqan_local/tests/basic/test_basic_aggregate.cpp
In file included from
/home/mi/h4nn3s/devel/seqan_local/tests/basic/test_basic_aggregate.cpp:41:0:
/home/mi/h4nn3s/devel/seqan_local/tests/basic/test_basic_aggregate.h: In
function 'void SEQAN_TEST_test_basic_aggregates_tuple_base_stream_output()
[with bool speed_up_dummy_to_prevent_compilation_of_unused_tests_ = true]':
/home/mi/h4nn3s/devel/seqan_local/tests/basic/test_basic_aggregate.h:1646:77:
error: statement marked for throw in middle of block
 SEQAN_DEFINE_TEST(test_basic_aggregates_tuple_base_stream_output)
 ^  
# .MEM_322 = VDEF <.MEM_320>
snprintf (&buffer, 14, &VALUE, 1);
/home/mi/h4nn3s/devel/seqan_local/tests/basic/test_basic_aggregate.h:1646:77:
internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

--

% cd /home/mi/h4nn3s/devel/seqan_local-build/release/tests/random &&
/usr/local/libexec/ccache/g++7   -DSEQAN_DISABLE_VERSION_CHECK
-DSEQAN_ENABLE_TESTING=1 -DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1
-DSEQAN_HAS_OPENMP=1 -DSEQAN_HAS_ZLIB=1 -D_FILE_OFFSET_BITS=64
-D_GLIBCXX_USE_C99=1 -D_LARGEFILE_SOURCE
-I/home/mi/h4nn3s/devel/seqan_local/include  -fdiagnostics-color -save-temps 
-W -Wall -pedantic -fstrict-aliasing -Wstrict-aliasing -fopenmp -O3
-DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o
CMakeFiles/test_random.dir/test_random.cpp.o -c
/home/mi/h4nn3s/devel/seqan_local/tests/random/test_random.cpp
In file included from
/home/mi/h4nn3s/devel/seqan_local/tests/random/test_random.cpp:42:0:
/home/mi/h4nn3s/devel/seqan_local/tests/random/test_random_beta.h: In function
'void SEQAN_TEST_test_random_beta_write() [with bool
speed_up_dummy_to_prevent_compilation_of_unused_tests_ = true]':
/home/mi/h4nn3s/devel/seqan_local/tests/random/test_random_beta.h:122:77:
error: statement marked for throw in middle of block
 SEQAN_DEFINE_TEST(test_random_beta_write)
 ^  
# .MEM_954 = VDEF <.MEM_953>
snprintf (&buffer, 32, "%g", 5.0e-1);
/home/mi/h4nn3s/devel/seqan_local/tests/random/test_random_beta.h:122:77:
error: statement marked for throw in middle of block
# .MEM_1015 = VDEF <.MEM_1014>
snprintf (&buffer, 32, "%g",
2.99988897769753748434595763683319091796875e-1);
/home/mi/h4nn3s/devel/seqan_local/tests/random/test_random_beta.h:122:77:
internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-

% cd /home/mi/h4nn3s/devel/seqan_local-build/release/tests/blast &&
/usr/local/libexec/ccache/g++7   -DSEQAN_DISABLE_VERSION_CHECK
-DSEQAN_ENABLE_TESTING=1 -DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1
-DSEQAN_HAS_OPENMP=1 -DSEQAN_HAS_ZLIB=1 -D_FILE_OFFSET_BITS=64
-D_GLIBCXX_USE_C99=1 -D_LARGEFILE_SOURCE
-I/home/mi/h4nn3s/devel/seqan_local/include  -fdiagnostics-color -save-temps 
-W -Wall -pedantic -fstrict-aliasing -Wstrict-aliasing -fopenmp -O3
-DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o
CMakeFiles/test_blast.dir/test_blast.cpp.o -c
/home/mi/h4nn3s/devel/seqan_local/tests/

[Bug c++/78901] internal compiler error: verify_gimple failed

[h2+bugs at fsfe dot org]

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

--- Comment #1 from h2+bugs at fsfe dot org ---
Created attachment 40397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40397&action=edit
intermediate file for test_blast

[Bug c++/78901] internal compiler error: verify_gimple failed

[h2+bugs at fsfe dot org]

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

--- Comment #2 from h2+bugs at fsfe dot org ---
Created attachment 40398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40398&action=edit
intermediate file for test_random

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 CC||trippels at gcc dot gnu.org
  Component|c++ |middle-end
Summary|internal compiler error:|[7 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   ||(error: statement marked
   ||for throw in middle of
   ||block)
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
Confirmed. Reducing...

[Bug tree-optimization/78886] [5/6/7 Regression] Segmentation fault malloc and volatile

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Thu Dec 22 13:09:11 2016
New Revision: 243886

URL: https://gcc.gnu.org/viewcvs?rev=243886&root=gcc&view=rev
Log:
Fix tree-optimization/78886.

PR tree-optimization/78886
* gcc.dg/tree-ssa/pr78886.c: New test.
PR tree-optimization/78886
* tree-ssa-strlen.c (handle_builtin_malloc): Return when LHS
is equal to NULL.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78886.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/78886] [5/6 Regression] Segmentation fault malloc and volatile

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5/6 Regression]
   |Segmentation fault malloc   |Segmentation fault malloc
   |and volatile|and volatile

--- Comment #7 from Martin Liška  ---
Fixed on trunk so far.

[Bug fortran/68887] [6/7 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
If the tests are compiled on darwin with an instrumented gfortran, execution
gives

==82783==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200150 at pc 0x000101b79d39 bp 0x7fff5e0a6300 sp 0x7fff5e0a62f8
READ of size 4 at 0x60200150 thread T0
#0 0x101b79d38 in _gfortran_caf_event_query
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100020d38)
#1 0x101b59f48 in MAIN__
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10f48)

0x60200151 is located 0 bytes to the right of 1-byte region
[0x60200150,0x60200151)
allocated by thread T0 here:
#0 0x101c47f30 in wrap_calloc (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x62f30)
#1 0x101b615e3 in _gfortran_caf_register
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x185e3)
#2 0x101b7b47d in _caf_init.1.3510
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10002247d)
#3 0x1089a1961  ()
#4 0x10899d1ed  ()
#5 0x10899c267  ()
#6 0x10899c2fc  ()
#7 0x10898e479  ()
#8 0x1089927df  ()
#9 0x10898d248  ()
#10 0x10898d035  ()

SUMMARY: AddressSanitizer: heap-buffer-overflow
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100020d38) in
_gfortran_caf_event_query
Shadow bytes around the buggy address:
  0x1c03ffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03ffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c03fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c04: fa fa fd fd fa fa fd fd fa fa 00 07 fa fa 00 06
  0x1c040010: fa fa 03 fa fa fa 00 00 fa fa 00 06 fa fa 06 fa
=>0x1c040020: fa fa 07 fa fa fa 07 fa fa fa[01]fa fa fa 00 00
  0x1c040030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c040070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==82783==ABORTING

[Bug tree-optimization/78886] [5/6 Regression] Segmentation fault malloc and volatile

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #5)
> I'd say tree-ssa-strlen.c is not the pass that should remove the malloc.

We probably want another PR about this, because a malloc whose return value is
ignored should not have survived all the way to the strlen pass.
gimple_fold_builtin looks like a place where we could handle this. I don't know
if there is some attribute that could be put on malloc so that DCE would handle
it automatically...

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Started with r242674, however I'll wait for reduced test-case to isolate a
first faulty revision with -fprintf-return-value.

I'm going to wait due to: error: ‘__builtin_addressof’ was not declared in this
scope.

[Bug tree-optimization/78902] New: Missed malloc optimizations: malloc w/ LHS and zero argument

[marxin at gcc dot gnu.org]

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

Bug ID: 78902
   Summary: Missed malloc optimizations: malloc w/ LHS and zero
argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

This is follow-up of PR78886.

[Bug tree-optimization/78886] [5/6 Regression] Segmentation fault malloc and volatile

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Marc Glisse from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > I'd say tree-ssa-strlen.c is not the pass that should remove the malloc.
> 
> We probably want another PR about this, because a malloc whose return value
> is ignored should not have survived all the way to the strlen pass.
> gimple_fold_builtin looks like a place where we could handle this. I don't
> know if there is some attribute that could be put on malloc so that DCE
> would handle it automatically...

Yep, I've just created PR78902.

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 40399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40399&action=edit
Patch candidate

Would be such change acceptable in GCC 7, or should be wait for GCC 8?

[Bug c/78903] New: __attribute__((section(".ram"))) ignored with -Os or -flto

[chrysn at fsfe dot org]

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

Bug ID: 78903
   Summary: __attribute__((section(".ram"))) ignored with -Os or
-flto
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrysn at fsfe dot org
  Target Milestone: ---

Created attachment 40400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40400&action=edit
example for amd64 linux where a function in should-be-crashing .data is inlined
into regular text

When function calls are inlined due to -Os or -flto, an
__attribute__((section(".ram"))) gets ignored.

This bites for example when GCC somewhere before 5.4 started inlining flash
writing sequences on ARM CortexM3 EFM32 chips in emlib where such an attribute
should have made sure that the flash is not accessed for program code during
the flash operation; there, it surfaced due to link time optimization.

I've created a minimal test case that seems equivalent to me, it is attached as
test.c. Instead of moving code to RAM like in the original but
harder-to-reproduce example on ARM, it is placing a test function `f()` in
".data", which on my system makes the program segfault when the f is invoked.

When compiled without optimizations ("gcc-7 test.c -o test"), the resulting
program crashes as expected, probably trying to execute ".data" and running
into protections. In the original microcontroller example, that crash would
have been a successful execution from RAM.

With "gcc-7 -Os test.c -o test", the call to `f()` is inlined and the program
exits successfully. In the original example, this would have a concurrent
access to flash and would have caused some undefined state in the processor.

In both cases, the compiler outputs "Warning: ignoring changed section
attributes for .data"; there is no equivalent output in the original ARM
example as ".ram" is a valid section there in the linker script.


My build system is Debian sid on amd64 running linux 4.9.0-rc8. The behavior
was obsered on arm-none-eabi-gcc 5.4, and on "regular" (amd64 debian built) gcc
6.2.1-7 and 7-20161217-1.


As a workaround, I'm currently marking the function __attribute__((noinline)).
I might be having a "x-y problem" with the compiler here as my main intention
is "keep your $pc off flash until this call returns" but I tell it "copy this
to ram" and thus need to enhance the instructions to "and don't place copies
anywhere else" and would appreciate suggestions on how to do it better, but
__attribute__((section(".ram"))) seems to be the accepted way of doing it. A
short inquery on freenode/#gcc indicated that this might be an optimizer bug.

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
The p=malloc(0) transformation looks strange.
(I never know if we are supposed to unlink_stmt_vdef, etc)

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Marc Glisse from comment #2)
> The p=malloc(0) transformation looks strange.
> (I never know if we are supposed to unlink_stmt_vdef, etc)

Yep, it's strange, should be p = NULL. As mentioned in MAN page:
If size is 0, then malloc() returns either NULL, or a unique pointer value that
can later be successfully passed to free().

I'll prepare regular patch and send it to ML.

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Martin Liška from comment #3)
> Yep, it's strange, should be p = NULL. As mentioned in MAN page:
> If size is 0, then malloc() returns either NULL, or a unique pointer value
> that can later be successfully passed to free().

While I would personally be happy with malloc(0) always returning 0, IIRC some
platforms actually guarantee that malloc(0) returns a unique non-null pointer
and may be unhappy about the compiler contradicting them. I may misremember
though.

(thanks for the PR and the patch, by the way)

[Bug c/78903] __attribute__((section(".ram"))) ignored with -Os or -flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
noinline is not a workaround; if you don't want some function to be inlined,
use noinline attribute, period.  The section attribute itself is not a reason
not to inline (and should not be).

[Bug c++/78898] [7 Regression] ICE: in get_template_base, at cp/pt.c:19665

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #14 from Georg-Johann Lay  ---
Author: gjl
Date: Thu Dec 22 15:02:43 2016
New Revision: 243889

URL: https://gcc.gnu.org/viewcvs?rev=243889&root=gcc&view=rev
Log:
gcc/testsuite/
PR testsuite/52641
* gcc.dg/fold-and-rshift-2.c [int <= 2]: Use 32-bit int as needed.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/fold-and-rshift-2.c

[Bug middle-end/78904] New: zero-extracts are not effective

[ubizjak at gmail dot com]

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

Bug ID: 78904
   Summary: zero-extracts are not effective
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
struct S1
{
  char pad1;
  unsigned char val;
  short pad2;
};

struct S1 test (struct S1 a, struct S1 b)
{
  struct S1 r = a;

  r.val = a.val + b.val;

  return r;
}
--cut here--

should be compiled to something involving:

addb %dh, %ah

but is compiled to a whole sequence of:

movl%edi, %ecx
movl%esi, %eax
xorl%edx, %edx
movzbl  %ch, %esi
movzbl  %ah, %eax
movb%dil, %dl
addl%esi, %eax
xorw%di, %di
movb%al, %dh
movzwl  %dx, %eax
orl %edi, %eax

The relevant patterns from i386.md are:

(define_insn "addqi_ext_1"
  [(set (zero_extract:SI (match_operand 0 "ext_register_operand" "=Q,Q")
 (const_int 8)
 (const_int 8))
(plus:SI
  (zero_extract:SI
(match_operand 1 "ext_register_operand" "0,0")
(const_int 8)
(const_int 8))
  (match_operand:QI 2 "general_operand" "Qn,Bn")))
   (clobber (reg:CC FLAGS_REG))]

and

(define_insn "*addqi_ext_2"
  [(set (zero_extract:SI (match_operand 0 "ext_register_operand" "=Q")
 (const_int 8)
 (const_int 8))
(plus:SI
  (zero_extract:SI
(match_operand 1 "ext_register_operand" "%0")
(const_int 8)
(const_int 8))
  (zero_extract:SI
(match_operand 2 "ext_register_operand" "Q")
(const_int 8)
(const_int 8
   (clobber (reg:CC FLAGS_REG))]

Combine pass tries to generate something resembling the above patterns:

(set (zero_extract:SI (reg:SI 92 [ D.1804 ])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(subreg:SI (plus:QI (subreg:QI (zero_extract:SI (reg/v:SI 95 [ b ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(reg:QI 98 [ a$val ])) 0))

but it looks that the pattern is not fully canonicalized and thus not
recognized.

[Bug c++/42329] Deduction of template template argument via base class fails

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Dec 22 15:19:54 2016
New Revision: 243890

URL: https://gcc.gnu.org/viewcvs?rev=243890&root=gcc&view=rev
Log:
PR c++/78898 - ICE on constructor with TTP

PR c++/42329
* pt.c (unify): Don't look for a class template from a non-class.

Added:
trunk/gcc/testsuite/g++.dg/template/ttp30.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/78898] [7 Regression] ICE: in get_template_base, at cp/pt.c:19665

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Dec 22 15:19:54 2016
New Revision: 243890

URL: https://gcc.gnu.org/viewcvs?rev=243890&root=gcc&view=rev
Log:
PR c++/78898 - ICE on constructor with TTP

PR c++/42329
* pt.c (unify): Don't look for a class template from a non-class.

Added:
trunk/gcc/testsuite/g++.dg/template/ttp30.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/78898] [7 Regression] ICE: in get_template_base, at cp/pt.c:19665

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug fortran/66681] [Coarray] Wrong result in assigning this_image() to a complex coarray

[damian at sourceryinstitute dot org]

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

--- Comment #9 from Damian Rouson  ---
I wonder if this is related to pr78892

[Bug c/78903] __attribute__((section(".ram"))) ignored with -Os or -flto

[chrysn at fsfe dot org]

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

--- Comment #2 from chrysn at fsfe dot org ---
I don't care about the function being inlined in general, I just don't want it
inlined into different sections -- that's why I'd consider noinline a
workaround.

Anyhow, if that is the definite answer, I'd like to suggest the following
addition to the common-function-attributes documentation on section:

"[ of the linker instead.] The section applies when the function is placed as a
whole; it can still be inlined into code in other sections."

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #40399|0   |1
is obsolete||

--- Comment #5 from Martin Liška  ---
Created attachment 40401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40401&action=edit
Patch candidate v2

Well, I guess it's GCC 8 issue. I can imagine to introduce an option that would
enable optimization of malloc(0) to return NULL? Similarly, we may want a
warning for both missing LHS and malloc(0). Is it a desired feature?

[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-22
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug c/77754] [5/6/7 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Though, it seems they can be hiding pretty much everywhere:
int fn3();
void (**fn5) (int[][fn3 ()]);

void fn1 () {
  int a[10][fn3 ()];
  (**fn5) (a);
}
ICEs with -O2 -flto, so does:
int fn3();
typedef void (*fn6) (int[][fn3 ()]);
fn6 **fn7;

void fn1 () {
  int a[10][fn3 ()];
  (**fn7) (a);
}
and so does:
int fn3();
typedef void (*fn6) (int[][fn3 ()]);
struct S {
  fn6 **fn7;
  fn6 *fn8;
  fn6 fn9;
} s;

void fn1 () {
  int a[10][fn3 ()];
  (**s.fn7) (a);
  (*s.fn8) (a);
  s.fn9 (a);
}

So I'd think trying to fix it up late is just too late, we want to change it
immediately after finishing a declaration that is not a function definition.

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
Warning on malloc with an unused return value sounds like a good idea to me (in
fact, it seems that all allocation functions to be declared with
warn_unused_result; i.e., all those declared with attribute alloc_size).

I also think warning on malloc(0) can be useful.  GCC 7 has -Walloc-zero that
warns on all zero-size allocations.  Unfortunately, it's not in -Wall or
-Wextra and has to be explicitly enabled.

Unconditionally turning malloc(0) into NULL wouldn't be safe since the call is
allowed to return a unique non-null pointer and there are implementations
(e.g., Glibc) that do return one.  But doing that under an option might be
useful on targets where the system malloc returns null (though it could break
with superimposition).

I'm not sure that eliminating calls to malloc whose return value is unused is a
safe optimization.  Malloc can be superimposed and the replacement version
might have important side-effects that the optimization would prevent.

[Bug c/77754] [5/6/7 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Perhaps doing it in grokdeclarator where build_function_type is called, if
initialized == false?  But it is unclear to me where all the side-effects can
hide.  E.g.
int fn3();

void fn4(int (*)[fn3 ()][fn3 () + 1][fn3 () + 2], struct S { int a[fn3 ()]; }
*);

void fn1() {
  int a[10][fn3 ()][fn3 () + 1][fn3 () + 2];
  fn4 (a, 0);
}
is accepted, so it can be even inside of non-array aggregate types.

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Dec 22 17:05:13 2016
New Revision: 243891

URL: https://gcc.gnu.org/viewcvs?rev=243891&root=gcc&view=rev
Log:
2016-12-22  Thomas Koenig  

Backport from trunk
PR fortran/78239
* decl.c (char_len_param_value): Also check for -fimplicit-none
when determining if implicit none is in force.

2016-12-22  Thomas Koenig  

Backport from trunk
PR fortran/78239
* gfortran.dg/fimplicit_none_1.f90:  New test.
* gfortran.dg/fimplicit_none_2.f90:  New test.



Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/fimplicit_none_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #9 from Jeffrey A. Law  ---
The posted patch is just papering over the problem by changing the iteration
order of jump threads we examine.  Since realization of some jump threads will
cause others to not be realized, changing the iteration order can cause
different jump threads to be realized.

As discussed PR72785, this is a kernel bug in that the kernel code assumes that
paths leading to a __builtin_object_size will not be duplicated/isolated.

[Bug middle-end/71474] PRED_LOOP_IV_COMPARE wrongly calculates number of iterations of a loop

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
It's resolved as we switched to C-style loops in Fortran in r238114.

[Bug translation/78745] Truncated messages in po file

[fmarchal at perso dot be]

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

--- Comment #4 from Frederic Marchal  ---
More multi-line descriptions in gcc/config/i386/i386.opt at line 567, 577, 844.

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Martin Sebor from comment #6)
> Warning on malloc with an unused return value sounds like a good idea to me
> (in fact, it seems that all allocation functions to be declared with
> warn_unused_result; i.e., all those declared with attribute alloc_size).

Good, I can do that in next stage1.

> 
> I also think warning on malloc(0) can be useful.  GCC 7 has -Walloc-zero
> that warns on all zero-size allocations.  Unfortunately, it's not in -Wall
> or -Wextra and has to be explicitly enabled.

That's a pity, why was the option not enabled in either -Wall or -Wextra?

> 
> Unconditionally turning malloc(0) into NULL wouldn't be safe since the call
> is allowed to return a unique non-null pointer and there are implementations
> (e.g., Glibc) that do return one.  But doing that under an option might be
> useful on targets where the system malloc returns null (though it could
> break with superimposition).

Or when an application does not rely on result being non-null.

> 
> I'm not sure that eliminating calls to malloc whose return value is unused
> is a safe optimization.  Malloc can be superimposed and the replacement
> version might have important side-effects that the optimization would
> prevent.

Both clang and gcc (in 037t.cddce1) can optimize out:
int main()
{
  __builtin_malloc(123);
  return 0;
}

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On December 22, 2016 5:36:56 PM GMT+01:00, "msebor at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78902
>
>Martin Sebor  changed:
>
>   What|Removed |Added
>
>  CC||msebor at gcc dot gnu.org
>
>--- Comment #6 from Martin Sebor  ---
>Warning on malloc with an unused return value sounds like a good idea
>to me (in
>fact, it seems that all allocation functions to be declared with
>warn_unused_result; i.e., all those declared with attribute
>alloc_size).
>
>I also think warning on malloc(0) can be useful.  GCC 7 has
>-Walloc-zero that
>warns on all zero-size allocations.  Unfortunately, it's not in -Wall
>or
>-Wextra and has to be explicitly enabled.
>
>Unconditionally turning malloc(0) into NULL wouldn't be safe since the
>call is
>allowed to return a unique non-null pointer and there are
>implementations
>(e.g., Glibc) that do return one.  But doing that under an option might
>be
>useful on targets where the system malloc returns null (though it could
>break
>with superimposition).
>
>I'm not sure that eliminating calls to malloc whose return value is
>unused is a
>safe optimization.  Malloc can be superimposed and the replacement
>version
>might have important side-effects that the optimization would prevent.

Given we remove malloc/free pairs it might be OK I think.

[Bug tree-optimization/78902] Missed malloc optimizations: malloc w/o LHS and zero argument

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #7)
> > I also think warning on malloc(0) can be useful.  GCC 7 has -Walloc-zero
> > that warns on all zero-size allocations.  Unfortunately, it's not in -Wall
> > or -Wextra and has to be explicitly enabled.
> 
> That's a pity, why was the option not enabled in either -Wall or -Wextra?

I think one of the reasons was that it is a late warning, so it has similar
problems -Wnonnull had, warning even just in cases where path isolation decided
to isolate some call where it just isn't called with those arguments.
So perhaps moving it to post_ipa_warn pass would help with that part.

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Why don't you use:
__GNUC__ >=5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)

instead for checking GCC version?

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[mattyclarkson at gmail dot com]

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

--- Comment #2 from Matt Clarkson  ---
Because wehen I compile with clang against the libstdc++ the problem will still
occur and __GNUC__ will not be defined. This happens on any distro where GCC is
the default but ships clang as an alternative compiler.

[Bug libstdc++/78905] New: Add a macro to determine that the library is implemented

[mattyclarkson at gmail dot com]

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

Bug ID: 78905
   Summary: Add a macro to determine that the  library is
implemented
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattyclarkson at gmail dot com
  Target Milestone: ---

libstdc++ 4.7 and 4.8 shipped with a incomplete  implementation.
Detecting this is a bit of a pain. I did my best to attempt a detection snippet
with:

#include 
#if __cplusplus >= 201103L && \
(!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
(defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
 defined(_GLIBCXX_REGEX_STATE_LIMIT)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif

This uses internal macros that are not guaranteed to exist. Would it be
possible to include a _GLIBCXX_REGEX_IMPLEMENTED (or similar) that would be
supported in future versions of the library so that the snippet can be updated
so that it doesn't break for future versions of the library?

I wrote a more lengthy description of the solution on stackoverflow:

http://stackoverflow.com/a/41186162/192993

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Markus Trippelsdorf  ---
This is what creduce finally came up with: 

 % cat test_blast.ii
extern "C" int snprintf(char *, unsigned long, const char *...);
template  struct Value;
template  struct A { typedef typename Value::Type Type; };
struct B;
template  struct C;
template  struct C {
  typedef typename Value::Type Type;
};
template  struct D;
template 
struct Value> : Value {};
template 
typename A>::Type operator*(D);
template 
void operator++(D);
template  struct F;
template 
struct D> {};
template  struct C {
  typedef D::Type>> Type;
};
template 
int operator!=(D, D);
struct G {
  char *format;
  G(char *p1) : format(p1) {}
};
template 
void write(TTarget, TIValue, TSize);
template 
void appendNumber(TTarget, TValue p2) {
  char a[0];
  int b = snprintf(a, sizeof(0), p2.format, 0);
  write(0, 0, b);
}
template  void write(TTarget, TValue p2) {
  appendNumber(0, p2);
}
template  struct H {
  _Tp operator*();
  void operator++();
  int operator!=(H);
};
template  struct I {
  typedef H<_Tp> const_iterator;
  const_iterator begin();
  const_iterator end();
};
template  typename C::Type begin(T);
template  typename C::Type end(T);
template  struct String;
template  struct Value>
{
  typedef TValue Type;
};
template 
struct Value const> : Value> {};
template  struct String {};
enum BlastProgram { DYNAMIC };
template 
struct J {};
struct K {
  I> matches;
} c;
enum struct BlastTabularSpec { DYNAMIC };
template 
struct L {};
template 
void _writeStatsBlock(TStream, L, TMatch) {
  write(0, G(""));
}
template 
void _writeFullMatch(TStream, L p2,
 J) {
  _writeStatsBlock(0, p2, 0);
}
template 
void writeRecord(TStream, L p2) {
  for (auto m : c.matches)
_writeFullMatch(0, p2, m);
}
void writeRecord(int, K) {
  L<> d;
  writeRecord(0, d);
}
template 
void _testBlastOutputWriteFile(TFile, L, TRecords p3) {
  for (auto r : p3)
writeRecord(0, r);
}
template 
void _testBlastOutputGenerateContent(TFile, L p2, TFormat) {
  String e;
  _testBlastOutputWriteFile(0, p2, e);
}
template 
void _testBlastOutput(L p1, TFormat) {
  _testBlastOutputGenerateContent(0, p1, 0);
}
void foo() try {
  L<> f;
  _testBlastOutput(f, 0);
} catch (int) {
}

 % ~/gcc_test/usr/local/bin/g++ -w -O3 -c test_blast.ii
test_blast.ii: In function ‘void foo()’:
test_blast.ii:105:6: error: statement marked for throw in middle of block
 void foo() try {
  ^~~
# .MEM_26 = VDEF <.MEM_23>
snprintf (&a, 4, "", 0);

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Matt Clarkson from comment #2)
> Because wehen I compile with clang against the libstdc++ the problem will
> still occur and __GNUC__ will not be defined. This happens on any distro
> where GCC is the default but ships clang as an alternative compiler.

Not something which GCC supports directly.  You need to ask clang folks about
that :).

Anyways 4.9.x is no longer maintained; there will be no new releases after the
current release of 4.9.4 (which happened two years after the first release of
4.9.0).

[Bug middle-end/78904] zero-extracts are not effective

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Before combine we have

===
(insn 9 7 10 2 (set (subreg:SI (reg:QI 97) 0)
(zero_extract:SI (reg/v:SI 95 [ b ])
(const_int 8 [0x8])
(const_int 8 [0x8]))) "78904.c":12 105 {*extzvsi}
 (expr_list:REG_DEAD (reg/v:SI 95 [ b ])
(nil)))
(insn 10 9 11 2 (set (subreg:SI (reg:QI 98 [ a$val ]) 0)
(zero_extract:SI (reg/v:SI 94 [ a ])
(const_int 8 [0x8])
(const_int 8 [0x8]))) "78904.c":12 105 {*extzvsi}
 (nil))
(insn 11 10 26 2 (parallel [
(set (reg:QI 88 [ _2 ])
(plus:QI (reg:QI 97)
(reg:QI 98 [ a$val ])))
(clobber (reg:CC 17 flags))
]) "78904.c":12 214 {*addqi_1}
 (expr_list:REG_DEAD (reg:QI 98 [ a$val ])
(expr_list:REG_DEAD (reg:QI 97)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 13 12 14 2 (set (zero_extract:SI (reg:SI 92 [ D.1801 ])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(subreg:SI (reg:QI 88 [ _2 ]) 0)) "78904.c":14 109 {insvsi_1}
 (expr_list:REG_DEAD (reg:QI 88 [ _2 ])
(nil)))
===

and combine then does

===
Trying 10, 9 -> 11:
Failed to match this instruction:
(parallel [
(set (reg:QI 88 [ _2 ]) 
(plus:QI (subreg:QI (zero_extract:SI (reg/v:SI 94 [ a ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(subreg:QI (zero_extract:SI (reg/v:SI 95 [ b ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)))
(clobber (reg:CC 17 flags))
])
===

and then it later tries 10, 9 -> 11 and 9, 11 -> 13 etc., but you need
11, 10, 9 -> 13 to match your insn pattern.

Maybe you want a pattern for the result of 10, 9 -> 11?  It is a valid
insn for i386 I think?

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to Markus Trippelsdorf from comment #5)
> This is what creduce finally came up with: 

Thanks for the test case.  The ICE goes away if the snprintf declaration is
declared throw() or attribute nothrow, or if __builtin_snprintf is used
directly.

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[mattyclarkson at gmail dot com]

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

--- Comment #4 from Matt Clarkson  ---
That's OK. I'm not particularly looking for the macro to be backported to 4.9.
Just as we move forward the new macro is available. If not it's not the end of
the world I can always maintain the snippet internally.

[Bug c++/78906] New: ICE with a member variable template whose type is a decltype of a member variable template of a class template

[ville.voutilainen at gmail dot com]

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

Bug ID: 78906
   Summary: ICE with a member variable template whose type is a
decltype of a member variable template of a class
template
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

template  struct A { static constexpr int digits = 0; };
template  struct B {
  template ::digits>
  static constexpr int XBitMask = 0;
};
struct C {
  using ReferenceHost = B;
  template  static decltype(ReferenceHost::XBitMask<0>) XBitMask;
};
int main() { C::XBitMask<0>; }

prog.cc:8:62: internal compiler error: Segmentation fault
   template  static decltype(ReferenceHost::XBitMask<0>) XBitMask;
  ^~~~
0xb04b0f crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:333
0x615d7c tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13172
0x622612 tsubst_template_args
/home/heads/gcc/gcc-source/gcc/cp/pt.c:11415
0x622ebc tsubst_aggr_type
/home/heads/gcc/gcc-source/gcc/cp/pt.c:11618
0x616399 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13098
0x62288b tsubst_qualified_id
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13979
0x625f41 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16550
0x61af77 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16146
0x62039c coerce_template_parms
/home/heads/gcc/gcc-source/gcc/cp/pt.c:7801
0x620c83 finish_template_variable(tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8782
0x620dc6 lookup_and_finish_template_variable
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8820
0x6229a9 tsubst_qualified_id
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14046
0x625f41 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16550
0x615e51 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13750
0x615e51 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13750
0x6231fc tsubst_decl
/home/heads/gcc/gcc-source/gcc/cp/pt.c:12511
0x61656f tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:13016
0x6159cb instantiate_template_1
/home/heads/gcc/gcc-source/gcc/cp/pt.c:17811
0x6159cb instantiate_template(tree_node*, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:17867
0x6c0cba finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
/home/heads/gcc/gcc-source/gcc/cp/semantics.c:3689
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/78906] ICE with a member variable template whose type is a decltype of a member variable template of a class template

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Ville Voutilainen  ---
Clang accepts the code.

[Bug tree-optimization/78856] [6/7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Mostly to record my thoughts...

Loop unrolling inserts a __builtin_unreachable as part of unrolling one of the
loops.  DOM3 looks at the first 10 or so blocks determines they all have a
statically determined successor and collapses the mess down to:

;;   basic block 2, loop depth 0, count 0, freq 333, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  f[0] = 1;
  f[1] = 1;
  f[2] = 1;
  e.3_3 = e;
  b.1_1 = b;
  c.2_2 = c;
  _31 = c.2_2 != 0;
  _15 = b.1_1 == 0 ? _31 : 0;
  iftmp.0_24 = (int) _15;
  _84 = 2;
  _4 = 9;
  _47 = 3;
  _49 = 9;
  _56 = 4;
  _57 = 9;
  _25 = 5;
  _86 = 9;
  __builtin_unreachable ();
;;succ:

And of course removes everything else.  If I work through the CFG prior to DOM3
by hand, I get the same result -- we always pass control to the block with the
__builtin_unreachable.  I really wonder if the problem is somewhere in loop
unrolling.

[Bug c++/78906] ICE with a member variable template whose type is a decltype of a member variable template of a class template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-22
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Here's a smaller test case:

$ cat t.C && gcc -O1 -S -Wall t.C
extern "C" int snprintf (char *, __SIZE_TYPE__, const char *, ...);

int foo ()
{
  try {
return snprintf (0, 0, "");
  } catch (...) { }
}
t.C: In function ‘int foo()’:
t.C:6:30: warning: zero-length gnu_printf format string [-Wformat-zero-length]
 return snprintf (0, 0, "");
  ^
t.C:8:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
t.C:3:5: error: dead STMT in EH table
 int foo ()
 ^~~
# .MEM_3 = VDEF <.MEM_2(D)>
_4 = snprintf (0B, 0, "");
t.C:3:5: internal compiler error: verify_gimple failed
0x1194b67 verify_gimple_in_cfg(function*, bool)
/src/gcc/git/gcc/tree-cfg.c:5266
0x1023a92 execute_function_todo
/src/gcc/git/gcc/passes.c:1965
0x1022b1d do_per_function
/src/gcc/git/gcc/passes.c:1649
0x1023c64 execute_todo
/src/gcc/git/gcc/passes.c:2015
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/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #40402|0   |1
is obsolete||

--- Comment #2 from Jakub Jelinek  ---
Created attachment 40403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40403&action=edit
gcc7-pr78899.patch

Updated patch.  tree-ssa/pr71077.c FAILs with this patch though:
gcc.dg/tree-ssa/pr71077.c:18:5: internal compiler error: in
compute_live_loop_exits, at tree-ssa-loop-manip.c:229
0xc7d317 compute_live_loop_exits
../../gcc/tree-ssa-loop-manip.c:229
0xc7d317 add_exit_phis_var
../../gcc/tree-ssa-loop-manip.c:316
0xc7d317 add_exit_phis
../../gcc/tree-ssa-loop-manip.c:338
0xc7d317 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../gcc/tree-ssa-loop-manip.c:657
0xd8e26c vectorize_loops()
../../gcc/tree-vectorizer.c:716
Please submit a full bug report,

so more time will need to be spent on it.

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Rin Okuyama from comment #9)
> > > However, I have a question on this fix. How about the case where
> > > "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified?
> > 
> > That might or might not work; the user had better know what he is
> > doing if he uses an assembler option.
> 
> Hmm, I understand. Is this documented explicitly anywhere?

Not in so many words I think, no.

> > GCC does not support -me500, right.  You need to configure your compiler
> > for a powerpc-*-eabispe* target as far as I know (I'm no expert on this).
> 
> We use -Wa,-me500 option to compile kernel on some machines. As they
> share userland with other machines, we cannot configure GCC for a
> powerpc-*-eabispe* target. Instead, I found a workaround to specify
> -mcpu=powerpc option. It passes -mppc option to assembler, but as it
> is preceding to -me500, the latter is prior to the former.

Maybe you could use -mcpu=e500mc or similar?  Or, GCC should probably
have a -mcpu=e500 option, but someone has to write the code for it.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
(In reply to janus from comment #2)
> (In reply to janus from comment #0)
> > It seems like the first character is being swallowed somewhere ...
> 
> Moreover the EOF is supposed to be an EOR?

I will start looking at this. I wonder off hand if we have an EOF because we
start reading one position off. I will see what I can figure out.

[Bug tree-optimization/78856] [6/7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
I can't prove it yet, but I suspect this is another case where transformations
have collapsed loops and invalidated the cached iteration information.

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 40404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40404&action=edit
gcc7-pr78901.patch

There are multiple issues, this patch hopefully fixes just one of them - the
case when the call might throw and is replaced by a constant that can't throw.
The other problems are:
if the call is not the NULL buffer, 0 size case, where the call is kept, just
lhs removed and lhs = cst; added after the call, then if the call might throw
(thus has to be last in the bb), inserting a stmt after it is invalid - if
(stmt_ends_bb_p (info.callstmt), then the stmt needs to be added to the
beginning of the fallthru basic block.  And another problem is that while you
nicely remove lhs = snprintf (0, 0, ""); call and just set lhs = 0;, if the
user just writes useless snprintf (0, 0, ""); without lhs, then nothing removes
it at all.  If the call has no lhs and is info.nowrite, then I think we can
just remove it (the case replacing it with constant will work for that too).

[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug middle-end/78904] zero-extracts are not effective

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #1)
> ===
> Trying 10, 9 -> 11:
> Failed to match this instruction:
> (parallel [
> (set (reg:QI 88 [ _2 ]) 
> (plus:QI (subreg:QI (zero_extract:SI (reg/v:SI 94 [ a ])
> (const_int 8 [0x8])
> (const_int 8 [0x8])) 0)
> (subreg:QI (zero_extract:SI (reg/v:SI 95 [ b ])
> (const_int 8 [0x8])
> (const_int 8 [0x8])) 0)))
> (clobber (reg:CC 17 flags))
> ])
> ===
> 
> and then it later tries 10, 9 -> 11 and 9, 11 -> 13 etc., but you need
> 11, 10, 9 -> 13 to match your insn pattern.
> 
> Maybe you want a pattern for the result of 10, 9 -> 11?  It is a valid
> insn for i386 I think?
No, unfortunately the above is not a valid x86 insn. x86 has two-operand
instructions, so output has to match one of the operands.

It looks that combine prefers:

   (subreg:SI (plus:QI
and 
   (subreg:QI (zero_extract:SI (... op ...)

while - according to the existing x86 patterns - in the past the patterns were
seemingly combined into:

(plus:SI
and
  (zero_extract:SI (... op ...)

[Bug middle-end/78904] zero-extracts are not effective

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Uroš Bizjak from comment #2)
> No, unfortunately the above is not a valid x86 insn. x86 has two-operand
> instructions, so output has to match one of the operands.

But these are pseudos.

> It looks that combine prefers:
> 
>(subreg:SI (plus:QI
> and 
>(subreg:QI (zero_extract:SI (... op ...)
> 
> while - according to the existing x86 patterns - in the past the patterns
> were seemingly combined into:
> 
>   (plus:SI
> and
> (zero_extract:SI (... op ...)

So when did this change?

Combine in general prefers smaller modes.

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Dec 22 20:27:52 2016
New Revision: 243895

URL: https://gcc.gnu.org/viewcvs?rev=243895&root=gcc&view=rev
Log:
2016-12-22  Thomas Koenig  

Backport from trunk
PR fortran/78239
* decl.c (char_len_param_value): Also check for -fimplicit-none
when determining if implicit none is in force.

2016-12-22  Thomas Koenig  

Backport from trunk
PR fortran/78239
* gfortran.dg/fimplicit_none_1.f90:  New test.
* gfortran.dg/fimplicit_none_2.f90:  New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/fimplicit_none_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/78906] ICE with a member variable template whose type is a decltype of a member variable template of a class template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Dec 22 20:29:07 2016
New Revision: 243897

URL: https://gcc.gnu.org/viewcvs?rev=243897&root=gcc&view=rev
Log:
PR c++/78906 - ICE with member variable template

* pt.c (finish_template_variable): Use most_general_template.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ54.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

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

[Bug fortran/66189] Block loops for inline matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Thomas Koenig  ---
So, the agreement is that we don't want to do this,
at least at the moment.  Closing as WONTFIX.

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu.org]

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

Bug 66189 Summary: Block loops for inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug libfortran/51119] MATMUL slow for large matrices

[tkoenig at gcc dot gnu.org]

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

Bug 66189 Summary: Block loops for inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug middle-end/78904] zero-extracts are not effective

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > No, unfortunately the above is not a valid x86 insn. x86 has two-operand
> > instructions, so output has to match one of the operands.
> 
> But these are pseudos.

Please note that

subreg:QI (zero_extract:SI (reg/v:SI 94 [ a ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)

describes the high-part of a 16bit register, e.g. %ah, while

(reg:QI 88 [ _2 ])

describes low-part, e.g. %al

The pattern from the comment #1 models %al <- %ah + %bh, which is not a valid
x86 insn.

> > It looks that combine prefers:
> > 
> >(subreg:SI (plus:QI
> > and 
> >(subreg:QI (zero_extract:SI (... op ...)
> > 
> > while - according to the existing x86 patterns - in the past the patterns
> > were seemingly combined into:
> > 
> > (plus:SI
> > and
> >   (zero_extract:SI (... op ...)
> 
> So when did this change?
> 
> Combine in general prefers smaller modes.

I don't know when, perhaps with the rewrite of extzv pattern, when mode was
added to these patterns?

Anyway, I see that some patterns, e.g. *cmpqi_ext_1 are written using

(subreg:QI (zero_extract:SI ...)), which seems consistent with your observation
in Comment #1. Following your explanation, it looks that:

(set (zero_extract:SI (reg:SI 92 [ D.1804 ])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(subreg:SI (_op_:QI ...

corresponds to setting of the highpart register (%ah), and consequently arith
and logic patterns in i386.md have to be rewritten.

[Bug tree-optimization/78856] [6/7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
So what appears to be happening is we have two loops, one natural, and an inner
irreducible loop.

We have a potential jump thread that starts on outside the outer loop and
targets a block that is in the irreducible region.  In essence it's crossing
two loop boundaries.   The transformations we make are all valid, but we have
that pesky cached loop iteration information which is incorrect after that
transformation.

Interestingly enough the jump threader already tries to avoid this kind of
situation (crossing multiple loop boundaries) -- but it only does so for
natural loop boundaries.  After reviewing the history of that code, there's a
good chance it was also working around the cached iteration information
problem.  The best solution may be to improve the detection code and properly
invalidate rather than just suppress the jump thread.  Still investigating.

[Bug middle-end/78904] zero-extracts are not effective

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
Created attachment 40405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40405&action=edit
Prototype patch for addqi_ext_[1,2] patterns

The prototype patch compiles the testcase to:

movl%edi, %edx
movl%esi, %eax
xorw%di, %di
addb%dh, %ah
movzwl  %ax, %eax
orl %edi, %eax

[Bug tree-optimization/78496] [7 Regression] Missed opportunities for jump threading

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
There's definitely a missing jump thread here.  ANd we've got code that's
supposed to handle this.

[Bug c++/78907] New: internal compiler error segmentation fault with recursive constexpr

[hr.jonas.hansen at gmail dot com]

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

Bug ID: 78907
   Summary: internal compiler error segmentation fault with
recursive constexpr
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hr.jonas.hansen at gmail dot com
  Target Milestone: ---

I recently updated my g++ version to 6.3.0 (g++ (Homebrew GCC 6.3.0) 6.3.0),
but now i get the following error:

g++: internal compiler error: Segmentation fault: 11 (program cc1plus). 

With the previous version (I'm not completely sure but around) 5.2 everything
worked. And on of my other computers I use g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1
and that also works.

The code is:

constexpr bool checkForPrimeNumber(const int p, const int t)
{
return p <= t or (p % t and checkForPrimeNumber(p, t + 2));
}

constexpr bool checkForPrimeNumber(const int p)
{
return p == 2 or (p & 1 and checkForPrimeNumber(p, 3));
}

int main() 
{
static_assert(checkForPrimeNumber(65521), "bug...");
}


I compile the code with:
g++ test.cpp -std=c++11 -fconstexpr-depth=65535

[Bug middle-end/78904] zero-extracts are not effective

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
A better testcase:

--cut here--
struct S1
{
  char pad1;
  unsigned char val;
  short pad2;
};

struct S1 test (struct S1 a, struct S1 b)
{
  a.val += b.val;

  return a;
}
--cut here--

compiles with -O2 to:

movl%edi, %eax
movl%esi, %ecx
movzbl  %ch, %edx
movzbl  %ah, %esi
addl%esi, %edx
movb%dl, %ah

with patched compiler:

movl%edi, %eax
movl%esi, %edx
addb%ah, %dh
movl%edx, %eax