[Bug c/84853] [7/8 Regression] ICE: verify_gimple failed (expand_shift_1)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 15 07:37:53 2018
New Revision: 258550

URL: https://gcc.gnu.org/viewcvs?rev=258550&root=gcc&view=rev
Log:
PR c/84853
* c-typeck.c (build_binary_op) :
If code1 is INTEGER_TYPE, only allow code0 VECTOR_TYPE if it has
INTEGER_TYPE element type.

* gcc.dg/pr84853.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84853.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/84853] [7 Regression] ICE: verify_gimple failed (expand_shift_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE:   |[7 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(expand_shift_1)|(expand_shift_1)

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

[Bug target/84860] ICE in emit_move_insn, at expr.c:3717

[jakub at gcc dot gnu.org]

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

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

[Bug target/84860] ICE in emit_move_insn, at expr.c:3717

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 15 08:35:28 2018
New Revision: 258552

URL: https://gcc.gnu.org/viewcvs?rev=258552&root=gcc&view=rev
Log:
PR target/84860
* optabs.c (emit_conditional_move): Pass address of cmode's copy
rather than address of cmode as last argument to prepare_cmp_insn.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr84860.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 15 08:55:04 2018
New Revision: 258553

URL: https://gcc.gnu.org/viewcvs?rev=258553&root=gcc&view=rev
Log:
2018-03-15  Vladimir Mezentsev  

PR target/68256
* varasm.c (hash_section): Return an unchangeble hash value
* config/aarch64/aarch64.c (aarch64_use_blocks_for_constant_p):
Return !aarch64_can_use_per_function_literal_pools_p ().

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/varasm.c

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Zhendong Su from comment #6)
> (In reply to Martin Liška from comment #5)
> > > gcc version 8.0.1 20180310 (experimental) [trunk revision 258413] (GCC)
> > 
> > Just a nit, this revision mentioned above is actually from GCC 7 branch.
> > Isn't that the issue?
> 
> Martin, it was checked out from the main trunk @
> svn://gcc.gnu.org/svn/gcc/trunk. 
> 
> I still see the ICE with rev. 258535: 
> 
> $ gcctk -v
> Using built-in specs.
> COLLECT_GCC=gcctk
> COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-
> pc-linux-gnu/8.0.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
> --prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
> Thread model: posix
> gcc version 8.0.1 20180314 (experimental) [trunk revision 258535] (GCC) 
> $ 
> $ gcctk -O3 -c small.c  
> during RTL pass: dse1
> small.c: In function ‘fn1’:
> small.c:12:1: internal compiler error: in smallest_mode_for_size, at
> stor-layout.c:355
>  }
>  ^
> 0xc8ff8b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
>   ../../gcc-source-trunk/gcc/stor-layout.c:355
> 0x1437abc smallest_int_mode_for_size(poly_int<1u, unsigned long>)
>   ../../gcc-source-trunk/gcc/machmode.h:842
> 0x1437abc find_shift_sequence
>   ../../gcc-source-trunk/gcc/dse.c:1701
> 0x1437abc get_stored_val
>   ../../gcc-source-trunk/gcc/dse.c:1847
> 0x143a41c record_store
>   ../../gcc-source-trunk/gcc/dse.c:1557
> 0x143b2c2 scan_insn
>   ../../gcc-source-trunk/gcc/dse.c:2545
> 0x143c4b2 dse_step1
>   ../../gcc-source-trunk/gcc/dse.c:2657
> 0x143c4b2 rest_of_handle_dse
>   ../../gcc-source-trunk/gcc/dse.c:3574
> 0x143c4b2 execute
>   ../../gcc-source-trunk/gcc/dse.c:3672
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> $

Can you please attach content of --save-temps?

[Bug tree-optimization/84873] [8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
This goes wrong during gimplification:

i1 (int w3, int n9)
{
  int D.1962;
  unsigned int iftmp.0;

  if (n9 == 0) goto ; else goto ;
  :
  _1 = 1.0e+0 + 1.55511151231257827021181583404541015625e-1;
  _2 = (long int) _1;
  _3 = (unsigned int) _2;
  iftmp.0 = _3 + 4294967295;
  goto ;
  :
  iftmp.0 = (unsigned int) _2;
  :
  D.1962 = w3 >> iftmp.0;
  return D.1962;

there's an odd jump-around here.  GENERIC arrives here with

  return w3 >> (long int) -(n9 == 0) + (long int) (1.0e+0 +
1.55511151231257827021181583404541015625e-1);

so it's probably some folding during gimplification that triggers this.

[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-15
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I suppose a RTL or (late) GIMPLE testcase would be nice to have
here,
the issue is likely latent.

[Bug tree-optimization/84824] DCE fails to remove dead code of std::function constructor

[manjian2006 at gmail dot com]

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

--- Comment #7 from linzj  ---
The core of this problem is escaped result is function wise, not block wise, or
instruction wise. Any place in the function the local variable escapes, will
count that variable as escaped.

Actually the printf does not make the artifact local variable escapes. The
later call to destructor of function
 ~_Function_base()
{
...
_M_manager(_M_functor, _M_functor, __destroy_functor);
...

make that variable escape.

If we patch the destructor like the following:
diff --git a/libstdc++-v3/include/bits/std_function.h
b/libstdc++-v3/include/bits/std_function.h
index 657b1c02d2e..28ee02e6d48 100644
--- a/libstdc++-v3/include/bits/std_function.h
+++ b/libstdc++-v3/include/bits/std_function.h
@@ -272,8 +272,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

 ~_Function_base()
 {
+  std::_Any_data d = _M_functor;
   if (_M_manager)
-   _M_manager(_M_functor, _M_functor, __destroy_functor);
+   _M_manager(d, d, __destroy_functor);
 }

will ease the problem, which generate the code:
main:
.LFB1365:
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDA1365
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$3, %esi
movl$.LC0, %edi
xorl%eax, %eax
.LEHB0:
callprintf
.LEHE0:
movq%rsp, %rsi
movq%rsp, %rdi
movl$3, %edx
movl$1, (%rsp)
call   
_ZNSt14_Function_base13_Base_managerIZL7getFunciEUliiE_E10_M_managerERSt9_Any_dataRKS3_St18_Manager_operation
xorl%eax, %eax
addq$24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret

The last call cannot get inlined simply because it has passed the inline phase,
so it's not related to the problem.

So what is needed to fix this problem, is a better grained esacped result.

[Bug c++/84874] New: internal compiler error: in reshape_init_class, at cp/decl.c:5800

[dhowells at redhat dot com]

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

Bug ID: 84874
   Summary: internal compiler error: in reshape_init_class, at
cp/decl.c:5800
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 43663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43663&action=edit
Test case

I'm seeing the following ICE:

g++ -Wall ice.cpp
ice.cpp: In function ‘void sema_init(semaphore*)’:
ice.cpp:30:2: internal compiler error: in reshape_init_class, at cp/decl.c:5800
  };
  ^

I've attached the preprocessed dump.

I think the code should produce an error (as it does if compiled for C).

The compiler is the Fedora 27 compiler, gcc-7.3.1-5.fc27.x86_64.

[Bug debug/84875] New: ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[marxin at gcc dot gnu.org]

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

Bug ID: 84875
   Summary: ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
on s390x
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: s390x-unknown-linux-gnu

Seen on current trunk with:

$ cat gba2.i
static long *a[];
static int b[];
void *c;
int d;
void e();
void f() {
  long *g = c;
  g--;
  d = *g;
  if (d)
if (b[d] < 8) {
  *(void **)g = a[d];
  a[d] = g;
  b[d]++;
  return;
}
  e(g);
}

$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B
/home/marxin/Programming/gcc2/objdir/gcc -Os -g -c -fPIE -march=z196
-o/dev/null gba2.i
during RTL pass: dwarf2
gba2.i: In function ‘f’:
gba2.i:18:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2348
 }
 ^
0xa45e6b maybe_record_trace_start
../../gcc/dwarf2cfi.c:2348
0xa465c1 scan_trace
../../gcc/dwarf2cfi.c:2541
0xa46b82 create_cfi_notes
../../gcc/dwarf2cfi.c:2694
0xa47724 execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3057
0xa48434 execute
../../gcc/dwarf2cfi.c:3545

The back-trace looks similar to PR83986, but I guess it's a different issue.

[Bug tree-optimization/84873] [7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|8.0 |7.4
Summary|[8 Regression] ICE: |[7/8 Regression] ICE:
   |verify_ssa failed (error:   |verify_ssa failed (error:
   |definition in block 3 does  |definition in block 3 does
   |not dominate use in block   |not dominate use in block
   |4)  |4)

--- Comment #2 from Jakub Jelinek  ---
Started with r235817.

[Bug debug/84875] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-15
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug c++/84874] internal compiler error: in reshape_init_class, at cp/decl.c:5800

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-15
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/84873] [7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Or rather it looks like a tree sharing issue.  The COND_EXPR is created via
fold_binary_op_with_conditional_arg when folding

(unsigned int) (long int) (1.0e+0 +
1.55511151231257827021181583404541015625e-1) - (unsigned int)
(n9 == 0)

which is created via

 /* Contract negates.  */
 /* A + (-B) -> A - B */
 (simplify
  (plus:c @0 (convert? (negate @1)))
  /* Apply STRIP_NOPS on the negate.  */
  (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
   && !TYPE_OVERFLOW_SANITIZED (type))
   (with
{
 tree t1 = type;
 if (INTEGRAL_TYPE_P (type)
 && TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
   t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
}
(convert (minus (convert:t1 @0) (convert:t1 @1))

which in the end is reached via the gimplify_expr langhook doing

243 if (!VECTOR_TYPE_P (TREE_TYPE (*op1_p))
244 && !types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE
(*op1_p)),
245 unsigned_type_node)
246 && !types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE
(*op1_p)),
247 integer_type_node))
248   *op1_p = convert (unsigned_type_node, *op1_p);

and

#9  0x00a40070 in convert_to_integer_1 (
type=, 
expr=, dofold=true)
at /space/rguenther/src/svn/early-lto-debug/gcc/convert.c:889
889 expr, inprec, outprec, dofold);
(gdb) l
884   || targetm.truly_noop_truncation (outprec, inprec)
885   || inprec > TYPE_PRECISION (TREE_TYPE (arg0))
886   || inprec > TYPE_PRECISION (TREE_TYPE (arg1)))
887 {
888   tree tem = do_narrow (loc, ex_form, type, arg0, arg1,
889 expr, inprec, outprec, dofold);

and this folding ends up creating tree sharing of

(unsigned int) (long int) (1.0e+0 +
1.55511151231257827021181583404541015625e-1)

which is TREE_CONSTANT:

  /* This transformation is only worthwhile if we don't have to wrap ARG
 in a SAVE_EXPR and the operation can be simplified without recursing
 on at least one of the branches once its pushed inside the COND_EXPR.  */
  if (!TREE_CONSTANT (arg)
  && (TREE_SIDE_EFFECTS (arg)
  || TREE_CODE (arg) == COND_EXPR || TREE_CODE (arg) == VEC_COND_EXPR
  || TREE_CONSTANT (true_value) || TREE_CONSTANT (false_value)))
return NULL_TREE;
...

  /* Check that we have simplified at least one of the branches.  */
  if (!TREE_CONSTANT (arg) && !TREE_CONSTANT (lhs) && !TREE_CONSTANT (rhs))
return NULL_TREE;

but of course saying this is TREE_CONSTANT is somewhat of a lie because
with -frounding-math it depends on the rounding mode!

Which also means in this case the folding isn't quite worthwhile.

I'm somewhat hesitant to do sth like

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 258552)
+++ gcc/tree.c  (working copy)
@@ -4682,8 +4682,9 @@ build2 (enum tree_code code, tree tt, tr

   /* Expressions without side effects may be constant if their
  arguments are as well.  */
-  constant = (TREE_CODE_CLASS (code) == tcc_comparison
- || TREE_CODE_CLASS (code) == tcc_binary);
+  constant = ((TREE_CODE_CLASS (code) == tcc_comparison
+  || TREE_CODE_CLASS (code) == tcc_binary)
+ && (!FLOAT_TYPE_P (TREE_TYPE (arg1)) || !flag_rounding_math));
   read_only = 1;
   side_effects = TREE_SIDE_EFFECTS (t);

at this point though.  A better localized fix would be

Index: gcc/c-family/c-gimplify.c
===
--- gcc/c-family/c-gimplify.c   (revision 258552)
+++ gcc/c-family/c-gimplify.c   (working copy)
@@ -245,7 +245,15 @@ c_gimplify_expr (tree *expr_p, gimple_se
unsigned_type_node)
&& !types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE (*op1_p)),
integer_type_node))
- *op1_p = convert (unsigned_type_node, *op1_p);
+ {
+   /* ???  Do not use convert () here or fold arbitrary trees
+  since folding can introduce tree sharing which is not
+  allowed during gimplification.  */
+   if (TREE_CODE (*op1_p) == INTEGER_CST)
+ *op1_p = fold_convert (unsigned_type_node, *op1_p);
+   else
+ *op1_p = build1 (NOP_EXPR, unsigned_type_node, *op1_p);
+ }
break;
   }

