[Bug rtl-optimization/78579] New: redundant instruction of the form cmp r0, r0 generated in assembly with -O2

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 78579
   Summary: redundant instruction of the form cmp r0, r0 generated
in assembly with  -O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
While investigating PR78529, I came across the following issue:

For the test-case:
char *f(char *dest, char *src)
{
  if (__builtin_strcpy (dest + 5, src) != (dest + 5))
__builtin_abort ();
}

gcc -O2 generates following assembly:

f:
.LFB0:
.cfi_startproc
leaq5(%rdi), %rdx
subq$8, %rsp
.cfi_def_cfa_offset 16
movq%rdx, %rdi
callstrcpy
cmpq%rax, %rax
jne .L5
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L5:
.cfi_restore_state
callabort
.cfi_endproc

This seems to start after "pro_and_epligoue" pass, which contains
the following insn in it's dump:
(insn 14 29 15 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/f:DI 0 ax [orig:87 _1 ] [87])
(reg:DI 0 ax [92]))) "strcpy-foo.c":3 8 {*cmpdi_1}
 (nil))

full dump: http://pastebin.com/TGMRFGyw

Thanks,
Prathamesh

[Bug rtl-optimization/78546] [6 Regression] wrong code at -O2 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 29 07:48:43 2016
New Revision: 242953

URL: https://gcc.gnu.org/viewcvs?rev=242953=gcc=rev
Log:
2016-11-29  Richard Biener  

PR middle-end/78546
* match.pd: Add CST1 - (CST2 - A) -> CST3 + A missing case.

* gcc.dg/tree-ssa/forwprop-36.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-36.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug lto/78562] Wrong warning for built-in functions with -flto

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Mon, 28 Nov 2016, gjl at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562
> 
> --- Comment #5 from Georg-Johann Lay  ---
> Maybe it is an option to be less strict?  In the test case, both function name
> and asm name (libname) are in the namespace of the implementation: both start
> with 2 underscores.  The function name even starts with __builtin_...

Yes, as I said, being less strict and for example not diagnosing
this as if it were in "system headers" would probably work.

diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index ce9e146..cf53d62 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -655,6 +655,13 @@ lto_symtab_merge_decls_2 (symtab_node *first, bool 
diagnosed_p)
   /* Diagnose all mismatched re-declarations.  */
   FOR_EACH_VEC_ELT (mismatches, i, decl)
 {
+  /* Do not diagnose two built in declarations, there is no useful
+ location in that case.  It also happens spuriously for AVR,
+see PR78562.  */
+  if (DECL_IS_BUILTIN (prevailing->decl)
+ && DECL_IS_BUILTIN (decl))
+   continue;
+
   int level = warn_type_compatibility_p (TREE_TYPE 
(prevailing->decl),
 TREE_TYPE (decl),
 DECL_COMDAT (decl));

works for me for the testcase.  Can you give it some more testing
on your side and propose it on the mailing list?

[Bug rtl-optimization/78575] [7 Regression] ICE: in trunc_int_for_mode, at explow.c:55 with -O2 -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug rtl-optimization/78575] [7 Regression] ICE: in trunc_int_for_mode, at explow.c:55 with -O2 -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
fix_debug_reg_uses is just terribly broken.  Working on a fix.

[Bug fortran/78578] character(len=:),allocatable :: CStr(:)

[qingfeng198325 at 126 dot com]

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

--- Comment #2 from zengxiaoqing  ---
Program Main
  implicit none
  integer :: ins
  type str
 character(len=:),allocatable :: CStr(:)
   end type
   type(str) ::tstr

   allocate(character(len=20)::tstr%CStr(20))

   tstr%CStr(1) = "20"
   tstr%CStr(2:19) = " "
   tstr%CStr(20) ="30"

   print*,tstr%CStr(:)   !error
End Program Main

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
Note this needs at least:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html

And a few more match.pd changes to fully replace conditional_replacement.  I
hope to be able to get a full patch for the next stage 1.

[Bug target/77687] frame access after release without redzone on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Tue Nov 29 05:29:47 2016
New Revision: 242949

URL: https://gcc.gnu.org/viewcvs?rev=242949=gcc=rev
Log:
rs6000: Make deallocation of a large frame work (PR77687)

If we use ABI_V4 and we have a big stack frame, we end the epilogue
with a "mr 1,11" (or similar) instruction.  This instruction however
has no dependencies on the earlier restores from stack (done via r11),
so sched2 can end up reordering the insns, which is bad because we
have no red zone so that you then restore from stack that is already
deallocated.

This fixes it by making that restore depend on the memory accesses.


PR target/77687
* config/rs6000/rs6000.c (rs6000_emit_stack_reset): Emit the
stack_restore_tie insn instead of stack_tie, for the SVR4 and
SPE ABIs.
* config/rs6000/rs6000.md (stack_restore_tie): New define_insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug fortran/78578] character(len=:),allocatable :: CStr(:)

[kargl at gcc dot gnu.org]

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

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 ---
Rename your variable 'tstr'.

[Bug fortran/78578] New: character(len=:),allocatable :: CStr

[qingfeng198325 at 126 dot com]

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

Bug ID: 78578
   Summary: character(len=:),allocatable :: CStr
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qingfeng198325 at 126 dot com
  Target Milestone: ---

program Main
  implicit none
  integer :: ins
  type str
 character(len=:),allocatable :: CStr(:)
   end type
   type(str) ::tstr

   allocate(character(len=20)::tstr%CStr(20))

   tsrt%CStr(1) ="20"
   tsrt%CStr(20) ="30"

   print*,tsrt%CStr(:)   !error


end program

[Bug libfortran/78549] Very slow formatted internal file output

[mecej4 at operamail dot com]

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

