[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

[pault at gcc dot gnu.org]

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

--- Comment #17 from Paul Thomas  ---
Author: pault
Date: Wed Aug 31 05:36:22 2016
New Revision: 239880

URL: https://gcc.gnu.org/viewcvs?rev=239880=gcc=rev
Log:
2016-08-31  Paul Thomas  
Jerry DeLisle  

PR fortran/48298

* decl.c (access_attr_decl): Include case INTERFACE_DTIO as
appropriate.
* gfortran.h : Add INTRINSIC_FORMATTED and
INTRINSIC_UNFORMATTED to gfc_intrinsic_op. Add INTERFACE_DTIO
to interface type. Add new enum 'dtio_codes'. Add bitfield
'has_dtio_procs' to symbol_attr. Add prototypes
'gfc_check_dtio_interfaces' and 'gfc_find_specific_dtio_proc'.
* interface.c (dtio_op): New function.
(gfc_match_generic_spec): Match generic DTIO interfaces.
(gfc_match_interface): Treat DTIO interfaces in the same way as
(gfc_current_interface_head): Add INTERFACE_DTIO appropriately.
(check_dtio_arg_TKR_intent): New function.
(check_dtio_interface1): New function.
(gfc_check_dtio_interfaces): New function.
(gfc_find_specific_dtio_proc): New function.
* io.c : Add FMT_DT to format_token.
(format_lex): Handle DTIO formatting.
* match.c (gfc_op2string): Add DTIO operators.
* resolve.c (derived_inaccessible): Ignore pointer components
to enclosing derived type.
(resolve_transfer): Resolve transfers that involve DTIO.
procedures. Find the specific subroutine for the transfer and
use its existence to over-ride some of the constraints on
derived types. If the transfer is recursive, require that the
subroutine be so qualified.
(dtio_procs_present): New function.
(resolve_fl_namelist): Remove inhibition of polymorphic objects
in namelists if DTIO read and write subroutines exist. Likewise
for derived types.
(resolve_types): Invoke 'gfc_verify_dtio_procedures'.
* symbol.c : Set 'dtio_procs' using 'minit'.
* trans-decl.c (gfc_finish_var_decl): If a derived-type/class
object is associated with DTIO procedures, make it TREE_STATIC.
* trans-expr.c (gfc_get_vptr_from_expr): If the expression
drills down to a PARM_DECL, extract the vptr correctly.
(gfc_conv_derived_to_class): Check 'info' in the test for
'useflags'. If the se expression exists and is a pointer, use
it as the class _data.
* trans-io.c : Add IOCALL_X_DERIVED to iocall and the function
prototype. Likewise for IOCALL_SET_NML_DTIO_VAL.
(set_parameter_tree): Renamed from 'set_parameter_const', now
returns void and has new tree argument. Calls modified to match
new interface.
(transfer_namelist_element): Transfer DTIO procedure pointer
and vpointer using the new function IOCALL_SET_NML_DTIO_VAL.
(get_dtio_proc): New function.
(transfer_expr): Add new argument for the vptr field of class
objects. Add the code to call the specific DTIO proc, convert
derived types to class and call IOCALL_X_DERIVED.
(trans_transfer): Add BT_CLASS to structures for treatment by
the scalarizer. Obtain the vptr for the dynamic type, both for
scalar and array transfer.

2016-08-31  Jerry DeLisle  
Paul Thomas  

PR libgfortran/48298
* gfortran.map : Flag _st_set_nml_dtio_var and
_gfortran_transfer_derived.
* io/format.c (format_lex): Detect DTIO formatting.
(parse_format_list): Parse the DTIO format.
(next_format): Include FMT_DT.
* io/format.h : Likewise. Add structure 'udf' to structure
'fnode' to carry the IOTYPE string and the 'vlist'.
* io/io.h : Add prototypes for the two types of DTIO subroutine
and a typedef for gfc_class. Also, add to 'namelist_type'
fields for the pointer to the DTIO procedure and the vtable.
Add fields to struct st_parameter_dt for pointers to the two
types of DTIO subroutine. Add to gfc_unit DTIO specific fields.
(internal_proto): Add prototype for 'read_user_defined' and
'write_user_defined'.
* io/list_read.c (check_buffers): Use the 'current_unit' field.
(unget_char): Likewise.
(eat_spaces): Likewise.
(list_formatted_read_scalar): For case BT_CLASS, call the DTIO
procedure.
(nml_get_obj_data): Likewise when DTIO procedure is present,.
* io/transfer.c : Export prototypes for 'transfer_derived' and
'transfer_derived_write'.
(unformatted_read): For case BT_CLASS, call the DTIO procedure.
(unformatted_write): Likewise.
(formatted_transfer_scalar_read): Likewise.
(formatted_transfer_scalar_write: Likewise.
(transfer_derived): New function.
(data_transfer_init): Set 

[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-08/msg02099.ht
   ||ml

[Bug target/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Another similar test case, but thi sone I'm able to make fail on a 64-bit LE
compile.

bergner@genoa:~/gcc/BUGS/PR77289$ cat q.i
void dummy (long *);
long bar (long);
void
foo (long a, long b)
{
  long array[128];
  long *c = array;
  for (b=0; b < a; b++)
c[b] = bar (c[b]);
  dummy (c);
}
bergner@genoa:~/gcc/BUGS/PR77289$
/home/bergner/gcc/build/gcc-fsf-mainline-pr77289/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr77289/gcc -O3 -mcpu=power7
-funroll-loops -ffast-math -mlra -S -mupdate -fno-auto-inc-dec q.i
bergner@genoa:~/gcc/BUGS/PR77289$
/home/bergner/gcc/build/gcc-fsf-mainline-pr77289-base/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr77289-base/gcc -O3 -mcpu=power7
-funroll-loops -ffast-math -mlra -S -mupdate -fno-auto-inc-dec q.i
q.i: In function ‘foo’:
q.i:11:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 91 93 92 15 (parallel [
(set (reg:DI 3 3)
(mem:DI (plus:DI (reg/f:DI 1 1)
(const_int 40 [0x28])) [1 MEM[base: _7, offset: 0B]+0
S8 A64]))
(set (reg:DI 31 31 [orig:209 ivtmp.9 ] [209])
(plus:DI (reg/f:DI 1 1)
(const_int 40 [0x28])))
]) q.i:9 590 {*movdi_update1}
 (nil))

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

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

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #24 from Bill Schmidt  ---
This seems to work as a short-term solution (c,c++,ada bootstrap succeeds). 
Need to do a full regstrap with all the languages.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 239871)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -24506,15 +24506,31 @@ rs6000_split_multireg_move (rtx dst, rtx src)
  && REG_P (basereg)
  && REG_P (offsetreg)
  && REGNO (basereg) != REGNO (offsetreg));
- if (REGNO (basereg) == 0)
+ /* We mustn't modify the stack pointer or frame pointer
+as this will confuse dead store elimination.  */
+ if ((REGNO (basereg) == STACK_POINTER_REGNUM
+  || REGNO (basereg) == HARD_FRAME_POINTER_REGNUM)
+ && REGNO (offsetreg) != 0)
{
- rtx tmp = offsetreg;
- offsetreg = basereg;
- basereg = tmp;
+ emit_insn (gen_add3_insn (offsetreg, basereg,
+   offsetreg));
+ restore_basereg = gen_sub3_insn (offsetreg, offsetreg,
+  basereg);
+ dst = replace_equiv_address (dst, offsetreg);
}
- emit_insn (gen_add3_insn (basereg, basereg, offsetreg));
- restore_basereg = gen_sub3_insn (basereg, basereg,
offsetreg);
- dst = replace_equiv_address (dst, basereg);
+ else
+   {
+ if (REGNO (basereg) == 0)
+   {
+ rtx tmp = offsetreg;
+ offsetreg = basereg;
+ basereg = tmp;
+   }
+ emit_insn (gen_add3_insn (basereg, basereg, offsetreg));
+ restore_basereg = gen_sub3_insn (basereg, basereg,
+  offsetreg);
+ dst = replace_equiv_address (dst, basereg);
+   }
}
}
  else if (GET_CODE (XEXP (dst, 0)) != LO_SUM)

