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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Reducing the test-case bit more:

$ int a = 0, c = 0;
static int d[][8] = {};

int main ()
{
  int e;
  for (int b = 0; b < 4; b++)
{
  __builtin_printf ("%d\n", b, e);
  while (a && c++)
e = d[30][0];
}

  return 0;
}

Problem is that we segfault here:

   │0x8048448  push   %ebx
   │0x8048449  push   %ecx
   │0x804844a  mov$0x0,%ebx
   │0x804844f  jmp0x8048459 
   │0x8048451  add$0x1,%ebx
   │0x8048454  cmp$0x4,%ebx
   │0x8048457  je 0x804849f 
   │0x8048459  sub$0x4,%esp
  >│0x804845c  pushl  0x1bc48534

which is I guess d[30][0], which is a dead-code that is placed
before the printf call first time in 273r.ira:

...
(insn 8 7 9 3 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1  S4 A32])
(mem/u:SI (const:SI (plus:SI (symbol_ref:SI ("d") [flags 0x2] 
)
(const_int 331350016 [0x13c0]))) [1 d+331350016 S4
A32])) "tc.c":9 58 {*pushsi2}
 (expr_list:REG_ARGS_SIZE (const_int 8 [0x8])
(nil)))
(insn 9 8 10 3 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1  S4 A32])
(reg/v:SI 88 [ b ])) "tc.c":9 58 {*pushsi2}
 (expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil)))
(insn 10 9 11 3 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [2  S4 A32])
(symbol_ref/f:SI ("*.LC0") [flags 0x2]  )) "tc.c":9 58 {*pushsi2}
 (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
(call_insn 11 10 12 3 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("printf") [flags 0x41]  ) [0 __builtin_printf S1 A8])
(const_int 16 [0x10]))) "tc.c":9 663 {*call_value}
 (expr_list:REG_UNUSED (reg:SI 0 ax)
(nil))
(nil))

That points to a different commit, I'll bisect that.

