[Bug tree-optimization/67908] gcc segfaults with -fstack-check (internal compiler error) / armv7 host and target

[gcc-bugs at zahlenfresser dot de]

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

--- Comment #4 from Stefan Keller  ---
So I rebuilt gcc:

GNU C99 (GCC) version 5.2.0 (armv7l-unknown-linux-gnueabihf)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=88 --param ggc-min-heapsize=110029
GNU C99 (GCC) version 5.2.0 (armv7l-unknown-linux-gnueabihf)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=88 --param ggc-min-heapsize=110029
Compiler executable checksum: 63e10edc02ccf1dede09ecb3cdb007dd

Program received signal SIGSEGV, Segmentation fault.
fold_builtin_alloca_with_align (stmt=0x766f0d20) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:2067
2067&& TREE_CODE (BLOCK_SUPERCONTEXT (block)) == FUNCTION_DECL))
(gdb) bt
#0  fold_builtin_alloca_with_align (stmt=0x766f0d20) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:2067
#1  ccp_fold_stmt (gsi=0x7efff4cc) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:2172
#2  0x00697a2c in substitute_and_fold_dom_walker::before_dom_children
(this=0x7efff538, bb=0x0) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-propagate.c:1177
#3  0x009c550c in dom_walker::walk (this=0x7efff538, bb=0x766dd940) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/domwalk.c:188
#4  0x00697458 in substitute_and_fold (get_value_fn=get_value_fn@entry=0x62b1c0
, fold_fn=fold_fn@entry=0x631bf4
, do_dce=do_dce@entry=true)
at /usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-propagate.c:1272
#5  0x0062973c in ccp_finalize () at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:941
#6  0x00629f68 in do_ssa_ccp () at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:2382
#7  (anonymous namespace)::pass_ccp::execute (this=) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:2414
#8  0x004cb2d4 in execute_one_pass (pass=pass@entry=0x1053508) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/passes.c:2330
#9  0x004cb70c in execute_pass_list_1 (pass=0x1053508) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/passes.c:2382
#10 0x004cb724 in execute_pass_list_1 (pass=0x1053408, pass@entry=0x1053388) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/passes.c:2383
#11 0x004cb764 in execute_pass_list (fn=0x7669cb60, pass=0x1053388) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/passes.c:2393
#12 0x00271764 in cgraph_node::expand (this=this@entry=0x7669f000) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/cgraphunit.c:1895
#13 0x00272b9c in expand_all_functions () at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/cgraphunit.c:2031
#14 symbol_table::compile (this=this@entry=0x76ad1000) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/cgraphunit.c:2384
#15 0x00274184 in symbol_table::compile (this=0x76ad1000) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/timevar.h:110
#16 symbol_table::finalize_compilation_unit (this=0x76ad1000) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/cgraphunit.c:2461
#17 0x0018393c in c_write_global_declarations () at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/c/c-decl.c:10798
#18 0x00573920 in compile_file () at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/toplev.c:613
#19 0x0016d3a0 in do_compile () at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/toplev.c:2067
#20 toplev::main (this=this@entry=0x7efff8d4, argc=0, argc@entry=27,
argv=0x106e6d8, argv@entry=0x7efffa44) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/toplev.c:2165
#21 0x0016dfcc in main (argc=27, argv=0x7efffa44) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/main.c:39

(gdb) p stmt
$1 = (gimple) 0x766f0d20
(gdb) p *stmt
$2 = {code = GIMPLE_CALL, no_warning = 0, visited = 1, nontemporal_move = 0,
plf = 0, modified = 0, has_volatile_ops = 0, pad = 0, subcode = 32, uid = 1,
location = 1840891, num_ops = 5, bb = 0x766dd940, next = 0x7682f2f8, 
  prev = 0x767fd900}
(gdb) up
#1  ccp_fold_stmt (gsi=0x7efff4cc) at
/usr/src/misc/pkg/gcc/src/gcc-5.2.0/gcc/tree-ssa-ccp.c:2172
2172tree new_rhs = fold_builtin_alloca_with_align (stmt);
(gdb) p gsi
$3 = (gimple_stmt_iterator *) 0x7efff4cc
(gdb) p *gsi
$4 = {ptr = 0x766f0d20, seq = 0x766dd960, bb = 0x766dd940}

Hope this helps.

[Bug testsuite/67959] "width of 'code' exceeds its type" error in ssa-thread-13

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
I confirm the test now passes on arm-non-eabi targets.

[Bug tree-optimization/67971] New: Failure to unify conditional argument selection with conditional result selection

[rsandifo at gcc dot gnu.org]

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

Bug ID: 67971
   Summary: Failure to unify conditional argument selection with
conditional result selection
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

We don't optimise:

int
f1 (int cond, double x, double y)
{ 
  double z1, z2;

  if (cond)
z1 = __builtin_cos (x);
  else
z1 = __builtin_cos (y);
  z2 = __builtin_cos (cond ? x : y);
  return z1 == z2;
}

to "return 1" at -O2.

[Bug c++/67961] Incorrect type of meber of struct in error message

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Closing then.

[Bug c++/67935] internal compiler error: Segmentation fault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|niqingliang2003 at gmail dot com   |
   Severity|critical|normal

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #5)
> Well, this PR has been rotting for more than four years and a half. I was
> only pointing to the fact that the initial patch no longer applies.
> 
> If you know what to do, please do so. If not, I don't see the point to keep
> it open for  the next decade.

I'll take a look over the weekend.

Thanks for your efforts to weed out some of the PRs that have passed their
sell-by date. It's much appreciated.

Paul

[Bug fortran/67972] New: Substrings of arrays of unicode strings are of type DEFAULT rather than ISO_10646

[alexandros.syrakos at outlook dot com]

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

Bug ID: 67972
   Summary: Substrings of arrays of unicode strings are of type
DEFAULT rather than ISO_10646
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexandros.syrakos at outlook dot com
  Target Milestone: ---

This seems related to bug 65141, but it is different so I submit it as a
separate bug. It appears that substrings of arrays of unicode strings are
always treated as of DEFAULT kind. The following code demonstrates this (I'm
using gfortran 5.2.0 on Kubuntu 14.04):

program test
use iso_fortran_env
implicit none
integer, parameter ::ucs4 = selected_char_kind( 'ISO_10646' )
character(kind=ucs4) :: a
character(kind=ucs4, len=8), dimension(2) :: page

a = ucs4_"U"
open (output_unit, encoding='UTF-8')
print "(a,i0)", "kind(page(1)(2:4)) is ", kind(page(1)(2:4))

page(1) = repeat(a,8)
print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) is: ",
page(1)

page(1)(2:4) = a
print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) is: ",
page(1)
end program test



The reason I used the variable "a" is to avoid assigning directly a constant to
the substring, something that would change the type to DEFAULT anyway,
according to bug 65141. The code demonstrates that page(1) treated as a whole
(as in page(1) = repeat(a,8)) causes no problems, but when a substring is
referenced (page(1)(2:4) = a), page(1) is made to contain garbage characters.
This makes arrays of unicode strings practically unusable.

[Bug other/66887] trunk/libmpx/mpxrt/mpxrt.c:158: possible performance problem

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu Oct 15 09:26:39 2015
New Revision: 228838

URL: https://gcc.gnu.org/viewcvs?rev=228838&root=gcc&view=rev
Log:
libmpx/

PR other/66887
* mpxrt/mpxrt.c (read_mpx_status_sig): Remove useless code.