--- Comment #4 from mecej4 at operamail dot com ---
(In reply to Jerry DeLisle from comment #3)
> We cannot address the Windows(+Cygwin,Mingw,etc.) issues which have more to
> do with the OS related layers I assume.
> 
> I will see what I get on Cygwin and report back in a few days.

Fair enough. For what it is worth, here are timings for the same test programs
built with Gfortran/GCC 6.2.0 under Windows Subsystem for Linux (Ubuntu 14) on
Windows-10:

   GCC 6.2.0  : 1.984 s
   GFortran 6.2.0 : 8.438 s

[Bug rtl-optimization/78342] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2657 (error: flow control insn inside a basic block)

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Tue Nov 29 02:02:45 2016
New Revision: 242947

URL: https://gcc.gnu.org/viewcvs?rev=242947=gcc=rev
Log:
combine: Make code after a new trap unreachable (PR78342)

Combine can turn a conditional trap into an unconditional trap.  If it
does that it should make the code after it unreachable (an unconditional
trap should be the last insn in its bb, and that bb has no successors).

This patch seems to work.  It is hard to be sure, this is very hard to
trigger.  Quite a few other passes look like they need something similar
as well, but I don't see anything else handling it yet either.


PR rtl-optimization/78342
* combine.c: Include "cfghooks.h".
(try_combine): If we create an unconditional trap, break the basic
block in two just after it, and remove the edge between; also, set
the *new_direct_jump_p flag so that cleanup_cfg is run.

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

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 40185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40185=edit
The start of the patch

Note this is just a start of the rewrite.  It needs improvement as it started
out really part of another patch which added a generic (non-loop based) ifcvt
to the tree level.  But I wanted to get it recorded somewhere so I don't lose
it again.  Note the problem I mentioned in comment #8 I don't hit any more.

[Bug target/78577] New: Fix define_insn operand types for vexturhlx, vexturhrx, vextuwlx, and vextuwrx patterns

[kelvin at gcc dot gnu.org]

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

Bug ID: 78577
   Summary: Fix define_insn operand types for vexturhlx,
vexturhrx, vextuwlx, and vextuwrx patterns
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

In each of these define_insn patterns, operand 2 is currently described as
having type V16QI.  Though the existing patterns correctly generate the
intended code through the use of implicit type coercions, the patterns as
currently written are confusing and unclear.  The half-word patterns should
constrain operand 2 to be of type V8HI, and the full-word patterns should
constrain operand 2 to be of type V4SI.

[Bug c/78568] [4.5 Regression] Wtype-limits warning regression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|Wtype-limits warning|[4.5 Regression]
   |regression  |Wtype-limits warning
   ||regression

--- Comment #2 from Martin Sebor  ---
If my revision numbers are accurate r145256 was introduced in GCC 4.5.

[Bug c/78568] Wtype-limits warning regression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-29
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The last revision that emits the warnings below is r145245.  The
first one that doesn't is r145256:

cc1.145245: warnings being treated as errors
t.c: In function ‘testa’:
t.c:4: error: comparison is always true due to limited range of data type
t.c: In function ‘testb’:
t.c:13: error: comparison is always true due to limited range of data type
t.c: In function ‘testc’:
t.c:21: error: comparison is always true due to limited range of data type

[Bug c++/78572] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4968

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-29
 CC||msebor at gcc dot gnu.org
Summary|internal compiler error: in |[6/7 Regression] internal
   |output_constructor_regular_ |compiler error: in
   |field, at varasm.c:4968 |output_constructor_regular_
   ||field, at varasm.c:4968
 Ever confirmed|0   |1
  Known to fail||6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r234636 as the change that caused it.  Looks
like it's a 6/7 regression, though designated initializers don't fully work in
G++.

(gcc 6.0.0) failed (status 4):

r234636 | nathan | 2016-03-31 11:30:33 -0400 (Thu, 31 Mar 2016) | 11 lines

PR c++/70393
* varasm.c (output_constructor_regular_field): Flush bitfield
earlier.  Assert we don't want to move backwards.

cp/
* constexpr.c (cxx_eval_store_expression): Keep CONSTRUCTOR
elements in field order.

testsuite/
* g++.dg/cpp0x/constexpr-virtual6.C: New.


The full stack trace is below:

t.C:7:1: internal compiler error: in output_constructor_regular_field, at
varasm.c:4989
 }
 ^
0x148b5bf output_constructor_regular_field
../../gcc/varasm.c:4989
0x148c3a5 output_constructor
../../gcc/varasm.c:5297
0x148aaf4 output_constant
../../gcc/varasm.c:4794
0x1482165 assemble_variable_contents
../../gcc/varasm.c:2083
0x1482bbf assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2259
0x149a0bc varpool_node::assemble_decl()
../../gcc/varpool.c:588
0xbab20d output_in_order
../../gcc/cgraphunit.c:2248
0xbab8d2 symbol_table::compile()
../../gcc/cgraphunit.c:2488
0xbabb1b symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2584
Please submit a full bug report,

[Bug rtl-optimization/78575] [7 Regression] ICE: in trunc_int_for_mode, at explow.c:55 with -O2 -g

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-29
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection identified r239378 as the first revision to ICE:

r239378 (gcc 7.0.0) failed (status 4):

r239378 | hjl | 2016-08-11 11:51:01 -0400 (Thu, 11 Aug 2016) | 21 lines

Use TImode for piecewise move in 64-bit mode

Use TImode for piecewise move in 64-bit mode.  We should use TImode in
32-bit mode and use OImode or XImode if they are available.  But since
by_pieces_ninsns determines the widest mode with MAX_FIXED_MODE_SIZE,
we can only use TImode in 64-bit mode.

gcc/

* config/i386/i386.h (MOVE_MAX_PIECES): Use TImode in 64-bit
mode if unaligned SSE load and store are optimal.

[Bug c/78574] [7 Regression] ice on valid C code at -O2 and -O3 in both 32- and 64-bit modes on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1))

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.2.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-11-29
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ice on valid C code at -O2  |[7 Regression] ice on valid
   |and -O3 in both 32- and |C code at -O2 and -O3 in
   |64-bit modes on |both 32- and 64-bit modes
   |x86_64-linux-gnu (internal  |on x86_64-linux-gnu
   |compiler error: |(internal compiler error:
   |Segmentation fault (program |Segmentation fault (program
   |cc1))   |cc1))
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r238242 as the first change with which the ICE
occurs.

r238242 | rguenth | 2016-07-12 09:32:04 -0400 (Tue, 12 Jul 2016) | 48 lines

2016-07-12  Steven Bosscher  
Richard Biener  

PR tree-optimization/23286
PR tree-optimization/70159
* doc/invoke.texi: Document -fcode-hoisting.
* common.opt (fcode-hoisting): New flag.
* opts.c (default_options_table): Enable -fcode-hoisting at -O2+.
* tree-ssa-pre.c (pre_stats): Add hoist_insert.
(do_regular_insertion): Rename to ...
(do_pre_regular_insertion): ... this and amend general comments
on insertion strathegy.
(do_partial_partial_insertion): Rename to ...
(do_pre_partial_partial_insertion): ... this.
(do_hoist_insertion): New function.
(insert_aux): Take flags on whether to do PRE and/or hoist insertion
and call do_hoist_insertion properly.
(insert): Adjust.
(pass_pre::gate): Enable also if -fcode-hoisting is enabled.
(pass_pre::execute): Register hoist_insert stats.

[Bug libgcc/62097] t-hardfp requires GNU sed

[chrisj at rtems dot org]

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

Chris Johns  changed:

   What|Removed |Added

 CC||chrisj at rtems dot org

--- Comment #10 from Chris Johns  ---
This issue is still present on FreeBSD 10.3 and gcc-6-20161110 when building:

mips-rtems4.12-gcc-6-20161110-newlib-2.4.0.20161025-x86_64-freebsd10.3-1

[Bug fortran/78573] ICE in resolve_component, at fortran/resolve.c:13405

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> Appeared between 20161023 (no ICE) and 20161030, with invalid code :

Are you sure of the range? I get the ICE or "(null):0: confused by earlier
errors, bailing out" from 4.8 up to trunk (7.0).

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  ---
Why do you think this isn't a lack of accuracy?  Floating to integer always
truncates.