[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-31
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r242872, which is however just a pass manager changes.
Thus I suspect it's a latent issue.

[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-31
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|[5 Regression] ICE in   |[7 Regression] ICE in
   |mangle_decl, at |mangle_decl, at
   |cp/mangle.c:3845|cp/mangle.c:3845
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r244935.

[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-31
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r241765.

[Bug ipa/79285] [7 Regression] new valgrind error in build

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I've got a patch for that, currently testing.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[doug.gilmore at imgtec dot com]

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

Doug Gilmore  changed:

   What|Removed |Added

 CC||law at redhat dot com,
   ||rguenth at gcc dot gnu.org,
   ||zqchen at gcc dot gnu.org

--- Comment #18 from Doug Gilmore  ---
CC author and reviewers of r216501.

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
new_ready just adds insns to the ready list.  High latency isn't
directly a problem: if we can schedule a high latency insn early
speculatively, that is a _good_ thing!

[Bug target/79299] New: [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw

[asolokha at gmx dot com]

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

Bug ID: 79299
   Summary: [7 Regression] Operand size mismatch for `vpgatherqd'
w/ -O3 -masm=intel -mavx512bw
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

When compiling the following snippet w/ -O3 -masm=intel -mavx512bw (and other
flavors of AVX-512) using gcc-7.0.0-alpha20170129 snapshot, gas 2.27 emits the
"operand size mismatch" error for instruction vpgatherqd:

int
q9 (int b7, int dr)
{
  int **ov;
  int rk = 

  while (dr != 0)
{
  while (b7 != 0)
++b7;
  rk += **ov;
  ++dr;
}

  return rk;
}

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20170129 -O3 -masm=intel -mavx512bw -c -w
xivubswo.c
/tmp/cc27Zzec.s: Assembler messages:
/tmp/cc27Zzec.s:38: Error: operand size mismatch for `vpgatherqd'
/tmp/cc27Zzec.s:39: Error: operand size mismatch for `vpgatherqd'

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner  ---
I agree the expander should call gpc_reg_operand and not reg_operand.  This is
due to the fact that on PowerPCs with separate floating point registers, SFmode
is represented internally as DFmode when it is in the floating point/vector
registers (i.e. my change on January 4th, 2017).  I evidently missed the
expander.

The history is originally we had a define_expand and three separate insns, one
in rs6000.md that handled the non-VSX case, one in spe.md, and one in vsx.md
that handled VSX, and it had a common insn for DF, V2DF, and V4SF modes.  We
later moved the scalar processing to rs6000.md.

However, since spe.md has its own unsigned fix insns, and it uses wildly
different constraints, etc. we need to keep a separate define_expand, and two
define_insns (in rs6000.md and spe.md).

Note, I have no way of testing SPE, other than by hand inspection of the
assembly code.

[Bug sanitizer/79265] -fsanitize=undefined inserts unnecessary null pointer tests

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
As I mentioned, the unnecessary null tests inserted by the sanitizer are
usually removed by subsequent optimization passes so they serve no useful
purpose.  They do, however, make GCC work harder which can cause trouble when
they result in calls to the nonnull functions with constant null pointers as a
result of jump threading (as we have seen, and as demonstrated by the test case
below).

In the test case in comment #0 GCC eliminates the null pointer checks in f0
(local array) and f2 (alloca) but retains those in f1 (VLA) and f3 (attribute
nonnull).  In all of f0, f1, and f2, the object whose address is tested against
null is on the stack, so emitting a null check in all three is equally
important or equally pointless (depending on one's point of view).

The only case where a valid pointer cannot point into the stack is f3.  In this
case the pointer is "guaranteed" to be non-null by the function being declared
attribute returns_nonnull.  As I also mentioned, there may be some value in
emitting the null pointer check here in case the returns_nonnull function
returns null despite its promise.  Even then, however, there is no point in
emitting the check or the handler more than once when the pointer is being
passed to a nonnull argument of a built-in function like sprintf (or strcpy)
that we know will try to write to it and crash.  Doing so only leads to
unnecessarily inefficient code and can cause false positives.  (The repeated
calls to the UBSan null handler are also unnecessary in these cases and suggest
missing logic in the sanitizer.)

Here's another test case highlighting the returns_nonnull problem discussed
above:

$ cat u.c && gcc -O3 -S -Wall -fdump-tree-optimized=/dev/stdout
-fsanitize=undefined u.c

char* __attribute__ ((alloc_size (1), returns_nonnull))
myalloc (unsigned);

void sink (void*);

void __attribute__ ((noinline, nonnull))
f (unsigned n)
{
  char *p = myalloc(n);

  *p = 'a';

  __builtin_sprintf (p, "%i", 1);
  sink (p);

  __builtin_sprintf (p, "%i", 2);
  sink (p);
}
u.c: In function ‘f’:
u.c:13:3: warning: null destination pointer [-Wformat-overflow=]
   __builtin_sprintf (p, "%i", 1);
   ^~

;; Function f (f, funcdef_no=0, decl_uid=2121, cgraph_uid=0, symbol_order=0)

__attribute__((noinline))
f (unsigned int n)
{
  char * p;

   [100.00%]:
  p_4 = myalloc (n_2(D));
  if (p_4 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_type_mismatch (&*.Lubsan_data4, 0);

   [100.00%]:
  *p_4 = 97;
  if (p_4 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0);
  __builtin_sprintf (0B, "%i", 1);
  sink (0B);
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);

   [100.00%]:
  __builtin_sprintf (p_4, "%i", 2);
  sink (p_4); [tail call]
  return;

   [99.96%]:
  __builtin_sprintf (p_4, "%i", 1);
  sink (p_4);
  goto ; [100.00%]

}

[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Guess this is key line "Not unifying; Symbol aliases are not supported by
target".

[Bug c++/79298] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-31
 CC||dmalcolm at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Bisection points to r244715:

r244715 | dmalcolm | 2017-01-20 09:36:46 -0500 (Fri, 20 Jan 2017) | 33 lines

C++: fix fix-it hints for misspellings within explicit namespaces

[Bug debug/63238] DWARF does not represent _Alignas

[aoliva at gcc dot gnu.org]

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

--- Comment #2 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Jan 31 01:03:15 2017
New Revision: 245052

URL: https://gcc.gnu.org/viewcvs?rev=245052=gcc=rev
Log:
[PR63238] output alignment debug information

Output DWARFv5+ DW_AT_alignment for non-default alignment of
variables, fields and types.

for gcc/ChangeLog

PR debug/63238
* dwarf2out.c (clone_as_declaration): Drop DW_AT_alignment.
(add_alignment_attribute): New.
(base_type_die): Add alignment attribute.
(subrange_type_die): Likewise.
(modified_type_die): Likewise.
(gen_array_type_die): Likewise.
(gen_descr_array_type_die: Likewise.
(gen_enumeration_type_die): Likewise.
(gen_subprogram_die): Likewise.
(gen_variable_die): Likewise.
(gen_field_die): Likewise.
(gen_ptr_to_mbr_type_die): Likewise.
(gen_struct_or_union_type_die): Likewise.
(gen_subroutine_type_die): Likewise.
(gen_typedef_die): Likewise.
(base_type_cmp): Compare alignment attribute.

for gcc/testsuite/ChangeLog

PR debug/63238
* gcc.dg/debug/dwarf2/align-1.c: New.
* gcc.dg/debug/dwarf2/align-2.c: New.
* gcc.dg/debug/dwarf2/align-3.c: New.
* gcc.dg/debug/dwarf2/align-4.c: New.
* gcc.dg/debug/dwarf2/align-5.c: New.
* gcc.dg/debug/dwarf2/align-6.c: New.
* gcc.dg/debug/dwarf2/align-as-1.c: New.
* g++.dg/debug/dwarf2/align-1.C: New.
* g++.dg/debug/dwarf2/align-2.C: New.
* g++.dg/debug/dwarf2/align-3.C: New.
* g++.dg/debug/dwarf2/align-4.C: New.
* g++.dg/debug/dwarf2/align-5.C: New.
* g++.dg/debug/dwarf2/align-6.C: New.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-1.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-3.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-4.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-5.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/align-6.C
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-1.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-2.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-3.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-4.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-5.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-6.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/align-as-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[doug.gilmore at imgtec dot com]

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

--- Comment #17 from Doug Gilmore  ---
> This really throws off the costing of substituting different IVs on
> MIPS.
I forgot to mention that for MIPS the net of effect r216501 is to not
produce indexed memory OPs in simple examples where we should.  But
we also will produce problematic indexed memory OPs in situations
where address generation costing is a bit complicated (the original
issue associated with this bug report).

Applying the the two patches I just attached fixes the problem of
generating indexed memory OPs in simple examples, and also will cause
IVOPTS to select IVs that are similar to those that were made in the
past that avoids the problem executing indexed memory OPs in O32
binaries on 64-bit MIPS processors running current Linux kernels.

There is still the issue of recognizing that rewriting a "use" to use
a different IV can expose a problem with indexed memory OPs on 64-bit
MIPS processors, where an infinite cost should be associated in that
situation, that still needs to be addressed (thus the need for the
flag to turn off the generation of indexed memory OPs until this issue
is addressed).

[Bug c++/79298] New: ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 79298
   Summary: ICE on invalid C++ code on x86_64-linux-gnu:
Segmentation fault
   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 seems to be a recent regression. 


$ g++-trunk -v  
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170130 (experimental) [trunk revision 245020] (GCC) 
$ 
$ g++-trunk -c tmp.cpp
tmp.cpp: In function ‘int foo()’:
tmp.cpp:6:13: error: ‘y’ is not a member of ‘M’
   return M::y;
 ^
tmp.cpp:6:13: internal compiler error: Segmentation fault
0xe13a2f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x89192b consider_binding_level
../../gcc-source-trunk/gcc/cp/name-lookup.c:4788
0x897a81 suggest_alternative_in_explicit_scope(unsigned int, tree_node*,
tree_node*)
../../gcc-source-trunk/gcc/cp/name-lookup.c:4529
0x7871b4 qualified_name_lookup_error(tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc-source-trunk/gcc/cp/error.c:3780
0x843ef8 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc-source-trunk/gcc/cp/semantics.c:3461
0x7b0373 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:5335
0x7b314e cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6782
0x7ae3cc cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8101
0x7bb627 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8778
0x7bbc35 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8880
0x7bc520 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9168
0x7befe9 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9335
0x7d16a3 cp_parser_jump_statement
../../gcc-source-trunk/gcc/cp/parser.c:12145
0x7d16a3 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10579
0x7d21cc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11025
0x7d22bf cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10979
0x7cccaf cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21431
0x7cccaf cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21467
0x7cd591 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26235
0x7ce7c9 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26147
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


namespace N { int x; }
namespace M = N; 

int foo () 
{
  return M::y;
}

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[doug.gilmore at imgtec dot com]

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

--- Comment #16 from Doug Gilmore  ---
Created attachment 40632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40632=edit
Tweak to adjust_setup_cost (r220473).

Second patch associated with previous comment.

[Bug target/79277] lies about alignment of DFmode

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Note that for compatibility you don't want to change either __alignof__ 
(double) (preferred alignment, 8) or _Alignof (double) (required 
alignment, 4).

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[doug.gilmore at imgtec dot com]

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

--- Comment #15 from Doug Gilmore  ---
Created attachment 40631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40631=edit
Prototype change to backout r216501.

> Bisected the problem to commit r216501:

The review discussion of r216501 starts with message:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00758.html

Which contains:

The are two implementations of seq_cost. The function bodies are
exactly the same. The patch removes one of them and make the other
global.

This seems the patch was cleanup that shouldn't introduce a
functional change.

However implementations of seq_cost are different, per
final version of the patch:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00896.html

cfgloopanal.c:
-   cost += set_rtx_cost (set, speed);


rtlanal.c:
+cost += set_rtx_cost (set, speed);

tree-ssa-loop-ivopts.c:
-   cost += set_src_cost (SET_SRC (set), speed);

In general, when computing the cost of a sequence of N INSNs this
increases the cost of the sequence by N*4.  This really throws
off the costing of substituting different IVs on MIPS.

The first patch attached (just a prototype) basically reverts
this change.  The second fixes a problem with r220473, a fix
for PR62631 from Eric Botcazou:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631#c17

This looks a generic problem in get_shiftadd_cost to me, it ought
to mimic the algorithms in expmed.c, something like ...

This change can lower the cost of a sequence of instruction.  However
there are situations this (lower) cost is being scaled by an estimated
iteration count will cause the adjusted cost to now become zero.  For
the example attached to the second patch the IV replacement algorithm
will determine that the cost using separate IVs for each load will be
less than then cost of one IV for all loads.

Thus, in the second patch we detect that a non-zero cost being scaled
to zero should represented by one instead, which gets us back to
IVSOPTS generating just one IV that will be used for all loads.

[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Bernd Schmidt from comment #5)
> (In reply to Christophe Leroy from comment #0)
> 
> > The following section is just useless: (shift left 4 bits, remove 16, shift
> > right 4 bits, add 1)
> > c000d984:   55 24 20 36 rlwinm  r4,r9,4,0,27
> > c000d988:   39 24 ff f0 addir9,r4,-16
> > c000d98c:   55 29 e1 3e rlwinm  r9,r9,28,4,31
> > c000d990:   39 29 00 01 addir9,r9,1
> 
> Are you suggesting just removing these? That would not produce the same
> value in all cases - consider zero as an input:
> 
> ((0 << 4) - 16) >> 4 = 0xfff, add one and you get 0x1000.

But this cannot happen, see the two immediately preceding instructions.

[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I forgot to provide the error. For completeness, it's:

s.cc: In member function ‘bool Printer::operator()(SongTag)’:
s.cc:16:36: error: request for member ‘int (Song::*)(unsigned int)
const::__pfn’ in ‘st.SongTag::function()’, which is of non-class type
‘Song::GetFunction {aka int (Song::*)(unsigned int) const}’
 return st.function() == ::get;
^~~

[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
Created attachment 40630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40630=edit
preprocessed source

[Bug middle-end/79297] New: [7 Regression] ICE (segfault) in main_block_label

[doko at gcc dot gnu.org]

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

Bug ID: 79297
   Summary: [7 Regression] ICE (segfault) in main_block_label
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20170129

$ cat share.ii
struct a {
  a() {
goto b;
if (0)
b:;
  }
} c;
(exp)doko@gb:/scratch/packages/tmp/yosys-0.7$ g++ -std=c++11 -c share.ii 
share.ii: In constructor 'a::a()':
share.ii:2:3: internal compiler error: Segmentation fault
   a() {
   ^
0xb1317f crash_signal
../../src/gcc/toplev.c:333
0xb3c743 main_block_label
../../src/gcc/tree-cfg.c:1381
0xb3cc3d cleanup_dead_labels()
../../src/gcc/tree-cfg.c:1564
0xb477f1 build_gimple_cfg
../../src/gcc/tree-cfg.c:238
0xb477f1 execute_build_cfg
../../src/gcc/tree-cfg.c:397
0xb477f1 execute
../../src/gcc/tree-cfg.c:433
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Created attachment 40629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40629=edit
ipa dump

[Bug c++/79296] New: [5 Regression] ICE in mangle_decl, at cp/mangle.c:3845

[doko at gcc dot gnu.org]

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

Bug ID: 79296
   Summary: [5 Regression] ICE in mangle_decl, at cp/mangle.c:3845
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen with 20170129

$ cat test_alias_initialization.ii
namespace a {
class b {
public:
  template  b(c h::*...) {
[] {};
  }
};
class d {};
template  class e {
public:
  template  void ab(const char *, g l) { b(l, int()); }
};
}
template  class ac;
template  class B {
protected:
  static ad i(int) {}
};
template  class o;
template 
class o : B {
public:
  static af k(const int , j... l) { B::i(p1)(l...); }
};
template  class ac {
  template  using m = int;

public:
  template , typename = m>
  ac(ad);
  using ah = af (*)(const int &, j...);
  ah n;
};
template 
template 
ac::ac(ad) {
  n = o::k;
}
namespace ai = a;
class q {
public:
  q(ac);
} r([](ai::d) {
  struct p {
virtual void f();
  };
  struct aj;
  ai::e().ab("", ::f);
});

$ g++ -c -std=c++14 -flto test_alias_initialization.ii
test_alias_initialization.ii:5:6: internal compiler error: in mangle_decl, at
cp/mangle.c:3845
 [] {};
  ^
0x6f3372 mangle_decl(tree_node*)
../../src/gcc/cp/mangle.c:3844
0xd29b1b decl_assembler_name(tree_node*)
../../src/gcc/tree.c:671
0xd29b1b assign_assembler_name_if_needed(tree_node*)
../../src/gcc/tree.c:5920
0xd2aeb1 free_lang_data_in_cgraph
../../src/gcc/tree.c:5969
0xd2aeb1 free_lang_data
../../src/gcc/tree.c:6006
0xd2aeb1 execute
../../src/gcc/tree.c:6055
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Mon Jan 30 23:24:24 2017
New Revision: 245041

URL: https://gcc.gnu.org/viewcvs?rev=245041=gcc=rev
Log:
2017-01-27  Aaron Sawdey  

PR target/79170
* gcc.dg/memcmp-1.c: Improved to catch failures seen in PR 79170.

2017-01-27  Aaron Sawdey  

PR target/79170
* config/rs6000/altivec.md (*setb_internal): Rename to setb_signed.
(setb_unsigned) New pattern for setb with CCUNS.
* config/rs6000/rs6000.c (expand_block_compare): Use a different
subfc./subfe sequence to avoid overflow problems.  Generate a
shorter sequence with cmpld/setb for power9.
* config/rs6000/rs6000.md (subf3_carry_dot2): Add a new pattern
for generating subfc. instruction.
(cmpstrsi): Add TARGET_POPCNTD predicate as the generate sequence
now uses this instruction.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/memcmp-1.c

[Bug other/79295] New: [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

[seurer at gcc dot gnu.org]

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

Bug ID: 79295
   Summary: [7 regression] gcc.target/powerpc/bcd-3.c fails
starting with r244942
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Causes an ICE

spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O2
-ffat-lto-objects -S -o bcd-3.s
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c: In function
'do_add_lt':
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c:34:1: error:
insn does not satisfy its constraints:
(insn 44 3 13 2 (parallel [
(set (reg/v:V1TI 32 0 [orig:156  ] [156])
(unspec:V1TI [
(reg/v:V1TI 77 0 [orig:157 a ] [157])
(reg/v:V1TI 78 1 [orig:158 b ] [158])
(const_int 0 [0])
] UNSPEC_BCDADD))
(set (reg:CCFP 74 6)
(compare:CCFP (unspec:V2DF [
(reg/v:V1TI 77 0 [orig:157 a ] [157])
(reg/v:V1TI 78 1 [orig:158 b ] [158])
(const_int 0 [0])
] UNSPEC_BCDADD)
(const_vector:V2DF [
(const_double:DF 0.0 [0x0.0p+0])
(const_double:DF 0.0 [0x0.0p+0])
])))
])
"/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c":30 1753
{*bcdadd_test2}
 (nil))
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/bcd-3.c:34:1:
internal compiler error: in extract_constrain_insn, at recog.c:2213
0x108a9b13 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/seurer/gcc/gcc-test/gcc/rtl-error.c:108
0x108a9b6b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/seurer/gcc/gcc-test/gcc/rtl-error.c:119
0x1086fa67 extract_constrain_insn(rtx_insn*)
/home/seurer/gcc/gcc-test/gcc/recog.c:2213
0x10874e1f copyprop_hardreg_forward_1
/home/seurer/gcc/gcc-test/gcc/regcprop.c:794
0x10875eb7 execute
/home/seurer/gcc/gcc-test/gcc/regcprop.c:1301

[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Patch committed.

[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Jan 30 22:26:26 2017
New Revision: 245039

URL: https://gcc.gnu.org/viewcvs?rev=245039=gcc=rev
Log:
PR debug/79289
* dwarf2out.c (gen_type_die_with_usage): When picking a variant
for FUNCTION_TYPE/METHOD_TYPE, use the first matching one.

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

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-30
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|wrong code at -O3 on|[7 Regression] wrong code
   |x86_64-linux-gnu in 32-bit  |at -O3 on x86_64-linux-gnu
   |mode (but not in 64-bit |in 32-bit mode (but not in
   |mode)   |64-bit mode)
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r239357.

[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-30
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r241425.

[Bug c++/79294] New: [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812

[doko at gcc dot gnu.org]

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

Bug ID: 79294
   Summary: [7 Regression] ICE in convert_nontype_argument, at
cp/pt.c:6812
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen with r244943 20170129

$ cat python.ii
template  struct a;
template  a < b

$ g++ -c -std=c++11 python.ii
python.ii:2:23: internal compiler error: in convert_nontype_argument, at
cp/pt.c:6812
 template  a < b
   ^
0x62d24a convert_nontype_argument
../../src/gcc/cp/pt.c:6811
0x62d24a convert_template_argument
../../src/gcc/cp/pt.c:7648
0x62de3c coerce_template_parms
../../src/gcc/cp/pt.c:8108
0x630139 lookup_template_class_1
../../src/gcc/cp/pt.c:8632
0x630139 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../src/gcc/cp/pt.c:8977
0x6c8bfd finish_template_type(tree_node*, tree_node*, int)
../../src/gcc/cp/semantics.c:3145
0x67923e cp_parser_template_id
../../src/gcc/cp/parser.c:15488
0x6793df cp_parser_class_name
../../src/gcc/cp/parser.c:21922
0x683987 cp_parser_qualifying_entity
../../src/gcc/cp/parser.c:6287
0x683987 cp_parser_nested_name_specifier_opt
../../src/gcc/cp/parser.c:5973
0x6705a2 cp_parser_constructor_declarator_p
../../src/gcc/cp/parser.c:25918
0x6705a2 cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.c:13312
0x670975 cp_parser_single_declaration
../../src/gcc/cp/parser.c:26574
0x68c64c cp_parser_template_declaration_after_parameters
../../src/gcc/cp/parser.c:26268
0x68c3ab cp_parser_explicit_template_declaration
../../src/gcc/cp/parser.c:26503
0x68c3ab cp_parser_template_declaration_after_export
../../src/gcc/cp/parser.c:26522
0x670ff1 cp_parser_declaration
../../src/gcc/cp/parser.c:12442
0x69692b cp_parser_declaration_seq_opt
../../src/gcc/cp/parser.c:12369
0x696c12 cp_parser_translation_unit
../../src/gcc/cp/parser.c:4369
0x696c12 c_parse_file()
../../src/gcc/cp/parser.c:38357
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug testsuite/79293] [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Test fixed via r245037.

[Bug testsuite/79293] [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Mon Jan 30 21:59:37 2017
New Revision: 245037

URL: https://gcc.gnu.org/viewcvs?rev=245037=gcc=rev
Log:
PR testsuite/79293 -  gcc.dg/tree-ssa/builtin-sprintf.c fails starting with
r244953

gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/builtin-sprintf.c: Relax long double test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c

[Bug testsuite/79293] [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-30
  Component|tree-optimization   |testsuite
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The following is the test case on line 724:

  RNG ( 3, 13, 14, "%Lg", 0.1L);

It expects the call to sprintf ("%Lg", 0.1L) to return a value between 3 and 13
but on powerpc64 it returns between 3 and 4 bytes ("0.1" when the argument is
rounded up and "0.099" when it's rounded down, with the decimal point
taking resulting in between 1 and 6 bytes in multibyte locales).

The test case needs to be relaxed for powerpc64.  Let me take care of it.

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Martin Sebor  ---
Resolving as fixed as per comment #14.

[Bug middle-end/79275] -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02353.html

[Bug target/79158] gcc.target/powerpc/pr70669.c fails on powerpc BE

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pthaugen at gcc dot 
gnu.org

--- Comment #1 from Pat Haugen  ---
The problem on BE is that the compiler recognizes it doesn't have to move the
value back to a VSR before dong the store, and just generates stores of the GPR
(hence the FAILs on mtvsrd/stxvd2x). Here's the source of testcase and output
on BE with current trunk.

#ifndef TYPE
#define TYPE __float128
#endif

void foo (TYPE *p, TYPE *q)
{
  TYPE r = *q;
#ifndef NO_ASM
  __asm__ (" # %0" : "+r" (r));
#endif
  *p = r;
}

.L.foo:
lxvd2x 0,0,4
mfvsrd 10,0
xxpermdi 0,0,0,3
mfvsrd 11,0
#APP
 # 14 "pr70669.c" 1
 # 10
 # 0 "" 2
#NO_APP
std 10,0(3)
std 11,8(3)
blr

Since this testcase is just trying to test that the moves don't go through
memory, modifying the last stmt to "*p = r + r" so that the value in 'r' (i.e.
GPR 10/11) is forced back to a VSR appears to fix the problem on BE and still
passes on LE.

Mike, Does this reasoning sound correct to you? If so I'll submit a patch.

[Bug target/78597] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-30
 CC||meissner at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Michael Meissner  ---
It is a real bug in the PowerPC backend.

The bug is that the unsigned int value of 0x8000 is converted incorrectly,
when it is converted from unsigned int to __float128 and back to unsigned int.

I have a solution already as part of PRs target/79038, target/79202, and
target/79203.

Most of the work in those bugs is an enhancement that did not make the stage3
cut, but I will try to isolate a minimum patch to fix GCC 7.

[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations

[drfiemost at email dot it]

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

--- Comment #7 from Leandro Nini  ---
Reduced testcase, ICEs with gcc -O2 -floop-interchange:

int a, b, d;
int **c;
int fn1() {
  while (a)
if (d) {
  int e = -d;
  for (; b < e; b++)
c[b] = 
} else {
  for (; b; b++)
c[b] = 
  d = 0;
}
}

[Bug ipa/79285] [7 Regression] new valgrind error in build

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-30
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, let me isolate a test-case.

[Bug tree-optimization/79293] New: [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails starting with r244953

[seurer at gcc dot gnu.org]

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

Bug ID: 79293
   Summary: [7 regression] gcc.dg/tree-ssa/builtin-sprintf.c fails
starting with r244953
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

At least I think it is 244753.  There were a bunch of updates for that revision
which left the compiler unable to build but after those were cleared up
builtin-sprintf was failing.

pawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -ansi -pedantic-errors
-O2 -Wall -Wno-pedantic -fprintf-return-value -lm -o ./builtin-sprintf.exe
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In
function 'test_d_i':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:307:20:
warning: '0' flag ignored with precision and '%i' gnu_printf format [-Wformat=]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:128:44:
note: in definition of macro 'RNG'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In
function 'test_percent':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:791:18:
warning: too many arguments for format [-Wformat-extra-args]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44:
note: in definition of macro 'EQL'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:792:18:
warning: too many arguments for format [-Wformat-extra-args]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44:
note: in definition of macro 'EQL'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:793:18:
warning: too many arguments for format [-Wformat-extra-args]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44:
note: in definition of macro 'EQL'
/tmp/ccg3ni4S.o: In function `test_g_long_double':
builtin-sprintf.c:(.text+0x5600): undefined reference to `failure_on_line_724'
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In
function 'test_d_i':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:307:20:
warning: '0' flag ignored with precision and '%i' gnu_printf format [-Wformat=]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:128:44:
note: in definition of macro 'RNG'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c: In
function 'test_percent':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:791:18:
warning: too many arguments for format [-Wformat-extra-args]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44:
note: in definition of macro 'EQL'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:792:18:
warning: too many arguments for format [-Wformat-extra-args]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44:
note: in definition of macro 'EQL'
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:793:18:
warning: too many arguments for format [-Wformat-extra-args]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c:114:44:
note: in definition of macro 'EQL'
/tmp/ccg3ni4S.o: In function `test_g_long_double':
builtin-sprintf.c:(.text+0x5600): undefined reference to `failure_on_line_724'
collect2: error: ld returned 1 exit status

PASS: gcc.dg/tree-ssa/builtin-sprintf.c  (test for warnings, line 307)
PASS: gcc.dg/tree-ssa/builtin-sprintf.c  (test for warnings, line 791)
PASS: gcc.dg/tree-ssa/builtin-sprintf.c  (test for warnings, line 792)
PASS: gcc.dg/tree-ssa/builtin-sprintf.c  (test for warnings, line 793)
FAIL: gcc.dg/tree-ssa/builtin-sprintf.c (test for excess errors)
Excess errors:
builtin-sprintf.c:(.text+0x5600): undefined reference to `failure_on_line_724'

UNRESOLVED: gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce
executable

[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm  ---
In theory we could fix the location of the stringified token; perhaps it could
use the location of the arg.

But cpp_interpret_string_ranges calls cpp_interpret_string_1 which expects the
strings it re-lexes to have opening quotes, which isn't going to be the case
for a stringified arg; we would have to somehow flag the token as being from
stringization, and to interpret it differently so that it doesn't expect
quotes.

This seems invasive and error-prone, so I think the lowest-risk fix is likely
to be to convert the failing assertion to an error-handling conditional, rather
than to attempt to fixup the locations.

[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
(In reply to Ian Lance Taylor from comment #1)
> This patch seems to fix the problem, but I can't tell whether this is
> correct or whether the other obvious change is correct.

This one looks good.

[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
For reference, after preprocessing, the format string is:
  "0423 lpfc_peer_port_login attribute cannot be set to %d, allowed range is
[0, 1]\n"
^~
...showing where the underline would be, if it was a regular string without
macros.

[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Origin of the garbage location_t value:

During macro expansion, temporary tokens (via _cpp_temp_token) use the location
of the last lexed token as their location, so identifying the origin of the
bogus location_t value requires some tracing back through a series of temporary
tokens.  The easier way to do it was to put an assertion into
linemap_position_for_column to detect where the bogus value is generated:

diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index cf7c110..021059c 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -195,6 +195,11 @@ get_combined_adhoc_loc (struct line_maps *set,
{
  source_location packed = locus | col_diff;
  set->num_optimized_ranges++;
+
+ /* What leads to this bogus value?  */
+ if (0)
+   linemap_assert (packed != 229843);
+
  return packed;
}
 }


The bogus location_t value arises when a cpp_token for the CPP_NAME
"lpfc_peer_port_login" is generated, due to:

#define LPFC_VPORT_ATTR_R(name, desc) \
unsigned int lpfc_##name;\
 ^ 
 first part

LPFC_VPORT_ATTR_R(peer_port_login,
  ^~~
  second part

and there isn't a way of representing this split location as a location_t.

In fact, it generates an entirely bogus location for the token:

line_table:   entering: void paste_all_tokens(cpp_reader*, const cpp_token*)
line_table:entering: bool paste_tokens(cpp_reader*, source_location, const
cpp_token**, const cpp_token*)
line_table: *plhs: lpfc_
../../src/pr79210-via-attachment.c:13:14: note: 209764
 unsigned int lpfc_##name;\
  ^
line_table: rhs: peer_port_login
../../src/pr79210-via-attachment.c:16:19: note: 22
 LPFC_VPORT_ATTR_R(peer_port_login,
   ^~~
line_table: entering: cpp_token* _cpp_lex_direct(cpp_reader*)
line_table:  entering: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table:   to_column: 1
line_table:   returning: 229824
../../src/pr79210-via-attachment.c:18:1: note: 229824
 "other.");
 ^
line_table:  exiting: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table:  entering: source_location
linemap_position_for_column(line_maps*, unsigned int)
line_table:   to_column: 20
line_table:   returning: 230432
../../src/pr79210-via-attachment.c:18:20: note: 230432
 "other.");
^
line_table:  exiting: source_location
linemap_position_for_column(line_maps*, unsigned int)

paste_tokens takes a pair of tokens, combines the text into a temporary buffer,
and calls _cpp_lex_direct on that temporary buffer.

Hence the start and finish locations for the resulting pasted token is insane:
it takes the line information from the last parsed line in the line table, and
uses the buffer length for the column number.

Subsequent temporary tokens (including the stringified name) "inherit" this
bogus location.

[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
The concatenation:

The concatenated string comes from 4 string tokens, with the following
locations, and locs[1] is a bogus value:

../../src/pr79210-via-attachment.c:8:6: note: locs[0]
  "0423 lpfc_"#attr" attribute cannot be set to %d, "\
  ^~~~
../../src/pr79210-via-attachment.c:18:1: note: locs[1]
 "other.");
 ^~~~
../../src/pr79210-via-attachment.c:8:23: note: locs[2]
  "0423 lpfc_"#attr" attribute cannot be set to %d, "\
   ^~~
  "allowed range is [0, 1]\n", val); \

../../src/pr79210-via-attachment.c:9:6: note: locs[3]
  "allowed range is [0, 1]\n", val); \
  ^~~

Note that diagnostic_show_locus doesn't print the full range of garbage value
locs[1] correctly, and needed this patch:

diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index 5c386ae..a41b19a 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -1367,9 +1367,11 @@ layout::get_state_at_point (/* Inputs.  */
  /* Within a multiline range, don't display any underline
 in any leading or trailing whitespace on a line.
 We do display carets, however.  */
+#if 0
  if (!out_state->draw_caret_p)
if (column < first_non_ws || column > last_non_ws)
  return false;
+#endif

  /* We are within a range.  */
  return true;

to avoid just printing:

(gdb) call inform(result->src_loc, "")
../../src/pr79210-via-attachment.c:18:1: note: 
 "other.");
 ^   ~~

[Bug preprocessor/79210] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Root cause is:
(a) a garbage location_t value for one of the string tokens within the
concatenation, but
(b) it's not clear that there *is* a non-garbage value for the string token in
question, as it comes from pasting macro tokens together.

[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-30
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Looks like this was caused by r244833

[Bug c++/79292] New: address of string constant

[nathan at gcc dot gnu.org]

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

Bug ID: 79292
   Summary: address of string constant
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

We warn about address of non-weak decl being non-null ('if () ...'), but we
don't warn about string constants:

  bool x = "baz";

[Bug tree-optimization/79291] New: r244397 introduces alias related performance issues for daxpy on MIPS

[doug.gilmore at imgtec dot com]

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

Bug ID: 79291
   Summary: r244397 introduces alias related performance issues
for daxpy on MIPS
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

It appears that r244397 introduces pealing for DP daxpy, which per
bug 69710, introduces a performance degradation due to alias issues.

After IVOPTS before r244897 (use daxpy example from bug 69710):

  ivtmp.20_36 = ivtmp.20_35 + 1;
  ivtmp.21_24 = ivtmp.21_9 + 16;
  ivtmp.24_3 = ivtmp.24_2 + 16;

After IVOPTS after r244897:  
  ivtmp.23_56 = ivtmp.23_24 + 1;
  ivtmp.24_11 = ivtmp.24_9 + 16;
  ivtmp.27_87 = ivtmp.27_86 + 16;
  ivtmp.29_90 = ivtmp.29_89 + 16;

Thus after r244397 we have a problem in DP daxpy that we were
only seeing for SP daxpy (or saxpy) as shown in bug69710.

BTW: I have been investigating another IVOPTS related regression
on MIPS32R2 that is related to the generation of indexed

memory OPs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176#c12

I'll be updating that report with more information on how to
fix the regression and how it relates to this issue.

Bin:  I suspect this is also now broken on ARM, can
you check?

Thanks,

Doug

[Bug debug/79289] DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
I think the bug is a mismatch in how the code determines the base type to use
for the DIE in this change:

2016-11-03  Jakub Jelinek  
Alexandre Oliva  
Jason Merrill  

PR debug/28767
PR debug/56974
* langhooks.h (struct lang_hooks_for_types): Add type_dwarf_attribute
langhook.
* langhooks.c (lhd_type_dwarf_attribute): New function.
* langhooks-def.h (lhd_type_dwarf_attribute): Declare.
(LANG_HOOKS_TYPE_DWARF_ATTRIBUTE): Define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add
LANG_HOOKS_TYPE_DWARF_ATTRIBUTE.
(check_qualified_type, check_aligned_type): Call it.
* dwarf2out.c (modified_type_die): Don't use type_main_variant
for FUNCTION_TYPE or METHOD_TYPE, instead walk over variants with
check_base_type and check_lang_type.
(gen_ptr_to_mbr_type_die): If lookup_type_die is already non-NULL,
return early.  For pointer-to-data-member add DW_AT_use_location
attribute.
(gen_subroutine_type_die): Add DW_AT_{,rvalue_}reference attribute
if needed.
(gen_type_die_with_usage): Don't use type_main_variant
for FUNCTION_TYPE or METHOD_TYPE, instead walk over variants with
check_base_type and check_lang_type.  Formatting fixes. Call
get_debug_type langhook.

The problem is that the DIE is stored with one type variant in
gen_type_die_with_usage (the last matching variant), but looked up with a
different type variant in modified_type_die (the first matching variant).

This patch seems to fix the problem, but I can't tell whether this is correct
or whether the other obvious change is correct.


Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 244166)
+++ gcc/dwarf2out.c (working copy)
@@ -24395,8 +24395,13 @@ gen_type_die_with_usage (tree type, dw_d
 but try to canonicalize.  */
   tree main = TYPE_MAIN_VARIANT (type);
   for (tree t = main; t; t = TYPE_NEXT_VARIANT (t))
-   if (check_base_type (t, main) && check_lang_type (t, type))
- type = t;
+   {
+ if (check_base_type (t, main) && check_lang_type (t, type))
+   {
+ type = t;
+ break;
+   }
+   }
 }
   else if (TREE_CODE (type) != VECTOR_TYPE
   && TREE_CODE (type) != ARRAY_TYPE)

[Bug c++/79290] New: [7 Regression] forming pointer to member function tries to access "__pfn"

[redi at gcc dot gnu.org]

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

Bug ID: 79290
   Summary: [7 Regression] forming pointer to member function
tries to access "__pfn"
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct Song {
  typedef int (Song::*GetFunction)(unsigned) const;

  virtual int get(unsigned) const = 0;
};

struct SongTag {
  Song::GetFunction function() const { return m_function; }

  Song::GetFunction m_function;
};

template
struct Printer {
  bool operator()(const SongTag st) {
return st.function() == ::get;
  }
};

int main()
{
  Printer p;
  p(SongTag{});
}

[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

[Bug debug/79289] New: DWARF info for typeof of C function with no args and no prototype is empty pointer

[ian at airs dot com]

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

Bug ID: 79289
   Summary: DWARF info for typeof of C function with no args and
no prototype is empty pointer
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

Compile this program with current mainline with -g on GNU/Linux:

static void sub() {}
void f1() { sub(); }
void f2(void) { sub(); }
__typeof__(f1) *v1;
__typeof__(f2) *v2;

Using readelf --debug to examine the debug info I see this for v1:

<1><2d>: Abbrev Number: 2 (DW_TAG_variable)
<2e>   DW_AT_name: v1   
<31>   DW_AT_decl_file   : 1
<32>   DW_AT_decl_line   : 4
<33>   DW_AT_type: <0x41>   
<37>   DW_AT_external: 1
<37>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><41>: Abbrev Number: 3 (DW_TAG_pointer_type)
<42>   DW_AT_byte_size   : 8

Note that the type of v1 is a pointer, but there is no type listed for what it
points to.

By comparison, the debug info for v2 is:

 <1><43>: Abbrev Number: 4 (DW_TAG_subroutine_type)
<44>   DW_AT_prototyped  : 1
 <1><44>: Abbrev Number: 2 (DW_TAG_variable)
<45>   DW_AT_name: v2   
<48>   DW_AT_decl_file   : 1
<49>   DW_AT_decl_line   : 5
<4a>   DW_AT_type: <0x58>   
<4e>   DW_AT_external: 1
<4e>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><58>: Abbrev Number: 5 (DW_TAG_pointer_type)
<59>   DW_AT_byte_size   : 8
<5a>   DW_AT_type: <0x43>   

Here the type of v2 is clearly a pointer to a function, although there is no
real information about the function: just that it is prototyped.


By comparison, with GCC 6, I see this for v1:

 <1><29>: Abbrev Number: 2 (DW_TAG_subroutine_type)
<2a>   DW_AT_sibling : <0x30>   
 <2><2e>: Abbrev Number: 3 (DW_TAG_unspecified_parameters)
 <2><2f>: Abbrev Number: 0
 <1><30>: Abbrev Number: 4 (DW_TAG_variable)
<31>   DW_AT_name: v1   
<34>   DW_AT_decl_file   : 1
<35>   DW_AT_decl_line   : 4
<36>   DW_AT_type: <0x44>   
<3a>   DW_AT_external: 1
<3a>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><44>: Abbrev Number: 5 (DW_TAG_pointer_type)
<45>   DW_AT_byte_size   : 8
<46>   DW_AT_type: <0x29>   

and I see this for v2 (the same as for GCC 7):

 <1><4a>: Abbrev Number: 6 (DW_TAG_subroutine_type)
<4b>   DW_AT_prototyped  : 1
 <1><4b>: Abbrev Number: 4 (DW_TAG_variable)
<4c>   DW_AT_name: v2   
<4f>   DW_AT_decl_file   : 1
<50>   DW_AT_decl_line   : 5
<51>   DW_AT_type: <0x5f>   
<55>   DW_AT_external: 1
<55>   DW_AT_location: 9 byte block: 3 8 0 0 0 0 0 0 0  (DW_OP_addr: 8)
 <1><5f>: Abbrev Number: 5 (DW_TAG_pointer_type)
<60>   DW_AT_byte_size   : 8
<61>   DW_AT_type: <0x4a>   


I'm not entirely sure what is correct here, but a pointer type that doesn't
point to anything must be wrong.  The change from GCC 6 to GCC 7 in the debug
info for v1 is a regression.

[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[tulipawn at gmail dot com]

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

--- Comment #11 from PeteVine  ---
Super cool, thanks! That makes the OP a true prophet before his time ;)

[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

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

[m.ostapenko at samsung dot com]

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

--- Comment #6 from Maxim Ostapenko  ---
(In reply to Maxim Ostapenko from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > Have you raised this with compiler-rt upstream already?
> > 
> > I don't believe that upstream supports the sanitisers for Darwin < 11.
> > 
> > However, as seen, they are quite capable of function with a little TLC.  I
> > don't have a chance to progress this until at least mid-Feb, if it's more
> > urgent, then (a) please adopt some version of the patch locally, or (b)
> > disable for Darwin < 11.
> 
> They don't, but they can actually accept the patch for Darwin 10 (I used to
> commit such patches after previous merge).
> I can post attached fix upstream, but than I'll ask you (or Dominique) for
> help in testing if they won't accept the patch as it is (most likely they
> won't).

I've initiated discussion upstream: https://reviews.llvm.org/D29287

[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The definition of the static data member could be of course in some shared
library the binary is linked against.  As I've caused this, I'll debug this
tomorrow.

[Bug c++/79288] New: [7 Regression] TLS model wrong for static data members since r241137

[jakub at gcc dot gnu.org]

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

Bug ID: 79288
   Summary: [7 Regression] TLS model wrong for static data members
since r241137
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r241137

struct S
{
  static __thread int *p;
};

int *
foo ()
{
  return S::p;
}

emits for non-pic code TLS local exec model relocations instead of initial
exec.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to James Clarke from comment #4)
> Ah, sorry, there's a separate C implementation of all this. I imagine it's
> the bools in "struct M" in runtime.h messing it up, so "struct Note" and
> "struct Lock" need __attribute__((aligned(4))) on their key fields.

I just did that on gcc-6.

The result is:

(sid-m68k-sbuild)root@ikarus:/# ./routines 
Alice
Bob
Hello
World
Alice
Bob
Hello
World
Alice
Bob
Hello
World
Alice
Bob
Hello
World
Alice
Bob
Hello
(sid-m68k-sbuild)root@ikarus:/#

:D

I haven't tested gcc-7 yet, but at least this fix for gcc-6 can be added.

[Bug fortran/79287] New: include files not searched for relative to the file containing the fortran include statement

[okiddle at yahoo dot co.uk]

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

Bug ID: 79287
   Summary: include files not searched for relative to the file
containing the fortran include statement
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okiddle at yahoo dot co.uk
  Target Milestone: ---

I have some Fortran code that makes use of the Fortran INCLUDE statement (as
opposed to the preprocessor). A source file includes an include file which in
turn includes another source file. Specifying no search path with -I it is able
to find the first include file, looking relative to the original source file
but when looking for the second include file it is not looking relative to the
first include file (the file containing the INCLUDE statement). The same code
compiles with the Intel or Solaris compilers.

As a basic test:
  hello.f90 contains INCLUDE 'include/first.inc'
  include/first.inc contains INCLUDE 'second.inc'
  include/second.inc contains whatever

In order to find second.inc, it should look relative to the directory
containing first.inc.

[Bug middle-end/79285] [7 Regression] new valgrind error in build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||GC, ice-on-valid-code
  Component|c   |middle-end
   Target Milestone|--- |7.0
Summary|new valgrind error in build |[7 Regression] new valgrind
   ||error in build

[Bug c++/79264] [7 Regression] ICE verify_type failed

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 40625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40625=edit
Reduced testcase

./obj/x86_64/gcc/cc1plus -fconcepts -std=c++1z -g3 79264-dbg.ii 

It's very easy to turn this into a different seg fault somewhere in the
gimplifier.  Sadly my 67273 patch doesn't fix this one.

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

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

--- Comment #14 from Franz Sirl  ---
I just finished testing with r245021 and now the warnings are as expected. All
warnings are there with -Wformat-truncation=2 and also -Wformat-truncation=1
behaves according to the documentation (BTW, there's a typo in invoke.texi,
"truncatation" instead of "truncation").
You can close the bug.

[Bug target/79240] [7 Regression] ICE in s390_extzv_shift_ok, at config/s390/s390.c:2475

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79286] New: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 79286
   Summary: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
(but not in 64-bit mode)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170130 (experimental) [trunk revision 245020] (GCC)
$
$ gcc-trunk -m32 -O2 small.c; ./a.out
$ gcc-trunk -m64 -O3 small.c; ./a.out
$
$ gcc-trunk -m32 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$


-


int printf (const char *, ...);

int a[6], b, c, d, e, f, g, h;
static int i[][8] = { { 0 } };

void fn1 (int l)
{ 
  c = (c & 5) ^ a[(c ^ l) & 5];
}

void fn2 ()
{ 
  fn1 (e >> 5);
  fn1 (e >> 6 & 5);
  c = (c & 5) ^ a[(c ^ 5) & 5];
  fn1 (e >> 2 & 5);
  fn1 (e & 5);
  fn1 (e >> 28 & 5);
}

void fn3 ()
{ 
  int k;
  for (; g < 4; g++)
{ 
  while (d)
{ 
  fn2 ();
  if (k)
printf ("%d\n", k);
}
  while (f)
while (h++)
  k = i[30][0];
  while (b)
while (1)
  d++;
}
}

int main ()
{ 
  fn3 ();
  return 0;
}

[Bug c/79285] New: new valgrind error in build

[dcb314 at hotmail dot com]

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

Bug ID: 79285
   Summary: new valgrind error in build
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried a gcc trunk build, under valgrind, and got this:

==19121== Invalid read of size 4
==19121==at 0x9C9E3D: slide (hash-table.h:999)
==19121==by 0x9C9E3D: begin (hash-table.h:476)
==19121==by 0x9C9E3D: begin (hash-map.h:233)
==19121==by 0x9C9E3D: release (symbol-summary.h:78)
==19121==by 0x9C9E3D:
function_summary::~function_summary() (symbol-summary.h:57)
==19121==by 0x7D2BA4: call (ggc-page.c:339)

Configure line was

../trunk/configure --prefix=/home/dcb/gcc/results.245021 \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=valgrind \
--enable-languages=c,c++,fortran

The last time I did this, on 20170120, there was no such valgrind error.

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #13 from Martin Sebor  ---
Franz, when you have a chance now that the full patch set for bug 78703 has
been committed, can you please give it try and let me know if it resolves the
issues you reported here?  If so I'd like to resolve this bug as fixed.  If
there are other issues unrelated to these please open a new bug.  (FYI: I'm
working on another patch for bug 79275 that should further reduce the false
positive rate in this area.)

[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #9 from Rainer Orth  ---
Fixed for gcc 6.4.0, 5.5.0.

[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Author: ro
Date: Mon Jan 30 16:08:42 2017
New Revision: 245034

URL: https://gcc.gnu.org/viewcvs?rev=245034=gcc=rev
Log:
Only declare gets for C++ < 2014 on Solaris (PR libstdc++/78979)

Backport from mainline
2017-01-13  Rainer Orth  

PR libstdc++/78979
* inclhack.def (solaris_gets_c11, solaris_gets_cxx14)
(solaris_std_gets_cxx14, solaris_stdlib_noreturn): New fixes.
* fixincl.x: Regenerate.
* tests/base/iso/stdio_iso.h [SOLARIS_GETS_C11_CHECK,
SOLARIS_GETS_CXX14_CHECK, SOLARIS_STD_GETS_CXX14_CHECK,
SOLARIS_STDLIB_NORETURN_CHECK]: New tests.

Added:
branches/gcc-5-branch/fixincludes/tests/base/iso/stdlib_c99.h
Modified:
branches/gcc-5-branch/fixincludes/ChangeLog
branches/gcc-5-branch/fixincludes/fixincl.x
branches/gcc-5-branch/fixincludes/inclhack.def
branches/gcc-5-branch/fixincludes/tests/base/iso/stdio_iso.h
branches/gcc-5-branch/fixincludes/tests/base/stdio.h

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[chefmax at gcc dot gnu.org]

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

--- Comment #30 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Mon Jan 30 16:06:15 2017
New Revision: 245033

URL: https://gcc.gnu.org/viewcvs?rev=245033=gcc=rev
Log:
PR lto/79061
* asan.c (get_translation_unit_decl): Remove function.
(asan_add_global): Force has_dynamic_init to zero in LTO mode.

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

[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(gdb) p debug_gimple_stmt(stmt)
mask__5.10_9 = mask__3.9_16 ^ vect_cst__10;
$1 = void


(gdb) p debug_gimple_stmt(rhs1))
Junk after end of expression.
(gdb) p debug_tree(rhs1_type)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x769a5f18 precision
32 min  max >
V4SI
size  constant 128>
unit size  constant 16>
align 128 symtab 0 alias set -1 canonical type 0x769a5d20 nunits 4>
$2 = void
(gdb) p debug_tree(rhs2_type)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x769a5738 precision 8
min  max >
unsigned V16QI
size  constant 128>
unit size  constant 16>
align 128 symtab 0 alias set -1 canonical type 0x769e1150 nunits 16>
$3 = void


(gdb) p debug_gimple_stmt(stmt)
mask__5.10_9 = mask__3.9_16 ^ vect_cst__10;
$4 = void
(gdb) p debug_tree(rhs1_type)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x769a5f18 precision
32 min  max >
V4SI
size  constant 128>
unit size  constant 16>
align 128 symtab 0 alias set -1 canonical type 0x769a5d20 nunits 4>
$5 = void
(gdb) p debug_tree(rhs2_type)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x769a5738 precision 8
min  max >
unsigned V16QI
size  constant 128>
unit size  constant 16>
align 128 symtab 0 alias set -1 canonical type 0x769e1150 nunits 16>
$6 = void

[Bug libstdc++/78979] 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  ---
Author: ro
Date: Mon Jan 30 16:01:11 2017
New Revision: 245032

URL: https://gcc.gnu.org/viewcvs?rev=245032=gcc=rev
Log:
Only declare gets for C++ < 2014 on Solaris (PR libstdc++/78979)

Backport from mainline
2017-01-13  Rainer Orth  

PR libstdc++/78979
* inclhack.def (solaris_gets_c11, solaris_gets_cxx14)
(solaris_std_gets_cxx14, solaris_stdlib_noreturn): New fixes.
* fixincl.x: Regenerate.
* tests/base/iso/stdio_iso.h [SOLARIS_GETS_C11_CHECK,
SOLARIS_GETS_CXX14_CHECK, SOLARIS_STD_GETS_CXX14_CHECK,
SOLARIS_STDLIB_NORETURN_CHECK]: New tests.

Added:
branches/gcc-6-branch/fixincludes/tests/base/iso/stdlib_c99.h
Modified:
branches/gcc-6-branch/fixincludes/ChangeLog
branches/gcc-6-branch/fixincludes/fixincl.x
branches/gcc-6-branch/fixincludes/inclhack.def
branches/gcc-6-branch/fixincludes/tests/base/iso/stdio_iso.h
branches/gcc-6-branch/fixincludes/tests/base/stdio.h

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
(In reply to Sylvestre Ledru from comment #11)
> Other testcase:
> ---
> #include 
> #include 
> int main() {
> char* buf = new char[10];
> uint8_t data = 255;
> printf("%.2x\n", data);// just print data
> snprintf([0], 2, "%.2x", data);
> return 0;
> }
> ---
> 
> foo.c:7:13: note: format output 3 bytes into a destination of size 2
>  snprintf([0], 2, "%.2x", data);
>  ^~

This is warning is valid.  The function is called with a buffer size of 2 bytes
but the total output for 255 in hex ("ff") and the terminating nul would be 3
bytes.  The output is truncated after the first 'f' which is usually a bug.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[jrtc27 at jrtc27 dot com]

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

--- Comment #4 from James Clarke  ---
Ah, sorry, there's a separate C implementation of all this. I imagine it's the
bools in "struct M" in runtime.h messing it up, so "struct Note" and "struct
Lock" need __attribute__((aligned(4))) on their key fields.

[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-30
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid code at -O3 on |[7 Regression] ICE on valid
   |x86_64-linux-gnu:   |code at -O3 on
   |verify_gimple failed|x86_64-linux-gnu:
   ||verify_gimple failed
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r237064.

[Bug tree-optimization/79284] New: ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 79284
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
verify_gimple failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170130 (experimental) [trunk revision 245020] (GCC)
$
$ gcc-trunk -O2 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:8:6: error: type mismatch in binary expression
 void fn1 (int p)
  ^~~
vector(4) 

vector(4) 

vector(16) unsigned char

mask__5.10_9 = mask__3.9_16 ^ vect_cst__10;
small.c:8:6: internal compiler error: verify_gimple failed
0xc6143f verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5266
0xb35752 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1966
0xb36109 execute_todo
../../gcc-source-trunk/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


-


struct
{ 
  unsigned a:1;
} b;

int c[5];

void fn1 (int p)
{ 
  char e = 4, f;
  for (; e; e--)
f = (c[e] && ~0) != b.a;
  while (1)
fn1 (f);
}

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[jrtc27 at jrtc27 dot com]

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

--- Comment #3 from James Clarke  ---
I believe the problem is in the "m" type in runtime2.go. There are 4 bools in a
row, which is fine, as they will take up 4 bytes, but then "printlock" is an
int8, which means "fastrand" will only be 2-byte aligned. This continues with
"ncgocall" and "ncgo" being 2-byte aligned, and then the "park" field will also
be 2-byte aligned only. Is there a way to tell gcngo that the "note" struct
(and in theory the "mutex" struct too, since that will be a futex, and I don't
know if anything embeds it incorrectly-aligned) should be 4-byte aligned, i.e.
an equivalent of __attribute__((aligned(4)))?

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
Perhaps this would be fixed by adding __attribute__((aligned(4))) to some field
of struct Sched in proc.c.

This code is all different on trunk/GCC7.  I don't know whether it still has
the same problem or not.  Probably it does but the fix would have to be
different.

[Bug gcov-profile/79259] [7 Regression] Corrupted profile when one uses -O1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/79259] [7 Regression] Corrupted profile when one uses -O1

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Mon Jan 30 15:35:57 2017
New Revision: 245031

URL: https://gcc.gnu.org/viewcvs?rev=245031=gcc=rev
Log:
Fix profile corruption with -O1 (PR gcov-profile/79259)

2017-01-30  Martin Liska  

PR gcov-profile/79259
* opts.c (common_handle_option): Enable flag_ipa_bit_cp w/
-fprofile-generate.
2017-01-30  Martin Liska  

PR gcov-profile/79259
* g++.dg/tree-prof/pr79259.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-prof/pr79259.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Bill Schmidt from comment #4)
> > Created attachment 40568 [details]
> > Proposed patch
> > 
> > Attaching proposed patch.  Iain, would you be able to test this on Darwin
> > 32- and 64-bit and see whether it makes sense?
> 
> On darwin (powerpc-darwin9, trunk 244915) the patch flips the fail from m32
> -> m64.  I.E. without the patch m64 passes and m32 fails; with the patch,
> the inverse.
> 
> I haven't built powerpc64-darwin9 in quite a while, so no comment there.
> 
> Apologies, but will have defer analysis for a while.

Hi Iain,

If you get a chance to just send me the vectorization dump file from each of
-m32 and -m64, I can figure out why the tests fail for powerpc-darwin9 -m64. 
My guess from what I'm seeing is that powerpc64-darwin9 will have the same
characteristics as powerpc-darwin9 -m64.

Thanks,
Bill

[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Mon Jan 30 15:16:33 2017
New Revision: 245030

URL: https://gcc.gnu.org/viewcvs?rev=245030=gcc=rev
Log:
Fix aarch64 PGO bootstrap (bootstrap/78985)

2017-01-30  Martin Liska  

PR bootstrap/78985
* config/aarch64/cortex-a57-fma-steering.c
(func_fma_steering::analyze):
Initialize variables with NULL value.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/cortex-a57-fma-steering.c

[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I think this is a problem with the di3_neon pattern in neon.md and in
particular the neon_for_64bits/avoid_neon_for_64bits stuff in the arch
attribute.

I think the last two alternatives that generate the NEON version should have
avoid_neon_for_64bits in their arch attribute rather than neon_for_64bits

[Bug c++/79232] [7 Regression] error: invalid rhs for gimple memory store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #40607|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

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

Fixed up patch with testcases.

[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[marxin at gcc dot gnu.org]

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

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

The patch fixes issue, however I believe that PHI handling is in general broken
in graphite since r236440. This PR is very similar to PR71351. Both are
confused by PHI nodes created by LIM.

[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Martin Liška from comment #8)
> Started with r236440.

Sorry, belongs to a different bug.

[Bug target/79260] [7 Regression] missing header files for plugins: arm-isa.h, arm-flags.h

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
Fixed.

[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Started with r236440.

[Bug target/79260] [7 Regression] missing header files for plugins: arm-isa.h, arm-flags.h

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Mon Jan 30 14:39:50 2017
New Revision: 245029

URL: https://gcc.gnu.org/viewcvs?rev=245029=gcc=rev
Log:
PR target/79260
* config.gcc (arm*-*-*): Add arm/arm-flags.h and arm/arm-isa.h to
tm_p_file.
* arm/arm-protos.h: Don't directly include arm-flags.h and arm-isa.h.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/arm/arm-protos.h

[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #8 from Martin Liška  ---
Started with r236440.

[Bug target/79260] [7 Regression] missing header files for plugins: arm-isa.h, arm-flags.h

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-30
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
Build an arm cross-compiler with --enable-plugin
configure the kernel with
make ARCH=arm defconfig
then manually edit the .config to set
CONFIG_GCC_PLUGINS=y

then build
make ARCH=arm -j all

and it will soon fail.

[Bug tree-optimization/79276] [7 Regression] ICE: Segmentation fault in VRP pass

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
(In reply to Christophe Leroy from comment #0)

> The following section is just useless: (shift left 4 bits, remove 16, shift
> right 4 bits, add 1)
> c000d984:   55 24 20 36 rlwinm  r4,r9,4,0,27
> c000d988:   39 24 ff f0 addir9,r4,-16
> c000d98c:   55 29 e1 3e rlwinm  r9,r9,28,4,31
> c000d990:   39 29 00 01 addir9,r9,1

Are you suggesting just removing these? That would not produce the same value
in all cases - consider zero as an input:

((0 << 4) - 16) >> 4 = 0xfff, add one and you get 0x1000.

[Bug tree-optimization/79276] [7 Regression] ICE: Segmentation fault in VRP pass

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 30 14:24:37 2017
New Revision: 245026

URL: https://gcc.gnu.org/viewcvs?rev=245026=gcc=rev
Log:
2017-01-30  Richard Biener  

PR tree-optimization/79276
* tree-vrp.c (process_assert_insertions): Properly adjust common
when removing a duplicate.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79276.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  ---
> > Finally rt_error --check radiation_generator failed with
> > 
> > Running test: radiation_generator_1
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
>
> This, however, seems to be a problem. That segmentation fault seems
> to be another problem not yet covered by the fix.

The change occurred between revisions r242872 (2016-11-25) and r242901
(2016-11-27, SIGSEGV), r242875 (pr78293)?. I let you reduce the problem and
file a new PR.

[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
Started with r232656.