Modified:
trunk/libmpx/ChangeLog
trunk/libmpx/mpxrt/mpxrt.c

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[ienkovich at gcc dot gnu.org]

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

Bug 66887 Summary: trunk/libmpx/mpxrt/mpxrt.c:158: possible performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66887

   What|Removed |Added

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

[Bug other/66887] trunk/libmpx/mpxrt/mpxrt.c:158: possible performance problem

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
Fixed

[Bug fortran/67972] Substrings of arrays of unicode strings are of type DEFAULT rather than ISO_10646

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-15
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0

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

[Bug libfortran/48958] Add runtime diagnostics for SIZE intrinsic function

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
This PR is related to pr46182. While I agree that it would be nice to have run
time errors for invalid use of unallocated variables/not associated pointers, I
doubt it will ever happen.

[Bug tree-optimization/67971] Failure to unify conditional argument selection with conditional result selection

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
VRP jump-threads this into sth PRE then can transform to

  :
  if (cond_3(D) != 0)
goto ;
  else
goto ;

  :
  z1_5 = __builtin_cos (x_4(D));
  goto ;

  :
  z1_7 = __builtin_cos (y_6(D));

  :
  # iftmp.0_2 = PHI 
  # z1_13 = PHI 
  # prephitmp_1 = PHI 
  # RANGE [0, 1]
  _9 = prephitmp_1 == z1_13;
  # RANGE [0, 1] NONZERO 1
  _10 = (int) _9;
  return _10;

leaving the followup missed equivalency for the inserted PHI.

but then somehow DOM running later CSEing z1_13 and prephitmp_1 fails
to fold the comparison and we end up with

  _9 = z1_13 == z1_13;

which even forwprop doesn't simplify (even though it is supposed to fold
all stmts).  We do have