[Bug fortran/78570] ICE in free_expr0, at fortran/expr.c:494

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug fortran/78571] ICE in create_character_initializer, at fortran/data.c:191

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0). Note the ICE is gone if I comment the
line

   data x /'b'/

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #3 from Peter Bergner  ---
(In reply to Andreas Schwab from comment #2)
> Why do you think 27 is wrong?

It was a typo.  He meant to say it prints 26 rather than the expected 27.

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
Why do you think 27 is wrong?

[Bug libgcc/78576] [PPC] wrong long double to long int conversion

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
The conversion is done by __fixtfdi in libgcc.

[Bug libgcc/78576] New: [PPC] wrong long double to long int conversion

[brenohl at br dot ibm.com]

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

Bug ID: 78576
   Summary: [PPC] wrong long double to long int conversion
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brenohl at br dot ibm.com
  Target Milestone: ---

On ppc64le environment, I am facing an wrong conversion between long double and
long int.

This is my test case, which prints 27 instead of 26.

#include
#include

int main (){
long double a = 3;
long double b = 3;

long c = powl(a,b);
printf("%d\n", c);


}

It does not seem to be a rounding issue, since fesetround() is not affecting
the result.

I also changed the optimization levels, and it is not affecting the result.

[Bug middle-end/67335] [6 Regression] ICE in compiling omp simd function with unused argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |compiling omp simd function |compiling omp simd function
   |with unused argument|with unused argument

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

[Bug target/71331] target-tilegx: nested-function-4.c: r10 is conflict which is both in function frame and in parameter.

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
Fixed by Chen's patch for the trunk.

[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] ICE: in|[6 Regression] ICE: in
   |df_refs_verify, at  |df_refs_verify, at
   |df-scan.c:4062 with -O  |df-scan.c:4062 with -O
   |-march=core2|-march=core2
  Known to fail|7.0 |

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

[Bug middle-end/78540] [6/7 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 28 22:51:29 2016
New Revision: 242937

URL: https://gcc.gnu.org/viewcvs?rev=242937=gcc=rev
Log:
PR middle-end/78540
* rtl.h (remove_reg_equal_equiv_notes): Return bool instead of void.
* rtlanal.c (remove_reg_equal_equiv_notes): Return true if any
note has been removed.
* postreload.c (reload_combine_recognize_pattern): If
remove_reg_equal_equiv_notes returns true, call df_notes_rescan.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr78540.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload.c
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
(In reply to Breno Leitao from comment #7)
> Created attachment 40182 [details]
> gcc dump with pre processed file

Ok, this on I have recreated.  I'll dig into it.

[Bug rtl-optimization/78575] New: [7 Regression] ICE: in trunc_int_for_mode, at explow.c:55 with -O2 -g

[zsojka at seznam dot cz]

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

Bug ID: 78575
   Summary: [7 Regression] ICE: in trunc_int_for_mode, at
explow.c:55 with -O2 -g
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -g testcase.c -Wno-psabi
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: in trunc_int_for_mode, at explow.c:55
 }
 ^
0x900b60 trunc_int_for_mode(long, machine_mode)
/repo/gcc-trunk/gcc/explow.c:54
0x8f0bf8 gen_int_mode(long, machine_mode)
/repo/gcc-trunk/gcc/emit-rtl.c:495
0xc75475 simplify_binary_operation_1
/repo/gcc-trunk/gcc/simplify-rtx.c:2399
0xc7c03d simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:2068
0xc7fd98 simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:5022
0xc8074c simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:4578
0x84da11 cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1823
0x84e71e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/repo/gcc-trunk/gcc/cselib.c:1530
0xf8b7dd vt_expand_var_loc_chain
/repo/gcc-trunk/gcc/var-tracking.c:8326
0xf8b7dd vt_expand_loc_callback
/repo/gcc-trunk/gcc/var-tracking.c:8488
0x84d7ea cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1684
0x84e71e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/repo/gcc-trunk/gcc/cselib.c:1530
0xf8b7dd vt_expand_var_loc_chain
/repo/gcc-trunk/gcc/var-tracking.c:8326
0xf8b7dd vt_expand_loc_callback
/repo/gcc-trunk/gcc/var-tracking.c:8488
0x84d48a cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1722
0x84e71e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/repo/gcc-trunk/gcc/cselib.c:1530
0xf8b7dd vt_expand_var_loc_chain
/repo/gcc-trunk/gcc/var-tracking.c:8326
0xf8b7dd vt_expand_loc_callback
/repo/gcc-trunk/gcc/var-tracking.c:8488
0x84d7ea cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1684
0x84e71e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/repo/gcc-trunk/gcc/cselib.c:1530
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242931-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242931-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161128 (experimental) (GCC) 

Tested revisions:
trunk r242931 - FAIL
6-branch r242029 - OK

[Bug c/78574] New: ice on valid C code at -O2 and -O3 in both 32- and 64-bit modes on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1))

[chengniansun at gmail dot com]

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

Bug ID: 78574
   Summary: ice on valid C code at -O2 and -O3 in both 32- and
64-bit modes on x86_64-linux-gnu (internal compiler
error: Segmentation fault (program cc1))
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161128 (experimental) [trunk revision 242906] (GCC) 
$ 
$ gcc-trunk -O3 small.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ cat small.c
int a, d, f, g;
int b[1];
short h;
int main() {
  long j;
  int k, i;
  for (; j; j++) {
i = 0;
for (; i < 6; i++) {
  int l = a, m = d || g;
L:
  l ^ m | a;
}
b[j + 1] = 2;
++k;
for (; g; g++) {
  d ^= h;
  if (f)
for (;;)
  ;
}
  }
  if (k)
goto L;
}
$

[Bug middle-end/78520] missing warning for snprintf with size greater than INT_MAX

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Warning added in r242935.

[Bug middle-end/78521] [7 Regression] incorrect byte count in -Wformat-length warning with non-constant width or precision

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed in r242935.

[Bug middle-end/78520] missing warning for snprintf with size greater than INT_MAX

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Mon Nov 28 21:41:41 2016
New Revision: 242935

URL: https://gcc.gnu.org/viewcvs?rev=242935=gcc=rev
Log:
PR middle-end/78521 - [7 Regression] incorrect byte count in -Wformat-length
warning with non-constant width or precision
PR middle-end/78520 - missing warning for snprintf with size greater than
INT_MAX

gcc/ChangeLog:

PR middle-end/78520
* gimple-ssa-sprintf.c (target_max_value): Remove.
(target_int_max, target_size_max): Use TYPE_MAX_VALUE.
(get_width_and_precision): New function.
(format_integer, format_floating, get_string_length, format_string):
Correct handling of width and precision with unknown value.
(format_directive): Add warning.
(pass_sprintf_length::compute_format_length): Allow for precision
to consist of a sole period with no asterisk or digits after it.

gcc/testsuite/ChangeLog:

PR middle-end/78520
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-6.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Add test cases.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c

[Bug middle-end/78521] [7 Regression] incorrect byte count in -Wformat-length warning with non-constant width or precision

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Mon Nov 28 21:41:41 2016
New Revision: 242935

URL: https://gcc.gnu.org/viewcvs?rev=242935=gcc=rev
Log:
PR middle-end/78521 - [7 Regression] incorrect byte count in -Wformat-length
warning with non-constant width or precision
PR middle-end/78520 - missing warning for snprintf with size greater than
INT_MAX

gcc/ChangeLog:

PR middle-end/78520
* gimple-ssa-sprintf.c (target_max_value): Remove.
(target_int_max, target_size_max): Use TYPE_MAX_VALUE.
(get_width_and_precision): New function.
(format_integer, format_floating, get_string_length, format_string):
Correct handling of width and precision with unknown value.
(format_directive): Add warning.
(pass_sprintf_length::compute_format_length): Allow for precision
to consist of a sole period with no asterisk or digits after it.