[Bug rtl-optimization/77416] LRA rematerializing use of CA reg across function call

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-30
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug rtl-optimization/77416] New: LRA rematerializing use of CA reg across function call

[pthaugen at gcc dot gnu.org]

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

Bug ID: 77416
   Summary: LRA rematerializing use of CA reg across function call
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje.gcc at gmail dot com,
vmakarov at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

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

CPU2006 benchmark 445.gobmk started failing verification of output starting
with r239105 (switch rs6000 port to LRA). I tracked it down to code where LRA
is rematerializing the use of the CA reg across a function call, which is not
valid since a call can clobber it.

Before the switch to LRA we saw the following code:

addic 9,9,-1
addze 9,16
stw 9,492(1)
... code with function call(s)
lwz 9,492(1)


After LRA switch the code looks like this:

addic 9,9,-1
addze 9,16
stw 9,492(1)
... code with function call(s)
addze 9,16


Compile options for reduced testcase: gcc -S -O2 -m32 -mcpu=power7

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #23 from Bill Schmidt  ---
Bleah, that doesn't work because offsetreg needs to contain something that's a
valid address in order to use replace_equiv_address.  So something more
involved is needed.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #22 from Michael Meissner  ---
Note, if the index register is R0 and the base register is SP, you might not be
able to use the other register (well you can use it, but you likely will get a
segmentation fault or just access the wrong memory).

I would at least put in a gcc_assert to make sure it isn't R0.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #21 from Bill Schmidt  ---
I think for the purposes of this bug we should be able to work around it by
forcing the offset register to be modified instead of the base register.  Going
to try testing this:

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 239871)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -24506,7 +24506,9 @@ rs6000_split_multireg_move (rtx dst, rtx src)
  && REG_P (basereg)
  && REG_P (offsetreg)
  && REGNO (basereg) != REGNO (offsetreg));
- if (REGNO (basereg) == 0)
+ if (REGNO (basereg) == 0
+ || REGNO (basereg) == STACK_POINTER_REGNUM
+ || REGNO (basereg) == HARD_FRAME_POINTER_REGNUM)
{
  rtx tmp = offsetreg;
  offsetreg = basereg;

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #20 from Michael Meissner  ---
Yeah, it sounds like you don't want to adjust any of the stack related
registers.

However, in looking at this $#!%, we probably need to rewrite it so it doesn't
do clever tricks like this.  Which probably means a trip through the whole
legitimize addressing support and secondary reload.

One thing that might help is removing the test for TARGET_QUAD_WORD around line
9448 of rs6000.c, and look for other places in rs6000.c that TImode and
TARGET_QUAD_WORD are mentioned near each other.

On LE systems, TARGET_QUAD_WORD is false because the LQ/STQ load the words in
the wrong order.

One consequence of this is it only allows TImode value addresses to be a single
register, on the other hand, when you are moving TImode in GPRs, you can use
D-FORM addressing to address the secondary parts.

In theory, PRE_MODIFY, PRE_INC, and PRE_DEC should never be set for TImode.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #19 from Bill Schmidt  ---
I'm suspicious of rs6000_split_multireg_move in rs6000.c, which appears to be
the code that gets called to split a TImode move involving a GPR pair.

In particular, this code:

  else
{
  rtx basereg = XEXP (XEXP (dst, 0), 0);
  rtx offsetreg = XEXP (XEXP (dst, 0), 1);
  gcc_assert (GET_CODE (XEXP (dst, 0)) == PLUS
  && REG_P (basereg)
  && REG_P (offsetreg)
  && REGNO (basereg) != REGNO (offsetreg));
  if (REGNO (basereg) == 0)
{
  rtx tmp = offsetreg;
  offsetreg = basereg;
  basereg = tmp;
}
  emit_insn (gen_add3_insn (basereg, basereg, offsetreg));
  restore_basereg = gen_sub3_insn (basereg, basereg,
offsetreg)\
;
  dst = replace_equiv_address (dst, basereg);
}

(Later on, restore_basereg is used to put the basereg back where it was before.
 This looks exactly like the case we're seeing.)

I don't think we should allow going through this logic if basereg is the stack
pointer or the frame pointer.  Mike, what do you think?

[Bug fortran/77415] ICE: tree check: expected function_type or method_type, have pointer_type in create_function_arglist, at fortran/trans-decl.c:2263

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

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

--- Comment #1 from Gerhard Steinmetz  
---

With official releases (configured with --enable-checking=release),
down to at least 4.8 :


$ gfortran-6 z1.f90
z1.f90:1:0:

 integer function f()

internal compiler error: in make_decl_rtl, at varasm.c:1292

[Bug fortran/77415] New: ICE: tree check: expected function_type or method_type, have pointer_type in create_function_arglist, at fortran/trans-decl.c:2263

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

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

Bug ID: 77415
   Summary: ICE: tree check: expected function_type or
method_type, have pointer_type in
create_function_arglist, at fortran/trans-decl.c:2263
   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 :


$ cat z1.f90
integer function f()
   f(g) = 0
contains
   integer function g()
   end
end


$ cat z2.f90
function f()
   f(g) = 0
contains
   function g()
   end
end


$ gfortran-7-20160828 z1.f90   # configured with --enable-checking=yes
z1.f90:1:0:

 integer function f()

internal compiler error: tree check: expected function_type or method_type,
have pointer_type in create_function_arglist, at fortran/trans-decl.c:2263
0xeaf81c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9742
0x742d2d tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc/tree.h:3045
0x742d2d create_function_arglist
../../gcc/fortran/trans-decl.c:2263
0x746bb9 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2820
0x74f349 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5185
0x74f349 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6143
0x6db090 translate_all_program_units
../../gcc/fortran/parse.c:5910
0x6db090 gfc_parse_file()
../../gcc/fortran/parse.c:6116
0x71d3a2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville.voutilainen at gmail dot com]

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

--- Comment #6 from Ville Voutilainen  ---
Fixed on trunk, backporting to the gcc-6 branch.

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville at gcc dot gnu.org]

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

--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Aug 30 18:46:11 2016
New Revision: 239870

URL: https://gcc.gnu.org/viewcvs?rev=239870=gcc=rev
Log:
PR libstdc++/77395
* include/std/type_traits (is_constructible): Forward-declare...
(__is_base_to_derived_ref): ...and use here.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust.
* testsuite/20_util/is_constructible/77395.cc: New.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/tuple/77395.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc
  - copied, changed from r239867,
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/77395.cc
  - copied, changed from r239867,
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
The frame pointer adjustments are introduced in 263r.split2.  I haven't yet run
down the offending split, but the pattern being split is a *vsx_movti_64bit.  I
know we've had changes in the back end fairly recently involving TImode moves,
so this may be why the problem didn't show up before.

I think DSE relies on the stack being fairly well behaved; it probably
shouldn't be making assumptions when the frame pointer is messed with like this
during the function.  Which means doing this sort of thing is bad for
optimization anyway, and should be avoided.  I'll look further.