(simplify
 (eq @0 @0)
 (if (! FLOAT_TYPE_P (TREE_TYPE (@0))
  || ! HONOR_NANS (TYPE_MODE (TREE_TYPE (@0
  { constant_boolean_node (true, type); }))

but for some reason it doesn't trigger.

Investigating.

[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Oct 15 09:39:35 2015
New Revision: 228839

URL: https://gcc.gnu.org/viewcvs?rev=228839&root=gcc&view=rev
Log:
PR tree-optimization/67953
* match.pd (X - (X / Y) * Y): Don't change signedness of @0.

* gcc.dg/fold-minus-6.c (fn4): Change the type of A to
unsigned.
* gcc.dg/torture/pr67953.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67953.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/fold-minus-6.c

[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/67971] Failure to unify conditional argument selection with conditional result selection

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
Ah, because they may be NaN if x or y were NaN.  Works ok with
-ffinite-math-only,
PRE already figures out the result is 1.

Thus invalid.

And thus if we performed this simplification on GENERIC somehow that was likely
an invalid transform.

[Bug target/67967] [5.2/6 Regression] ICE in i386_pe_seh_unwind_emit

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|c   |target
 Resolution|--- |FIXED

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

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
I assume not fixed by

2015-10-13  Alexandre Oliva 

PR middle-end/67912
* expmed.c (store_bit_field_1): Adjust mode of BLKmode inputs.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[rsandifo at gcc dot gnu.org]

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

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Oct 15 09:50:07 2015
New Revision: 228840

URL: https://gcc.gnu.org/viewcvs?rev=228840&root=gcc&view=rev
Log:
PR67945: Fix oscillation between pow representations

This patch fixes some fallout from my patch to move the sqrt and cbrt
folding rules to match.pd.  The rules included canonicalisations like:

   sqrt(sqrt(x))->pow(x,1/4)

which in the original code was only ever done at the generic level.
My patch meant that we'd do it whenever we tried to fold a gimple
statement, and eventually it would win over the sincos optimisation
that replaces pow(x,1/4) with sqrt(sqrt(x)).

Following a suggestion from Richard B, the patch adds a new
PROP_gimple_* flag to say whether fp routines have been optimised
for the target.  If so, match.pd should only transform calls to math
functions if the result is actually an optimisation, not just an
IL simplification or canonicalisation.  The question then of course
is: which rules are which?  I've added block comments that describe
the criteria I was using.

A slight wart is that we need to use the cfun global to access
the PROP_gimple_* flag; there's no local function pointer available.

Bootstrapped & regression-tested on x86_64-linux-gnu.  Also tested
on powerc64-linux-gnu.

gcc/
PR tree-optimization/67945
* tree-pass.h (PROP_gimple_opt_math): New property flag.
* generic-match-head.c (canonicalize_math_p): New function.
* gimple-match-head.c: Include tree-pass.h.
(canonicalize_math_p): New function.
* match.pd: Group math built-in rules into simplifications
and canonicalizations.  Guard the latter with canonicalize_math_p.
* tree-ssa-math-opts.c (pass_data_cse_sincos): Provide the
PROP_gimple_opt_math property.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/generic-match-head.c
trunk/gcc/gimple-match-head.c
trunk/gcc/match.pd
trunk/gcc/tree-pass.h
trunk/gcc/tree-ssa-math-opts.c

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Fixed.  Sorry for the breakage.

[Bug target/67963] -march=lakemont generates x87 instructions

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
I have a patch that moves -m80387 to ISA flags.

[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Not actively working on this.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #10 from Dominik Vogt  ---
This is what's happening:

Before the dse2 pass, there is a store instruction (25) followed by a read
instruction later (29):

---
# store first byte
(insn 25 135 136 4 (set (mem/j:QI (reg/v/f:DI 2 %r2 [orig:47 ps ] [47]) [2
ps_7\
->f1+0 S1 A32]) 
(reg:QI 1 %r1 [orig:51 D.2017+3 ] [51])) t67443.cxx:17 74 {*movqi} 
 (nil))

(insn 136 25 137 4 (set (reg/v/f:DI 1 %r1 [orig:47 ps ] [47]) 
(reg/v/f:DI 3 %r3 [orig:47 ps ] [47])) t67443.cxx:18 63 {*movdi_64} 
 (nil)) 

# overwrites r2
(insn 137 136 29 4 (set (reg:SI 2 %r2 [68]) 
(mem/u/c:SI (unspec:DI [ 
(symbol_ref/u:DI ("*.LC0") [flags 0x2]) 
(reg:DI 13 %r13) 
] UNSPEC_LTREF) [3  S4 A32])) t67443.cxx:18 67 {*movsi_zarch} 
 (nil)) 

# write three bytes
(insn 29 137 139 4 (parallel [ 
(set (reg:SI 2 %r2 [68]) 
(and:SI (reg:SI 2 %r2 [68]) 
(mem/j:SI (reg/v/f:DI 1 %r1 [orig:47 ps ] [47]) [2
ps_7->f2\
+-1 S4 A32]))) 
(clobber (reg:CC 33 %cc)) 
]) t67443.cxx:18 454 {*andsi3_zarch} 
 (nil)) 
---

With the unpatched code, the a "value" expression is put in the mem_addr field
of the store_info for the "set" (similar for the read in insn 29):

store (value:DI 3:3 @0xb7049598/0xb70516a8) 
read  (value:DI 3:3 @0xb7049598/0xb70516a8) 

With the patched code, the mem_addr is resolved to a register expression r2 for
the store and r1 for the read:

store (reg/v/f:DI 2 %r2 [orig:47 ps ] [47])
read  (reg/v/f:DI 1 %r1 [orig:47 ps ] [47])

Then, canon_true_dependence is called with these terms and calls get_addr on
them again.  In the unpatched case, the same address value is resolved to the
same register expression:

(reg/v/f:DI 1 %r1 [orig:47 ps ] [47])

With the patched code, there's nothing left to do for get_addr, so there are
two different register expressions that describe the same address.  In the end,
memrefs_conflict_p() gets called with the two different register expressions
and fails to detect that they refer to the same address (which they do *not* at
insn 29 because r2 has been overwritten in between).

So, I'd say the new call of get_addr() in record_store() is too early because
it may replace the address value by an expression that is no longer valid when
the memory is read later.

[Bug c++/67926] Using folding expressions in a constexpr context ice's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-15
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #11 from Dominik Vogt  ---
This is the bug report for the problem that the patch fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557

[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #7 from Dominik Vogt  ---
This fix causes a regression on s390.  Please refer to bug 67443:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[josephpattara at gmail dot com]

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

Joseph John  changed:

   What|Removed |Added

 CC||josephpattara at gmail dot com

--- Comment #3 from Joseph John  ---
I am trying to compile GCC 4.9.2 on HP-UX 11.31 and am precisely getting the
same LD error. Do we have any update or toot cause on this issue?

[Bug target/67963] -march=lakemont generates x87 instructions

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> I have a patch that moves -m80387 to ISA flags.

Not really. To be attached much simpler patch introduces PTA_NO_80387 and
changes target flags instead.

[Bug target/67963] -march=lakemont generates x87 instructions

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Created attachment 36516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36516&action=edit
Patch that introduces PTA_NO_80387

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #12 from Dominique d'Humieres  ---
> This PR seems to have been fixed between r224139 (test for excess errors)
> and 224288 (UNSUPPORTED).

Fixed by r228273. Closing as FIXED.

[Bug target/67973] New: All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[dominiq at lps dot ens.fr]

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

Bug ID: 67973
   Summary: All the tests for -gstabs* fail on
x86_64-apple-darwin14 with Xcode 7
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: howarth.at.gcc at gmail dot com, iains at gcc dot gnu.org,
mikestump at comcast dot net
  Target Milestone: ---
  Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
 Build: x86_64-apple-darwin14

All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7: see
https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00310.html.

The new assembly needs the option -Wa,-Q in order to accept -gstabs*.

Tentative patch:

--- ../_clean/gcc/testsuite/lib/gcc-dg.exp  2015-08-21 20:09:57.0
+0200
+++ gcc/testsuite/lib/gcc-dg.exp2015-09-23 14:57:59.0 +0200
@@ -492,11 +492,10 @@ proc gcc-dg-debug-runtest { target_compi
set DEBUG_TORTURE_OPTIONS ""
foreach type {-gdwarf-2 -gstabs -gstabs+ -gxcoff -gxcoff+ -gcoff} {
set comp_output [$target_compile \
-   "$srcdir/$subdir/$trivial" "trivial.S" assembly \
+   "$srcdir/$subdir/$trivial" "trivial.S" assemble \
"additional_flags=$type"]
if { ! [string match "*: target system does not support the * debug
format*" \
$comp_output] } {
-   remove-build-file "trivial.S"
foreach level {1 "" 3} {
if { ($type == "-gdwarf-2") && ($level != "") } {
lappend DEBUG_TORTURE_OPTIONS [list "${type}"
"-g${level}"]
@@ -505,13 +504,22 @@ proc gcc-dg-debug-runtest { target_compi
[list "${type}" "-g${level}" "$opt" ]
}
} else {
-   lappend DEBUG_TORTURE_OPTIONS [list "${type}${level}"]
-   foreach opt $opt_pend DEBUG_TORTURE_OPTIONS \
-   [list "${type}${level}" "$opt" ]
+   if { [istarget *-*-darwin*] && [string match "*gstabs*"
$type] } {
+   lappend DEBUG_TORTURE_OPTIONS [list
"${type}${level}" "-Wa,-Q" ]
+   foreach opt $opt_opts {
+   lappend DEBUG_TORTURE_OPTIONS \
+   [list "${type}${level}" "$opt" "-Wa,-Q"
]
+   }
+   } else {
+   lappend DEBUG_TORTURE_OPTIONS [list
"${type}${level}" ]
+   foreach opt $opt_opts {
+   lappend DEBUG_TORTURE_OPTIONS \
+   [list "${type}${level}" "$opt" ]
+   }
}
}
}
+   remove-build-file "trivial.S"
}
}
 }


see https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00339.html.

Comments welcomed!

[Bug testsuite/57413] FAIL: gcc.dg/debug/dwarf2/discriminator.c scan-assembler on x86_64-apple-darwin10, Solaris/x86

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #11 from Dominique d'Humieres  ---
> > I'd have to look it up myself, but it doesn't matter now.
>
> Any progress?

No feedback for almost a year. Closing as FIXED. Please open new PR(s) for
remaining issue(s).

[Bug target/67963] -march=lakemont generates x87 instructions

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #36516|0   |1
is obsolete||

--- Comment #7 from Uroš Bizjak  ---
Created attachment 36517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36517&action=edit
V2 patch that introduces PTA_NO_80387

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[josephpattara at gmail dot com]

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

--- Comment #4 from Joseph John  ---
I tried with source build for 4.9.2 and 4.9.3 but both of them resulted in same
ld relocation error.

[Bug testsuite/67974] New: Missing gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support-darwin.s file

[dominiq at lps dot ens.fr]

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

Bug ID: 67974
   Summary: Missing
gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support-da
rwin.s file
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

The file gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support-darwin.s is
missing, but is needed by gcc.target/x86_64/abi/avx/abi-avx.exp: the comment

# FIXME: Darwin isn't tested.

is no longer true with Xcode 7. See 

https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00310.html 

and

https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00339.html

The same file is probably needed for
gcc.target/x86_64/abi/avx512f/abi-avx512f.exp (still no tested with Xcode 7).

[Bug tree-optimization/67975] New: Failure to optimise equality between two call sequences

[rsandifo at gcc dot gnu.org]

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

Bug ID: 67975
   Summary: Failure to optimise equality between two call
sequences
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

We don't simplify the following test to "return 1", even with fast
math enabled:

int
f1 (double x, double y)
{
  double z1 = __builtin_cos(y<10 ? x : __builtin_tan(x<20 ? x : y));
  double z2 = __builtin_cos(y<10 ? x : __builtin_tan(x<20 ? x : y));
  return z1 == z2;
}

whereas we do for:

int
f1 (double x, double y)
{
  return (__builtin_cos(y<10 ? x : __builtin_tan(x<20 ? x : y))
  == __builtin_cos(y<10 ? x : __builtin_tan(x<20 ? x : y)));
}

[Bug target/67963] -march=lakemont generates x87 instructions

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #7)
> Created attachment 36517 [details]
> V2 patch that introduces PTA_NO_80387

We need some testcases to verify it works on command line as well
as with __attribute__((target("arch="))).

[Bug testsuite/67974] Missing gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support-darwin.s file

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-15
 CC||howarth.at.gcc at gmail dot 
com,
   ||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net
 Ever confirmed|0   |1

[Bug tree-optimization/67975] Failure to optimise equality between two call sequences

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The issue is that to do the optimization we rely on jump-threading
to duplicate out the tails.  We can't see the equivalence of the functions
without
that trick.  Basically the following kind of pattern

  :
  if (x_6(D) < 2.0e+1)
goto ;
  else
goto ;

  :
  goto ;

  :

  :
  # iftmp.1_2 = PHI 
  iftmp.0_7 = __builtin_tan (iftmp.1_2);
  z1_15 = __builtin_cos (iftmp.0_7);
  if (x_6(D) < 2.0e+1)
goto ;
  else
goto ;

  :
  goto ;

  :

  :
  # iftmp.3_4 = PHI 
  iftmp.2_9 = __builtin_tan (iftmp.3_4);
  _23 = __builtin_cos (iftmp.2_9);

requires jump-threading to remove the duplicate check and prove the
PHIs equal.  VRP misses a secondary jump-threading opportunity here
for example.

I will think about this a bit to see whether it's (easily) possible to
value-number the PHIs the same without performing the jump-threading.

[Bug tree-optimization/67975] Failure to optimise equality between two call sequences

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
int foo (int x, int y)
{
  int a = x > 5 ? x : y;
  int b = x > 5 ? x : y;
  return a == b;
}

this should be handled in FRE1 already (well, if hopefully easily possible).
Currently two PHIs are only ever considered to have the same value if they
appear in the same basic-block.

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-15
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
No, not fixed by Alexandre's patch.

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
It's again a move between a BLKmode RHS and a DImode LHS.  Frankly, I don't
understand why this is now allowed to reach the RTL expander, we will probably
need to add conversions on quite a number of paths instead of having a single
treatment in the VIEW_CONVERT_EXPR case...

[Bug go/67976] New: Cgo + Gccgo not working like Cgo + Golang?

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 67976
   Summary: Cgo + Gccgo not working like Cgo + Golang?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
  Target Milestone: ---

The authors of the Ethereum project seem to assume that cgo can handle the code
below in a sensible way, but when using the -gccgo option that is not the case.

-- snip --
package foo 

/* 
int foo_cgo(unsigned); 
*/ 
import "C" 
import "unsafe" 

//export foo 
func foo(x C.unsigned) C.int { 
return 0 
} 

func () bar() { 
_ = unsafe.Pointer(C.foo_cgo) 
} 
-- snip --

Running this through

  $ mkdir _obj
  $ cgo -objdir _obj -gccgo foo.go

Results in this code in _cgo_main.c:

  extern char foo_cgo[]; 
  void *_cgohack_foo_cgo = foo_cgo; 
  #include "_cgo_export.h"

And this line in _cgo_export.h:

  int foo_cgo(unsigned); 

Redeclaring foo_cgo results in an error message when trying to compile
_cgo_main.c.

Maybe _cgo_export.h should simply be emitted to _cgo_main.c *before* all the
declarations?

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #1 from Dominik Vogt  ---
Can you please attach the source file that caused the crash so I can try to
reproduce this?

[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #13 from Segher Boessenkool  ---
Yes, not the same thing as PR67789.

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[josephpattara at gmail dot com]

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

Joseph John  changed:

   What|Removed |Added

 CC||josephpattara at gmail dot com

--- Comment #9 from Joseph John  ---
Hi,
I am hitting the same error on the below platform.
B.11.31 U ia64 rx2800 

g++ -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.
-I. -I../../gcc-5.2.0/gcc -I../../gcc-5.2.0/gcc/.
-I../../gcc-5.2.0/gcc/../include -I../../gcc-5.2.0/gcc/../libcpp/include
-I/home/jjohn/hpux/gcc_520/gcc_build/./gmp
-I/home/jjohn/hpux/gcc_520/gcc-5.2.0/gmp
-I/home/jjohn/hpux/gcc_520/gcc_build/./mpfr/src
-I/home/jjohn/hpux/gcc_520/gcc-5.2.0/mpfr/src
-I/home/jjohn/hpux/gcc_520/gcc-5.2.0/mpc/src 
-I../../gcc-5.2.0/gcc/../libdecnumber -I../../gcc-5.2.0/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc-5.2.0/gcc/../libbacktrace
-I/home/jjohn/hpux/gcc_520/gcc_build/./isl/include
-I/home/jjohn/hpux/gcc_520/gcc-5.2.0/isl/include  -o gcov-tool.o -MT
gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo ../../gcc-5.2.0/gcc/gcov-tool.c
../../gcc-5.2.0/gcc/gcov-tool.c: In function 'int unlink_profile_dir(const
char*)':
../../gcc-5.2.0/gcc/gcov-tool.c:84: error: invalid conversion from 'int
(*)(const char*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*,
int, FTW)'
Makefile:1065: recipe for target 'gcov-tool.o' failed
make[3]: *** [gcov-tool.o] Error 1
make[3]: Leaving directory '/home/jjohn/hpux/gcc_520/gcc_build/gcc'

Is there a similar fix also for the ia64 platform?

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Our internal x86 tester finally recovered from the r288586 build breakage and
reports another failure mode, namely an ICE in store_field, at expr.c:6690.

[Bug other/60158] powerpc: usage of the .data.rel.ro.local section

[joakim.tjernlund at transmode dot se]

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

joakim.tjernlund at transmode dot se  
changed:

   What|Removed |Added

 CC||joakim.tjernlund@transmode.
   ||se

--- Comment #1 from joakim.tjernlund at transmode dot se  ---
There is a patch at http://patchwork.ozlabs.org/patch/342888/
to address this issue and I THINK it is included in gcc-4.9.3

However, when I build the test case I do not get any .fixup section
I cross building from amd64 to ppc32 if that is important

[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Thu Oct 15 16:38:47 2015
New Revision: 228846

URL: https://gcc.gnu.org/viewcvs?rev=228846&root=gcc&view=rev
Log:
Backport from mainline
2015-10-14  Peter Bergner  
Torvald Riegel  

PR target/67281
* config/rs6000/htm.md (UNSPEC_HTM_FENCE): New.
(tabort, tabortc, tabortci, tbegin, tcheck, tend,
trechkpt, treclaim, tsr, ttest): Rename define_insns from this...
(*tabort, *tabortc, *tabortci, *tbegin, *tcheck, *tend,
*trechkpt, *treclaim, *tsr, *ttest): ...to this.  Add memory barrier.
(tabort, tabortc, tabortci, tbegin, tcheck, tend,
trechkpt, treclaim, tsr, ttest): New define_expands.
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
__TM_FENCE__ for htm.
* doc/extend.texi: Update documentation for htm builtins.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/htm.md
branches/gcc-5-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-5-branch/gcc/doc/extend.texi

[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Author: bergner
Date: Thu Oct 15 16:40:14 2015
New Revision: 228847

URL: https://gcc.gnu.org/viewcvs?rev=228847&root=gcc&view=rev
Log:
Backport from mainline
2015-10-14  Peter Bergner  
Torvald Riegel  

PR target/67281
* config/rs6000/htm.md (UNSPEC_HTM_FENCE): New.
(tabort, tabortc, tabortci, tbegin, tcheck, tend,
trechkpt, treclaim, tsr, ttest): Rename define_insns from this...
(*tabort, *tabortc, *tabortci, *tbegin, *tcheck, *tend,
*trechkpt, *treclaim, *tsr, *ttest): ...to this.  Add memory barrier.
(tabort, tabortc, tabortci, tbegin, tcheck, tend,
trechkpt, treclaim, tsr, ttest): New define_expands.
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
__TM_FENCE__ for htm.
* doc/extend.texi: Update documentation for htm builtins.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/htm.md
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-4_9-branch/gcc/doc/extend.texi

[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc*-linux
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #9 from Peter Bergner  ---
Fixed in trunk and the FSF 5 and 4.9 branches.

[Bug fortran/67977] New: allocatable strings, array section reallocated - non-standard behaviour

[mexas at bristol dot ac.uk]

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

Bug ID: 67977
   Summary: allocatable strings, array section reallocated -
non-standard behaviour
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
  Target Milestone: ---

character(:), allocatable :: z
z = "cockatoo"
write (*,*) z, len(z)
z(:) = ''
write (*,*) z, len(z)
end

with gfortran 4.9 to 6.0 this returns:

 cockatoo   8
0

which is wrong. It should return:

 cockatoo   8
8

i.e. the length of variable "z" must not change
from the second assignment statement. This is because
the array section is used ( z(:) ), which should not
trigger reallocation. So "z" after the second assignment
must still be 8 characters long, all blanks.

Anton

[Bug c/67978] New: dead code elimination deleted the predicated branch within the function block.

[feqin1023 at gmail dot com]

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

Bug ID: 67978
   Summary: dead code elimination deleted the predicated branch
within the function block.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: feqin1023 at gmail dot com
  Target Milestone: ---

if i have this input:

void foo(int *x) {
  int y = *x; // dead code can be clean

}

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #14 from Jack Howarth  ---
I finally got around to rebuilding the Apple open source release of
libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
interesting as the default build is a Debug one compiled at -O0. The debug
build of libunwind.dylib produces a binary which exhibits the same breakage in
the boehm-gc test suite binaries built on darwin14 as is seen on darwin15 with
the optimized system libunwind.dylib. This makes it much more likely that the
issue isn't an optimization bug in Apple Clang 7.0 but rather a linker bug in
Xcode 7. Unfortunately, it is impossible to test that by linking the Xcode 7
build under the Xcode 6 linker because the Xcode 7 build uses the 10.11 SDK on
10.10 which needs a linkage on libc++abi.tbd and thus requires the new linker
with the .tbd support.

FYI, The .tbd files are new "text-based stub libraries", that provide a much
more compact version of the stub libraries for use in the SDK, and help to
significantly reduce its download size.

[Bug c/67979] New: dead code elimination deleted the predicated branch within the function block.

[feqin1023 at gmail dot com]

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

Bug ID: 67979
   Summary: dead code elimination deleted the predicated branch
within the function block.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: feqin1023 at gmail dot com
  Target Milestone: ---

Created attachment 36518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36518&action=edit
the source test dead code elimination.

if i have this input:

/*test.c*/
void bar_i(int);
void foo(int *x) {
  int y = *x; // dead code can be clean
  if (!x)
return;   // this branch ALSO will be clean 
  bar_i(y);
}
/*--*/

we call gcc like this:

  gcc -O2 -S test.c

the the whole branch in function foo(int *) will be clean.
BUT, if foo(int *) is called like this:

  foo(NULL);

gcc has CHANGED the original semantic even sometimes which
 is error. but compiler can do this?

I also test Clang, Clang ALWAYS keep the branch in foo(int *).

[Bug target/67880] [ARM] -fno-align-functions does not work for thumb

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #2 from Ramana Radhakrishnan  ---
Dup of PR67745.

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

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  ---
*** Bug 67880 has been marked as a duplicate of this bug. ***

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #15 from Jack Howarth  ---
(In reply to Jack Howarth from comment #14)
> I finally got around to rebuilding the Apple open source release of
> libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
> interesting as the default build is a Debug one compiled at -O0. The debug
> build of libunwind.dylib produces a binary which exhibits the same breakage
> in the boehm-gc test suite binaries built on darwin14 as is seen on darwin15
> with the optimized system libunwind.dylib. This makes it much more likely
> that the issue isn't an optimization bug in Apple Clang 7.0 but rather a
> linker bug in Xcode 7. Unfortunately, it is impossible to test that by
> linking the Xcode 7 build under the Xcode 6 linker because the Xcode 7 build
> uses the 10.11 SDK on 10.10 which needs a linkage on libc++abi.tbd and thus
> requires the new linker with the .tbd support.
> 
> FYI, The .tbd files are new "text-based stub libraries", that provide a much
> more compact version of the stub libraries for use in the SDK, and help to
> significantly reduce its download size.

Nick,
 Are there any changes in the default behavior of the linker from Xcode 6.4
to 7.0 which I can revert in my Xcode 7 build of libunwind-35.3 on 10.10.5 with
linker flags?
  Jack

[Bug target/67871] LTO falis for ARM big-endian

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-15
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Do you have big endian multilibs suitably built ? How did you configure your
toolchain ?

I am unable to replicate this issue.

[Bug c/67979] dead code elimination deleted the predicated branch within the function block.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The code is undefined if NULL is passed and that is why the branch is removed. 
If you don't want this optimization then use -fno-delete-null-pointer-checks

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-15
 CC||ramana at gcc dot gnu.org
Version|6.0 |4.9.0
   Target Milestone|--- |4.9.4
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #1 from mrs at gcc dot gnu.org  ---
So, I think I prefer if we have -gstabs and -gstabs+ automagically add -Q for
the assembler on systems that have/need -Q.  Then, we fix existing users that
merely use -gstabs, and the test suite as well.  I looked around, and didn't
see the documentation for -Q.  What does it mean?

#define ASM_SPEC is where the specs for the assembler live.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[mrs at gcc dot gnu.org]

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

--- Comment #2 from mrs at gcc dot gnu.org  ---
Ah, found it, use the GNU assembler.  Maybe a little tricky, as one day, even
that will be removed.  At that point, I think we just reject the -gstabs
option.  The other option, is to just reject that now on darwin14+ (or wherever
it no longer works).

[Bug c/67979] dead code elimination deleted the predicated branch within the function block.

[feqin1023 at gmail dot com]

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

zet  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|INVALID |FIXED

--- Comment #2 from zet  ---
(In reply to Andrew Pinski from comment #1)
> The code is undefined if NULL is passed and that is why the branch is
> removed.  If you don't want this optimization then use
> -fno-delete-null-pointer-checks

Well, it's a feature.
Thx.

[Bug c++/67980] New: left shift count is negative [-Wshift-count-negative] generated for unreachable code

[nacitar at ubercpp dot com]

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

Bug ID: 67980
   Summary: left shift count is negative [-Wshift-count-negative]
generated for unreachable code
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nacitar at ubercpp dot com
  Target Milestone: ---

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

With -Wall, unreachable code in a constexpr function generates a warning if
written using c++14's expanded constexpr and using actual if statements,
however does not in the case of a ternary-styled c++11 constexpr function.

This can be worked around using template specializations, but certainly this
error shouldn't happen given that these values are all known at compilation
time and it's impossible for that count to ever actually be negative.

This is a simplification of the problem from a larger issue.

[Bug c++/67980] left shift count is negative [-Wshift-count-negative] generated for unreachable code

[nacitar at ubercpp dot com]

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

--- Comment #1 from Jacob McIntosh  ---
> but certainly this error shouldn't happen

By error, I meant "warning".

[Bug c++/67980] left shift count is negative [-Wshift-count-negative] generated for unreachable code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
There is another bug about this specific issue.

[Bug target/67871] LTO falis for ARM big-endian

[jonathan at codesourcery dot com]

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

--- Comment #3 from Jonathan Roelofs  ---
(In reply to Ramana Radhakrishnan from comment #2)
> Do you have big endian multilibs suitably built ?

Yes, both the big-endian and little-endian multilibs seem to work, and have
reasonable results in the testsuite... except for the big-endian + lto tests,
that is, which all fail with the same symptoms as my reduced testcase.

> How did you configure your toolchain ?

gcc was configured with:

/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/src/gcc-mainline/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared
--enable-lto --with-newlib --disable-nls
--prefix=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install
--with-headers=yes
--with-sysroot=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi
--with-gmp=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-isl=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --disable-libatomic --disable-libssp
--disable-libcc1 --enable-poison-system-directories
--with-python-dir=arm-none-eabi/share/gdb/python
--with-build-time-tools=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi/bin
--with-build-time-tools=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi/bin
SED=sed

ginutils was configured with:

/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/obj/binutils-src-mainline-0-arm-none-eabi-i686-pc-linux-gnu/configure
--prefix=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install
--build=i686-pc-linux-gnu --target=arm-none-eabi --host=i686-pc-linux-gnu
--disable-gdb --disable-libdecnumber --disable-readline --disable-sim
--disable-nls
--with-sysroot=/scratch/jroelofs/builds/fsf/mainline/arm-none-eabi/install/arm-none-eabi
--enable-poison-system-directories --enable-plugins

both pulled from trunk.

> 
> I am unable to replicate this issue.

[Bug c++/67980] left shift count is negative [-Wshift-count-negative] generated for unreachable code

[nacitar at ubercpp dot com]

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

--- Comment #3 from Jacob McIntosh  ---
(In reply to Andrew Pinski from comment #2)
> There is another bug about this specific issue.

Which?

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[jeremyhu at macports dot org]

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

--- Comment #16 from Jeremy Huddleston Sequoia  
---
(In reply to Jack Howarth from comment #14)
> I finally got around to rebuilding the Apple open source release of
> libunwind-35.3 from 10.10.5 under Xcode 7 on 10.10.5. The results are rather
> interesting as the default build is a Debug one compiled at -O0. The debug
> build of libunwind.dylib produces a binary which exhibits the same breakage
> in the boehm-gc test suite binaries built on darwin14 as is seen on darwin15
> with the optimized system libunwind.dylib. This makes it much more likely
> that the issue isn't an optimization bug in Apple Clang 7.0 but rather a
> linker bug in Xcode 7.

I don't see how you come to that conclusion.  All I see are these data points:

libunwind-35.3 built against the 10.10 SDK with Xcode6-era clang and Xcode6-era
linker produces a libunwind.dylib that does not exhibit this problem.

libunwind-35.3 built against the 10.11 SDK with Xcode7-era clang and Xcode7-era
linker produces a libunwind.dylib that exhibits this problem.

I suggest you try using the Xcode 7 linker with the Xcode 6 compiler and 10.10
SDK.  If you hypothesis is correct, it should fail.  You can do that by just
copying Xcode7's linker to
Xcode6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
(make sure you backup the old one of course).


> Unfortunately, it is impossible to test that by
> linking the Xcode 7 build under the Xcode 6 linker because the Xcode 7 build
> uses the 10.11 SDK on 10.10 which needs a linkage on libc++abi.tbd and thus
> requires the new linker with the .tbd support.

Well then I suggest you similarly test using the Xcode 7 compiler with the
Xcode 7 linker and the 10.10 SDK to rule out the SDK as a factor and then test
using the Xcode 7 compiler with the Xcode 6 linker and the 10.10 SDK.

> FYI, The .tbd files are new "text-based stub libraries", that provide a much
> more compact version of the stub libraries for use in the SDK, and help to
> significantly reduce its download size.

[Bug target/67871] LTO falis for ARM big-endian

[jonathan at codesourcery dot com]

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

--- Comment #4 from Jonathan Roelofs  ---
s/ginutils/binutils/

[Bug testsuite/67948] xor-and.c needs updating after r228661

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-15
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
The x86-64 tester also recovered and reports the same failures as the x86 one,
plus a few failures similar to this one on IA-64.

[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc

[bugfeed at online dot de]

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

--- Comment #11 from Leif Leonhardy  ---
(In reply to Jonathan Wakely from comment #2)
> We've had situations in the past where the minimum suggested versions work
> and the latest versions prevented GCC from building.
Well, in the past... ;-)


> The suggested versions
> are known to work and have been thoroughly tested, which might not be true
> of the latest versions.
Sure.

But note that this is not (or no longer) true for at least GMP 4.3.2, assuming
"works" includes "the library's test suite passes [when compiled] with GCC".  

I.e., GMP 4.3.2's test suite contains a subtle bug (fixed long ago, in all
later versions) that will cause a single test (t-scan) to fail when compiled
with GCC 4.8.0 and any later version; it only incidentally doesn't show up with
earlier ones.

While the bug doesn't affect the library code or GCC itself, it is annoying to
users building GCC as well, as most won't know until they report it to
gmp-bugs, which happens pretty often.  (In fact, the error message of course
asks them to do so.  And people are encouraged to run 'make check'.)

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2015-10-15, at 10:32 AM, josephpattara at gmail dot com wrote:

> Is there a similar fix also for the ia64 platform?

I believe a similar fix could be developed along the lines of the change in
comment #7.  I looked at
the 11.31 defines in developing the PA-RISC change.

It would be very helpful if you could work on this and try to develop a fix for
ia64.  Not many have access
to ia64 systems.

Dave
--
John David Anglin   dave.ang...@bell.net

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #17 from Jack Howarth  ---
Okay, I have verified on 10.10 that llvm.org clang 3.6 builds a libunwind.dylib
which doesn't show the boehm-gc test suite regressions but when libunwind.dylib
is built with llvm.org clang 3.7, it does. According to Jeremy, the commit in
llvm which tickled this regression in boehm-gc is...

http://llvm.org/viewvc/llvm-project?view=revision&revision=226751

which caused the symbol ordering to change and resulted in the linker moving
stuff out of __bss into __data.

[Bug c++/67913] new expression with negative size not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-16
 Ever confirmed|0   |1

[Bug c++/67981] New: new expression with zero size not diagnosed

[msebor at gcc dot gnu.org]

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

Bug ID: 67981
   Summary: new expression with zero size not diagnosed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Continuing with new expression conformance issues (bug 67913 and bug 67917):

In 5.3.4, p6, C++ 11 says that "Every constant-expression in a
noptr-new-declarator shall be an integral constant expression (5.19) and
evaluate to a strictly positive value."  C++ 14 has an equivalent requirement.

The following test case shows that gcc doesn't implement this constraint and
accepts a constant expression with a zero value:

$ echo "void* f () { return new char [0]; }" | g++ -Wall -Werror -Wextra
-Wpedantic -c -std=c++11 -xc++ -

[Bug c++/67981] new expression with zero size not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-16
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-16
 Ever confirmed|0   |1

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00915.html

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> It's again a move between a BLKmode RHS and a DImode LHS.  Frankly, I don't
> understand why this is now allowed to reach the RTL expander, we will probably
> need to add conversions on quite a number of paths instead of having a single
> treatment in the VIEW_CONVERT_EXPR case...

This was a outcome of dicussion of the patch:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02392.html

I believe the general idea is that modes should not be part of GIMPLE's type
system
and things will work bit smoother if we do not produce VIEW_CONVERT_EXPRs for
these.
Originally the code also skipped TYPE_MODE checking for aggregates only, but it
checked TYPE_CANONICAL which, at least in a way built by Ada, seems to be never
same for two types of different modes.

Either we commit to this decision and add conversions to the paths as needed
(indeed it seems like there will be quite few) or we can decide that mode
should match.  This should be accomplished by the patch attached which permits
only conversions from incomplete types (where mode ought to be VOIDmode).

This patch bootstraps/regtested ppc64-linux.

Going either way is not going to block my original desire to fix LTO's type
based alias analysis for cross-language cases.  Here I needed to make
TYPE_CANONICAL to match for cases where are not useless_type_conversion, thus
the motivation to get rid of this use of TYPE_CANONICAL and make it agan TBAA
specific.

In this respect I would grealy apprechiate help with adding Ada testcases.
The testcases I added for Fortran basically iterate through list of types
that should be compatible with C variants and checks that TBAA works and that
no surprious warnings are output.
See testsuite/gfortran.dg/lto/bind_c-*

Because I do not understand Ada much, I would really apprechiate if you
or someone at Adacore could prepare Ada variants of these testcases.

Note that I am not done with Fortran and C standards yet - we have at
least two deviations still.  C standard state that order of fields in union
does not matter and Fortran has character type that apparently forces
compatibility between array and scalar char.  I am not sure if the second
can be done reliably (because proably there are ABIs out there that require 
char and array of char of size 1 to be passed differently). Perhaps this
can be handled as a defect in the standard.

There is also case where global variable of Fortran variant of size_t (which
is signed) will produce warning when matched by size_t declared variable.
I have a patch for this but I am looking for cleaner solution.

Index: gimple-expr.c
===
--- gimple-expr.c   (revision 228851)
+++ gimple-expr.c   (working copy)
@@ -88,9 +88,12 @@ useless_type_conversion_p (tree outer_ty
 return true;

   /* Changes in machine mode are never useless conversions unless we
- deal with aggregate types in which case we defer to later checks.  */
+ deal with aggregate types in which case we defer to later checks.
+ For Aggregates we allow casts to incomplete types that always have
+ VOIDmode.  */
   if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type)
-  && !AGGREGATE_TYPE_P (inner_type))
+  && (!AGGREGATE_TYPE_P (inner_type)
+ || COMPLETE_TYPE_P (outer_type)))
 return false;

   /* If both the inner and outer types are integral types, then the

[Bug ipa/67056] [5/6 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  ---
OK, the unreachable is introduced here:
 - Creating a specialized node of bool staticBoolFunc(CompositeClass*)/414 for
all known contexts.
 the new node is /977.
 known ctx 0 is Outer type (dynamic):struct EmptyClass offset -64   
No devirtualization target in /977
ipa-prop: Discovered a virtual call to a known target (/977 -> void
__builtin_unreachable()/976), for stmt OBJ_TYPE_REF(_15;ptr_2(D)->1)
(ptr_2(D));
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/unique_ptr.h:76:2: note:
converting indirect call in  to direct call to void
__builtin_unreachable()
No devirtualization target in /977
ipa-prop: Discovered a virtual call to a known target (/977 -> void
__builtin_unreachable()/976), for stmt OBJ_TYPE_REF(_27;ptr_2(D)->1)
(ptr_2(D));
/aux/hubicka/trunk-install/include/c++/6.0.0/bits/unique_ptr.h:76:2: note:
converting indirect call in  to direct call to void
__builtin_unreachable()

So ipa-CP thinks that staticBoolFunc is called on EmptyClass instead of
CompositeClass:

Jump functions: 
  Jump functions of caller  long unsigned int __builtin_object_size(const
void*, int)/967:
  Jump functions of caller  void operator delete(void*, long unsigned int)/964: 
  Jump functions of caller  void* operator new(std::size_t)/963:
  Jump functions of caller  int main(int, char**)/415:  
callsite  int main(int, char**)/415 -> void operator delete(void*, long
unsigned int)/964 :
callsite  int main(int, char**)/415 -> bool
staticBoolFunc(CompositeClass*)/414 :
   param 0: UNKNOWN 
 Context: Outer type (dynamic):struct EmptyClass offset -64 
 Unknown alignment  
callsite  int main(int, char**)/415 -> EmptyClass::EmptyClass()/404 :   
   param 0: UNKNOWN 
 Context: Outer type (dynamic): (or a derived type) (maybe in
construction) offset 64 Speculative outer type:struct CompositeClass (or a
derived type) at offset 64
 Unknown alignment  

This is indeed wrong. Jump function analysis seems to confuse constructors:

Modification phase of node int main(int, char**)/402
int main(int, char**) (int D.39529, char * * D.39530)
{
  void * _3;
  struct EmptyClass * _7;

  :
  _3 = operator new (16);
  MEM[(struct  &)_3] ={v} {CLOBBER};
  MEM[(struct CompositeClass *)_3]._vptr.CompositeClass = &MEM[(void
*)&_ZTV14CompositeClass + 16B];
  _7 = &MEM[(struct CompositeClass *)_3].object;
  EmptyClass::EmptyClass (_7);

  :
  staticBoolFunc (_3);
  return 0;

:
  operator delete (_3, 16);
  resx 1

EmptyClass ctor is called, but it should not type the object.

Determining dynamic type for call: staticBoolFunc (_3);
  Starting walk at: staticBoolFunc (_3);
  instance pointer: _3  Outer instance pointer: _3 offset: 0 (bits) vtbl
reference: 
  Checking constructor call: EmptyClass::EmptyClass (_7);
  Recording type: struct EmptyClass at offset -64
  Determined dynamic type.

This is quite a nonsense, because EmptyClass is not even. So there are two
bugs.
First is that we determine useless outer type. This should be just missed
optimization. But we also manage to consider to miss the case in placement_new
checking where we are completely off the structure

[Bug ipa/67056] [5/6 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Created attachment 36520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36520&action=edit
Fix I am teching.

[Bug fortran/67982] New: Incorrect -Wunused-function warning

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 67982
   Summary: Incorrect -Wunused-function warning
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The following code illustrates an incorrect -Wunused-function warning:

> cat test.f90
MODULE base
  INTERFACE 
SUBROUTINE bar_int()
END SUBROUTINE 
  END INTERFACE
  PUBLIC hook
  PRIVATE 
  PROCEDURE(bar_int), POINTER :: hook=>NULL()
END MODULE base

MODULE foo
  USE base, ONLY: hook  
  PUBLIC init
  PRIVATE 
CONTAINS
  SUBROUTINE init()
 hook=>bar
  END SUBROUTINE init
  SUBROUTINE bar()
 WRITE(6,*) "In bar"
  END SUBROUTINE 
END MODULE

USE foo, ONLY: init
USE base, ONLY: hook
CALL init()
CALL hook()
END

> gfortran -Wunused-function test.f90
test.f90:19:0:

   SUBROUTINE bar()
 ^
Warning: ‘bar’ defined but not used [-Wunused-function]

> ./a.out
 In bar

[Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
OK, what it does is:
Determining dynamic type for call: _50 = OBJ_TYPE_REF(_47;(struct
basic_streambuf)&ostr._M_stringbuf->13) (&ostr._M_stringbuf, 88);
  Starting walk at: _46 = MEM[(struct basic_streambuf *)&ostr +
8B]._vptr.basic_streambuf;
  instance pointer: &ostr._M_stringbuf  Outer instance pointer: ostr offset: 0
(bits) vtbl reference: MEM[(struct basic_streambuf *)&ostr +
8B]._vptr.basic_streambuf
  Checking constructor call:
std::__cxx11::basic_ostringstream::basic_ostringstream (&ostr, 16);
  Recording type: struct basic_ostringstream at offset 0
  Determined dynamic type.  
  Targets of polymorphic call of type 5:struct basic_streambuf token 13 
Outer type (dynamic):struct basic_ostringstream

Now the code is:

  :
  std::__cxx11::basic_ostringstream::basic_ostringstream (&ostr, 16);
  MEM[(struct  &)&iter] ={v} {CLOBBER};
  MEM[(struct  &)&iter] ={v} {CLOBBER};
  iter._M_sbuf = &ostr._M_stringbuf;
  iter._M_failed = 0;
  _30 = iter._M_failed;
  if (_30 != 0)
goto ;
  else
goto ;

  :
  _32 = iter._M_sbuf;
  _33 = MEM[(char_type * *)_32 + 40B];
  _34 = MEM[(char_type * *)_32 + 48B];
  _35 = _33 < _34;
  _36 = (long int) _35;
  _37 = _36;
  if (_33 < _34)
goto ;
  else
goto ;

  :
  *_33 = 88;
  _38 = MEM[(char_type * *)_32 + 40B];
  _39 = _38 + 1;
  MEM[(char_type * *)_32 + 40B] = _39;
  goto ;

  :
  _46 = MEM[(struct basic_streambuf *)_32]._vptr.basic_streambuf;
  _47 = MEM[(int (*__vtbl_ptr_type) () *)_46 + 104B];
  _50 = OBJ_TYPE_REF(_47;(struct basic_streambuf)_32->13) (_32, 88);

so the analysis looks OK to me.

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Eric,
can you, please, send me info how to reproduce the x86/x86_64 ICEs?

Honza

[Bug c++/67983] New: ICE: Error reporting routines re-entered.

[allan at archlinux dot org]

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

Bug ID: 67983
   Summary: ICE: Error reporting routines re-entered.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: allan at archlinux dot org
  Target Milestone: ---

Created attachment 36521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36521&action=edit
Unreduced testcase

Compiling the attached file with "g++ -std=c++11" causes an ICE:

Internal compiler error: Error reporting routines re-entered.

[Bug c++/67983] ICE: Error reporting routines re-entered.

[allan at archlinux dot org]

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

--- Comment #1 from Allan McRae  ---
Created attachment 36522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36522&action=edit
Reduced testcase

[Bug c++/67983] ICE: Error reporting routines re-entered.

[allan at archlinux dot org]

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

--- Comment #2 from Allan McRae  ---
Observed with gcc-5.2.0 (5-20150623), x86_64, Arch Linux.

[Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
OK,
the problem is that we loss offset of 64.  This happens in get_dynamic_type
where we restrict to inner class and get difference in between offset inside
restricted type and offset from basic instance pointer.

I am testing the following:
Index: ipa-polymorphic-call.c
===
--- ipa-polymorphic-call.c  (revision 228735)
+++ ipa-polymorphic-call.c  (working copy)
@@ -1621,13 +1637,13 @@ ipa_polymorphic_call_context::get_dynami
   print_generic_expr (dump_file, otr_object, TDF_SLIM);
   fprintf (dump_file, "  Outer instance pointer: ");
   print_generic_expr (dump_file, instance, TDF_SLIM);
-  fprintf (dump_file, " offset: %i (bits)", (int)offset);
+  fprintf (dump_file, " offset: %i (bits)", (int)instance_offset);
   fprintf (dump_file, " vtbl reference: ");
   print_generic_expr (dump_file, instance_ref, TDF_SLIM);
   fprintf (dump_file, "\n");
 }

-  tci.offset = offset;
+  tci.offset = instance_offset;
   tci.instance = instance;
   tci.vtbl_ptr_ref = instance_ref;
   gcc_assert (TREE_CODE (instance) != MEM_REF);


will need to re-read the code to double check it works as intended now, but I
would think so ;)

Honza

[Bug ipa/67056] [5/6 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #16 from Jan Hubicka  ---
*** Bug 66738 has been marked as a duplicate of this bug. ***

[Bug ipa/66738] [5/6 Regression] optimizer bug related to exceptions and static symbols

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jan Hubicka  ---
r218024 probably just uncovers symptoms. This is the same negative offset bug
as the other PR.

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

[Bug c/67984] New: "internal compiler error:" with lot of loop optimizations enabled

[inferrna at gmail dot com]

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

Bug ID: 67984
   Summary: "internal compiler error:" with lot of loop
optimizations enabled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: inferrna at gmail dot com
  Target Milestone: ---

Compiler output:

$ gcc dcttest.c -O3 -ftree-loop-vectorize -ftree-loop-distribution
-ftree-parallelize-loops=4  -floop-nest-optimize -floop-interchange 
-floop-strip-mine -floop-block -floop-unroll-and-jam -ftree-loop-ivcanon 
-ftree-loop-if-convert -march=native -lOpenCL -lm -v -save-temps -o dcttest
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-5.real
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.2.1-22ubuntu1'
--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.2.1 20151010 (Ubuntu 5.2.1-22ubuntu1) 
COLLECT_GCC_OPTIONS='-O3' '-ftree-loop-vectorize' '-ftree-loop-distribution'
'-ftree-parallelize-loops=4' '-floop-nest-optimize' '-floop-interchange'
'-floop-strip-mine' '-floop-block' '-floop-unroll-and-jam'
'-ftree-loop-ivcanon' '-ftree-loop-if-convert' '-march=native' '-v'
'-save-temps' '-o' 'dcttest' '-pthread'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
-D_REENTRANT dcttest.c -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3
-mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2
-msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=haswell
-ftree-loop-vectorize -ftree-loop-distribution -ftree-parallelize-loops=4
-floop-nest-optimize -floop-interchange -floop-strip-mine -floop-block
-floop-unroll-and-jam -ftree-loop-ivcanon -ftree-loop-if-convert -O3
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o
dcttest.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-ftree-loop-vectorize' '-ftree-loop-distribution'
'-ftree-parallelize-loops=4' '-floop-nest-optimize' '-floop-interchange'
'-floop-strip-mine' '-floop-block' '-floop-unroll-and-jam'
'-ftree-loop-ivcanon' '-ftree-loop-if-convert' '-march=native' '-v'
'-save-temps' '-o' 'dcttest' '-pthread'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -fpreprocessed dcttest.i -march=haswell
-mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe
-maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi
-mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle
-mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave
-mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf
-mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq
-mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb
-mno-pcommit -mno-mwaitx --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=3072 -mtune=haswell -quiet -dumpbase dc

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #18 from Jack Howarth  ---
The upstream commit...

https://github.com/ivmai/bdwgc/commit/faef04e7cb3741163dfdf65900ef5d2a0530be0f

2011-02-09 Ivan Maidanski 
* src/atomic_ops.c (AO_USE_NO_SIGNALS, AO_USE_NANOSLEEP): New
macros.
* src/atomic_ops.c (AO_USE_WIN32_PTHREADS): Imply
AO_USE_NO_SIGNALS.
* src/atomic_ops.c: Don't include signal.h if AO_USE_NO_SIGNALS.
* src/atomic_ops.c: Include time.h if AO_USE_NANOSLEEP.
* src/atomic_ops.c (AO_locks, AO_pause): Reformat the code.
* src/atomic_ops.c (AO_pause): Use nanosleep() if
AO_USE_NANOSLEEP.
* src/atomic_ops.c (all_sigs, initialized,
AO_compare_and_swap_emulation,
AO_compare_double_and_swap_double_emulation): Use
AO_USE_NO_SIGNALS instead of AO_USE_WIN32_PTHREADS.

potentially could contain useful change for darwin. This is the specific commit
in between the 7.2alpha4 and 7.2alpha6 releases which eliminates the test suite
failures on darwin. The caveat is that these failures are for all darwin and
not just darwin15.