gcc/testsuite/ChangeLog:

PR middle-end/78520
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-6.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Add test cases.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c

[Bug libfortran/78549] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
We cannot address the Windows(+Cygwin,Mingw,etc.) issues which have more to do
with the OS related layers I assume.

I will see what I get on Cygwin and report back in a few days.

[Bug target/74748] libgcc_s.so.1 isn't created correctly for Blackfin FDPIC

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/74748] libgcc_s.so.1 isn't created correctly for Blackfin FDPIC

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Mon Nov 28 21:30:40 2016
New Revision: 242934

URL: https://gcc.gnu.org/viewcvs?rev=242934=gcc=rev
Log:
PR gcc/74748
* libgcc/config/bfin/libgcc-glibc.ver, libgcc/config/bfin/t-linux:
use generic linker version information on Blackfin.

2016-11-27  Iain Sandoe  

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/bfin/libgcc-glibc.ver
trunk/libgcc/config/bfin/t-linux

[Bug target/74748] libgcc_s.so.1 isn't created correctly for Blackfin FDPIC

[law at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Mon Nov 28 21:27:47 2016
New Revision: 242933

URL: https://gcc.gnu.org/viewcvs?rev=242933=gcc=rev
Log:
PR gcc/74748
* libgcc/mkmap-symver.awk: add support for skip_underscore

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/mkmap-symver.awk

[Bug c++/77591] [6 Regression] decltype(auto) and ternary operator allow returning local reference without a warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression]|[6 Regression]
   |decltype(auto) and ternary  |decltype(auto) and ternary
   |operator allow returning|operator allow returning
   |local reference without a   |local reference without a
   |warning |warning
  Known to fail|7.0 |

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

[Bug rtl-optimization/78546] [6 Regression] wrong code at -O2 and above

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression] wrong code |[6 Regression] wrong code
   |at -O2 and above|at -O2 and above
  Known to fail|7.0 |

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

[Bug c++/72808] [6 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE on |[6 Regression] ICE on valid
   |valid c++ code in   |c++ code in verify_type
   |verify_type |(gcc/tree.c:14047)
   |(gcc/tree.c:14047)  |

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

[Bug c/78498] [7 Regression] valgrind conditional jump or move depends on uninitialised value(s) in format_type_warning

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Fix would seem to be to use strnlen within xstrndup; libiberty has a strnlen.

[Bug c/78498] [7 Regression] valgrind conditional jump or move depends on uninitialised value(s) in format_type_warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Seems to resemble:
  http://austingroupbugs.net/view.php?id=1019
   "0001019: strndup shouldn't require source array to be null-terminated"

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 40183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40183=edit
revert part of r242745 for strcat, strcat_chk, strncat, strncat_chk

Hi,
Unfortunately I haven't been able to reproduce the issue on aarch64-none-elf
with (almost) identical configure opts with make-check,
and neither did it get caught by our validation matrix.
I would be grateful for suggestions on how to build strcat-chk.c standalone.
It seems it depends on lib/chk.c and possibly other files ?
I tried a few approaches but none of them worked :/

Regarding the code-gen difference "cmp x0, x0", I have verified that is not
caused by my patch.
The same can be reproduced with the following test-case before r242745.

char *f(char *dest, char *src)
{
  if (__builtin_strcpy (dest + 5, src) != (dest + 5))
__builtin_abort ();
}

-O2 shows following assembly for aarch64-none-elf:
f:
add x2, x0, 5
stp x29, x30, [sp, -16]!
mov x0, x2
add x29, sp, 0
bl  strcpy
cmp x0, x0
bne .L5
ldp x29, x30, [sp], 16
ret

This seems to start after "pro_and_epilogue" pass, which probably realizes
strcpy returns 1st arg.
The dump of the pass contains the following insn:
(insn 13 36 14 2 (set (reg:CC 66 cc)
(compare:CC (reg/f:DI 0 x0 [orig:73 _1 ] [73])
(reg:DI 0 x0))) "foo2.c":3 393 {cmpdi}
 (nil))

Full dump: http://pastebin.com/sUmg09SK

Apparently, this is also observed on x86_64-unknown-linux-gnu:
f:
.LFB0:
.cfi_startproc
leaq5(%rdi), %rdx
subq$8, %rsp
.cfi_def_cfa_offset 16
movq%rdx, %rdi
callstrcpy
cmpq%rax, %rax
jne .L5
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret

The reason it started showing up this for strcat/strcat_chk is because r242745
changed attribute of BUILT_IN_STRCAT_CHK
and BUILT_IN_STRCAT from ATTR_NOTHROW_NONNULL_LEAF to
ATTR_RET1_NOTHROW_NONNULL_LEAF, which is same as for strcpy.
Could you check if reverting that change (attached patch), doesn't cause the
issue ?

Thanks,
Prathamesh

[Bug c/78498] [7 Regression] valgrind conditional jump or move depends on uninitialised value(s) in format_type_warning

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-28
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed.

I don't think it's a dup of bug 78324, though.

c-format.c gets the line via input.c, then has:

3345 Generate a trimmed copy, containing the prefix part of the
conversion
3346 specification, up to the (but not including) the length modifier.
3347 In the above example, this would be "%-+*.*".  */
3348  const char *current_content = line + start.column - 1;
3349  int length_up_to_type = caret.column - start.column;
3350  char *prefix = xstrndup (current_content, length_up_to_type);

leading to a call to xstrndup.

xstrndup has:

47  char *
48  xstrndup (const char *s, size_t n)
49  {
50char *result;
51size_t len = strlen (s);
52  
53if (n < len)
54  len = n;

The uninit read happens within the call to strlen at line 51.

I was surprised to see that strlen within xstrndup; I was expecting it to
simply use "n".

input.c doesn't zero-terminate the strings fed in, so presumably that strlen
call is reading arbitrary data past the end of the allocation until it hits a
zero - but then the result is ignored, since the conditional at line 53 will
always hold.

[Bug target/71293] [7 regression] test case gcc.dg/plugin/must-tail-call-2.c fails starting with r236514

[seurer at linux dot vnet.ibm.com]

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

--- Comment #2 from Bill Seurer  ---
From old logs it appears these started working back in June sometime

Regressions on trunk (power8) at revision 237314 vs revision 237309

New passes:
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 32)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 39)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 57)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so
(test for excess errors)

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[brenohl at br dot ibm.com]

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