[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410

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

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

--- Comment #1 from Gerhard Steinmetz  
---

Backup tests, more variants :

$ cat z2.f90
subroutine s(x)
   real :: x
contains
   subroutine s(x)
  character(*) :: x
   end
end

$ cat z3.f90
subroutine s(x)
   real :: x
contains
   subroutine s(x)
  character(:), allocatable :: x
   end
end

$ cat z4.f90
subroutine s(x)
   character(*) :: x
contains
   subroutine s(x)
  character(:), allocatable :: x
   end
end


---

Generating backtrace from pr44348 :

$ cat z7.f90
subroutine s(x)
   character(*) :: x
contains
   subroutine s(x)
  real :: x
   end
end

$ cat z8.f90
subroutine s(x)
   character(*) :: x
contains
   subroutine s(x)
  real :: x(*)
   end
end

$ cat z9.f90
subroutine s(x)
   character(*) :: x
contains
   subroutine s(x)
  character :: x(*)
   end
end

[Bug fortran/77414] New: ICE in create_function_arglist, at fortran/trans-decl.c:2410

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

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

Bug ID: 77414
   Summary: ICE in create_function_arglist, at
fortran/trans-decl.c:2410
   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, related to pr44348 :


$ cat z1.f90
subroutine s(x)
   character(*) :: x
contains
   subroutine s(x)
  character(*) :: x
   end
end


$ gfortran-7-20160828 z1.f90
z1.f90:4:0:

subroutine s(x)

internal compiler error: in create_function_arglist, at
fortran/trans-decl.c:2410
0x742cf1 create_function_arglist
../../gcc/fortran/trans-decl.c:2410
0x746bb9 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2820
0x74f349 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5185
0x74f349 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6143
0x6db090 translate_all_program_units
../../gcc/fortran/parse.c:5910
0x6db090 gfc_parse_file()
../../gcc/fortran/parse.c:6116
0x71d3a2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/44348] ICE in build_function_decl

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

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

--- Comment #12 from Gerhard Steinmetz  
---
Slightly modified variant :


$ cat z7.f90
subroutine s(x)
contains
   subroutine s(x)
   end
end


$ gfortran-7-20160828 z7.f90
z7.f90:3:0:

subroutine s(x)

internal compiler error: in gfc_generate_function_code, at
fortran/trans-decl.c:6100
0x751496 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6100
0x74f357 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5194
0x74f357 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6143
0x6db090 translate_all_program_units
../../gcc/fortran/parse.c:5910
0x6db090 gfc_parse_file()
../../gcc/fortran/parse.c:6116
0x71d3a2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug tree-optimization/22041] Reverse loop order for increased efficiency

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2013-03-17 12:00:00 |2016-8-30

--- Comment #9 from Thomas Koenig  ---
Still the same - we have an additional instruction in the first
variant.  It is

movss   (%rsi), %xmm0
addl$1, %eax
addq%r8, %rsi
movss   %xmm0, (%rdi)
addq%rcx, %rdi
cmpl%eax, %edx
jne .L3


vs.

.L3:
movss   (%rsi), %xmm0
addq%r8, %rsi
movss   %xmm0, (%rdi)
addq%rcx, %rdi
subl$1, %edx
jne .L3

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
> Is this kind of frame pointer adjustment a common occurrence with Ada code
> gen, or do you think this is related to POWER code gen somehow?  I've never
> seen this sort of thing before.

No, that's really weird, but the indices of the 4 instructions show that they
have been generated as a group after the initial RTL expansion.  Can you find
you which RTL pass generates them and attach the associated couple of dump
files?

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Looks like the back end must be inserting the frame pointer adjustments, as
they aren't there at expand time.  From the 218.vregs dump:

(call_insn 141 140 3128 2 (parallel [
(set (reg:TI 3 3)
(call (mem:SI (symbol_ref:DI
("system__secondary_stack__ss_mark\
") [flags 0x41]  ) [0 system__secondary_stack__ss_mark S4 A8])
(const_int 0 [0])))
(clobber (reg:DI 65 lr))
]) /home/wschmidt/gcc/gcc-mainline-base/gcc/ada/make.adb:6327 661
{*cal\
l_value_nonlocal_aixdi}
 (expr_list:REG_CALL_DECL (symbol_ref:DI
("system__secondary_stack__ss_mark\
") [flags 0x41]  )
(nil))
(expr_list (use (reg:DI 2 2))
(nil)))
(insn 3128 141 142 2 (set (reg:DI 1674)
(const_int 1208 [0x4b8]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 -1
 (nil))
(insn 142 3128 143 2 (set (mem/j/c:TI (plus:DI (reg/f:DI 113 sfp)
(reg:DI 1674)) [1137 FRAME.2381.M1944b+0 S16 A64])
(reg:TI 3 3))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/make.adb:632\
7 975 {*vsx_movti_64bit}
 (nil))

I'll continue to dig.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #10 from Jeff Hammond  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Jeff Hammond from comment #8)
> > So GCC refuses to compile any code that potentially includes undefined
> > behavior?
> 
> Semantics not being defined is different than undefined behavior.

GCC happily compiles a C++11 OpenMP program that is equivalent to the C11
OpenMP program that it will not compile.

GCC happily compiles the following Fortran 2008 OpenMP program that actually
does something that could be considered undefined.

$ gfortran-6 -fopenmp -std=f2008 -fcoarray=single caf-openmp.f 
$ cat caf-openmp.f 
  program atomic
  use iso_fortran_env
  use omp_lib
  implicit none
  integer :: i
  integer(atomic_int_kind) :: atom[*]
  call atomic_define (atom[1], this_image())
  !$OMP ATOMIC
  atom[1] = -this_image()
  end program atomic

If you want to break user experience for OpenMP programmers, please do it
systematically.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Jeff Hammond from comment #8)
> So GCC refuses to compile any code that potentially includes undefined
> behavior?

Semantics not being defined is different than undefined behavior.

[Bug middle-end/20432] complex reciprocal has too many operations

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2008-12-11 21:22:46 |2016-8-30
 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
Still an issue:

#include 
#include 

int main()
{
float complex c,d;
foo();
d=1.0f/c;
return creal(d)+cimag(d)<0;
}

Using -fcx-fortran-rules yields (from the optimized dump)

  _13 = REALPART_EXPR ;
  _14 = IMAGPART_EXPR ;
  _15 = ABS_EXPR <_13>;
  _16 = ABS_EXPR <_14>;
  if (_15 < _16)
goto ;
  else
goto ;

  :
  _18 = _13 / _14;
  _19 = _13 * _18;
  _20 = _14 + _19;
  _21 = _18 + 0.0;
  _22 = _18 * 0.0;
  _23 = _22 - 1.0e+0;
  _24 = _21 / _20;
  _25 = _23 / _20;
  goto ;

  :
  _26 = _14 / _13;
  _27 = _14 * _26;
  _28 = _13 + _27;
  _29 = _26 * 0.0;
  _30 = _29 + 1.0e+0;
  _31 = 0.0 - _26;
  _32 = _30 / _28;
  _33 = _31 / _28;


I do not think it is possible to create a NaN/Inf situation here
where just ignoring the imaginary zero is wrong.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #8 from Jeff Hammond  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jeff Hammond from comment #3)
> > Do you seriously pick this one time to prevent the user from even trying to
> > write incorrect code, while allowing an uncountable number of others?
> 
> This is different because the semantics are not defined at all.

So GCC refuses to compile any code that potentially includes undefined
behavior?

Please tell me about the undefined behavior in the following program, when
compiled with -fopenmp:

#include 

int main(void)
{
return 0;
}

> > One of the motivations for writing code that mixes C11 and OpenMP is because
> > I am a member of the OpenMP working group devoted to supporting C11 and
> > C++14 in the OpenMP standard.  By refusing to allow me to experiment with
> > OpenMP+C11, you actively harm progress in the OpenMP standard that would
> > allow you to resolve the semantic ambiguity that motivated disabling
> > C11+OpenMP in the first place.
> 
> If you are part of the working group then you should be able to help define
> the semantics instead of complaining we disable things :).

As I said already, I am trying to define them, but that has nothing to do with
the fact that GCC unnecessary broke an infinite number of valid programs.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #7 from Jeff Hammond  ---
The fact that the parser doesn't handle a particle case where something might
go wrong is no reason to have the compiler refuse to compile code that includes
stdatomic.h with -fopenmp.  Look at my example and tell me what possible thing
can go wrong in it that justifies aborting the compilation.

This sort of attack on user experience is unprecedented in my career of
programming.  Do you break every other mixture of programming standard
semantics that is currently undefined?  I can think of others that GCC allows,
but will not list them, out of fear that someone will decide to break those as
well.

At most, this should have been a warning to indicate to the user that OpenMP
constructs do not correctly interact with _Atomic and the user should take care
to rely on only what is supported by ISO C11 and OpenMP 4.5.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
Created attachment 39520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39520=edit
Dumps before and after dse2

Here are the full dumps before and after dse2 in tarball form.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jeff Hammond from comment #3)
> Do you seriously pick this one time to prevent the user from even trying to
> write incorrect code, while allowing an uncountable number of others?

This is different because the semantics are not defined at all.

> 
> One of the motivations for writing code that mixes C11 and OpenMP is because
> I am a member of the OpenMP working group devoted to supporting C11 and
> C++14 in the OpenMP standard.  By refusing to allow me to experiment with
> OpenMP+C11, you actively harm progress in the OpenMP standard that would
> allow you to resolve the semantic ambiguity that motivated disabling
> C11+OpenMP in the first place.

If you are part of the working group then you should be able to help define the
semantics instead of complaining we disable things :).

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
From the original discussions on why this is disabled:
_Atomic support is currently disabled for Objective-C and OpenMP.  For
both (but mainly OpenMP), the relevant parser code needs checking to
determine where convert_lvalue_to_rvalue calls need inserting to
ensure that accesses to atomic variables involve atomic loads.  For
Objective-C, there are also various special cases of compound
assignment that need special handling for atomics just as standard C
compound assignment is handled differently for atomics, as well as
some TYPE_MAIN_VARIANT calls to check for correctness for atomics; see
the comment on the relevant sorry () call for details.  OpenMP should
also have TYPE_MAIN_VARIANT uses checked as well as a use of
TYPE_QUALS_NO_ADDR_SPACE for a diagnostic in
c_parser_omp_declare_reduction (where the diagnostic refers to a
particular list of qualifiers).