[Bug target/84876] New: [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[marxin at gcc dot gnu.org]

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

Bug ID: 84876
   Summary: [8 Regression] ICE on invalid code in lra_assign at
gcc/lra-assigns.c:1601 since r258504
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from the mentioned revision we ICE on:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80833-3.c
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80833-3.c: In
function ‘test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr80833-3.c:11:1:
internal compiler error: Segmentation fault
 }
 ^
0xc46c4f crash_signal
../../gcc/toplev.c:325
0x76a2fba7 __GI___libc_malloc
malloc.c:2943
0x16c9627 xmalloc
../../libiberty/xmalloc.c:147
0xaa011a lra_assign(bool&)
../../gcc/lra-assigns.c:1601
0xa9b034 lra(_IO_FILE*)
../../gcc/lra.c:2482
0xa4c421 do_reload
../../gcc/ira.c:5465
0xa4c421 execute
../../gcc/ira.c:5649

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-3-15
 CC||vmakarov at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug c++/84874] internal compiler error: in reshape_init_class, at cp/decl.c:5800

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
ICEs likely since r185587, before it has been rejected:
pr84874.C: In function ‘void sema_init(semaphore*)’:
pr84874.C:30:2: error: no match for ‘operator=’ in ‘* sem = 0}},
{"(*sem).lock"}}}’
pr84874.C:30:2: note: candidates are:
pr84874.C:19:8: note: semaphore& semaphore::operator=(const semaphore&)
pr84874.C:19:8: note:   no known conversion for argument 1 from
‘’ to ‘const semaphore&’
pr84874.C:19:8: note: semaphore& semaphore::operator=(semaphore&&)
pr84874.C:19:8: note:   no known conversion for argument 1 from
‘’ to ‘semaphore&&’

ICEs even with -std=c++2a, where this is valid code (previously it has been
just GNU C++ extension), so with -std=c++17 and earlier -pedantic-errors
rejects it (and ICEs during error-recovery).
With added .key = 0, before .name = it works.