--- Comment #7 from Breno Leitao  ---
Created attachment 40182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40182=edit
gcc dump with pre processed file

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
(In reply to Breno Leitao from comment #5)
> I can reproduce this (or a very similar version of this) bug on my system. 
> 
> I am seeing this failure when compiling package yadifa-2.2.2 on Debian
> testing with (Debian 6.2.1-4) 6.2.1 20161119.
> 
> If I use -O2 instead of -O3, I see no failure.

Can you attach the preprocessed source of the file that is failing?

[Bug fortran/78573] New: ICE in resolve_component, at fortran/resolve.c:13405

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78573
   Summary: ICE in resolve_component, at fortran/resolve.c:13405
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Appeared between 20161023 (no ICE) and 20161030, with invalid code :


$ cat z1.f90
program p
   type t1
  class(t2), pointer :: q(2)
   end type
end


$ gfortran-7-20161127 z1.f90
z1.f90:3:32:

   class(t2), pointer :: q(2)
1
Error: Pointer array component of structure at (1) must have a deferred shape
z1.f90:3:32:

   class(t2), pointer :: q(2)
1
Error: The pointer component 'q' of 't1' at (1) is a type that has not been
declared
z1.f90:1:9:

 program p
 1
Error: Argument 'src' of '_copy' with PASS(src) at (1) must be of the derived
type '__class_p_T2_1_0p'
z1.f90:1:9:

 program p
 1
Error: Argument 'array' of '_final' with PASS(array) at (1) must be of the
derived type '__class_p_T2_1_0p'
f951: internal compiler error: Segmentation fault
0xc4532f crash_signal
../../gcc/toplev.c:333
0x7019ca resolve_component
../../gcc/fortran/resolve.c:13405
0x701c6a resolve_fl_derived0
../../gcc/fortran/resolve.c:13735
0x702037 resolve_fl_derived0
../../gcc/fortran/resolve.c:13119
0x702037 resolve_fl_derived
../../gcc/fortran/resolve.c:13812
0x6fce07 resolve_symbol
../../gcc/fortran/resolve.c:14143
0x716fbb do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x6fffba resolve_types
../../gcc/fortran/resolve.c:15945
0x6fbb0c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16058
0x6e609a resolve_all_program_units
../../gcc/fortran/parse.c:5977
0x6e609a gfc_parse_file()
../../gcc/fortran/parse.c:6224
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/78571] New: ICE in create_character_initializer, at fortran/data.c:191

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78571
   Summary: ICE in create_character_initializer, at
fortran/data.c:191
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 (with --enable-checking=yes).
A different facet; ICE does not depend on compile options, nor on locale.
Potentially related to pr70070.


$ cat z1.f90
program p
   type t
  character :: c
   end type
   character :: x = t('a')
   data x /'b'/
end


$ gfortran-7-20161127 z1.f90
z1.f90:5:19:

character :: x = t('a')
   1
Error: Can't convert TYPE(t) to CHARACTER(1) at (1)
f951: internal compiler error: Segmentation fault
0xc4532f crash_signal
../../gcc/toplev.c:333
0x678c32 create_character_initializer
../../gcc/fortran/data.c:191
0x678c32 gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1])
../../gcc/fortran/data.c:488
0x6f5779 check_data_variable
../../gcc/fortran/resolve.c:15032
0x6f5779 traverse_data_var
../../gcc/fortran/resolve.c:15161
0x700181 resolve_data
../../gcc/fortran/resolve.c:15216
0x700181 resolve_types
../../gcc/fortran/resolve.c:15970
0x6fbb0c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16058
0x6e609a resolve_all_program_units
../../gcc/fortran/parse.c:5977
0x6e609a gfc_parse_file()
../../gcc/fortran/parse.c:6224
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug c++/78572] New: internal compiler error: in output_constructor_regular_field, at varasm.c:4968

[comer352l at googlemail dot com]

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

Bug ID: 78572
   Summary: internal compiler error: in
output_constructor_regular_field, at varasm.c:4968
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: comer352l at googlemail dot com
  Target Milestone: ---

static int array[10] = { array[3]=5, array[7]=3, };

int main ()
{
return 0;
}

=> leads to the following compilation error:

main.c:7:1: internal compiler error: in output_constructor_regular_field, at
varasm.c:4968
 }
 ^
Please submit a full bug report

[Bug fortran/78570] New: ICE in free_expr0, at fortran/expr.c:494

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78570
   Summary: ICE in free_expr0, at fortran/expr.c:494
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Follow-up of pr78479 :


$ cat z1.f90
program p
   type t
  character(3) :: c(2) = 'a' // ['b', 'c']
   end type
   type(t) :: z
   print *, size(z%c), len(z%c), z
end


$ cat z2.f90
program p
   type t
  character(2) :: c(2) = '' // ['a']
   end type
   type(t) :: z
   print *, size(z%c), len(z%c), z
end


$ gfortran-7-20161127 z1.f90
f951: internal compiler error: free_expr0(): Bad expr type
0x68ea6f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1327
0x68f7cb free_expr0
../../gcc/fortran/expr.c:494
0x68f81d gfc_free_expr(gfc_expr*)
../../gcc/fortran/expr.c:513
0x71b273 gfc_free_charlen(gfc_charlen*, gfc_charlen*)
../../gcc/fortran/symbol.c:3840
0x71b349 gfc_free_namespace(gfc_namespace*)
../../gcc/fortran/symbol.c:3890
0x71b89c gfc_symbol_done_2()
../../gcc/fortran/symbol.c:3926
0x6c33d8 gfc_done_2()
../../gcc/fortran/misc.c:264
0x6e61f6 translate_all_program_units
../../gcc/fortran/parse.c:6057
0x6e61f6 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[brenohl at br dot ibm.com]

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

Breno Leitao  changed:

   What|Removed |Added

 CC||brenohl at br dot ibm.com

--- Comment #5 from Breno Leitao  ---
I can reproduce this (or a very similar version of this) bug on my system. 

I am seeing this failure when compiling package yadifa-2.2.2 on Debian testing
with (Debian 6.2.1-4) 6.2.1 20161119.

If I use -O2 instead of -O3, I see no failure.

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

Version|6.0 |7.0

--- Comment #6 from Gerhard Steinmetz  
---
gfortran-7-20161127 (configured with --enable-checking=yes) also ICEs
for all posted and unposted tests, with different messages.
Special backtrace from comment 4 is not reproducible with 7.
Apart from that, there is another variant, using LANG=de_DE.UTF-8 :


$ cat z2.f90
program p
   integer :: i
   character(10) :: c
   data (c(i:i), i=1,100) /100*'c'/
end


$ gfortran-7-20161127 z2.f90
f951: internal compiler error: Speicherzugriffsfehler
0xc4532f crash_signal
../../gcc/toplev.c:333
0x67803e formalize_init_expr
../../gcc/fortran/data.c:642
0x716fbb do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x7001c3 resolve_types
../../gcc/fortran/resolve.c:15973
0x6fbb0c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16058
0x6e609a resolve_all_program_units
../../gcc/fortran/parse.c:5977
0x6e609a gfc_parse_file()
../../gcc/fortran/parse.c:6224
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202


With LANG=C :