So it looks like there is more than even what Jakub listed.

Also patches are welcome to handle OpenMP and _Atomic better.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
Confirmed that the frame pointer dance is where the issue is.  Prior to dse2:

(insn 3854 144 4133 2 (set (reg:DI 9 9 [1674])
(const_int 1208 [0x4b8]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 565 {*movdi_internal64}
 (expr_list:REG_EQUIV (const_int 1208 [0x4b8])
(nil)))
(insn 4133 3854 4135 2 (set (reg/f:DI 31 31)
(plus:DI (reg/f:DI 31 31)
(reg:DI 9 9 [1674])))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 75 {*adddi3}
 (nil))
(insn 4135 4133 4136 2 (set (mem/j/c:DI (reg/f:DI 31 31) [1137
FRAME.2381.M1944\
b+0 S8 A64])
(reg:DI 3 3))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/make.adb:632\
7 565 {*movdi_internal64}
 (nil))
(insn 4136 4135 4134 2 (set (mem/j/c:DI (plus:DI (reg/f:DI 31 31)
(const_int 8 [0x8])) [1137 FRAME.2381.M1944b+8 S8 A64])
(reg:DI 4 4 [+8 ]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/make.a\
db:6327 565 {*movdi_internal64}
 (nil))
(insn 4134 4136 3868 2 (set (reg/f:DI 31 31)
(minus:DI (reg/f:DI 31 31)
(reg:DI 9 9 [1674])))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 102 {*subfdi3}
 (nil))

You can see the "mark" being established with the stores from r3 and r4.

Following dse2:

(insn 3854 144 4133 2 (set (reg:DI 9 9 [1674])
(const_int 1208 [0x4b8]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 565 {*movdi_internal64}
 (expr_list:REG_EQUIV (const_int 1208 [0x4b8])
(nil)))
(insn 4133 3854 4134 2 (set (reg/f:DI 31 31)
(plus:DI (reg/f:DI 31 31)
(reg:DI 9 9 [1674])))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 75 {*adddi3}
 (nil))
(insn 4134 4133 3868 2 (set (reg/f:DI 31 31)
(minus:DI (reg/f:DI 31 31)
(reg:DI 9 9 [1674])))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
make.adb:6327 102 {*subfdi3}
 (expr_list:REG_DEAD (reg:DI 9 9 [1674])
(nil)))

DSE thought the two stores were dead and nuked them.

Is this kind of frame pointer adjustment a common occurrence with Ada code gen,
or do you think this is related to POWER code gen somehow?  I've never seen
this sort of thing before.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #4 from Jeff Hammond  ---
Apparently, the GCC team wants to make it impossible for anyone to build
software where independent components that share CFLAGS in the build system
cannot use both the C11 atomics header and the OpenMP flag.  It doesn't matter
if you use either feature, literally including stdatomic.h and compiling with
-fopenmp is impossible.

So projects that use autotools and support CFLAGS=-fopenmp now need to
segregate the build system to compile any source files that include stdatomic.h
using a different set of options from the default?

It is really hard to imagine how someone came to the conclusion this was a
reasonable thing to do.

Anyways, here is the trivial test program that is broken by CFLAGS=-fopenmp.

#include 

int main(void)
{
return 0;
}

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

[saaadhu at gcc dot gnu.org]

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

--- Comment #21 from Senthil Kumar Selvaraj  ---
It occurs with "7.0.0 20160824 (experimental) (GCC)". Besides, the errors go
away if I remove --relax, so I think it's a linker issue.

[Bug middle-end/66240] RFE: extend -falign-xyz syntax

[vda.linux at googlemail dot com]

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

--- Comment #5 from Denis Vlasenko  ---
Patches v3 posted to the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02073.html
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02074.html

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[renlin at gcc dot gnu.org]

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

--- Comment #11 from Renlin Li  ---
(In reply to Christophe Lyon from comment #10)
> I've noticed that something similar to what Renlin suggested was committed
> to trunk as r238728.
> 
> Could this testcase fix be backported to the release branches too?

Yes, the failure can still be observed in branch 49 and 5.
It will be good to backport the fix to those branches.

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> I'm getting my head around this now! The conversion functions will need to
> perform the 32-bit to 64-bit sign extension but do nothing for the reverse.
> I think this means that only the raw-to-rvalue needs updating based on the
> function names.

My understanding as well.

> I'll give it a go.

Thanks in advance.  The other change to java/lang/reflect/natVMProxy.cc looks
correct because it uses the regular API.  And reverting the interpret-run.cc
change alone indeed eliminates all the regressions reported by Rainer.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
> Yes, it does!  The tools appear to be building normally with this option. 
> Without it the build of gnattools fails almost immediately.
> 
> I'll work on getting some dumps to see what is happening in DSE.

Thanks in advance, that would be great.  The weird dance with FP can certainly
be a mightily confusing factor for the RTL DSE pass.

On my side, I have bootstrapped on good old 32-bit PowerPC/Linux and Ada is in
nominal shape here (we're slowing migrating to 64-bit... big-endian for now).
Thanks to Marc, I'll try to reproduce the issue on gcc2-power8, but the system
compiler doesn't come with Ada so this may take some time.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #3 from Jeff Hammond  ---
This is awful.  How do I disable this horrible thing?

I am using OpenMP to create a thread pool, because C11 threads are still not
implemented in glibc, and all of my access to C11 _Atomic variables use C11
atomic operations, so my code is correct.  Do you seriously pick this one time
to prevent the user from even trying to write incorrect code, while allowing an
uncountable number of others?

One of the motivations for writing code that mixes C11 and OpenMP is because I
am a member of the OpenMP working group devoted to supporting C11 and C++14 in
the OpenMP standard.  By refusing to allow me to experiment with OpenMP+C11,
you actively harm progress in the OpenMP standard that would allow you to
resolve the semantic ambiguity that motivated disabling C11+OpenMP in the first
place.

[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[jakub at gcc dot gnu.org]

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

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 39519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39519=edit
gcc7-pr77374.patch

Untested fix.

[Bug c/63336] cilkplus array notation ICE in find_rank

[yves.vandriessche at intel dot com]

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

--- Comment #10 from Yves Vandriessche  ---
A similar internal compile error is triggered in find_rank when dealing with
two-dimensional array arguments, for both g++-5.2 and g++-6.1.1.

>void test(double Arr[][16]) {
>  double A[16]= {0};
>  for(int i=0; i<4; i++) {
>A[:] += Arr[i][:]; // internal compile error:
>   // in find_rank, at c-family/array-notation-common.c:232
>  }
>  printf("%f \n", A[0]);
>}

This only happens on two-dimensional arrays. Passing a regular array (e.g.
Arr[16]) correctly yields a normal compile error (not an ICE); start-index and
length cannot be determined as `double Arr[16]` degenerates into `double *Arr`.

Complete test code has been attached attached.

[Bug c/63336] cilkplus array notation ICE in find_rank

[yves.vandriessche at intel dot com]

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

--- Comment #9 from Yves Vandriessche  ---
Created attachment 39518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39518=edit
2D-array cilk array notation ICE test case

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
(In reply to Eric Botcazou from comment #10)
> > So the double-word load before the call to SS_Release should be from a
> Mark_Id object obtained from a preceding call to SS_Mark.  It indeed looks
> like the double-word store to this Mark_Id object has been optimized away,
> possibly because of the strange back-and-forth adjustment to the FP.  Does
> passing CFLAGS="-O2 -fno-dse" for the gnattools make a difference?

Yes, it does!  The tools appear to be building normally with this option. 
Without it the build of gnattools fails almost immediately.

I'll work on getting some dumps to see what is happening in DSE.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
(In reply to Eric Botcazou from comment #8)
> > I'm afraid I don't know anything about Ada and how its runtime works; it
> > looks like system.secondary_stack.ss_release is called automatically somehow
> > as part of entering make.Initialize, but I have no idea if that's supposed
> > to happen.  It seems questionable at first glance.
> 
> Unfortunately I don't seem to be able to connect to gcc112 in the
> CompileFarm:
> 
> eric@arcturus:~> ssh -l ebotcazou gcc112.osuosl.org
> ssh: Could not resolve hostname gcc112.osuosl.org: Name or service not known
> 
> Try to recompile the gnattools with reload instead of LRA, for example:
>   rm -rf gnattools gcc/ada/tools gcc/stamp-tools
>   make all-gnattools CFLAGS="-O2 -mno-lra"
> 
> Does this eliminate the problem?

No, unfortunately it doesn't; I see the same error.  I'll try the DSE
experiment now.

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[matthew.fortune at imgtec dot com]

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

--- Comment #10 from Matthew Fortune  ---
(In reply to Eric Botcazou from comment #9)
> > I'll certainly check on this but I did run the fix on both big and little
> > endian MIPS which seems to suggest there isn't a double adjustment overall.
> 
> So this was broken in 64-bit big-endian too before your fix?

Ah, I did BE/LE 32-bit and LE 64-bit. The bug was seen on LE 64-bit.

I'm getting my head around this now! The conversion functions will need to
perform the 32-bit to 64-bit sign extension but do nothing for the reverse. I
think this means that only the raw-to-rvalue needs updating based on the
function names.

I'll give it a go.

[Bug tree-optimization/59124] [5/6/7 Regression] Wrong warnings "array subscript is above array bounds"

[szotsaki at gmail dot com]

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

--- Comment #43 from Szőts Ákos  ---
Yes, I can agree with this reasoning. However, when you remove either the
"while" or the "if" statements, the warning disappears. I don't think they
should have any influence on the array_size.

[Bug tree-optimization/69270] DOM should exploit range information to create more equivalences

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #6 from mwahab at gcc dot gnu.org ---
The new test gcc.dg/tree-ssa/pr69270-3.c fails on aarch64 and arm targets.

There seems to be a disparity between the expected output directive and the
comment preceding it. The directive seems to look for 4 instances of ", 1" but
the comment says that it should be looking for one instance (of a constant
argument).

In the output generated for aarch64-none-linux-gnu, there is one instance of ",
1" in the line

  # phi_inserted_4 = PHI 


Is this just the test or could it be something else going wrong?
Matthew

[Bug libstdc++/77413] [7 regression] experimental/numeric/gcd.cc etc. FAIL

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
i.e. it's caused by r239777

[Bug libstdc++/77413] [7 regression] experimental/numeric/gcd.cc etc. FAIL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Rainer Orth from comment #0)
> I noticed that the earlier (successful) test was compiled without -include
> bits/stdc++.h, while the newer (failing) one is using that flag.  Omitting it
> manually lets the tests PASS.

Ah, this will be because -include bits/stdc++.h is in the default options, but
previously the use of { dg-options "-std=gnu++14" } would override the default
options.

Now that it uses { target c++14 } instead of dg-options it doesn't override the
default, so bits/stdc++.h is used. I wonder why the PCH breaks it.

[Bug tree-optimization/59124] [5/6/7 Regression] Wrong warnings "array subscript is above array bounds"

[ppalka at gcc dot gnu.org]

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

--- Comment #42 from Patrick Palka  ---
(In reply to Szőts Ákos from comment #41)
> A newer example:
> 
> int main() {
>   bool exists = true;
>   int i = 0;
>   int sum = 0;
> 
>   volatile int array_size = 7;
>   volatile int array[7];
> 
>   while (exists)
>   {
> for (i = 0; i < array_size - 1; i++)
> {
>   if (array[i] == 0) sum += array[i + 1];
>   exists = false;
> }
>   }
> 
>   return 0;
> }
> 
> Can be reproduced both by v5.3.0 and v6.1.1 with "g++ -O3 -Wall main.cpp".

Isn't this warning valid?  By marking array_size as volatile you are telling
the compiler that its value could change at any time.  So the loop won't
necessarily terminate once i == 6.

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> I'll certainly check on this but I did run the fix on both big and little
> endian MIPS which seems to suggest there isn't a double adjustment overall.

So this was broken in 64-bit big-endian too before your fix?

> Is there any definition for the raw API? I've seen some reference to
> arguments being passed 'in the way a java stack works' but am not sure how
> that relates to FFI return values passed in registers.

Unfortunately, no, the raw API is undocumented.  My understanding is that it's
an API that bypasses all the promotions/demotions stuff, at least for targets
that implement it natively (i.e. FFI_NATIVE_RAW_API defined, only x86 AFAICS). 
For other targets, java_raw_api.c contains the necessary glue code.  In
particular, you don't need to promote 32-bit return values to 64-bit ffi_arg
with it because both ffi_java_rvalue_to_raw and ffi_java_raw_to_rvalue do the
adjustments, at least in the 64-bit big-endian case.  There might be something
missing (an extension) for 64-bit little-endian for non-x86 targets.

[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

[Bug libstdc++/77413] [7 regression] experimental/numeric/gcd.cc etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug libstdc++/77413] New: [7 regression] experimental/numeric/gcd.cc etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 77413
   Summary: [7 regression] experimental/numeric/gcd.cc etc. FAIL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.12
Target: *-*-solaris2.12
 Build: *-*-solaris2.12

Between 20160826 (r239769) and 20610829 (r239817), two new testsuite
regressions
occured on Solaris 12 (haven't tried earlier OS versions yet):

+FAIL: experimental/numeric/gcd.cc (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/gcd.cc:24:
error: non-constant condition for static assertion
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/gcd.cc:24:
  in constexpr expansion of 'std::experimental::fundamentals_v2::lcm(21, 6)'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:77:
error: call to non-constexpr function 'int std::abs(int)'

+FAIL: experimental/numeric/lcm.cc (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/lcm.cc:24:
error: non-constant condition for static assertion
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/lcm.cc:24:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(1071, 462)'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:65:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(__n, (__m % __n))'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:65:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(__n, (__m % __n))'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:65:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(__n, (__m % __n))'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:64:
error: call to non-constexpr function 'int std::abs(int)'
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/lcm.cc:25:
error: non-constant condition for static assertion
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/lcm.cc:25:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(2000, 20)'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:65:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(__n, (__m % __n))'
/var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libstdc++-v3/include/experimental/numeric:64:
error: call to non-constexpr function 'int std::abs(int)'
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/lcm.cc:26:
error: non-constant condition for static assertion
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/numeric/lcm.cc:26:
  in constexpr expansion of 'std::experimental::fundamentals_v2::gcd(2011, 17)'

both 32 and 64-bit, both sparc and x86.

I noticed that the earlier (successful) test was compiled without -include
bits/stdc++.h, while the newer (failing) one is using that flag.  Omitting it
manually lets the tests PASS.

I suspect this is from testsuite/lib/libstdc++.exp (libstdc++_init), but
haven't checked yet.

  Rainer

[Bug fortran/77382] ICE: verify_gimple failed -- expand_expr_real_1, at expr.c:9651

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
If this is invalid Fortran, it should be diagnosed somewhere during resolve.c
and not make it the translation phase.  There for the "s" symbol which is a
subroutine is first given a FUNCTION_DECL as backend_decl, but later on in
create_function_arglist where the same symbol (without attr.dummy being set)
appears in the argument list the backend_decl is overwritten and becomes a
PARM_DECL, which then confuses everything.

[Bug fortran/77382] ICE: verify_gimple failed -- expand_expr_real_1, at expr.c:9651

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r162491, with -fwhole-file it ICEd already much earlier.

[Bug tree-optimization/59124] [5/6/7 Regression] Wrong warnings "array subscript is above array bounds"

[szotsaki at gmail dot com]

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

Szőts Ákos  changed:

   What|Removed |Added

 CC||szotsaki at gmail dot com

--- Comment #41 from Szőts Ákos  ---
A newer example:

int main() {
  bool exists = true;
  int i = 0;
  int sum = 0;

  volatile int array_size = 7;
  volatile int array[7];

  while (exists)
  {
for (i = 0; i < array_size - 1; i++)
{
  if (array[i] == 0) sum += array[i + 1];
  exists = false;
}
  }

  return 0;
}

Can be reproduced both by v5.3.0 and v6.1.1 with "g++ -O3 -Wall main.cpp".

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[matthew.fortune at imgtec dot com]

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

--- Comment #8 from Matthew Fortune  ---
(In reply to Eric Botcazou from comment #7)
> > 2016-07-13  Matthew Fortune  
> > 
> > * interpret-run.cc: Use ffi_arg for FFI integer return types.
>
> so we now have a double adjustment on 64-bit big-endian and this breaks. 
> Maybe there is something missing for little-endian MIPS in java_raw_api.c.

I'll certainly check on this but I did run the fix on both big and little
endian MIPS which seems to suggest there isn't a double adjustment overall. 
The layers involved in this have however exceeded what I can fit in my head so
I'll have to draw things out to try and understand what was/should-be/is
happening.

Is there any definition for the raw API? I've seen some reference to arguments
being passed 'in the way a java stack works' but am not sure how that relates
to FFI return values passed in registers.

[Bug tree-optimization/69047] memcpy is not as optimized as union is

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 30 Aug 2016, mwahab at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69047
> 
> mwahab at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||mwahab at gcc dot gnu.org
> 
> --- Comment #9 from mwahab at gcc dot gnu.org ---
> The new test gcc.dg/pr69047.c fails on big-endian aarch64 
> (aarch64_be-none-elf)
> because the expected output isn't generated.
> 
> For big-endian aarch64, the expression in the cddce1 file is
> 
>   _2 = BIT_FIELD_REF ;
> 
> 
> For little-endian aarch64, the expression is as expected:
> 
>   _2 = (unsigned char) b_6(D);
> 

Fixed this with r239857 I think

[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #10 from mwahab at gcc dot gnu.org ---
For aarch64 and arm, the new test g++.dg/cpp0x/explicit12.C shows as UNRESOLVED
and the log complain about output files not existing.

The test has { dg-do link .. } and { dg-final { scan-assembler-not .. } } but
dg-do link doesn't seem to preserve the assembler files. Was the test intended
to have a { dg-options "-save-temps" } set?

Matthew

[Bug fortran/77412] constructor of an extended type with an allocatable component in the base type crashes gfortran

[daanvanvugt at gmail dot com]

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

--- Comment #1 from Daan van Vugt  ---
Some more info: changing 1.0 to 1d0 does not prevent the crash. Adding a type
constructor and changing 1.0 to 1d0 does work.

[Bug tree-optimization/69047] memcpy is not as optimized as union is

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #9 from mwahab at gcc dot gnu.org ---
The new test gcc.dg/pr69047.c fails on big-endian aarch64 (aarch64_be-none-elf)
because the expected output isn't generated.

For big-endian aarch64, the expression in the cddce1 file is

  _2 = BIT_FIELD_REF ;


For little-endian aarch64, the expression is as expected:

  _2 = (unsigned char) b_6(D);


Matthew

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

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

Untested partial fix for the compiler side.  It should fix the common case when
this happens, but it is still possible that something from the file scope ctors
isn't optimized away, yet no global vars are referenced, like:
// PR sanitizer/77396
// { dg-do run }
// { dg-additional-options "-O2" }
// { dg-set-target-env-var ASAN_OPTIONS "check_initialization_order=true" }

struct S { S () { asm volatile ("" : : : "memory"); } };
static S c;

int
main ()
{
  return 0;
}

and in that case it will still fail.  I'm afraid it is too hard to fix this
inside of GCC, unless we want to emit too ugly code - the
__asan_{before,after}_dynamic_call calls need to be in a different function
from the function that invokes the globals registration, and the latter is only
emitted at the very end, so either we'd need to for -fsanitize=address disable
some optimization (e.g. don't remove unused local statics), or force some
useless global if there are no other globals but
__asan_{before,after}_dynamic_call has been seen.
All in all, IMHO it is better to change __asan_{before,after}_dynamic_call -
exit early if the vector is NULL, instead of the assertion.

[Bug fortran/77412] New: constructor of an extended type with an allocatable component in the base type crashes gfortran

[daanvanvugt at gmail dot com]

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

Bug ID: 77412
   Summary: constructor of an extended type with an allocatable
component in the base type crashes gfortran
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daanvanvugt at gmail dot com
  Target Milestone: ---

The below segment causes gfortran 6.1.1 to crash with:
test.f90:11:0:

   a = test_ext(timestep = 1.0)

internal compiler error: in fold_convert_loc, at fold-const.c:2250

program test_allocatable_component
  type, abstract :: test_base
real*8, allocatable :: timestep
  end type

  type, extends(test_base) :: test_ext
  end type

  type(test_ext) :: a

  a = test_ext(timestep = 1.0)

end program test_allocatable_component

For an integer, dimension(:) variable the exact same situation does work.

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-30
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org
  Component|c++ |sanitizer
   Target Milestone|--- |6.3
 Ever confirmed|0   |1

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 30 Aug 2016, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
> 
> --- Comment #8 from Alexander Monakov  ---
> > The extension is closely modeled after openCL
> 
> Hm, that doesn't sound right: gcc had vector types long before OpenCL was even
> a thing; I believe it's modeled after Altivec actually: the discrepancy 
> between
> C-style casts on scalar and vector types definitely comes from Altivec.

Sure, but for later enhancements we decided to follow openCL

> > IIRC openCL uses "intrinsics" for these kind of operations?
> 
> Yes, in OpenCL there's no implicit casts for vector types, and one has to use
> built-in functions like 'convert_float4'.
> 
> Also worth mentioning that Clang provides __builtin_convertvector(arg, type)
> for casting.

Ah, might be useful to support as well.

Of course that's all moot if the optimization possibility results
from other optimization.

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
> The extension is closely modeled after openCL

Hm, that doesn't sound right: gcc had vector types long before OpenCL was even
a thing; I believe it's modeled after Altivec actually: the discrepancy between
C-style casts on scalar and vector types definitely comes from Altivec.

> IIRC openCL uses "intrinsics" for these kind of operations?

Yes, in OpenCL there's no implicit casts for vector types, and one has to use
built-in functions like 'convert_float4'.

Also worth mentioning that Clang provides __builtin_convertvector(arg, type)
for casting.

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Alexander Monakov from comment #6)
> Thanks. Any comment on having gimple lowering emit cleaner code in the first
> place?

well, I'm not sure if it is worth the trouble.  FEs emit

  return <<< Unknown tree: compound_literal_expr
v4sf D.1795 = {(float) VIEW_CONVERT_EXPR(f)[0], (float)
VIEW_CONVERT_EXPR(f)[1], (float) VIEW_CONVERT_EXPR(f)[2],
(float) VIEW_CONVERT_EXPR(f)[3]}; >>>;

and gimplification then forces the scalar computations to temporaries:

  _1 = BIT_FIELD_REF ;
  _2 = (float) _1;
  _3 = BIT_FIELD_REF ;
  _4 = (float) _3;
  _5 = BIT_FIELD_REF ;
  _6 = (float) _5;
  _7 = BIT_FIELD_REF ;
  _8 = (float) _7;
  D.1797 = {_2, _4, _6, _8};

this is theoretically a point where stmt folding could replace it by

  D.1797 = (float) f;

the code in forwprop would need to be moved to gimple-fold.c and eventually
the gimplifier needs to be changed to fold more stmts (it really should
fold all of them, with SSA edge following enabled -- the point we now
have SSA names as early as gimplification).

I think the real issue for writing vector code is that our GCC generic
vector extension has no casting support (or pack-/unpack-support).  The
extension is closely modeled after openCL and IIRC openCL uses
"intrinsics" for these kind of operations?

So I still believe that the forwprop code should be extended, and eventually
the forwprop code should be moved to gimple-fold.c (invoked via fold_stmt),
aka "manually written" match.pd patterns.

[Bug target/63789] g++ -m32 on solaris has trouble finding abs with int64_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-30
 Ever confirmed|0   |1

--- Comment #7 from Jonathan Wakely  ---
Yes, this should be fixed in GCC 6, and if it isn't we now have the tools to
fix it.

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
Thanks. Any comment on having gimple lowering emit cleaner code in the first
place?

[Bug middle-end/77407] Optimize integer i / abs (i) into the sign of i

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-30
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
Full testcase(?)

int foo (int c)
{
  if (c != 0)
c /= __builtin_abs (c);
  return c;
}

Possible "fix":

(simplify
 (trunc_div @0 (abs @0))
 (if (! TYPE_UNSIGNED (type)
  && TYPE_OVERFLOW_UNDEFINED (type))
  (cond (lt @0 { build_zero_cst (type); }) { build_minus_one_cst (type); } {
build_one_cst (type); })))

but eventually we should simply make __builtin_copysign also work on
integers...

Not sure if desirable also for _Complex int and vector int (both handled
above).

Need to double-check for non-truncating divisions.

Similar testcase would be

  if (c != 0)
c /= -c;

[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |6.3

[Bug ipa/77397] function initializing global static variables is not optimized away fully

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-30
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|c++ |ipa
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
The issue is that the global initializer function is created very early (by
frontends) rather than having global initializers being first-class citizens
in the symtab code (registering inline functions as DECL_INITIAL maybe).

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
OTOH sth like tree-complex.c for vectors would be nice as well (well, really
re-writing tree-vect-generic.c to sth better).

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note that this is a patten matching issue that could be quite easily fixed in
tree-ssa-forwprop.c:simplify_vector_constructor (which currently recognizes
a VEC_PERM but it should be easy to handle intermediate conversions meaning
to handle even pack-/unpack-style permuted (float-int) conversions).

Just to give a hint where this can be handled.  [yeah, match.pd but there
we'd need a way to handle variable-length stuff like CONSTRUCTORs first...,
see the "awkward" handling of BIT_FIELD_REF  there]

[Bug tree-optimization/69047] memcpy is not as optimized as union is

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 30 09:22:17 2016
New Revision: 239857

URL: https://gcc.gnu.org/viewcvs?rev=239857=gcc=rev
Log:
2016-08-30  Richard Biener  

PR tree-optimization/69047
* gcc.dg/pr69047.c: Fix byte-order check.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr69047.c

[Bug testsuite/77411] object-size-9.c -fpic -m32 failure

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Analysis at https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01985.html :
...
The problem here is that the functions f2 and f3 access a stack-
based object out of bounds and that is inlined in main and
therefore smashes the return address of main in this case.
...

[Bug testsuite/77411] New: object-size-9.c -fpic -m32 failure

[vries at gcc dot gnu.org]

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

Bug ID: 77411
   Summary: object-size-9.c -fpic -m32 failure
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-testresults/2016-08/msg03113.html :
...
FAIL: c-c++-common/ubsan/object-size-9.c   -O2  execution test
FAIL: c-c++-common/ubsan/object-size-9.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
...

[Bug tree-optimization/72866] Compile time hog w/ -O3 (-Ofast)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7 Regression] Compile time |Compile time hog w/ -O3
   |hog w/ -O3 (-Ofast) |(-Ofast)

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk, keeping open for possible backport to 6.3 (5.x doesn't have
the problem).

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> It does look possible that this is an LRA issue.  Here's the code right
> before failure:
> 
> 100dae08:   f8 95 22 39 addir9,r2,-27144
> 100dae0c:   01 00 40 39 li  r10,1
> 100dae10:   00 00 49 99 stb r10,0(r9)
> 100dae14:   b8 04 20 39 li  r9,1208
> 100dae18:   14 4a 7f 7c add r3,r31,r9
> 100dae1c:   08 00 83 e8 ld  r4,8(r3)
> 100dae20:   00 00 63 e8 ld  r3,0(r3)
> 100dae24:   3d 86 14 48 bl  10223460
>  lease>
> 100dae28:   00 00 00 60 nop
> 
> At the call, r3 has a value of 0.  It looks quite possible that the stack
> load at 0x100dae20 is from a spill slot.  I don't see offset 1208 used for a
> corresponding store anywhere in the function.  There is, however, some odd
> code that uses that constant to fiddle with the frame pointer and then set
> it back to where it was:
> 
> 100da5d8:   b8 04 20 39 li  r9,1208
> 
> 100da5e4:   14 4a ff 7f add r31,r31,r9
> 100da5e8:   50 f8 e9 7f subfr31,r9,r31

Here are the declarations of the relevant subroutines:

   type Mark_Id is private;
   --  Type used to mark the stack for mark/release processing

   function SS_Mark return Mark_Id;
   --  Return the Mark corresponding to the current state of the stack

   procedure SS_Release (M : Mark_Id);
   --  Restore the state of the stack corresponding to the mark M. If an
   --  additional chunk have been allocated, it will never be freed during a
   --  ??? missing comment here

   type Mark_Id is record
  Sstk : System.Address;
  Sptr : SS_Ptr;
   end record;
   --  A mark value contains the address of the secondary stack structure,
   --  as returned by System.Soft_Links.Get_Sec_Stack_Addr, and a stack
   --  pointer value corresponding to the point of the mark call.

So the double-word load before the call to SS_Release should be from a Mark_Id
object obtained from a preceding call to SS_Mark.  It indeed looks like the
double-word store to this Mark_Id object has been optimized away, possibly
because of the strange back-and-forth adjustment to the FP.  Does passing
CFLAGS="-O2 -fno-dse" for the gnattools make a difference?

[Bug c++/77363] [5/6 Regression] Missing debug information in DWARF

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work||7.0
 Resolution|FIXED   |---
Summary|[5/6/7 Regression] Missing  |[5/6 Regression] Missing
   |debug information in DWARF  |debug information in DWARF
  Known to fail|7.0 |

--- Comment #7 from Jakub Jelinek  ---
Still not fixed for 6.3/5.5, so reopening until that happens.

[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF

[EngyCZ at gmail dot com]

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

Jiří Engelthaler  changed:

   What|Removed |Added

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

--- Comment #6 from Jiří Engelthaler  ---
Confirmed that the patch fixes my case in GCC 5.4.0.
Please backport the patch to gcc-5 branch.

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

Summary|SLP does not handle |Poor code generation for
   |BIT_FIELD_REF or|vector casts and loads
   |CONSTRUCTOR |

--- Comment #3 from Alexander Monakov  ---
Thanks for confirming and for the extra testcase. However, the initial issue is
really not about SLP (I just used it to demonstrate that proper abstraction is
available on the gimple level): I think that kind of code should be handled
well at -O2 when no auto-vectorization is active, because the desired code
generation can be naturally inferred from original source code.

Your testcase will exhibit poor code generation even without the implicit
casts; simply constructing a vector won't use (unaligned) vector loads, even at
-O3:

typedef float v4sf __attribute__((vector_size(16)));
v4sf vec_load(float *f)
{
  return (v4sf){f[0], f[1], f[2], f[3]};
}

(clang/llvm generates one unaligned vector load here)

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup dot 
org

--- Comment #9 from Marc Glisse  ---
(In reply to Eric Botcazou from comment #8)
> Unfortunately I don't seem to be able to connect to gcc112 in the
> CompileFarm:
> 
> eric@arcturus:~> ssh -l ebotcazou gcc112.osuosl.org
> ssh: Could not resolve hostname gcc112.osuosl.org: Name or service not known

gcc112.fsffrance.org (aka gcc2-power8.osuosl.org)

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> I'm afraid I don't know anything about Ada and how its runtime works; it
> looks like system.secondary_stack.ss_release is called automatically somehow
> as part of entering make.Initialize, but I have no idea if that's supposed
> to happen.  It seems questionable at first glance.

Unfortunately I don't seem to be able to connect to gcc112 in the CompileFarm:

eric@arcturus:~> ssh -l ebotcazou gcc112.osuosl.org
ssh: Could not resolve hostname gcc112.osuosl.org: Name or service not known

Try to recompile the gnattools with reload instead of LRA, for example:
  rm -rf gnattools gcc/ada/tools gcc/stamp-tools
  make all-gnattools CFLAGS="-O2 -mno-lra"

Does this eliminate the problem?

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> if that attempt doesn't let you reproduce it, and if it still happens when I
> remove that flag, I can start bisecting and see if I can get it to a
> specific day or even commit that caused it.  That will obviously take some
> time though.

I cannot reproduce on Linux with CFLAGS="-pipe -O2 -fno-strict-aliasing" and
the same configure flags as you.  Please try to get a backtrace.

[Bug tree-optimization/72866] [7 Regression] Compile time hog w/ -O3 (-Ofast)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 30 06:54:02 2016
New Revision: 239856

URL: https://gcc.gnu.org/viewcvs?rev=239856=gcc=rev
Log:
PR tree-optimization/72866
* tree-vect-patterns.c (search_type_for_mask): Turn into
a small wrapper, move all code to ...
(search_type_for_mask_1): ... this new function.  Add caching
and adjust recursive calls.

* gcc.dg/vect/pr72866.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr72866.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 30 06:46:38 2016
New Revision: 239855

URL: https://gcc.gnu.org/viewcvs?rev=239855=gcc=rev
Log:
PR debug/77363
* dwarf2out.c (modified_type_die): Use lookup_type_die (type)
instead of lookup_type_die (type_main_variant (type)) even for array
types.

* g++.dg/debug/dwarf2/pr77363.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr77363.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 30 06:45:56 2016
New Revision: 239854

URL: https://gcc.gnu.org/viewcvs?rev=239854=gcc=rev
Log:
PR middle-end/77377
* simplify-rtx.c (avoid_constant_pool_reference): For out of bounds
constant pool reference return x instead of c.

* gcc.target/i386/pr77377.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr77377.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/77389] FAIL: g++.dg/debug/dwarf2/template-params-12f.C -std=gnu++11 scan-assembler-times DIE \\\\([^\\n]*\\\\) DW_TAG_template_value_param ...

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 30 06:44:43 2016
New Revision: 239853

URL: https://gcc.gnu.org/viewcvs?rev=239853=gcc=rev
Log:
PR debug/77389
* g++.dg/debug/dwarf2/template-params-12f.C: Pass -gno-strict-dwarf
in dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-params-12f.C

[Bug objc/77404] Add Wobjc-root-class

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-30
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Confirmed.  in Objective-C (like Java though different from Java since there is
no implicit inheriting from the Object), all classes inherit from an Object
class.  This Object class contains a few things including but not limited to
the class field.

[Bug tree-optimization/67962] Optimization opportunity with conditional swap to two MIN/MAX in phiopt

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2015-10-14 00:00:00 |2016-8-29

--- Comment #2 from Andrew Pinski  ---
Just for completeness here is the C testcase (std::swap converted below):

int g(int x, int y);
static inline void swap(int *x, int *y)
{
  int t = *x;
  *x = *y;
  *y = t;
}
int f(int x, int y)
{
  if (y < x)
{
swap(, );
}
  return g(x, y);
}

[Bug objc/77404] Add Wobjc-root-class

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Eric Gallager from comment #1)
> (In reply to Tom de Vries from comment #0)
> > Is the -Wobjc-root-class warning something we want to have in gcc objc as
> > well?
> 
> What's the reasoning behind clang having it?

My understanding of the reasoning is: when gcc encounters a class that does not
have a super class, either:
a. it's a new root class, or
b. the programmer forgot to specify the super class.
Given that the amount of root classes in a typical objc application is small,
the warning/attribute combination allows the trade off that by annotating the
root classes (case a) with the attribute, which should be a minor effort, we
can warn about the programmer errors (case b).