[Bug c/84873] [7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-code
  Component|tree-optimization   |c

--- Comment #4 from Richard Biener  ---
Note GCC 6 generated wrong code instead:

i1 (int w3, int n9)
{
  int D.1760;
  unsigned int iftmp.0;
  double D.1764;
  long int D.1765;
  unsigned int D.1766;

  if (n9 == 0) goto ; else goto ;
  :
  D.1764 = 1.0e+0 +
1.55511151231257827021181583404541015625e-1;
  D.1765 = (long int) D.1764;
  D.1766 = (unsigned int) D.1765;
  iftmp.0 = D.1766 + 4294967295;
  goto ;
  :
  iftmp.0 = (unsigned int) D.1765;
  :
  D.1760 = w3 >> iftmp.0;
  return D.1760;
}

note how D.1765 is used uninitialized.

[Bug c/84873] [6/7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[7/8 Regression] ICE:   |[6/7/8 Regression] ICE:
   |verify_ssa failed (error:   |verify_ssa failed (error:
   |definition in block 3 does  |definition in block 3 does
   |not dominate use in block   |not dominate use in block
   |4)  |4)

[Bug c++/84874] [6/7/8 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:5800

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|internal compiler error: in |[6/7/8 Regression] internal
   |reshape_init_class, at  |compiler error: in
   |cp/decl.c:5800  |reshape_init_class, at
   ||cp/decl.c:5800

[Bug c/84873] [6/7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Known to work||4.8.5
   Target Milestone|7.4 |6.5
  Known to fail||5.5.0, 6.4.0

--- Comment #5 from Richard Biener  ---
So the real bad commit was r218142.

[Bug c/84873] [6/7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Why the
+   if (TREE_CODE (*op1_p) == INTEGER_CST)
+ *op1_p = fold_convert (unsigned_type_node, *op1_p);
+   else
+ *op1_p = build1 (NOP_EXPR, unsigned_type_node, *op1_p);
?  Just change the convert to fold_convert...  I hope the FE ensures that the
shift count has a sane type (some integral one).

[Bug c/84873] [6/7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 15 Mar 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84873
> 
> --- Comment #6 from Jakub Jelinek  ---
> Why the
> +   if (TREE_CODE (*op1_p) == INTEGER_CST)
> + *op1_p = fold_convert (unsigned_type_node, *op1_p);
> +   else
> + *op1_p = build1 (NOP_EXPR, unsigned_type_node, *op1_p);
> ?  Just change the convert to fold_convert...  I hope the FE ensures that the
> shift count has a sane type (some integral one).

Because it's fold_binary_op_with_conditional_arg which introduces
the tree sharing.  So if, say, *op1_p was (long)  (x == 0) + (long) y
then fold_convert will fold away the conversion and re-fold the
PLUS which then may reach fold_binary_op_with_conditional_arg again.

I might have used

  tree tem = fold_unary_to_constant (...);
  if (!tem)
tem = build1 (...);
  *op1_p = tem;

but fold_unary_to_constant uses TREE_CONSTANT as well ...
(but it looks like COND_EXPR will never be TREE_CONSTANT at least).

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
Version|unknown |8.0.1

[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.4 |8.0

--- Comment #10 from Ramana Radhakrishnan  ---
Fixed for gcc-8

[Bug middle-end/84877] New: Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[renlin at gcc dot gnu.org]

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

Bug ID: 84877
   Summary: Local stack copy of BLKmode parameter on the stack is
not aligned when the requested alignment exceeds
MAX_SUPPORTED_STACK_ALIGNMENT
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: renlin at gcc dot gnu.org
  Target Milestone: ---

For a test case like this,

#include 
struct U {
uint32_t M0;
uint32_t M1;
} __attribute((aligned(16)));

void tmp (struct U *);
void foo(struct U P0)
{
  struct U P1 = P0;
  tmp (&P1);
}

void bar(struct U P0)
{
  tmp (&P0);
}

The required alignment of a BLKmode parameter is truncated to
MAX_SUPPORTED_STACK_ALIGNMENT when it exceeds.
On the other hand, the compiler will try to dynamically align
the stack slot for local variable.

For example, on arm-gcc toolchain,
The function foo () will return a 16-byte aligned address.
However, P0 is temporarily stored on stack in an unaligned address.
Function bar () will return an unaligned address which is the address
of local stack copy of P0.

a warning could be emitted when the alignment could not be fulfilled or
dynamically align it thought it will waste stack space.

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[7/8 Regression] Bogus  |[7 Regression] Bogus
   |Warning:|Warning:
   |'__builtin_memset': |'__builtin_memset':
   |specified size 4294967291   |specified size 4294967291
   |exceeds maximum object size |exceeds maximum object size
   |2147483647  |2147483647

--- Comment #28 from janus at gcc dot gnu.org ---
With a current trunk (gcc version 8.0.1 20180315 / trunk revision 258550), I
don't see the warnings on comment 0 and comment 3 any more.

I do see them with gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04), but I
haven't checked the latest gcc-7-branch.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm-none-eabi
 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
Isn't this something you said you could see from 6.x ?

[Bug fortran/81304] [6 Regression] Bogus warning with -Wsurprising and -fopenmp: Type specified for intrinsic function 'min' / 'max'

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
Thanks for fixing, Jakub! Will you backport to gcc-6-branch as well?

[Bug c++/84874] [6/7/8 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:5800

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
struct A { const char *a, *b; };
struct B { struct A c; };

void
foo (B *x)
{
  *x = { .c = { .b = "" } };
}

  *x = B { .c = { .b = "" } };
instead of
  *x = { .c = { .b = "" } };
works fine, but it is not reshape_init that adds the missing .a initializer.

I wonder if we can just do:
--- gcc/cp/decl.c.jj2018-03-15 08:36:22.232776316 +0100
+++ gcc/cp/decl.c   2018-03-15 11:41:39.994485812 +0100
@@ -5885,8 +5885,13 @@ reshape_init_class (tree type, reshape_i
return error_mark_node;

  if (TREE_CODE (d->cur->index) == FIELD_DECL)
-   /* We already reshaped this.  */
-   gcc_assert (d->cur->index == field);
+   {
+ /* We already reshaped this.  */
+ tree id = DECL_NAME (d->cur->index);
+ gcc_checking_assert (d->cur->index
+  == get_class_binding (type, id, false));
+ field = d->cur->index;
+   }
  else if (TREE_CODE (d->cur->index) == IDENTIFIER_NODE)
field = get_class_binding (type, d->cur->index, false);
  else
or that without the gcc_checking_assert and tree id = ...;

[Bug target/84878] New: ICE: Segmentation fault (in add_cross_iteration_register_deps)

[asolokha at gmx dot com]

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

Bug ID: 84878
   Summary: ICE: Segmentation fault (in
add_cross_iteration_register_deps)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-8.0.0-alpha20180311 snapshot (r258438) ICEs when compiling the following
snippet w/ -mcpu=7450 (7400, 970, G4, G5, cell, e6500) -O2 (-O3, -Ofast)
-fmodulo-sched -ftree-vectorize -funroll-loops -fassociative-math
-fno-signed-zeros -fno-trapping-math for BE powerpc targets:

int ek;
float zu;

int
k5 (int ks)
{
  while (ek < 1)
{
  ks += (int)(0x100 + zu + !ek);
  ++ek;
}

  return ks;
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180311 -mcpu=7450 -O2
-fmodulo-sched -ftree-vectorize -funroll-loops -fassociative-math
-fno-signed-zeros -fno-trapping-math -c xmkp9hyx.c 
  during RTL pass: sms
xmkp9hyx.c: In function 'k5':
xmkp9hyx.c:14:1: internal compiler error: Segmentation fault
 }
 ^
0xc587f9 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/toplev.c:325
0x153c510 add_cross_iteration_register_deps
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/ddg.c:298
0x153c510 build_inter_loop_deps
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/ddg.c:379
0x153c510 create_ddg(basic_block_def*, int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/ddg.c:642
0x14c6fcc sms_schedule
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/modulo-sched.c:1511
0x14c7372 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180311/work/gcc-8-20180311/gcc/modulo-sched.c:3345

[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.

[tnfchris at gcc dot gnu.org]

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

--- Comment #3 from Tamar Christina  ---
Author: tnfchris
Date: Thu Mar 15 10:53:17 2018
New Revision: 258554

URL: https://gcc.gnu.org/viewcvs?rev=258554&root=gcc&view=rev
Log:
2018-03-15  Tamar Christina  

PR target/84711
* config/arm/arm.c (arm_can_change_mode_class): Use GET_MODE_UNIT_SIZE
instead of GET_MODE_SIZE when comparing Units.

gcc/testsuite/
2018-03-15  Tamar Christina  

PR target/84711
* gcc.target/arm/big-endian-subreg.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/big-endian-subreg.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #4 from Tamar Christina  ---
Fix in trunk, will backport to GCC7 soon.

[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda

[anders at knatten dot org]

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

Anders Schau Knatten  changed:

   What|Removed |Added

 CC||anders at knatten dot org

--- Comment #3 from Anders Schau Knatten  ---
Hi, Anders from cppquiz.org here, in which the example code for this bug report
originated.

The entire §5.1.2¶18 from C++11 seems to be gone from
http://eel.is/c++draft/expr.prim.lambda. It used to say:

"Every occurrence of decltype((x)) where x is a possibly parenthesized
id-expression that names an entity of automatic storage duration is treated as
if x were transformed into an access to a corresponding data member of the
closure type that would have been declared if x were an odr-use of the denoted
entity."

So I believe clang is correct according to c++11, and gcc is correct according
to whichever standard removed that sentence.

A bug was also opened against cppquiz.org for this very question, you can see
the discussion at https://github.com/knatten/cppquiz/issues/96 if you're
interested.

[Bug tree-optimization/39612] [6/7/8/9 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Target Milestone|8.0 |9.0
Summary|[6/7/8 Regression] LIM  |[6/7/8/9 Regression] LIM
   |inserts loads from  |inserts loads from
   |uninitialized local memory  |uninitialized local memory

--- Comment #31 from Richard Biener  ---
deferred again.

[Bug c++/84874] [6/7/8 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:5800

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43664&action=edit
gcc8-pr84874.patch

Full untested patch.

[Bug tree-optimization/56049] [7/8/9 Regression] Simplification to constants not done

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Target Milestone|8.0 |9.0
Summary|[7/8 Regression]|[7/8/9 Regression]
   |Simplification to constants |Simplification to constants
   |not done|not done

--- Comment #22 from Richard Biener  ---
deferred

[Bug middle-end/63184] [6/7/8/9 Regression] Fails to simplify comparison

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Target Milestone|8.0 |9.0
Summary|[6/7/8 Regression] Fails to |[6/7/8/9 Regression] Fails
   |simplify comparison |to simplify comparison

--- Comment #10 from Richard Biener  ---
deferred.

[Bug tree-optimization/64715] [6/7/8/9 Regression] __builtin_object_size (..., 1) fails to locate subobject

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Target Milestone|8.0 |9.0
Summary|[6/7/8 Regression]  |[6/7/8/9 Regression]
   |__builtin_object_size (..., |__builtin_object_size (...,
   |1) fails to locate  |1) fails to locate
   |subobject   |subobject

--- Comment #25 from Richard Biener  ---
deferred again

[Bug tree-optimization/76957] [7/8/9 Regression] XFAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||deferred
   Target Milestone|8.0 |9.0
Summary|[7/8 Regression] XFAIL: |[7/8/9 Regression] XFAIL:
   |gcc.dg/graphite/scop-dsyr2k |gcc.dg/graphite/scop-dsyr2k
   |.c scan-tree-dump-times |.c scan-tree-dump-times
   |graphite "number of SCoPs   |graphite "number of SCoPs

--- Comment #12 from Richard Biener  ---
deferred

[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
Will close it once backport is done.

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

--- Comment #37 from Aldy Hernandez  ---
Hi Richi.

(In reply to rguent...@suse.de from comment #31)

> I'd have not restricted the out-of-loop IV use to IV +- CST but
> instead did the transform
> 
> +   LOOP:
> + # p_8 = PHI 
> + ...
> + p_INC = p_8 - 1;
> + goto LOOP;
> + ... p_8 uses ...
> 
> to
> 
> +   LOOP:
> + # p_8 = PHI 
> + ...
> + p_INC = p_8 - 1;
> + goto LOOP;
>   newtem_12 = p_INC + 1; // undo IV increment
>   ... p_8 out-of-loop p_8 uses replaced with newtem_12 ...
> 
> so it would always work if we can undo the IV increment.
> 
> The disadvantage might be that we then rely on RTL optimizations
> to combine the original out-of-loop constant add with the
> newtem computation but I guess that's not too much to ask ;)
> k

It looks like RTL optimizations have a harder time optimizing things when I
take the above approach.

Doing what you suggest, we end up optimizing this (simplified for brevity):

  
  # p_8 = PHI 
  p_19 = p_8 + 4294967295;
  if (ui_7 > 9)
goto ; [89.00%]
  ...

  
  p_22 = p_8 + 4294967294;
  MEM[(char *)p_19 + 4294967295B] = 45;

into this:

  :
  # p_8 = PHI 
  p_19 = p_8 + 4294967295;
  if (ui_7 > 9)
  ...

  :
  _25 = p_19 + 1;  ;; undo the increment
  ...

  :
  p_22 = _25 + 4294967294;
  MEM[(char *)_25 + 4294967294B] = 45;

I haven't dug into the RTL optimizations, but the end result is that we only
get one auto-dec inside the loop, and some -2 indexing outside of it:

strbr1, [r4, #-1]!
lsr r3, r3, #3
bhi .L4
cmp r6, #0
movlt   r2, #45
add r3, r4, #1
strblt  r2, [r3, #-2]
sublt   r4, r4, #1

as opposed to mine:

  :
  # p_8 = PHI 
  p_19 = p_8 + 4294967295;
  if (ui_7 > 9)
  ...

  :
  p_22 = p_19 + 4294967295;
  *p_22 = 45;

which gives us two auto-dec, and much tighter code:

strbr1, [r4, #-1]!
lsr r3, r3, #3
bhi .L4
cmp r6, #0
movlt   r3, #45
strblt  r3, [r4, #-1]!

Would it be OK to go with my approach, or is worth looking into the rtl
optimizers and seeing what can be done (boo! :)).

Thanks.

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Perhaps it would help to catch this earlier if the pointers were cleared after
freeing.
And perhaps the clearing needs to be done in another function, and not done in
fails_p in lra_assign,
but left for the caller to clear it later after the lra_split_hard_reg_for
call.

==18696== Invalid read of size 4
==18696==at 0xD87999: lra_split_hard_reg_for() (lra-assigns.c:1758)
==18696==by 0xD80591: lra(_IO_FILE*) (lra.c:2507)
==18696==by 0xD27C63: do_reload() (ira.c:5465)
==18696==by 0xD28156: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5649)
==18696==by 0xE7506C: execute_one_pass(opt_pass*) (passes.c:2497)
==18696==by 0xE753BD: execute_pass_list_1(opt_pass*) (passes.c:2586)
==18696==by 0xE753EE: execute_pass_list_1(opt_pass*) (passes.c:2587)
==18696==by 0xE75446: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==18696==by 0x9F7D3B: cgraph_node::expand() (cgraphunit.c:2139)
==18696==by 0x9F8800: output_in_order() (cgraphunit.c:2381)
==18696==by 0x9F8ED5: symbol_table::compile() (cgraphunit.c:2623)
==18696==by 0x9F914E: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2717)
==18696==  Address 0xd3fe27c is 380 bytes inside a block of size 396 free'd
==18696==at 0x4C30D18: free (vg_replace_malloc.c:530)
==18696==by 0xD87625: lra_assign(bool&) (lra-assigns.c:1655)
==18696==by 0xD80516: lra(_IO_FILE*) (lra.c:2482)
==18696==by 0xD27C63: do_reload() (ira.c:5465)
==18696==by 0xD28156: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5649)
==18696==by 0xE7506C: execute_one_pass(opt_pass*) (passes.c:2497)
==18696==by 0xE753BD: execute_pass_list_1(opt_pass*) (passes.c:2586)
==18696==by 0xE753EE: execute_pass_list_1(opt_pass*) (passes.c:2587)
==18696==by 0xE75446: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==18696==by 0x9F7D3B: cgraph_node::expand() (cgraphunit.c:2139)
==18696==by 0x9F8800: output_in_order() (cgraphunit.c:2381)
==18696==by 0x9F8ED5: symbol_table::compile() (cgraphunit.c:2623)
==18696==  Block was alloc'd at
==18696==at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==18696==by 0x1D26807: xmalloc (xmalloc.c:147)
==18696==by 0xD87229: lra_assign(bool&) (lra-assigns.c:1601)
==18696==by 0xD80516: lra(_IO_FILE*) (lra.c:2482)
==18696==by 0xD27C63: do_reload() (ira.c:5465)
==18696==by 0xD28156: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5649)
==18696==by 0xE7506C: execute_one_pass(opt_pass*) (passes.c:2497)
==18696==by 0xE753BD: execute_pass_list_1(opt_pass*) (passes.c:2586)
==18696==by 0xE753EE: execute_pass_list_1(opt_pass*) (passes.c:2587)
==18696==by 0xE75446: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==18696==by 0x9F7D3B: cgraph_node::expand() (cgraphunit.c:2139)
==18696==by 0x9F8800: output_in_order() (cgraphunit.c:2381)
==18696== 
==18696== Invalid write of size 4
==18696==at 0xD879DF: lra_split_hard_reg_for() (lra-assigns.c:1761)
==18696==by 0xD80591: lra(_IO_FILE*) (lra.c:2507)
==18696==by 0xD27C63: do_reload() (ira.c:5465)
==18696==by 0xD28156: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5649)
==18696==by 0xE7506C: execute_one_pass(opt_pass*) (passes.c:2497)
==18696==by 0xE753BD: execute_pass_list_1(opt_pass*) (passes.c:2586)
==18696==by 0xE753EE: execute_pass_list_1(opt_pass*) (passes.c:2587)
==18696==by 0xE75446: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==18696==by 0x9F7D3B: cgraph_node::expand() (cgraphunit.c:2139)
==18696==by 0x9F8800: output_in_order() (cgraphunit.c:2381)
==18696==by 0x9F8ED5: symbol_table::compile() (cgraphunit.c:2623)
==18696==by 0x9F914E: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2717)
==18696==  Address 0x65fec60 is 0 bytes inside a block of size 396 free'd
==18696==at 0x4C30D18: free (vg_replace_malloc.c:530)
==18696==by 0xD87634: lra_assign(bool&) (lra-assigns.c:1656)
==18696==by 0xD80516: lra(_IO_FILE*) (lra.c:2482)
==18696==by 0xD27C63: do_reload() (ira.c:5465)
==18696==by 0xD28156: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5649)
==18696==by 0xE7506C: execute_one_pass(opt_pass*) (passes.c:2497)
==18696==by 0xE753BD: execute_pass_list_1(opt_pass*) (passes.c:2586)
==18696==by 0xE753EE: execute_pass_list_1(opt_pass*) (passes.c:2587)
==18696==by 0xE75446: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==18696==by 0x9F7D3B: cgraph_node::expand() (cgraphunit.c:2139)
==18696==by 0x9F8800: output_in_order() (cgraphunit.c:2381)
==18696==by 0x9F8ED5: symbol_table::compile

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

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

--- Comment #38 from rguenther at suse dot de  ---
On Thu, 15 Mar 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> --- Comment #37 from Aldy Hernandez  ---
> Hi Richi.
> 
> (In reply to rguent...@suse.de from comment #31)
> 
> > I'd have not restricted the out-of-loop IV use to IV +- CST but
> > instead did the transform
> > 
> > +   LOOP:
> > + # p_8 = PHI 
> > + ...
> > + p_INC = p_8 - 1;
> > + goto LOOP;
> > + ... p_8 uses ...
> > 
> > to
> > 
> > +   LOOP:
> > + # p_8 = PHI 
> > + ...
> > + p_INC = p_8 - 1;
> > + goto LOOP;
> >   newtem_12 = p_INC + 1; // undo IV increment
> >   ... p_8 out-of-loop p_8 uses replaced with newtem_12 ...
> > 
> > so it would always work if we can undo the IV increment.
> > 
> > The disadvantage might be that we then rely on RTL optimizations
> > to combine the original out-of-loop constant add with the
> > newtem computation but I guess that's not too much to ask ;)
> > k
> 
> It looks like RTL optimizations have a harder time optimizing things when I
> take the above approach.
> 
> Doing what you suggest, we end up optimizing this (simplified for brevity):
> 
>   
>   # p_8 = PHI 
>   p_19 = p_8 + 4294967295;
>   if (ui_7 > 9)
> goto ; [89.00%]
>   ...
> 
>   
>   p_22 = p_8 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> into this:
> 
>   :
>   # p_8 = PHI 
>   p_19 = p_8 + 4294967295;
>   if (ui_7 > 9)
>   ...
> 
>   :
>   _25 = p_19 + 1;  ;; undo the increment
>   ...
> 
>   :
>   p_22 = _25 + 4294967294;
>   MEM[(char *)_25 + 4294967294B] = 45;

shouldn't the p_19 in the MEM remain?  Why a new BB for the adjustment?
(just asking...)

> I haven't dug into the RTL optimizations, but the end result is that we only
> get one auto-dec inside the loop, and some -2 indexing outside of it:
> 
> strbr1, [r4, #-1]!
> lsr r3, r3, #3
> bhi .L4
> cmp r6, #0
> movlt   r2, #45
> add r3, r4, #1
> strblt  r2, [r3, #-2]
> sublt   r4, r4, #1
> 
> as opposed to mine:
> 
>   :
>   # p_8 = PHI 
>   p_19 = p_8 + 4294967295;
>   if (ui_7 > 9)
>   ...
> 
>   :
>   p_22 = p_19 + 4294967295;
>   *p_22 = 45;
> 
> which gives us two auto-dec, and much tighter code:
> 
> strbr1, [r4, #-1]!
> lsr r3, r3, #3
> bhi .L4
> cmp r6, #0
> movlt   r3, #45
> strblt  r3, [r4, #-1]!
> 
> Would it be OK to go with my approach, or is worth looking into the rtl
> optimizers and seeing what can be done (boo! :)).

Would be interesting to see what is causing things to break.  If it's
only combine doing the trick then it will obviously be multi-uses
of the adjustment pseudo.  But eventually I thought fwprop would
come to the rescue...

I think a good approach would be to instead of just replacing
all out-of-loop uses with the new SSA name doing the adjustment
check if the use is in a "simple" (thus SSA name +- cst) stmt
and there forward the adjustment.

So have the best of both worlds.  I would have hoped this
extra complication isn't needed but as you figured...

[Bug tree-optimization/82847] [8 regression] gcc.dg/vect/slp-perm-9.c fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
So a possible fix would be to require vect_perm_short tests to append
appropriate x86 flags for compiling (likewise for vect_perm_byte).

This particular testcase starts passing when SSSE3 is enabled.

The situation on x86 is that not all permutation masks are equal so I don't
expect that one can append random subtarget flags enabling or disabling ISAs
and still have all vectorizer tests pass as expected.

Not sure what the desired way of fixing this is.

Some targets have things like mips_msa which checks whether -mmsa was given
but x86 has targets like sse4 which checks whether we can assemble SSE4
instructions (with explicitely adding -msse4).  That looks somewhat
inconsistent to me.  So we could go for a sse3a_enabled target and condition
vect_perm_short on that.  But it would of course be a lie as already SSE2
can do a subset of short permutes via pshufhw/pshuflw and punpck*,
in fact any short permute should be synthesizable via those.

All testcases now using vect_perm_{short,byte} will fail on x86 if you enable
recent enough ISAs:

FAIL: gcc.dg/vect/pr81196.c scan-tree-dump-times vect "vectorized 1 loops" 2
FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-perm-8.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "permutation requires
at least three vectors" 1

that said, I'll happily do testcase / targets-supports.exp adjustments but
I'm unsure of the general direction we want to go with all those
vectorizer related effective targets.

For now I think

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 258552)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -5788,6 +5788,7 @@ proc check_effective_target_vect_perm_by
 && ![check_effective_target_vect_variable_length])
 || [istarget powerpc*-*-*]
 || [istarget spu-*-*]
+|| [istarget i?86-*-*] || [istarget x86_64-*-*]
 || ([istarget mips-*.*]
 && [et-is-effective-target mips_msa])
 || ([istarget s390*-*-*]
@@ -5828,6 +5829,7 @@ proc check_effective_target_vect_perm_sh
 && ![check_effective_target_vect_variable_length])
 || [istarget powerpc*-*-*]
 || [istarget spu-*-*]
+|| [istarget i?86-*-*] || [istarget x86_64-*-*]
 || ([istarget mips*-*-*]
  && [et-is-effective-target mips_msa])
 || ([istarget s390*-*-*]

should be done given vect_perm includes x86 already.  Then we need to
adjust the above failing testcases somehow - but how?

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I think GCC needs to copy P0 to a properly aligned stack slot in the prologue.

[Bug gcov-profile/84879] New: GCOV tool crash when invoked for intermediate format

[marxin at gcc dot gnu.org]

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

Bug ID: 84879
   Summary: GCOV tool crash when invoked for intermediate format
   Product: gcc
   Version: unknown
   URL: https://github.com/linux-test-project/lcov/issues/38#i
ssuecomment-373348413
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Extracted from github issue:

$ echo "int main() { return 0; }" > t.c
$ gcc t.c -o t --coverage
$ ./t
$ gcov -iab t.c
File 't.c'
Lines executed:100.00% of 1
No branches
No calls
Creating 't.c.gcov'
Segmentation fault (core dumped)

[Bug libfortran/84880] New: [libgfortran] libgfortran fail to build on aarch64/arm 32bit cross toolchain

[amker at gcc dot gnu.org]

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

Bug ID: 84880
   Summary: [libgfortran] libgfortran fail to build on aarch64/arm
32bit cross toolchain
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

After change at:
commit af3e0188d727fd2d2878d625dcd9919379a6374e
Author: kargl 
Date:   Wed Mar 14 00:56:48 2018 +

2018-03-13  Steven G. Kargl  

* check.c (gfc_check_kill_sub):  Remove check for INTEGER(4) or (8).
* intrinsic.c (add_functions): Remove reference to gfc_resolve_kill.
(add_subroutines): Remove reference to gfc_resolve_kill_sub.
* intrinsic.texi: Update documentation.
* iresolve.c (gfc_resolve_kill, gfc_resolve_kill_sub): Remove.
* trans-decl.c (gfc_build_intrinsic_function_decls):  Add
gfor_fndecl_kill and gfor_fndecl_kill_sub
* trans-intrinsic.c (conv_intrinsic_kill, conv_intrinsic_kill_sub): new
functions.
(gfc_conv_intrinsic_function): Use conv_intrinsic_kill.
(gfc_conv_intrinsic_subroutine): Use conv_intrinsic_kill_sub.
* trans.h: Declare gfor_fndecl_kill and gfor_fndecl_kill_sub.

2018-03-13  Steven G. Kargl  

* libgfortran/gfortran.map: Remove _gfortran_kill_i4,
_gfortran_kill_i4_sub, _gfortran_kill_i8, and _gfortran_kill_i8_sub.
Add _gfortran_kill and _gfortran_kill_sub.
* libgfortran/intrinsics/kill.c: Eliminate _gfortran_kill_i4,
_gfortran_kill_i4_sub, _gfortran_kill_i8, and _gfortran_kill_i8_sub.
Add _gfortran_kill and _gfortran_kill_sub.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258511
138bc75d-0d04-0410-961f-82ee72b054a4



libgfortran fail to build with below error message:

/.../obj/gcc2/./gcc/xgcc -B/.../obj/gcc2/./gcc/
-B/.../install/aarch64-none-elf/bin/
-B/.../install/aarch64-none-elf/lib/ -isystem
/.../install/aarch64-none-elf/include -isystem
/.../install/aarch64-none-elf/sys-include -DHAVE_CONFIG_H -I.
-I/.../gcc/libgfortran -iquote/.../gcc/libgfortran/io
-I/.../gcc/libgfortran/../gcc -I/.../gcc/libgfortran/../gcc/config
-I../../.././gcc -I/.../gcc/libgfortran/../libgcc -I../../libgcc
-I/.../gcc/libgfortran/../libbacktrace -I../../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -ffunction-sections
-fdata-sections -O2 -mabi=ilp32 -MT kill.lo -MD -MP -MF .deps/kill.Tpo
-c /.../gcc/libgfortran/intrinsics/kill.c -o kill.o
/.../gcc/libgfortran/intrinsics/kill.c:54:22: error: conflicting types
for 'kill'
 extern GFC_INTEGER_4 kill (GFC_INTEGER_4, GFC_INTEGER_4);
  ^~~~
In file included from /.../install/aarch64-none-elf/include/signal.h:6,
 from /.../gcc/libgfortran/intrinsics/kill.c:28:
/.../install/aarch64-none-elf/include/sys/signal.h:176:5: note:
previous declaration of 'kill' was here
 int kill (pid_t, int);
 ^~~~
In file included from /.../gcc/libgfortran/intrinsics/kill.c:26:
/.../gcc/libgfortran/intrinsics/kill.c:55:14: error: conflicting types
for 'kill'
 export_proto(kill);
  ^~~~
/.../gcc/libgfortran/libgfortran.h:150:57: note: in definition of
macro 'sym_rename2'
 #define sym_rename2(old, ulp, new) extern __typeof(old) old __asm__(#ulp #new)
 ^~~
/.../gcc/libgfortran/libgfortran.h:148:30: note: in expansion of macro
'sym_rename1'
 #define sym_rename(old, new) sym_rename1(old, __USER_LABEL_PREFIX__, new)
  ^~~
/.../gcc/libgfortran/libgfortran.h:195:26: note: in expansion of macro
'sym_rename'
 # define export_proto(x) sym_rename(x, PREFIX(x))
  ^~
/.../gcc/libgfortran/intrinsics/kill.c:55:1: note: in expansion of
macro 'export_proto'
 export_proto(kill);
 ^~~~
In file included from /.../install/aarch64-none-elf/include/signal.h:6,
 from /.../gcc/libgfortran/intrinsics/kill.c:28:
/.../install/aarch64-none-elf/include/sys/signal.h:176:5: note:
previous declaration of 'kill' was here
 int kill (pid_t, int);
 ^~~~
/.../gcc/libgfortran/intrinsics/kill.c:58:1: error: conflicting types for
'kill'
 kill (GFC_INTEGER_4 pid, GFC_INTEGER_4 signal)
 ^~~~
In file included from /.../install/aarch64-none-elf/include/signal.h:6,
 from /.../gcc/libgfortran/intrinsics/kill.c:28:
/.../install/aarch64-none-elf/include/sys/signal.h:176:5: note:
previous declaration of 'kill' was here
 int kill (pid_t, int);
 ^~~~

The gcc is configured with:
gcc/configure --target=aarch64-none-elf --prefix=...
--with-gmp=.../host-tools --with-mpfr=.../ho

[Bug gcov-profile/84879] GCOV tool crash when invoked for intermediate format

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-15
  Known to work||8.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0

--- Comment #1 from Martin Liška  ---
Fixed on trunk in r247374. I'll consider backporting that to GCC 7 and maybe 6
branches.

[Bug debug/84875] [8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I don't have my bisect s390x seed built with checking, but from the generated
code I think this started with r207605.

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

--- Comment #39 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #38)
> On Thu, 15 Mar 2018, aldyh at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> > 
> > --- Comment #37 from Aldy Hernandez  ---
> > Hi Richi.
> > 
> > (In reply to rguent...@suse.de from comment #31)
> > 
> > > I'd have not restricted the out-of-loop IV use to IV +- CST but
> > > instead did the transform
> > > 
> > > +   LOOP:
> > > + # p_8 = PHI 
> > > + ...
> > > + p_INC = p_8 - 1;
> > > + goto LOOP;
> > > + ... p_8 uses ...
> > > 
> > > to
> > > 
> > > +   LOOP:
> > > + # p_8 = PHI 
> > > + ...
> > > + p_INC = p_8 - 1;
> > > + goto LOOP;
> > >   newtem_12 = p_INC + 1; // undo IV increment
> > >   ... p_8 out-of-loop p_8 uses replaced with newtem_12 ...
> > > 
> > > so it would always work if we can undo the IV increment.
> > > 
> > > The disadvantage might be that we then rely on RTL optimizations
> > > to combine the original out-of-loop constant add with the
> > > newtem computation but I guess that's not too much to ask ;)
> > > k
> > 
> > It looks like RTL optimizations have a harder time optimizing things when I
> > take the above approach.
> > 
> > Doing what you suggest, we end up optimizing this (simplified for brevity):
> > 
> >   
> >   # p_8 = PHI 
> >   p_19 = p_8 + 4294967295;
> >   if (ui_7 > 9)
> > goto ; [89.00%]
> >   ...
> > 
> >   
> >   p_22 = p_8 + 4294967294;
> >   MEM[(char *)p_19 + 4294967295B] = 45;
> > 
> > into this:
> > 
> >   :
> >   # p_8 = PHI 
> >   p_19 = p_8 + 4294967295;
> >   if (ui_7 > 9)
> >   ...
> > 
> >   :
> >   _25 = p_19 + 1;  ;; undo the increment
> >   ...
> > 
> >   :
> >   p_22 = _25 + 4294967294;
> >   MEM[(char *)_25 + 4294967294B] = 45;
> 
> shouldn't the p_19 in the MEM remain?  Why a new BB for the adjustment?
> (just asking...)

Oh, I was adjusting/propagating that one as a special case to see if the [_25 +
4294967294] could be CSE'd somehow by the RTL optimizers.  But even with the
p_19 remaining, the result is the same in the assembly.  For the record, with
the p_19 in place, we would get (see below for a more complete dump):

  p_22 = _25 + 4294967294;
  MEM[(char *)p_19 + 4294967295B] = 45;

There is no new BB.  That was the result of adding the TMP on the non-back
edge.  My simplification of the gimple IL for illustration purposes made that
bit unclear.

The unadulterated original was:

[local count: 1073741825]:
  # ui_7 = PHI 
  # p_8 = PHI 
  _4 = ui_7 % 10;
  _5 = (char) _4;
  p_19 = p_8 + 4294967295;
  _6 = _5 + 48;
  MEM[base: p_19, offset: 0B] = _6;
  ui_21 = ui_7 / 10;
  if (ui_7 > 9)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111601]:
  if (i_12(D) < 0)
goto ; [41.00%]
  else
goto ; [59.00%]

   [local count: 48425756]:
  p_22 = p_8 + 4294967294;
  MEM[(char *)p_19 + 4294967295B] = 45;

with a corresponding transformation (keeping the p_19 as you inquired) of:

   [local count: 1073741825]:
  # ui_7 = PHI 
  # p_8 = PHI 
  _4 = ui_7 % 10;
  _5 = (char) _4;
  p_19 = p_8 + 4294967295;
  _6 = _5 + 48;
  MEM[base: p_19, offset: 0B] = _6;
  ui_21 = ui_7 / 10;
  ui_24 = ui_21;
  if (ui_7 > 9)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111601]:
  _25 = p_19 + 1;  ;; undo the increment on the non-back edge
  if (i_12(D) < 0)
goto ; [41.00%]
  else
goto ; [59.00%]

   [local count: 48425756]:
  p_22 = _25 + 4294967294;
  MEM[(char *)p_19 + 4294967295B] = 45;

> 
> > I haven't dug into the RTL optimizations, but the end result is that we only
> > get one auto-dec inside the loop, and some -2 indexing outside of it:
> > 
> > strbr1, [r4, #-1]!
> > lsr r3, r3, #3
> > bhi .L4
> > cmp r6, #0
> > movlt   r2, #45
> > add r3, r4, #1
> > strblt  r2, [r3, #-2]
> > sublt   r4, r4, #1
> > 
> > as opposed to mine:
> > 
> >   :
> >   # p_8 = PHI 
> >   p_19 = p_8 + 4294967295;
> >   if (ui_7 > 9)
> >   ...
> > 
> >   :
> >   p_22 = p_19 + 4294967295;
> >   *p_22 = 45;
> > 
> > which gives us two auto-dec, and much tighter code:
> > 
> > strbr1, [r4, #-1]!
> > lsr r3, r3, #3
> > bhi .L4
> > cmp r6, #0
> > movlt   r3, #45
> > strblt  r3, [r4, #-1]!
> > 
> > Would it be OK to go with my approach, or is worth looking into the rtl
> > optimizers and seeing what can be done (boo! :)).
> 
> Would be interesting to see what is causing things to break.  If it's
> only combine doing the trick then it will obviously be multi-uses
> of the adjustment pseudo.  But eventually I thought fwprop would
> come to the rescue...

I could post the WIP for this approach if anyone is interested.

> 
> I think a good approach would be to instead of just replacing
> all out-of-loop uses with the new SSA name doing the adjustm

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |6.5
Summary|[8 Regression] ICE in   |[6/7/8 Regression] ICE in
   |maybe_record_trace_start,   |maybe_record_trace_start,
   |at dwarf2cfi.c:2348 on  |at dwarf2cfi.c:2348 on
   |s390x   |s390x

--- Comment #2 from Jakub Jelinek  ---
But just configured with --enable-checking=yes build of 4.9.
./xgcc -B ./ --version; ./cc1 -quiet -Os -fpie -march=z196 pr84875.c -nostdinc
xgcc (GCC) 4.9.4 20160720 (prerelease)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pr84875.c: In function ‘f’:
pr84875.c:18:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2239
 }
 ^
0x6514bc maybe_record_trace_start
../../gcc/dwarf2cfi.c:2239
0x65351e scan_trace
../../gcc/dwarf2cfi.c:2416
0x653b07 create_cfi_notes
../../gcc/dwarf2cfi.c:2570
0x653b07 execute_dwarf2_frame
../../gcc/dwarf2cfi.c:2925
0x653b07 execute
../../gcc/dwarf2cfi.c:3421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libfortran/84880] [8 Regression] libgfortran fail to build on aarch64/arm 32bit cross toolchain

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1
   Target Milestone|--- |8.0
Summary|[libgfortran] libgfortran   |[8 Regression] libgfortran
   |fail to build on|fail to build on
   |aarch64/arm 32bit cross |aarch64/arm 32bit cross
   |toolchain   |toolchain

[Bug c++/84881] New: internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[hp at tmm dot cx]

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

Bug ID: 84881
   Summary: internal compiler error: in assign_temp, at
function.c:968 when building for gnueabihf
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at tmm dot cx
  Target Milestone: ---

Created attachment 43665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43665&action=edit
File causing the ICE

When trying to cross-compile the Godot game engine we're seeing an ICE. The
problem happens in GCC6 as well. Latest test was done with 7.3.0 and the
problem persists.

The downstream bugreport is here:
https://github.com/godotengine/godot/issues/16100

I've attached the preprocessed file causing the ICE.

[Bug c++/84881] internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[hp at tmm dot cx]

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

--- Comment #1 from Hein-Pieter van Braam  ---
I forgot to mention: The ICE doesn't happen when building for i686 or x86_64.

[Bug c++/84881] internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[hp at tmm dot cx]

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

--- Comment #2 from Hein-Pieter van Braam  ---
Created attachment 43666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43666&action=edit
Result of the compilation with -fbugreport enabled

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

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

--- Comment #40 from rguenther at suse dot de  ---
On Thu, 15 Mar 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> --- Comment #39 from Aldy Hernandez  ---
> (In reply to rguent...@suse.de from comment #38)
> > On Thu, 15 Mar 2018, aldyh at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> > > 
> > > --- Comment #37 from Aldy Hernandez  ---
> > > Hi Richi.
> > > 
> > > (In reply to rguent...@suse.de from comment #31)
> > > 
> > > > I'd have not restricted the out-of-loop IV use to IV +- CST but
> > > > instead did the transform
> > > > 
> > > > +   LOOP:
> > > > + # p_8 = PHI 
> > > > + ...
> > > > + p_INC = p_8 - 1;
> > > > + goto LOOP;
> > > > + ... p_8 uses ...
> > > > 
> > > > to
> > > > 
> > > > +   LOOP:
> > > > + # p_8 = PHI 
> > > > + ...
> > > > + p_INC = p_8 - 1;
> > > > + goto LOOP;
> > > >   newtem_12 = p_INC + 1; // undo IV increment
> > > >   ... p_8 out-of-loop p_8 uses replaced with newtem_12 ...
> > > > 
> > > > so it would always work if we can undo the IV increment.
> > > > 
> > > > The disadvantage might be that we then rely on RTL optimizations
> > > > to combine the original out-of-loop constant add with the
> > > > newtem computation but I guess that's not too much to ask ;)
> > > > k
> > > 
> > > It looks like RTL optimizations have a harder time optimizing things when 
> > > I
> > > take the above approach.
> > > 
> > > Doing what you suggest, we end up optimizing this (simplified for 
> > > brevity):
> > > 
> > >   
> > >   # p_8 = PHI 
> > >   p_19 = p_8 + 4294967295;
> > >   if (ui_7 > 9)
> > > goto ; [89.00%]
> > >   ...
> > > 
> > >   
> > >   p_22 = p_8 + 4294967294;
> > >   MEM[(char *)p_19 + 4294967295B] = 45;
> > > 
> > > into this:
> > > 
> > >   :
> > >   # p_8 = PHI 
> > >   p_19 = p_8 + 4294967295;
> > >   if (ui_7 > 9)
> > >   ...
> > > 
> > >   :
> > >   _25 = p_19 + 1;  ;; undo the increment
> > >   ...
> > > 
> > >   :
> > >   p_22 = _25 + 4294967294;
> > >   MEM[(char *)_25 + 4294967294B] = 45;
> > 
> > shouldn't the p_19 in the MEM remain?  Why a new BB for the adjustment?
> > (just asking...)
> 
> Oh, I was adjusting/propagating that one as a special case to see if the [_25 
> +
> 4294967294] could be CSE'd somehow by the RTL optimizers.  But even with the
> p_19 remaining, the result is the same in the assembly.  For the record, with
> the p_19 in place, we would get (see below for a more complete dump):
> 
>   p_22 = _25 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> There is no new BB.  That was the result of adding the TMP on the non-back
> edge.  My simplification of the gimple IL for illustration purposes made that
> bit unclear.
> 
> The unadulterated original was:
> 
> [local count: 1073741825]:
>   # ui_7 = PHI 
>   # p_8 = PHI 
>   _4 = ui_7 % 10;
>   _5 = (char) _4;
>   p_19 = p_8 + 4294967295;
>   _6 = _5 + 48;
>   MEM[base: p_19, offset: 0B] = _6;
>   ui_21 = ui_7 / 10;
>   if (ui_7 > 9)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 118111601]:
>   if (i_12(D) < 0)
> goto ; [41.00%]
>   else
> goto ; [59.00%]
> 
>[local count: 48425756]:
>   p_22 = p_8 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> with a corresponding transformation (keeping the p_19 as you inquired) of:
> 
>[local count: 1073741825]:
>   # ui_7 = PHI 
>   # p_8 = PHI 
>   _4 = ui_7 % 10;
>   _5 = (char) _4;
>   p_19 = p_8 + 4294967295;
>   _6 = _5 + 48;
>   MEM[base: p_19, offset: 0B] = _6;
>   ui_21 = ui_7 / 10;
>   ui_24 = ui_21;
>   if (ui_7 > 9)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 118111601]:
>   _25 = p_19 + 1;  ;; undo the increment on the non-back edge
>   if (i_12(D) < 0)
> goto ; [41.00%]
>   else
> goto ; [59.00%]
> 
>[local count: 48425756]:
>   p_22 = _25 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> 
> > 
> > > I haven't dug into the RTL optimizations, but the end result is that we 
> > > only
> > > get one auto-dec inside the loop, and some -2 indexing outside of it:
> > > 
> > > strbr1, [r4, #-1]!
> > > lsr r3, r3, #3
> > > bhi .L4
> > > cmp r6, #0
> > > movlt   r2, #45
> > > add r3, r4, #1
> > > strblt  r2, [r3, #-2]
> > > sublt   r4, r4, #1
> > > 
> > > as opposed to mine:
> > > 
> > >   :
> > >   # p_8 = PHI 
> > >   p_19 = p_8 + 4294967295;
> > >   if (ui_7 > 9)
> > >   ...
> > > 
> > >   :
> > >   p_22 = p_19 + 4294967295;
> > >   *p_22 = 45;
> > > 
> > > which gives us two auto-dec, and much tighter code:
> > > 
> > > strbr1, [r4, #-1]!
> > > lsr r3, r3, #3
> > > bhi .L4
> > > cmp r6, #0
> > > movlt   r3, #45
> > > strblt  r3, [r4, #-1]!
> > > 
> > > Would it be OK to go w

[Bug c++/79085] ICE with placement new to unaligned location

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||hp at tmm dot cx

--- Comment #3 from Martin Liška  ---
*** Bug 84881 has been marked as a duplicate of this bug. ***

[Bug c++/84881] internal compiler error: in assign_temp, at function.c:968 when building for gnueabihf

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
According to reduced test-case it's dup:

typedef struct {
  char a[6];
} b;
void *operator new(unsigned, void *c, int, char *) { return c; }
class d {
public:
  d(int);
};
class e {
public:
  enum {} f;
  e call(d, const e **, int, int);
  ~e();
};
b g() {
  int h, error;
  e *i;
  int *j;
  const e **args;
  b k;
  e *dest = (e *)&k;
  new (dest, sizeof(e), "") e(i->call(*j, args, h, error));
  return k;
}

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

[Bug middle-end/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

--- Comment #41 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #40)

> Well, your patch only replaces increments it can modify possibly
> leaving uses unaltered.  That's IMHO not good.
> 
> Which is why I suggested to have it like your original patch for
> those uses you can modify but for other uses simply substitute
> the LHS of the compensation stmt.
> 
> If the compensation stmt ends up being not used it won't be
> expanded I think (you could of course insert/build it just on-demand).

Ah.  I had misunderstood.

I will do as you suggest and then take the patch upstream so we can finish the
rest of the discussion there.

Thanks so much for the feedback.

[Bug c/84873] [6/7/8 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Mar 15 13:10:24 2018
New Revision: 258556

URL: https://gcc.gnu.org/viewcvs?rev=258556&root=gcc&view=rev
Log:
2018-03-15  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Do not fold expressions.

* c-c++-common/pr84873.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/pr84873.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
  Known to work||5.4.0
Summary|ICE with placement new to   |[6/7/8 Regression] ICE with
   |unaligned location  |placement new to unaligned
   ||location
  Known to fail||8.0

--- Comment #4 from Martin Liška  ---
Still failing, as GCC 5 worked, it's a regression. Can please somebody take a
look?

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So, we have a function which conditionally bypasses the prologue and epilogue
and just performs a tailcall, otherwise saves two registers (%r10 and %r11)
into %f2 and %f0 registers, clobbers one of them (%r11) and conditionally
branches to epilogue sequence that restores the two:
(insn/f 105 107 106 5 (set (reg:DI 10 %r10)
(reg:DI 17 %f2)) "pr84875.c":18 -1
 (expr_list:REG_DEAD (reg:DI 17 %f2)
(expr_list:REG_CFA_RESTORE (reg:DI 10 %r10)
(nil
(insn/f 106 105 94 5 (set (reg:DI 11 %r11)
(reg:DI 16 %f0)) "pr84875.c":18 -1
 (expr_list:REG_DEAD (reg:DI 16 %f0)
(expr_list:REG_CFA_RESTORE (reg:DI 11 %r11)
(nil
and falls through into the tailcall (otherwise performs some other stuff,
clobbers also the %r10 register, restores the two registers and returns).
That is fine.  Now, cprop_hardreg figures out the %r10 register isn't really
clobbered in the particular path and changes it to:
(insn/f 105 107 106 5 (set (reg:DI 10 %r10)
(reg:DI 10 %r10 [17])) "pr84875.c":18 1270 {*movdi_64}
 (expr_list:REG_DEAD (reg:DI 17 %f2)
(expr_list:REG_CFA_RESTORE (reg:DI 10 %r10)
(nil
(insn/f 106 105 94 5 (set (reg:DI 11 %r11)
(reg:DI 16 %f0)) "pr84875.c":18 1270 {*movdi_64}
 (expr_list:REG_DEAD (reg:DI 16 %f0)
(expr_list:REG_CFA_RESTORE (reg:DI 11 %r11)
(nil
From the POV of unwind info that is still ok, there is really no need to
actually restore the register physically, we just need to emit the .cfi_restore
because we are entering code where the register might not be really safed in
the original register anymore.

And finally rtl_dce just removes the insn 105 as a noop move and removes with
it also the REG_CFA_RESTORE note.

[Bug debug/84875] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348 on s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43667&action=edit
gcc8-pr84875.patch

This seems to work (though isn't pretty).

[Bug c/84873] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |verify_ssa failed (error:   |verify_ssa failed (error:
   |definition in block 3 does  |definition in block 3 does
   |not dominate use in block   |not dominate use in block
   |4)  |4)
  Known to fail||7.3.0

--- Comment #9 from Richard Biener  ---
Fixed on trunk sofar.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
The summary is now misleading as well.  IMHO the bug shouldn't have been
overloaded with the fallout of the original fix.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[hp at tmm dot cx]

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

--- Comment #5 from Hein-Pieter van Braam  ---
I can build the file I reported #84881 on with the following extra options: -O3
-fno-tree-fre -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-ccp
-fno-code-hoisting -fno-tree-pre -fno-tree-vrp

Perhaps that can help nailing down this issue?

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||33315

--- Comment #7 from Richard Biener  ---
The patch for PR33315 manages to transform

  if (n_21 > 255)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  a[0] = 255;
  goto ; [100.00%]

   [local count: 477815112]:
  _1 = (unsigned char) n_21;
  a[0] = _1;

   [local count: 955630225]:
  _2 = a[0];

to

  if (n_21 > 255)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  _1 = (unsigned char) n_21;

   [local count: 955630225]:
  # _23 = PHI <255(5), _1(6)>
  a[0] = _23;
  _2 = a[0];

but as proposed that would happen too late (we've already threaded the jump
and PRE already would have done sth similar via the load from a[0]).  As
given it looks like sinking should be performed before the first phiopt pass
(which also runs quite late - there was talk of an early phiopt pass).
Possibly cselim could be enhanced to catch the above as well.  In fact its
comments say it would handle the above.  Ah, we do

  /* Set PARAM_MAX_STORES_TO_SINK to 0 if either vectorization or if-conversion
 is disabled.  */
  if ((!opts->x_flag_tree_loop_vectorize && !opts->x_flag_tree_slp_vectorize)
   || !opts->x_flag_tree_loop_if_convert)
maybe_set_param_value (PARAM_MAX_STORES_TO_SINK, 0,
   opts->x_param_values, opts_set->x_param_values);

for whatever reason :/  --param max-stores-to-sink=2 fixes the testcase.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug 33315] stores not commoned by sinking

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
(In reply to Ramana Radhakrishnan from comment #0)
> __complex double x;
> __complex double y;
> __complex double z;
> double a, b, c, d;
> 
> int main (void)
> {
>   x = y * z;
>   return 0; 
> }
> 
> Could well be implemented as:
> 
> 
> int main (void)
> {
>   x = y * z;
>   if (isnan (__real x) && isnan (__imag__ x))
> x = __muldc3 (y, z);
> 
>   return 0;
> }
> 
> essentially opencoding this as the standard suggests in G.5.1 => 6for C99.
> 
> spotted while looking at profiles that were reported on aarch64 with code
> compiled at O2 / O3.
> 
> I note that lowering this in this form in tree-complex.c will need a bit of
> book-keeping given that it's sort of bounded on the phi nodes and ssa_names
> before lowering begins but this could well be another math-optimization done
> later rather than munging it with the existing lowering.

Note that isnan (x) || isnan (y) is optimized to isunordered (x, y), so that
would be a faster check.

Also it may be beneficial to vectorize this despite the fallback.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

--- Comment #6 from Jakub Jelinek  ---
Started to ICE with r232167, before that it has been just silent wrong-code,
calling the function/method with a temporary and then copying it over (and not
destructing) despite perhaps having non-trivial copy ctor and/or dtor.

Untested fix:
--- gcc/calls.c.jj  2018-02-22 12:37:02.641387687 +0100
+++ gcc/calls.c 2018-03-15 15:17:42.596835316 +0100
@@ -3422,9 +3422,14 @@ expand_call (tree exp, rtx target, int i
if (CALL_EXPR_RETURN_SLOT_OPT (exp)
&& target
&& MEM_P (target)
-   && !(MEM_ALIGN (target) < TYPE_ALIGN (rettype)
-&& targetm.slow_unaligned_access (TYPE_MODE (rettype),
-  MEM_ALIGN (target
+   /* If rettype is addressable, we may not create a temporary.
+  If target is properly aligned at runtime and the compiler
+  just doesn't know about it, it will work fine, otherwise it
+  will be UB.  */
+   && (TREE_ADDRESSABLE (rettype)
+   || !(MEM_ALIGN (target) < TYPE_ALIGN (rettype)
+&& targetm.slow_unaligned_access (TYPE_MODE (rettype),
+  MEM_ALIGN (target)
  structure_value_addr = XEXP (target, 0);
else
  {

[Bug target/84882] New: -mstrict-align on aarch64 should not be RejectNegative

[jakub at gcc dot gnu.org]

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

Bug ID: 84882
   Summary: -mstrict-align on aarch64 should not be RejectNegative
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

-mno-strict-align works on all targets that support -mstrict-align option,
except aarch64.  Any reason for the RejectNegative in there?  From what I can
see, it isn't the default on aarch64, and there is no way to undo an earlier
flag on command line.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 43668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43668&action=edit
gcc8-pr79085.patch

Untested fix.

[Bug tree-optimization/82491] UBSAN in gcc/gimple-fold.c:6187:6: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #5)
> Thanks Richard!
> 
> Now I still see the other issue in dwarf2out:
> 
> Breakpoint 1, based_loc_descr (reg=0x751183a8, offset=...,
> initialized=VAR_INIT_STATUS_INITIALIZED) at ../../gcc/dwarf2out.c:14170
> warning: Source file is more recent than executable.
> 14170   elim = strip_offset_and_add (elim, &offset);
> (gdb) c
> Continuing.
> ../../gcc/poly-int.h:414:21: runtime error: signed integer overflow:
> 9223372036854775789 + 48 cannot be represented in type 'long int'
> #0 0xaa9c75 in poly_int_pod<1u, long>& poly_int_pod<1u,
> long>::operator+=(poly_int_pod<1u, long> const&)
> ../../gcc/poly-int.h:414
> #1 0xaa9266 in strip_offset_and_add(rtx_def*, poly_int_pod<1u, long>*)
> ../../gcc/rtl.h:4340
> #2 0xd4f022 in based_loc_descr ../../gcc/dwarf2out.c:14170
> #3 0xd5da4c in mem_loc_descriptor(rtx_def*, machine_mode, machine_mode,
> var_init_status) ../../gcc/dwarf2out.c:15643
> #4 0xd65a2a in loc_descriptor ../../gcc/dwarf2out.c:16616
> ...
> 
> (gdb) p debug_rtx(elim)
> (plus:DI (reg/f:DI 7 sp)
> (const_int 48 [0x30]))
> $2 = void
> (gdb) p offset
> $3 = {> = {coeffs = {9223372036854775789}},  fields>}
> 
> Is it Jakub something we should handle? Do you have a suggestion how to do
> that?

Dunno, either perform the calculation in poly_uint64 instead and then cast to
poly_int64, or don't do it at all if there is overflow.

[Bug bootstrap/81033] [8 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

Summary|[8 Regression] Revision |[8 Regression] there are
   |r249019 breaks bootstrap on |cases where ld64 is not
   |darwin  |able to determine correct
   ||atom boundaries from the
   ||output GCC currently
   ||produces

--- Comment #34 from Eric Gallager  ---
(In reply to Richard Biener from comment #33)
> The summary is now misleading as well.  IMHO the bug shouldn't have been
> overloaded with the fallout of the original fix.

Updated summary based on:

(In reply to Iain Sandoe from comment #29)
> (In reply to Dominique d'Humieres from comment #28)
> > Bootstrap is fixed, but the fix did not please to Iain Sandoe.
> 
> The fix allows bootstrap to proceed, but doesn't solve the underlying
> problem (which is that there are cases where the linker [ld64] is not able
> to determine correct atom boundaries from the output we currently produce
> from GCC).
> 
> I will hopefully have some cycles for Darwin over the next month to address
> this and other issues.

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Sorry, my bad.  It is easy to fix.  I think the patch will be ready today.

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Mine.  We can handle the case of a single store in the BBs more generally and
bypass the limit.  The limit was added in r171381 where it was imposed on
all transforms when the function was changed to handle the case of more
than one stmt (store) in each BB.  Previously the transform for the single
stores case was always performed.

Thus, for example like the following.  Could be simplified somewhat iff
the stores need to be the last stmt in the BBs (like it was before said
re-org).  last_and_only_stmt isn't enough here as we have a feeding
scalar stmt around in one BB.

Opinions?

Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c   (revision 258552)
+++ gcc/tree-ssa-phiopt.c   (working copy)
@@ -2061,8 +2061,6 @@ static bool
 cond_if_else_store_replacement (basic_block then_bb, basic_block else_bb,
 basic_block join_bb)
 {
-  gimple *then_assign = last_and_only_stmt (then_bb);
-  gimple *else_assign = last_and_only_stmt (else_bb);
   vec then_datarefs, else_datarefs;
   vec then_ddrs, else_ddrs;
   gimple *then_store, *else_store;
@@ -2073,14 +2071,49 @@ cond_if_else_store_replacement (basic_bl
   tree then_lhs, else_lhs;
   basic_block blocks[3];

-  if (MAX_STORES_TO_SINK == 0)
+  /* Handle the case with single store in THEN_BB and ELSE_BB.  That is
+ cheap enough to always handle.  */
+  gphi *vphi = NULL;
+  for (gphi_iterator si = gsi_start_phis (join_bb); !gsi_end_p (si);
+   gsi_next (&si))
+if (virtual_operand_p (gimple_phi_result (si.phi (
+  {
+   vphi = si.phi ();
+   break;
+  }
+  if (!vphi)
 return false;
+  gimple *then_assign = SSA_NAME_DEF_STMT (PHI_ARG_DEF_FROM_EDGE
+   (vphi, single_succ_edge
(then_bb)));
+  gimple *else_assign = SSA_NAME_DEF_STMT (PHI_ARG_DEF_FROM_EDGE
+   (vphi, single_succ_edge
(else_bb)));
+
+  /* Verify there are no other stores or loads in the BBs.  That allows us
+ to elide dependence checking.  */
+  use_operand_p use_p;
+  imm_use_iterator imm_iter;
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vuse (then_assign))
+if (USE_STMT (use_p) != then_assign
+   && gimple_bb (USE_STMT (use_p)) == then_bb)
+  {
+   then_assign = NULL;
+   break;
+  }
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vuse (else_assign))
+if (USE_STMT (use_p) != else_assign
+   && gimple_bb (USE_STMT (use_p)) == else_bb)
+  {
+   else_assign = NULL;
+   break;
+  }

-  /* Handle the case with single statement in THEN_BB and ELSE_BB.  */
   if (then_assign && else_assign)
 return cond_if_else_store_replacement_1 (then_bb, else_bb, join_bb,
  then_assign, else_assign);

+  if (MAX_STORES_TO_SINK == 0)
+return false;
+
   /* Find data references.  */
   then_datarefs.create (1);
   else_datarefs.create (1);

[Bug tree-optimization/84859] [8 Regression] bogus -Warray-bounds on a memcpy in a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Like moving over a const call after the stores might cause us to spill across
the call.  Moving over any stmt could enlarge lifetimes enough to do that. 
Register
lifetime could be so that we cannot coalesce the copies in the PHI (but that
probably is offset by removing one of the stores -- but maybe the fast path
is slowed down then).

value_replacement has /* Allow up to 2 cheap preparation statements that
prepare argument ... */ for example.  But I guess preparation stmts are never
of a concern?

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Since r246954 we treat array prvalues like class prvalues.  So this
2054   if (!obvalue_p (exp)
2055   && ! (TREE_CODE (exp) == CONSTRUCTOR && TREE_STATIC (exp)))
2056 {
2057   if (complain & tf_error)
2058 error_at (loc, "invalid use of non-lvalue array");
2059   return error_mark_node;
2060 }
in decay_conversion no longer triggers because obvalue_p is now 1.
cp_build_addr_expr_1 says
If STRICT_LVALUE is true, require an lvalue; otherwise, allow xvalues
and class rvalues as well.
so I'm not sure if we should allow array rvalues too.  If not then perhaps

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5760,7 +5760,7 @@ build_nop (tree type, tree expr)

 /* Take the address of ARG, whatever that means under C++ semantics.
If STRICT_LVALUE is true, require an lvalue; otherwise, allow xvalues
-   and class rvalues as well.
+   and class and array rvalues as well.

Nothing should call this function directly; instead, callers should use
cp_build_addr_expr or cp_build_addr_expr_strict.  */
@@ -5842,7 +5842,9 @@ cp_build_addr_expr_1 (tree arg, bool strict_lvalue,
tsubst_flags_t complain)
   && TREE_CODE (argtype) != METHOD_TYPE)
 {
   cp_lvalue_kind kind = lvalue_kind (arg);
-  if (kind == clk_none)
+  if (kind == clk_none
+ || (kind == clk_class
+ && TREE_CODE (argtype) == ARRAY_TYPE))
{
  if (complain & tf_error)
lvalue_error (input_location, lv_addressof);

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Eh, never mind the first hunk then.

[Bug c/84883] New: No warning when dereferencing an array as a pointer

[tim.ruehsen at gmx dot de]

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

Bug ID: 84883
   Summary: No warning when dereferencing an array as a pointer
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

Created attachment 43669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43669&action=edit
Small test code

It would be nice to a warning (option) if accidentally dereferencing an array
instead of a pointer.

struct BCHAN bchan[5], *bchanp = bchan + 3;
bchanp->x = 1; // that's how it's supposed to be
bchan->x = 1; // arg, typo. but now bchan[0].x has been written

I experienced this in a pretty large codebase. This was causing *very* rare
weird behavior and it's detection was more of a lucky punch.

It is certainly valid C, but what a about an -Warray-deref ?

[Bug c++/84884] New: [DR 2244] [C++17] protected constructor and aggregate initialization of base

[jason at gcc dot gnu.org]

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

Bug ID: 84884
   Summary: [DR 2244] [C++17] protected constructor and aggregate
initialization of base
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Here we should accept f and g because we're using the protected constructor on
a base of a B object, so friendship makes it OK:

struct A {
protected:
  A();
};
struct B : A {
  friend B f();
  friend B g();
  friend B h();
};
B f() { return {}; } // ok
B g() { return {{}}; } // ok
B h() { return {A{}}; } // error

This will need significant changes to build_aggr_conv.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #8 from Zhendong Su  ---
> Can you please attach content of --save-temps?

$ gcctk -O3 -c --save-temps small.c
during RTL pass: dse1
small.c: In function ‘fn1’:
small.c:12:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc9006b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x1437b9c smallest_int_mode_for_size(poly_int<1u, unsigned long>)
../../gcc-source-trunk/gcc/machmode.h:842
0x1437b9c find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1701
0x1437b9c get_stored_val
../../gcc-source-trunk/gcc/dse.c:1847
0x143a4fc record_store
../../gcc-source-trunk/gcc/dse.c:1557
0x143b3a2 scan_insn
../../gcc-source-trunk/gcc/dse.c:2545
0x143c592 dse_step1
../../gcc-source-trunk/gcc/dse.c:2657
0x143c592 rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3574
0x143c592 execute
../../gcc-source-trunk/gcc/dse.c:3672
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 
$ cat small.i
# 1 "small.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "small.c"
int a;
long b[1][9];

void fn1 ()
{
  while (a)
{
  for (a = 0; a < 9; a++)
b[218][a] = 1;
  break;
}
}
$ cat small.s
.file   "small.c"
.text
$

[Bug c/84852] [8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1105

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Thu Mar 15 15:39:46 2018
New Revision: 258559

URL: https://gcc.gnu.org/viewcvs?rev=258559&root=gcc&view=rev
Log:
Fix testcase for PR c/84852

gcc/testsuite/ChangeLog:
PR c/84852
* gcc.dg/fixits-pr84852-1.c: Fix filename in dg-regexp.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/gcc.dg/fixits-pr84852-1.c

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
It is indeed a non-sensical combination, but I think last time we've determined
it isn't that easy to diagnose and/or silently fix up, the toplev.c diagnostics
can be bypassed through optimize attribute.

A quick hack out of this would be to add !flag_rounding_math to
can_reassociate_p next to flag_associative_math.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

[thopre01 at gcc dot gnu.org]

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

--- Comment #8 from Thomas Preud'homme  ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 43668 [details]
> gcc8-pr79085.patch
> 
> Untested fix.

That fixes the original testcase for me. Thanks!

[Bug fortran/84885] New: c_char bind length

[mdblack98 at yahoo dot com]

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

Bug ID: 84885
   Summary: c_char bind length
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdblack98 at yahoo dot com
  Target Milestone: ---

subroutine foo(i,c)
  use, intrinsic :: iso_c_binding, only: c_char
integer i

  type, bind(C) :: params_block
character(kind=c_char,len=10) :: c
  end type params_block
write(*,*) 'X',c,'Z'
end

This program fails to compile with gcc 8.0.1 20180304 -- but only if the
character declaration is inside a type block
Compiles fine with pre 8.0 compilers

gfortran -fPIC -g -c foo.f90
foo.f90:6:42:

 character(kind=c_char,len=10) :: c
  1
Error: Component 'c' of BIND(C) type at (1) must have length one

Mike

[Bug c/39808] warn_unused_result fails to produce warning in a statement expression

[dave.pagan at oracle dot com]

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

Dave Pagan  changed:

   What|Removed |Added

 CC||dave.pagan at oracle dot com

--- Comment #5 from Dave Pagan  ---
Anyone looking at this? If not, I'd like to.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[dave.pagan at oracle dot com]

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

--- Comment #6 from Dave Pagan  ---
Helpful update, Jonathan - did you want to follow up on this bug then? Or
should I go ahead based on your new information?

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
On the other side, the assumption that +/* of two REAL_CSTs can be always
folded isn't false just for -frounding-math, but also e.g. with IBM long double
(aka composite mode) and no -funsafe-math-optimizations.  So e.g.
long double
foo (long double x, long double y)
{
  long double a = 10e50;
  long double b = 10e-50;
  a = a + b;
  a = a + x;
  a = a + y;
  return a;
}
with -mlong-double-128 -O2 -fassociative-math -fno-trapping-math
-fno-signed-zeros --param tree-reassoc-width=2
also has 2 REAL_CSTs in there that can't be folded together.

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #2)
> Sorry, my bad.  It is easy to fix.  I think the patch will be ready today.

Unfortunately, this test also triggers more serious problem of my last patch
(r258504) which results in LRA cycling.  I think it will some time to fix the
problem but I hope it will be done on this week.

[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants

[amylaar at gcc dot gnu.org]

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

--- Comment #7 from Jorn Wolfgang Rennecke  ---
(In reply to jos...@codesourcery.com from comment #6)
> Since we have docstring relicensing maintainers, I don't think this is an 
> issue now.

Oops, that slipped my mind.  Indeed, we can consider this arrangement
to have fixed this issue.

[Bug target/84882] -mstrict-align on aarch64 should not be RejectNegative

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-15
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Wilco  ---
(In reply to Jakub Jelinek from comment #0)
> -mno-strict-align works on all targets that support -mstrict-align option,
> except aarch64.  Any reason for the RejectNegative in there?  From what I
> can see, it isn't the default on aarch64, and there is no way to undo an
> earlier flag on command line.

Confirmed, it doesn't make any sense. There are more options that should have
the no- variant enabled, eg. -mno-general-regs-only.

[Bug fortran/84885] c_char bind length

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to mdblack98 from comment #0)
> subroutine foo(i,c)
>   use, intrinsic :: iso_c_binding, only: c_char
> integer i
> 
>   type, bind(C) :: params_block
> character(kind=c_char,len=10) :: c

I see length of 10 here.

>   end type params_block
> write(*,*) 'X',c,'Z'
> end
> 
> This program fails to compile with gcc 8.0.1 20180304 -- but only if the
> character declaration is inside a type block
> Compiles fine with pre 8.0 compilers
> 
> gfortran -fPIC -g -c foo.f90
> foo.f90:6:42:
> 
>  character(kind=c_char,len=10) :: c
>   1
> Error: Component 'c' of BIND(C) type at (1) must have length one

From the F2018 standard,

18.3.2 Interoperability of intrinsic types

Table 18.2 shows the interoperability between Fortran intrinsic
types and C types.  A Fortran intrinsic type with particular type
parameter values is interoperable with a C type if the type and
kind type parameter value are listed in the table on the same row
as that C type.  If the type is character, the length type parameter
is interoperable if and only if its value is one.


C1806 (R726) Each component of a derived type with the BIND
attribute shall be a nonpointer, nonallocatable data component
with interoperable type and type parameters.

Your code is invalid, and the number constraint means
that gfortran must tell you about it.

[Bug go/84765] "cmd/go/internal/work/buildid.go" breaks for various non-English locales

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Thanks for the report.  I just committed a patch to fix this.

[Bug tree-optimization/84841] [7/8 Regression] ICE: tree check: expected ssa_name, have real_cst in rewrite_expr_tree_parallel, at tree-ssa-reassoc.c:4624

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 43670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43670&action=edit
gcc8-pr84841.patch

Untested fix.  The problem actually aren't the multiple REAL_CSTs, but the
artificial -1.0 added by try_special_add_to_ops which isn't reflected in the
original IL.  We rely on that one to be merged with other constants.
And, const_binop generally fails only for inexact computations, multiplication
by -1.0 or 1.0 should never be inexact.  So this patch just makes sure we sort
-1.0 (and 1.0 which has similar properties) last.

Another possibility would be to try harder if some const_binop fails, up to
O(n^2) attempts where n is the number of REAL_CSTs at the end of the ops list.
Even with -frounding-math or the IBM long double, we can be successful with
some foldings and not others.  Is that worth it though?

And, seems the sorting wasn't matching the comment:
/* We want integer ones to end up last no matter what, since they are
   the ones we can do the most with.  */
I must say I fail to see when we'd have constants of different types in the
same ops list, but the documentation says sort integers (i.e. the highest
constant_type values) last, but sorting function did the opposite.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[lopezibanez at gmail dot com]

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

--- Comment #7 from Manuel López-Ibáñez  ---
My advice would be to create a new option Wreturn-pedantic. Make this
option control the pedwarns that don't have any option. Then, enable it by
default, but also make it be enabled by Wpedantic and Wreturn-type.

An alternative would be to have the default setting of Wreturn-type depend
on flag_isoc99. Then, add OPT_Wreturn_type to all those pedwarns.

On Thu, 15 Mar 2018, 16:12 dave.pagan at oracle dot com, <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976
>
> --- Comment #6 from Dave Pagan  ---
> Helpful update, Jonathan - did you want to follow up on this bug then? Or
> should I go ahead based on your new information?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/84222] [6/7/8 Regression] [[deprecated]] class complains about internal class usage

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 15 17:45:01 2018
New Revision: 258568

URL: https://gcc.gnu.org/viewcvs?rev=258568&root=gcc&view=rev
Log:
PR c++/84222
* cp-tree.h (cp_warn_deprecated_use): Declare.
* tree.c (cp_warn_deprecated_use): New function.
* typeck2.c (build_functional_cast): Use it.
* decl.c (grokparms): Likewise.
(grokdeclarator): Likewise.  Temporarily push nested class scope
around grokparms call for out of class member definitions.

* g++.dg/warn/deprecated.C (T::member3): Change dg-warning to dg-bogus.
* g++.dg/warn/deprecated-6.C (T::member3): Likewise.
* g++.dg/warn/deprecated-13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/deprecated-13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/deprecated-6.C
trunk/gcc/testsuite/g++.dg/warn/deprecated.C