$ gfortran-7-20161127 z2.f90
*** Error in
`/home/gst/gcc/gcc-7-20161127-oyd/lib/gcc/x86_64-pc-linux-gnu/7.0.0/f951':
corrupted double-linked list: 0x03e0f690 ***
# hangs

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is also the same issue as PR 78498.

[Bug c++/72808] [6/7 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 28 19:20:02 2016
New Revision: 242930

URL: https://gcc.gnu.org/viewcvs?rev=242930=gcc=rev
Log:
PR c++/72808
* decl.c (finish_enum_value_list): Call fixup_type_variants on
current_class_type after
insert_late_enum_def_into_classtype_sorted_fields.

* g++.dg/debug/pr72808.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr72808.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 28 19:15:51 2016
New Revision: 242929

URL: https://gcc.gnu.org/viewcvs?rev=242929=gcc=rev
Log:
PR rtl-optimization/78546
* simplify-rtx.c (neg_const_int): When negating most negative
number in mode wider than HOST_BITS_PER_WIDE_INT, use
simplify_const_unary_operation to produce CONST_DOUBLE or
CONST_WIDE_INT.
(simplify_plus_minus): Hanlde the case where neg_const_int
doesn't return a CONST_INT.

* gcc.dg/torture/pr78546-1.c: New test.
* gcc.dg/torture/pr78546-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr78546-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr78546-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
that was binutils 2.27.51.20161124, and the Debian GCC version (unstable),
configured with
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.1-5ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-objc-gc --enable-secureplt --with-cpu=power8
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch
--disable-werror --with-long-double-128 --enable-checking=release
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu

[Bug tree-optimization/78512] [7 Regression] r242674 miscompiles Linux kernel

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
I wonder if we just need to bite the bullet and decide that %p is too system
dependent, particularly when performing optimization.

[Bug lto/78562] Wrong warning for built-in functions with -flto

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
Maybe it is an option to be less strict?  In the test case, both function name
and asm name (libname) are in the namespace of the implementation: both start
with 2 underscores.  The function name even starts with __builtin_...

[Bug target/78556] config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value -12301

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Fixed on trunk.

[Bug target/78556] config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value -12301

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Author: trippels
Date: Mon Nov 28 18:33:19 2016
New Revision: 242928

URL: https://gcc.gnu.org/viewcvs?rev=242928=gcc=rev
Log:
Fix PR78556 - left shift of negative values

Running bootstrap-ubsan on ppc64le shows many instances of e.g.:
 config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value
-12301

PR target/78556
* config/rs6000/rs6000.c (vspltis_constant): Add casts to avoid
left shifting of negative values.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug rtl-optimization/78547] [7 Regression] ICE: in loc_cmp, at var-tracking.c:3417 with -Os -g -mstringop-strategy=libcall -freorder-blocks-algorithm=simple

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org,
   ||ienkovich at gcc dot gnu.org

--- Comment #2 from James Greenhalgh  ---
I'd be surprised if r238594 was the root cause, but it may have exposed
something latent. This revision changed the cost model for if conversion,
effectively disabling it in this testcase. You can emulate turning off
if-conversion for the testcase with -fno-if-conversion on the command line.
Adding that, you can continue the bisect further back until r237647 which looks
more probable given the testcase body.

I'm now compiling with:

  -Os -g -mstringop-strategy=libcall -freorder-blocks-algorithm=simple
-fdump-rtl-all-all -fno-if-conversion


Author: hjl 
Date:   Tue Jun 21 14:24:31 2016 +

Convert V1TImode register to TImode in debug insn

TImode register referenced in debug insn can be converted to V1TImode
by scalar to vector optimization.  After converting a TImode register
to V1TImode, we need to check all debug insns on its use chain to
convert the V1TImode register to SUBREG TImode.

gcc/

2016-06-21  H.J. Lu  
Ilya Enkovich  

PR target/71549
* config/i386/i386.c (timode_scalar_chain::fix_debug_reg_uses):
New member function to convert V1TImode register to SUBREG
TImode in debug insn.
(timode_scalar_chain::convert_insn): Call fix_debug_reg_uses
after changing register mode to V1TImode.

gcc/testsuite/

2016-06-21  H.J. Lu  

PR target/71549
* gcc.target/i386/pr71549.c: New test.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@237647

[Bug fortran/78298] ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 28 17:31:37 2016
New Revision: 242926

URL: https://gcc.gnu.org/viewcvs?rev=242926=gcc=rev
Log:
PR fortran/78298
* tree-nested.c (convert_local_reference_stmt): After adding
shared (FRAME.NN) clause to omp parallel, task or target,
add it also to all outer omp parallel, task or target constructs.

* gfortran.dg/gomp/pr78298.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr78298.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nested.c

[Bug middle-end/78540] [6/7 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
I cannot recreate this using r242827 of the FSF 6 branch.  What configure
options are you using?   ...and in case it makes a difference (it can), what
binutils version?

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
I just tried reproducing the earlier bug with my gcc build and failed to get
the ICE, so I assume this is a different problem despite also getting "internal
compiler error: in get_substring_ranges_for_loc, at input.c:13xx".

I opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78569, which is seems
related to a buffer overflow in sprintf(), which is similar to the one here,
but as far as I can tell, this one doesn't overflow as we print an 'unsigned
char' variable into a five-byte string.

[Bug lto/78562] Wrong warning for built-in functions with -flto

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
(In reply to rguent...@suse.de from comment #3)
> Yes, using aliases would be a good workaround.

hmmm, for libgcc functions written in asm this is easy enough, like

.global func1_alias
.global func1

func1_alias:
func1:
   ;; asm-code

But how can I define an extra symbol for a libgcc function if that function is
written in C? E.g. __countlshi2 from libgcc/config/avr/lib2funcs.c.

[Bug c++/78313] [7 Regression] Misleading spelling suggestion

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
(See also bug 78504)

[Bug c++/78504] Bad fixit hint: '_Pragma' does not name a type; did you mean '_Pragma'?

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Similar to bug 78313; am looking at a fix.

[Bug preprocessor/78569] New: "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[arnd at linaro dot org]

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

Bug ID: 78569
   Summary: "internal compiler error: in
get_substring_ranges_for_loc" processing sprintf
buffer overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 40180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40180=edit
preprocessed drivers/tty/nozomi.c from linux-4.9-rc5+next

Originally replied to bug #78169, but I believe it's different now, so I opened
a new one here.

When building the Linux kernel with gcc snapshot x86_64-linux-gcc-7.0.0 (GCC)
7.0.0 20161124 (experimental), I get this output for incorrect code:

/git/arm-soc/drivers/tty/nozomi.c: In function 'receive_flow_control':
/git/arm-soc/drivers/tty/nozomi.c:919:12: internal compiler error: in
get_substring_ranges_for_loc, at input.c:1388
 static int receive_flow_control(struct nozomi *dc)
^~~~
0x110f22f get_substring_ranges_for_loc
/home/arnd/git/gcc/gcc/input.c:1388
0x110f22f get_source_location_for_substring(cpp_reader*, string_concat_db*,
unsigned int, cpp_ttype, int, int, int, unsigned int*)
/home/arnd/git/gcc/gcc/input.c:1458
0x67230e c_get_substring_location(substring_loc const&, unsigned int*)
/home/arnd/git/gcc/gcc/c-family/c-common.c:865
0xa5ce8f substring_loc::get_location(unsigned int*) const
/home/arnd/git/gcc/gcc/substring-locations.c:194
0xa5ce8f format_warning_va(substring_loc const&, source_range const*, char
const*, int, char const*, __va_list_tag (*) [1])
/home/arnd/git/gcc/gcc/substring-locations.c:112
0xa5d1f4 format_warning_at_substring(substring_loc const&, source_range const*,
char const*, int, char const*, ...)
/home/arnd/git/gcc/gcc/substring-locations.c:179
0x1038159 add_bytes
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2083
0x1038159 compute_format_length
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2208
0x1038159 handle_gimple_call
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2772
0x1038159 execute
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2799
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

It seems to only happen when I first preprocess the file and feed that into
compiler again (as done by ccache, but easily reproduced without it).

command to reproduce is:
x86_64-linux-gcc-7.0.0 -Wall -O -Wno-pointer-sign -s nozomi.i

I've only seen this with an x86 target, not with ARM, but that could be
coincidence.

The code line causing this is

  do {if (0x01 & debug) do { char tmp[128]; snprintf(tmp, sizeof(tmp),"The Base
Band sends this value as a response to a " "request for IMSI detach sent over
the control " "channel uplink (see section 7.6.1)."); printk("\001" "7" "[%d]
%s(): %s\n", 932, __func__, tmp); } while (0); } while (0);

and this in turn causes a stack overflow of the 'tmp' array as the string that
gets copied in there is slightly longer than 128 bytes.

[Bug middle-end/78540] [6/7 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Looks like postreload bug, will have a look.

[Bug c/78568] New: Wtype-limits warning regression

[sirl at gcc dot gnu.org]

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

Bug ID: 78568
   Summary: Wtype-limits warning regression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

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

The attached testcase produces warnings with gcc-4.4.7 on RHEL6, but somewhere
along the way it regressed. I've tested 4.6, 4.8, 4.9, 5, 6 and trunk, none of
them warns anymore, but they all still happily optimize the comparisons away.

gcc-4.4.7 produced:
$ gcc -O2 -Wtype-limits -c Wtype-limits.c 
Wtype-limits.c: In function 'testa':
Wtype-limits.c:4: warning: comparison is always true due to limited range of
data type
Wtype-limits.c: In function 'testb':
Wtype-limits.c:12: warning: comparison is always true due to limited range of
data type
Wtype-limits.c: In function 'testc':
Wtype-limits.c:20: warning: comparison is always true due to limited range of
data type

[Bug c++/77591] [6/7 Regression] decltype(auto) and ternary operator allow returning local reference without a warning

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 28 15:21:53 2016
New Revision: 242924

URL: https://gcc.gnu.org/viewcvs?rev=242924=gcc=rev
Log:
PR c++/77591
* typeck.c (maybe_warn_about_returning_address_of_local): Optimize
whats_returned through fold_for_warn.

* g++.dg/cpp1y/pr77591.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Actually, no array is needed,
struct A { union { short s; char d[2]; }; constexpr A (char x) : s(0x2020) {
d[0] = x; } };
A c { 'a' };
ICEs as well.  The C++ FE creates a CONSTRUCTOR that contains both initializer
for s as well for d[0], that obviously can't be emitted properly.
Before Nathan's fix, GCC just emitted garbage:
.type   c, @object
.size   c, 2
c:
.value  8224
.byte   97
.zero   1
i.e. c actually didn't have size 2, but 4.
struct A { union { short s; char d[2]; }; constexpr A (const char x) :
s(0x2020) { d[0] = x; } };
constexpr A c { 'a' };
const A *p = 
is rejected by clang++, because of:
assignment to member 'd' of union with active member 's' is not allowed in a
constant expression
g++ still ICEs.
Finally:
struct A { union { short s; char d[2]; }; constexpr A (const char x) : d{0,0} {
d[0] = x; d[1] = x; } };
constexpr A c { 'a' };
const A *p = 
is accepted by both compilers and looks good.

[Bug c++/78567] GCC trunk fails to compile all-stage2-gcc in i386.c

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
Also happens on a fresh configure.

[Bug tree-optimization/78542] [7 Regression] wrong code at -Og results in endless loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.0 |6.3

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.  Latent on the GCC 6 branch.

[Bug tree-optimization/78542] [7 Regression] wrong code at -Og results in endless loop

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 28 15:03:55 2016
New Revision: 242920

URL: https://gcc.gnu.org/viewcvs?rev=242920=gcc=rev
Log:
2016-11-28  Richard Biener  

PR tree-optimization/78542
* tree-ssa-ccp.c (evaluate_stmt): Only valueize simplification
if allowed.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr78542.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug libstdc++/68838] AIX 32 bit wchar_t testsuite failures

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
oss_01 is "good" with zero size until the string is emitted.


.good: 1 .fail: 0
size: 0

  oss_01 << str_01;

.good: 0 .fail: 1
size: 33554432

[Bug c++/78567] New: GCC trunk fails to compile all-stage2-gcc in i386.c

[marc.mutz at kdab dot com]

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

Bug ID: 78567
   Summary: GCC trunk fails to compile all-stage2-gcc in i386.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Last successful built was 5th of October (yielding gcc version 7.0.0 20161005
(experimental) (GCC)), this failure persists since somewhen around the
beginning of November:

  make[3]: Entering directory '/home/marc/C++/gcc-build/gcc'
  /home/marc/C++/gcc-build/./prev-gcc/xg++
-B/home/marc/C++/gcc-build/./prev-gcc/ -B/d/gcc/trunk/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/marc/C++/gcc/libstdc++-v3/libsupc++
-L/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/marc/C++/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o i386.o -MT i386.o -MMD
-MP -MF ./.deps/i386.TPo ../../gcc/gcc/config/i386/i386.c
  ../../gcc/gcc/config/i386/i386.c: In function ‘rtx_def*
ix86_expand_builtin(tree, rtx, rtx, machine_mode, int)’:
  ../../gcc/gcc/config/i386/i386.c:38407:18: error: ‘fcn’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  emit_insn (fcn (target, accum, wide_reg, mem));
  ~~^~~~
  cc1plus: all warnings being treated as errors
  Makefile:2198: recipe for target 'i386.o' failed
  make[3]: *** [i386.o] Error 1
  make[3]: Leaving directory '/home/marc/C++/gcc-build/gcc'
  Makefile:4589: recipe for target 'all-stage2-gcc' failed
  make[2]: *** [all-stage2-gcc] Error 2
  make[2]: Leaving directory '/home/marc/C++/gcc-build'
  Makefile:24513: recipe for target 'stage2-bubble' failed
  make[1]: *** [stage2-bubble] Error 2
  make[1]: Leaving directory '/home/marc/C++/gcc-build'
  Makefile:935: recipe for target 'all' failed
  make: *** [all] Error 2

Host compiler is

  $ g++ -v
  Using built-in specs.
  COLLECT_GCC=g++
  COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
  Thread model: posix
  gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 

Configure line:

  configure --prefix=/d/gcc/trunk --enable-checking=release
--enable-languges=c,c++,fortran,lto,objc,obj-c++

(out-of-souce build, clean except for config.status, which was how this build
was configured)

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase:
struct A { union { long s; char d[1]; }; constexpr A (char x) : s(0) { d[0] =
x; } };
struct B { A b[2]; };
B c { 'a', 'b' };

[Bug c++/71848] [7 Regression] libstdc++ testsuite error on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #4 from David Edelsohn  ---
Fixed.

[Bug lto/78562] Wrong warning for built-in functions with -flto

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 28 Nov 2016, gjl at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562
> 
> --- Comment #2 from Georg-Johann Lay  ---
> Thanks for looking into it.
> 
> IIUC it's a backend issue.
> 
> config/avr/builtins.def sets library names for some built-ins, and some
> libnames are the same because the libgcc asm code is exactly the same, even if
> the used types on C level are different.
> 
> So the fix for this one would be to use different asm names (pointing to the
> same code)?

Yes, using aliases would be a good workaround.

Richard.

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #2 from Peter Bergner  ---
I'll have a look.

[Bug lto/78562] Wrong warning for built-in functions with -flto

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Thanks for looking into it.

IIUC it's a backend issue.

config/avr/builtins.def sets library names for some built-ins, and some
libnames are the same because the libgcc asm code is exactly the same, even if
the used types on C level are different.

So the fix for this one would be to use different asm names (pointing to the
same code)?

[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Mon, 28 Nov 2016, zsojka at seznam dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546
> 
> --- Comment #14 from Zdenek Sojka  ---
> (In reply to Jakub Jelinek from comment #12)
> > Therefore the comment should be
> > /* CST1 - (CST2 - A) -> (CST1 - CST2) - A  */
> > rather than
> > /* CST - (CST - A) -> CST - A  */
> 
> How comes it is not "CST1 - (CST2 - A) -> (CST1 - CST2) + A"?

My mistake

[Bug middle-end/78566] [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug lto/78562] Wrong warning for built-in functions with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
The two builtins share DECL_ASSEMBLER_NAME, __ssabs_2.  Can it be the AVR
backend misuses DECL_ASSEMBLER_NAME for builtins somehow?  They have different
return mode, HQ vs. HA mode.

It might be possible to avoid diagnosing this but the middle-end can't see
that there is no ABI issue.

 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2c039c78
precision 16>
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality
arg-types 
chain >>
pointer_to_this >
addressable public external built-in HI file  line 0 col 0
align 8 built-in BUILT_IN_MD 17 context >

 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2c039498
precision 16>
QI
size 
unit size 
align 8 symtab 0 alias set -1 structural equality
arg-types 
chain >>
pointer_to_this >
addressable public external built-in HI file  line 0 col 0
align 8 built-in BUILT_IN_MD 14 context >

[Bug fortran/78298] ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/60145] [AVR] Suboptimal code for byte order shuffling using shift and or

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|other   |tree-optimization

--- Comment #4 from Georg-Johann Lay  ---
(In reply to Matthijs Kooijman from comment #3)
> I suppose you meant
> https://gcc.gnu.org/viewcvs/gcc?view=revision=242907 instead of the
> commit you linked (which is also nice btw, I noticed that extra sbiw in some
> places as well).

Ah yes, I meant r242907.

> Looking at the generated assembly, the optimizations look like fairly simple
> (composable) translations, but I assume that the optimization needs to
> happen before/while the assembly is generated, not afterwards. And then I
> can see that the patterns would indeed become complex.

Well, 4 extensions from u8 to u32, 3 shifts and 3 or make 10 operations which
have to be written as ONE single insn if the backend should catch this...  This
needs at least one intermediate pattern because otherwise the insn combiner
will not combine such complex expressions.

> My goal was indeed to compose values. Using a union is endian-dependent,
> which is a downside.

Maybe you can use GCC built-in macros like __BYTE_ORDER__ to factor out
endianess?

#define __ORDER_LITTLE_ENDIAN__ 1234
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__

(as displayed with -E -dM | grep END)

> If I understand your vector-example correctly, vectors are always stored as
> big endian, so using this approach would be portable? I couldn't find
> anything about this in the documentation, though.

Looking at the code the example

typedef uint8_t v4 __attribute__((vector_size (4)));

uint32_t join4 (uint8_t b0, uint8_t b1, uint8_t b2, uint8_t b3)
{
v4 vec;
vec[0] = b0;
vec[1] = b1;
vec[2] = b2;
vec[3] = b3;
return (uint32_t) vec;
}

generates, it's little endian, i.e. b0 is stored in the low byte of vec so that
vectors are similar to arrays:

join4:
mov r23,r22 ; b1
mov r25,r18 ; b3
mov r22,r24 ; b0
mov r24,r20 ; b2
ret

On tree level, this is represented as BIT_INSERT_EXPR (from
-fdump-tree-optimized)

join4 (uint8_t b0, uint8_t b1, uint8_t b2, uint8_t b3)
{
  v4 vec;
  uint32_t _6;

  :
  vec_8  = BIT_INSERT_EXPR ;
  vec_9  = BIT_INSERT_EXPR ;
  vec_10 = BIT_INSERT_EXPR ;
  vec_11 = BIT_INSERT_EXPR ;
  _6 = VIEW_CONVERT_EXPR(vec_11);
  return _6;
}

Hence an open-coded composition of byte-values into a 4-byte value can be
represented neatly on tree level, and this is quite an improvement over
ZERO_EXTEND + ASHIFT + IOR w.r.t. the resulting code.

Thus turned into a tree level optimization issue.

[Bug libfortran/78549] Very slow formatted internal file output

[mecej4 at operamail dot com]

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

--- Comment #2 from mecej4 at operamail dot com ---
Thanks, Martin. After posting, I found that I could add more add more
attachments, but I was a bit worried that, as in other forums, the initial post
could not be edited or modified.

I presume that you ran your confirmation runs on Linux. Even if the Fortran
version is three times slower than the C version, as you found, perhaps one
could live with that. However, on Windows(+Cygwin,Mingw,etc.) the performance
of the Fortran version is terrible, and I think that this reflects poorly on
the otherwise fine Gfortran compiler, which often outperforms expensive
commercial Fortran compilers in the quality of the generated code.

A collaborator tells me that the problem did not exist in the Windows/MinGW
release of Gfortran 4.9.3. I could not test that assertion myself because the
installer failed on my Windows 10 system.

[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above

[zsojka at seznam dot cz]

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

--- Comment #14 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #12)
> Therefore the comment should be
> /* CST1 - (CST2 - A) -> (CST1 - CST2) - A  */
> rather than
> /* CST - (CST - A) -> CST - A  */

How comes it is not "CST1 - (CST2 - A) -> (CST1 - CST2) + A"?

[Bug middle-end/78566] [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-28
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Mine.

[Bug middle-end/78566] New: [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k

[aldyh at gcc dot gnu.org]

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

Bug ID: 78566
   Summary: [7 regression] gcc.dg/uninit-pred-6_[abc].c
regressions on Arm and m68k
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldyh at gcc dot gnu.org
  Target Milestone: ---

FAIL: gcc.dg/uninit-pred-6_a.c warning (test for warnings, line 36)
FAIL: gcc.dg/uninit-pred-6_b.c warning (test for warnings, line 42)
FAIL: gcc.dg/uninit-pred-6_c.c warning (test for warnings, line 43)

Caused by my change of r242639 for pr61409.

On Arm it is reproduced with:

configure'   '--disable-multilib' '--target=arm-none-linux-gnueabihf'
'--with-cpu=cortex-a5' '--with-fpu=vfpv3-d16-fp16'
'target_alias=arm-none-linux-gnueabihf' '--enable-languages=c,lto'

[Bug fortran/78557] [7 Regression] [OOP] ICE in trans-expr.c with -fcheck=mem

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org
Summary|[7 Regression] ICE in   |[7 Regression] [OOP] ICE in
   |trans-expr.c with   |trans-expr.c with
   |-fcheck=all |-fcheck=mem

--- Comment #4 from janus at gcc dot gnu.org ---
Reduced test case:

implicit none
type :: t1
  logical, allocatable :: flag
end type
class(t1), dimension(:), allocatable :: sf_int
allocate (t1 :: sf_int (2))
end