[Bug c++/86049] Array bindings are not const when initializer is

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Jason/Jonathan, is that true?  What exactly shall be the qualification in the
array case?  Ored type quals of the initializer's element type and provided
quals from the structured binding declaration?  If so, it would be something
like:
--- gcc/cp/pt.c.jj  2018-06-04 15:47:24.633937198 +0200
+++ gcc/cp/pt.c 2018-06-05 09:12:56.151035636 +0200
@@ -26734,10 +26734,15 @@ do_auto_deduction (tree type, tree init,
   && auto_node == type
   && init != error_mark_node
   && TREE_CODE (TREE_TYPE (init)) == ARRAY_TYPE)
-/* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
-   and initializer has array type, deduce cv-qualified array type.  */
-return cp_build_qualified_type_real (TREE_TYPE (init), TYPE_QUALS (type),
-complain);
+{
+  /* [dcl.decomp]/1 - if decomposition declaration has no ref-qualifiers
+and initializer has array type, deduce cv-qualified array type.  */
+  int type_quals = TYPE_QUALS (type);
+  tree eltype = strip_array_types (TREE_TYPE (init));
+  type_quals |= TYPE_QUALS (eltype);
+  return cp_build_qualified_type_real (TREE_TYPE (init), type_quals,
+  complain);
+}
   else if (AUTO_IS_DECLTYPE (auto_node))
 {
   bool id = (DECL_P (init)

[Bug tree-optimization/86042] [8/9 Regression] missing strlen optimization after second strcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.2
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  Note this was a correctness fix so we properly copy padding given
aggregate assignment in GIMPLE is not a block copy if done for a structure
type.

For this case in question it shouldn't have made a difference though.

We seem to invalidate the string info for some reason after visiting the
second store.

[Bug gcov-profile/84846] GCOV intermediate format improvements

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Tue Jun  5 08:11:52 2018
New Revision: 261188

URL: https://gcc.gnu.org/viewcvs?rev=261188&root=gcc&view=rev
Log:
Print working directory only in intermediate format (PR gcov-profile/84846).

2018-06-05  Martin Liska  

PR gcov-profile/84846
* gcov.c (output_lines): Print working directory only
in intermediate format.

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

[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #4)
> Updated version: F08/0052 at
> ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1907.txt
> (incorporated in Corrigendum 1 to F2008).

Updated link for this one:

https://wg5-fortran.org/N1901-N1950/N1907.txt

[Bug c/86046] [9 Regression] ICE in execute_todo, at passes.c:2043

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-05
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  After CCP:

No longer having address taken: D.1960

but then we fail to rewrite it.

  VIEW_CONVERT_EXPR(D.1960)[1] = 0;

Ah, so the issue seems to be that D.1960 is already DECL_GIMPLE_REG_P but
it is just TREE_ADDRESSABLE avoiding the rewriting need.  But
update_address_taken simply clears TREE_ADDRESSABLE but leaves
DECL_GIMPLE_REG_P
in place thinking it cannot be set.

The issue may be premature setting of DECL_GIMPLE_REG_P but we can work around
this in update_address_taken.

There's a missed optimization as well, we expect to rewrite the array-ref into
a bitfield ref during gimplification.  Ah, but we avoid doing that for
the out-of-bound access this is.

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Thanks for checking! For now I'll just keep the same _Quoted_string definition
so it stores a reference to a basic_string_view. We can reconsider before the
GCC 9 release if needed.

[Bug tree-optimization/86047] [9 Regression] ICE in for_each_index, at tree-ssa-loop.c:647

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-05
  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.2

[Bug target/86048] [8/9 Regression] .seh_savexmm offset is negative error when compiling libpng

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

[Bug fortran/86051] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3717

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> This may have been fixed by a patch I submitted today.

I confirmed that the PR is fixed by the patch at

https://gcc.gnu.org/ml/fortran/2018-06/msg00013.html

[Bug libstdc++/12595] link problems with static libstdc++

[karsten_burger at gmx dot de]

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

Karsten Burger  changed:

   What|Removed |Added

 CC||karsten_burger at gmx dot de

--- Comment #15 from Karsten Burger  ---
(In reply to Dirk Walther from comment #14)
thanks for this hint, however I understand it requires recompile of gcc

[Bug tree-optimization/86050] Inline break tail-call optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  It is because the address of 'value' escapes which is easier to
see when you instead do

static void __attribute__((noinline)) stackConsume(const char*stack){
char value;
__builtin_putchar ((long)&value);
}

this then causes us to hit

  /* Make sure the tail invocation of this function does not indirectly
 refer to local variables.  (Passing variables directly by value
 is OK.)  */
  FOR_EACH_LOCAL_DECL (cfun, idx, var)
{
  if (TREE_CODE (var) != PARM_DECL
  && auto_var_in_fn_p (var, cfun->decl)
  && may_be_aliased (var)
  && (ref_maybe_used_by_stmt_p (call, var)
  || call_may_clobber_ref_p (call, var)))
return;
}

where we think that the recursive call might possibly access that very
escaped stack slot (for example via a global pointer).  We do not have
sophisticated enough analysis to fix that easily.

[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Another very related case that gfortran currently accepts, although it is
invalid according to the interpretation request:


module m1
   implicit none

   type, abstract :: t1
   contains
  procedure(ifc), deferred, private :: tbp
   end type

   abstract interface
  subroutine ifc(arg)
 import :: t1
 class(t1) :: arg
  end subroutine
   end interface

end module


module m2
   use m1
   implicit none

   type, extends(t1) :: t2
   contains
  procedure :: tbp => tbp_t2
   end type

contains

   subroutine tbp_t2(arg)
  class(t2) :: arg
  print *, "this is t2!"
   end subroutine

end module


program test
   use m2
   implicit none

   type(t2) :: x
   call x%tbp()
end


It is correctly rejected by ifort 18.

[Bug ipa/60243] IPA is slow on large cgraph tree

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #21 from Richard Biener  ---
Current trunk at -O2 -fno-checking (w/ otherwise checking enabled):

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
   1245 kB (  0%)
 phase parsing  :  16.72 (  6%)  15.15 ( 75%)  31.86 ( 10%)
 612162 kB ( 18%)
 phase opt and generate : 272.51 ( 94%)   5.08 ( 25%) 277.63 ( 90%)
2719266 kB ( 82%)
 ipa inlining heuristics:  31.82 ( 11%)   0.00 (  0%)  31.85 ( 10%)
  0 kB (  0%)
 ipa profile:   9.92 (  3%)   0.00 (  0%)   9.93 (  3%)
  0 kB (  0%)
 ipa SRA: 153.77 ( 53%)   1.81 (  9%) 155.54 ( 50%)
 741949 kB ( 22%)
 early inlining heuristics  :  24.54 (  8%)   0.03 (  0%)  24.65 (  8%)
   2987 kB (  0%)

at -O -g we can also see to my surprise:

 tree CFG construction  :   6.27 (  4%)   0.04 (  0%)   6.28 (  4%)
 628095 kB ( 15%)
 tree operand scan  :   3.78 (  3%)   0.99 (  4%)   5.01 (  3%)
  47597 kB (  1%)
 tree CFG cleanup   :   7.51 (  5%)   0.05 (  0%)   7.71 (  5%)
  0 kB (  0%)

the tree CFG construction time is _entirely_ spent in assign_discriminators!
That's because expand_location is costly and the discriminator_per_locus
hashtable does that all the time.  It's also because the testcase
sits on a single line.  The whole code seems odd to me as well given
it doesn't very well handle trailing or leading UNKNOWN_LOCATION stmts.
I also wonder why it is done at CFG construction time.

The IPA SRA time is all spent in compute_fn_summary via convert_callers.
Not sure why that's necessary here?  Martin, in r152368 you reduced those
to once-per-caller but obviously if each function calls each other function
as in this testcase this is still O(n^2).  Why's the summary not simply
recomputed when we process the caller next?  Thus at most N times?

[Bug ipa/60243] IPA is slow on large cgraph tree

[hubicka at ucw dot cz]

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

--- Comment #22 from Jan Hubicka  ---
> The IPA SRA time is all spent in compute_fn_summary via convert_callers.
> Not sure why that's necessary here?  Martin, in r152368 you reduced those
> to once-per-caller but obviously if each function calls each other function
> as in this testcase this is still O(n^2).  Why's the summary not simply
> recomputed when we process the caller next?  Thus at most N times?

This is because summary needs to be ready for early inliner to decide whether
caller is good for inlning or not.  I think we can simply mark it as dirty and
compute on demand from the inliner.

I also have finally working patches for incremental update of inline summary in
the IPA inliner.

Honza

[Bug fortran/86052] New: ICE with parameterized derived types

[juergen.reuter at desy dot de]

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

Bug ID: 86052
   Summary: ICE with parameterized derived types
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following example from c.l.f. (Dec 14, 2015, "explicit specialization for
Fortran2003 recursively-defined parameterized data types?" leads to an ICE with
the current trunk of gfortran (r260633). In the code below, if the non-pointer
declaration is commented in, gfortran correctly vetoes this as "Component at
(1) must have the POINTER attribute", but with the version below this leads to
an ICE. With ifort v18 and v19 the code is rejected as "error #7555: Not yet
implemented: Type containing ALLOCATABLE/POINTER field of same type with
different type parameters. 
type(tensor(rank-1,dim)), pointer :: values(:)"



*

Code triggering the ICE:

module tensor_names
implicit none
private
type :: tensor(rank,dim)
integer, kind :: rank
integer, kind :: dim
type(tensor(rank-1,dim)), pointer :: values(:)
! type(tensor(rank-1,dim)) :: values(dim) ! Illegal!!!
contains
procedure, private :: create_tensor_rank_2_dim_2
generic :: create => create_tensor_rank_2_dim_2
end type
contains
subroutine create_tensor_rank_2_dim_2 ( this )
implicit none
class(tensor(2,2)), intent(inout) :: this
end subroutine
end module tensor_names

[Bug fortran/86052] ICE with parameterized derived types

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 Blocks||82173
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors

[Bug rtl-optimization/85925] [7/8/9 Regression] Mis-compilation at -02, masking with 257 goes wrong in combine

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
I can reproduce.

[Bug rtl-optimization/85925] [7/8/9 Regression] Mis-compilation at -02, masking with 257 goes wrong in combine

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|segher at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #3 from Eric Botcazou  ---
Investigating.

[Bug target/81497] [7/8/9 Regression] error compiling arm_acle.h

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Jun  5 09:50:16 2018
New Revision: 261191

URL: https://gcc.gnu.org/viewcvs?rev=261191&root=gcc&view=rev
Log:
[arm] PR target/81497: Fix arm_acle.h for C++

When trying to compile something with arm_acle.h using G++ we get a number of
nasty errors:
arm_acle.h:48:49: error: invalid conversion from ‘const void*’ to ‘const int*’
[-fpermissive]
return __builtin_arm_ldc (__coproc, __CRd, __p);

This is because the intrinsics that are supposed to be void return the "result"
of their builtin,
which is void. C lets that slide but C++ complains.

After fixing that we run into further errors:
arm_acle.h:48:46: error: invalid conversion from 'const void*' to 'const int*'
[-fpermissive]
return __builtin_arm_ldc (__coproc, __CRd, __p);
   ^~~
Because the pointer arguments in these intrinsics are void pointers but the
builtin
expects int pointers. So this patch introduces new qualifiers for void pointers
and their
const-qualified versions and uses that in the specification of these
intrinsics.

This gives us the opportunity of creating an arm subdirectory in g++.dg and
inaugurates it
with the first arm-specific C++ tests (in that directory).


PR target/81497
* config/arm/arm-builtins.c (arm_type_qualifiers): Add
qualifier_void_pointer and qualifier_const_void_pointer.
(arm_ldc_qualifiers, arm_stc_qualifiers): Use the above.
(arm_init_builtins): Handle the above.
* config/arm/arm_acle.h (__arm_cdp, __arm_ldc, __arm_ldcl, __arm_stc,
__arm_stcl, __arm_mcr, __arm_cdp2, __arm_ldc2, __arm_ldcl2, __arm_stc2,
__arm_stcl2,__arm_mcr2, __arm_mcrr, __arm_mcrr2): Remove return for
void intrinsics.

* g++.target/arm/arm.exp: New file.
* g++.target/arm/pr81497.C: Likewise.

Added:
trunk/gcc/testsuite/g++.target/arm/
trunk/gcc/testsuite/g++.target/arm/arm.exp
trunk/gcc/testsuite/g++.target/arm/pr81497.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/config/arm/arm_acle.h
trunk/gcc/testsuite/ChangeLog

[Bug target/81497] [7/8 Regression] error compiling arm_acle.h

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] error|[7/8 Regression] error
   |compiling arm_acle.h|compiling arm_acle.h
  Known to fail||8.1.0

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. Will backport to the branches after a few days.

[Bug tree-optimization/86047] [9 Regression] ICE in for_each_index, at tree-ssa-loop.c:647

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  5 10:01:49 2018
New Revision: 261192

URL: https://gcc.gnu.org/viewcvs?rev=261192&root=gcc&view=rev
Log:
2018-06-05  Richard Biener  

PR tree-optimization/86047
* tree-ssa-loop.c (for_each_index): Glob handling of all
decls and constants and really handle all of them.

* gcc.dg/pr86047.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr86047.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop.c

[Bug tree-optimization/86047] [9 Regression] ICE in for_each_index, at tree-ssa-loop.c:647

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> So is this fixed now?

I have spotted some new tests requiring c_int:

--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_usage_24.f90 2018-02-18
00:40:36.0 +0100
+++ ../p_work/gcc/testsuite/gfortran.dg/bind_c_usage_24.f90 2018-05-12
16:01:26.0 +0200
@@ -30,9 +30,10 @@ contains
 end module m

 program test
+  use iso_c_binding
   use m
   implicit none
-  integer :: val
+  integer(c_int) :: val

   val = 4
   call c_proc (.false._c_bool)
--- ../_clean/gcc/testsuite/gfortran.dg/internal_dummy_4.f082018-02-18
00:40:40.0 +0100
+++ ../p_work/gcc/testsuite/gfortran.dg/internal_dummy_4.f082018-05-12
16:01:29.0 +0200
@@ -39,11 +39,11 @@ end module test_mod
 program main
   use test_mod
   implicit none
-  integer :: a
+  integer(c_int) :: a
   a = 33
-  call test_sub (one, a, 7*33)
+  call test_sub (one, a, 7_c_int*33_c_int)
   a = 23
-  call test_func(two, a, -123*23)
+  call test_func(two, a, -123_c_int*23_c_int)
 contains
   subroutine one(x) bind(c)
  integer(c_int),intent(inout) :: x

There is also a problem with gfortran.dg/bind_c_usage_10.f03 I have been unable
to fix:

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:66:31:

   integer(c_int) function func4()
   1
Error: FUNCTION result func4 can't be of type INTEGER(4) in FUNCTION func4 at
(1)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:59:31:

   integer(c_int) function func3() bind(c, name="myFunc3")
   1
Error: FUNCTION result func3 can't be of type INTEGER(4) in FUNCTION func3 at
(1)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:52:31:

   integer(c_int) function func2()
   1
Error: FUNCTION result func2 can't be of type INTEGER(4) in FUNCTION func2 at
(1)
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:45:31:

   integer(c_int) function func1() bind(c, name="myFunc1")
   1
Error: FUNCTION result func1 can't be of type INTEGER(4) in FUNCTION func1 at
(1)

[Bug c/86046] [9 Regression] ICE in execute_todo, at passes.c:2043

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  5 10:02:50 2018
New Revision: 261193

URL: https://gcc.gnu.org/viewcvs?rev=261193&root=gcc&view=rev
Log:
2018-06-05  Richard Biener  

PR tree-optimization/86046
* tree-ssa.c (maybe_optimize_var): Clear DECL_GIMPLE_REG_P
if required after clearing TREE_ADDRESSABLE.

* gcc.dg/pr86046.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr86046.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug c/86046] [9 Regression] ICE in execute_todo, at passes.c:2043

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[jan.kratochvil at redhat dot com]

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

--- Comment #8 from Jan Kratochvil  ---
Created attachment 44236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44236&action=edit
incredibleshrinkingvector.C

What's wrong with this implementation? The permitted operator new symbols
interposition was suggested by Pavel Labath at:
https://reviews.llvm.org/D47492#1122080

[Bug c/86053] New: Builtin fwrite arguments have non_null attribute and builtin function declaration not overloaded

[olivier at wuillemin dot fr]

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

Bug ID: 86053
   Summary: Builtin fwrite arguments have non_null attribute and
builtin function declaration not overloaded
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olivier at wuillemin dot fr
  Target Milestone: ---

Builtin fwrite arguments have non_null attribute and builtin function
declaration not overloaded

I'm compiling ARM embedded software using Atmel Studio 7 and Atmel toolchain
6.3.1.508 a package of ARM's gcc-arm-embedded project 6-2017-q2-update1.
Files functions (fopen, fread, fwrite...) are embedded in a specific 
module, weak libc stdio functions are overloaded.

1°/ Buitin fwrite function seems to have the 4th parameter (file handle) with
nonnull attribute.

Compile this code :

#include 

int main(void)
{
  fwrite("Hello", 5, 1, NULL);
  fread(NULL, 5, 1, NULL);
}

For the fwrite line a warning is generated : 
  main.c (6,2): null argument where non-null required (argument 4) [-Wnonnull]"
For the fread line, no warning is generated.
Some others warnings  are without interest for this demonstration.

This warning is also generated using Codelite and TDM32 [gcc (tdm-1) 5.1.0].

Arm's toolchain stdio.h fwrite prototype doesn't have the nonnull attribute :
  size_t_EXFUN(fwrite, (const _PTR __restrict , size_t _size, size_t
_n, FILE *));
TDM32's  toolchain stdio.h fwrite prototype doesn't have the nonnull attribute
:
_CRTIMP size_t __cdecl __MINGW_NOTHROW  fwrite (const void*, size_t, size_t,
FILE*);

- Is it normal that the builtin fwrite arguments have the non-null attribute ?
- Is it normal that read argument attibutes have not the same behaviour than
write ? 


2°/ Buitin fwrite prototype overload local fwrite declaration

Compile this code :

#include 

typedef struct  {
  unsigned foo;
} FILE;

size_t fwrite(const void *ptr, size_t size, size_t n, FILE *stream)
{
  size_t lCount;

  lCount = 0;
  if (stream != NULL) {
lCount = size * n;
  }
  return (size_t)lCount;
}

size_t fread(void *ptr, size_t size, size_t n, FILE *stream)
{
  size_t lCount;

  lCount = 0;
  if (stream != NULL) {
lCount = size * n;
  }
  return (size_t)lCount;
}

int main(int argc, char **argv)
{

fwrite("hello world\n", 5, 1, NULL);
fread(NULL, 5, 1, NULL);

return 0;
}

With ARM toolchain, 2 warnings are generated  :
One for the fwrite call :
  main.c(32,2): warning: null argument where non-null required (argument 4)
[-Wnonnull]
One for the the fwrite function :
  main.c(12,6): warning: nonnull argument 'stream' compared to NULL
[-Wnonnull-compare]

Local fwrite declaration has no nonnull attribute for 4th parameter and : 
  - a warning is generated at fonction call.
  - More strange is the warning generated inside the function itself. It's own
declaration is overload by builtin declaration. no effect.

Compiling the code with TDM32 generate only one warning at function call.

Compilers options are -O0 -Wall 

When using compiler option -fno-builtin, warnings disappear.

Best regards,

Olivier

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Jun  5 11:27:12 2018
New Revision: 261196

URL: https://gcc.gnu.org/viewcvs?rev=261196&root=gcc&view=rev
Log:
PR c++/85731 - wrong error with qualified-id in template.

* semantics.c (finish_qualified_id_expr): build_qualified_name
for unbound names in the current class.

Added:
trunk/gcc/testsuite/g++.dg/template/qualified-id7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Jun  5 11:27:15 2018
New Revision: 261197

URL: https://gcc.gnu.org/viewcvs?rev=261197&root=gcc&view=rev
Log:
PR c++/85731 - wrong error with qualified-id in template.

* semantics.c (finish_qualified_id_expr): build_qualified_name
for unbound names in the current class.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/template/qualified-id7.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/semantics.c

[Bug fortran/86052] ICE with parameterized derived types

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
(In reply to Jürgen Reuter from comment #0)
> The following example from c.l.f. (Dec 14, 2015, "explicit specialization
> for Fortran2003 recursively-defined parameterized data types?" leads to an
> ICE with the current trunk of gfortran (r260633). In the code below, if the
> non-pointer declaration is commented in, gfortran correctly vetoes this as
> "Component at (1) must have the POINTER attribute", but with the version
> below this leads to an ICE. With ifort v18 and v19 the code is rejected as
> "error #7555: Not yet implemented: Type containing ALLOCATABLE/POINTER field
> of same type with different type parameters. 
> type(tensor(rank-1,dim)), pointer :: values(:)"
> 
> 
> 
> *
> 
> Code triggering the ICE:
> 
> module tensor_names
> implicit none
> private
> type :: tensor(rank,dim)
> integer, kind :: rank
> integer, kind :: dim
> type(tensor(rank-1,dim)), pointer :: values(:)
> ! type(tensor(rank-1,dim)) :: values(dim) ! Illegal!!!
> contains
> procedure, private :: create_tensor_rank_2_dim_2
> generic :: create => create_tensor_rank_2_dim_2
> end type
> contains
> subroutine create_tensor_rank_2_dim_2 ( this )
> implicit none
> class(tensor(2,2)), intent(inout) :: this
> end subroutine
> end module tensor_names

Hi Juergen,

You really come up with some fine ones :-) I know where this is happening
without even looking.

I am sharpening up for a PDT-fest for the last half of this month. Next week, I
will commence with a triage of PDTs and clear out some of the last of my
non-PDT bugs.

Many thanks

Paul

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug fortran/86052] ICE with parameterized derived types

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Paul, it is not my example, it was posted by Alberto Fco. Martín-Huertas in
December 2015 on c.l.f., and you commented at that time that you were
contemplating on how to implement PDTs together with recursive allocatables :P
I am just playing a little bit around and following the (older) entries on
c.l.f.

[Bug tree-optimization/86054] New: [8.1/9 Regression] SPEC CPU2006 416.gamess miscompare after r259592 with march=skylake-avx512

[alexander.nesterovskiy at intel dot com]

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

Bug ID: 86054
   Summary: [8.1/9 Regression] SPEC CPU2006 416.gamess miscompare
after r259592 with march=skylake-avx512
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.nesterovskiy at intel dot com
  Target Milestone: ---

Created attachment 44237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44237&action=edit
reproducer

r259592 introduced a runfail due to miscompare in SPEC CPU2006 416.gamess.
Minimal optset to reproduce is "-O3 -march=skylake-avx512".
There is no miscompare when vectorization is disabled with
"-fno-tree-vectorize".

This benchmark has some issues described in documentation
(https://www.spec.org/cpu2006/Docs/416.gamess.html):
"Some arrays are accessed past the end of the defined array size. This will,
however, not cause memory access faults" and
"The argument array sizes defined in some subroutines do not match the size of
the actual argument passed"

The problem is in "JKBCDF" function in "grd2c.F" and it's related to these
issues with wrong argument array sizes.
Patching the benchmark source solves a problem (but this patching is not
allowed according to SPEC rules):
"DIMENSION ABV(5,1),CV(18,1)" -> "DIMENSION ABV(5,NUMG),CV(18,NUMG)"

Reproducer is attached.
Symptoms here and in original 416.gamess case is that some loop iterations are
skipped.

[Bug tree-optimization/86054] [8/9 Regression] SPEC CPU2006 416.gamess miscompare after r259592 with march=skylake-avx512

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unknown |8.1.1
 Resolution|--- |INVALID
   Target Milestone|--- |8.2
Summary|[8.1/9 Regression] SPEC |[8/9 Regression] SPEC
   |CPU2006 416.gamess  |CPU2006 416.gamess
   |miscompare after r259592|miscompare after r259592
   |with march=skylake-avx512   |with march=skylake-avx512

--- Comment #1 from Richard Biener  ---
The rev. in question is just a costing change which means it uncovers
previously latent issues.

Note I wonder why not vectorizing helps here because niter analysis should
conclude from

DIMENSION A(5, 1), B(2, W, H), C(W, H, 3)

DO I=1, H
  DO J=1, W
C(J, I, 1)=B(2, J, I)*A(4, J)
C(J, I, 2)=1.0d0
C(J, I, 3)=1.0d0
  END DO
END DO

that the J loop only runs once via the access to A(4, J).  I guess due
to the lowering to a 1-dim array that somehow doesn't work but it works
when vectorized.

As this is clearly invalid code there's nothing we can do about this
(but close it as dup of one of the many gamess bugs about this or
related issues like PR56993 or PR53086).

I believe a workaround is -fno-aggressive-loop-optimizations and/or
-funconstrained-commons

[Bug gcov-profile/84846] GCOV intermediate format improvements

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Fixed now.

[Bug other/86039] Compiler placed in deep/long folder cannot open/run needed files on Windows

[samuel.hultgren at st dot com]

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

--- Comment #2 from Samuel Hultgren  ---
(In reply to Jim Wilson from comment #1)
> Windows has a 260 character default maximum path length.  See for instance
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).
> aspx#maxpath
> 
> This looks like an OS problem not a gcc problem.

Maybe both.

It is possible to read/write files that have longer paths than 260 characters
if you use UNC paths by prefixing absolute paths with "\\?\" on Windows.

For executing files on Windows we can improve the situation by using a
combination of UNC paths together with GetShortPathNameW before sending the
path to CreateProcessW. Only restriction here is that the resulting shorted
path must still be shorter than 260 characters.

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
Author: marxin
Date: Tue Jun  5 12:10:22 2018
New Revision: 261199

URL: https://gcc.gnu.org/viewcvs?rev=261199&root=gcc&view=rev
Log:
Support variables in expansion of -fprofile-generate option (PR
gcov-profile/47618).

2018-06-05  Martin Liska  

PR gcov-profile/47618
* doc/invoke.texi: Document how -fprofile-dir format
is extended.
2018-06-05  Martin Liska  

PR gcov-profile/47618
* libgcov-driver-system.c (replace_filename_variables): New
function.
(gcov_exit_open_gcda_file): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-driver-system.c

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #22 from Martin Liška  ---
Implemented.

[Bug tree-optimization/86054] [8/9 Regression] SPEC CPU2006 416.gamess miscompare after r259592 with march=skylake-avx512

[alexander.nesterovskiy at intel dot com]

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

--- Comment #2 from Alexander Nesterovskiy  ---
Thanks, "-fno-aggressive-loop-optimizations" helps.

[Bug c++/85976] [8/9 Regression] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jun  5 13:11:00 2018
New Revision: 261200

URL: https://gcc.gnu.org/viewcvs?rev=261200&root=gcc&view=rev
Log:
PR c++/85976
* tree.c (cp_tree_equal): Handle USING_DECL.

* g++.dg/cpp0x/alias-decl-64.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-64.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85976] [8 Regression] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |cp_tree_equal when building |cp_tree_equal when building
   |Blitz. May be nested|Blitz. May be nested
   |templates.  |templates.

--- Comment #9 from Marek Polacek  ---
Fixed on trunk so far.

[Bug fortran/85701] [openacc] ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[cesar at gcc dot gnu.org]

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

--- Comment #3 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Tue Jun  5 13:58:50 2018
New Revision: 261202

URL: https://gcc.gnu.org/viewcvs?rev=261202&root=gcc&view=rev
Log:
PR fortran/85701

gcc/fortran/
* openmp.c (gfc_resolve_oacc_declare): Error on functions and
subroutine data clause arguments.

gcc/testsuite/
* gfortran.dg/goacc/pr85701.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/goacc/pr85701.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug c/86055] New: Bitshifts temporarly change uint32_t to int32_t on x86_64 Mac OS

[guicrith at gmail dot com]

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

Bug ID: 86055
   Summary: Bitshifts temporarly change uint32_t to int32_t on
x86_64 Mac OS
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guicrith at gmail dot com
  Target Milestone: ---

Created attachment 44238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44238&action=edit
Simple test program source, no dependancys.

Right-shifting a negative value is implementation-defined and not recommended
by good coding practice. Wikipedia
The same behavior is occuring with a uint32_t, but it should be impossible for
it to be negative.
Under the existing C rules uint16_t should be promoted to int64_t(the native
int type for x86_64) before bitshifting.
It seems to be taking the signed part of int64_t without the 64 bits part.

x86_64 Mac OS 10.13.5 gcc version 8.1.0 (Homebrew GCC 8.1.0)

[Bug c/86055] Bitshifts temporarly change uint32_t to int32_t on x86_64 Mac OS

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>Under the existing C rules uint16_t should be promoted to int64_t

No, just to int.

[Bug c/86053] Builtin fwrite arguments have non_null attribute and builtin function declaration not overloaded

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I don't see this as a real issue as the C standard has a requirement that the
FILE* argument should be non-null; otherwise it is undefined behavior at
runtime.  Using -fno-builtins or -ffree-standing is the correct fix here.

[Bug target/86056] New: Codegen can result in multiple sequential mfence instructions

[redbeard0531 at gmail dot com]

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

Bug ID: 86056
   Summary: Codegen can result in multiple sequential mfence
instructions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

This is from an example to prove that atomic_thread_fence does not prevent the
compiler from optimizing non-escaped memory.

https://godbolt.org/g/288mTC

#include 
#include 
struct Type {
Type(Type&&)=default;
int i;
};

Type func(Type t) {
auto out = Type(Type(std::move(t)));
std::atomic_thread_fence(std::memory_order_seq_cst);
return out;
}

auto func2(Type t) { return func(func(func(func(std::move(t); }

func(Type):
  movl (%rsi), %edx
  movq %rdi, %rax
  movl %edx, (%rdi)
  mfence
  ret
func2(Type):
  movl (%rsi), %edx
  movq %rdi, %rax
  mfence
  mfence
  mfence
  movl %edx, (%rdi)
  mfence
  ret

[Bug c++/85847] [6/7/8 Regression] unexpected expression of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jun  5 15:33:51 2018
New Revision: 261205

URL: https://gcc.gnu.org/viewcvs?rev=261205&root=gcc&view=rev
Log:
PR c++/85847
* init.c (build_new_1): Use fold_non_dependent_expr.  Use a dedicated
variable for its result.  Fix a condition.
(build_new): Use fold_non_dependent_expr.  Tweak a condition.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/new3.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/init.c

[Bug c++/85847] [6/7/8 Regression] unexpected expression of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/85976] [8 Regression] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jun  5 15:41:34 2018
New Revision: 261206

URL: https://gcc.gnu.org/viewcvs?rev=261206&root=gcc&view=rev
Log:
PR c++/85976
* tree.c (cp_tree_equal): Handle USING_DECL.

* g++.dg/cpp0x/alias-decl-64.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-64.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/tree.c

[Bug middle-end/86056] Codegen can result in multiple sequential mfence instructions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #1 from Andrew Pinski  ---
I don't see why you think atomic_thread_fence should prevent this kind of
optimization here as no other thread can "see" the stores that would be doing.

The only thing I see missing is the merging of the __atomic_thread_fence

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[cohenjon at google dot com]

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

Jon Cohen  changed:

   What|Removed |Added

 CC||cohenjon at google dot com

--- Comment #21 from Jon Cohen  ---
What is the current status on this bug?  I'm currently working on exception
safety for Abseil's call_once which uses pthread_once under the hood.  It looks
like there are still people bringing up issue with this in the glibc thread as
well -- is this still actively being worked on?

[Bug bootstrap/86057] New: Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[kargl at gcc dot gnu.org]

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

Bug ID: 86057
   Summary: Use of mempcpy in libgcc/ libgcov-driver-system.c
breaks bootstrap
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

In file included from ../../gcc/gcc/../libgcc/libgcov-driver.c:322:0:
../../gcc/gcc/../libgcc/libgcov-driver-system.c: In function 'char*
replace_filename_variables(char*)':
../../gcc/gcc/../libgcc/libgcov-driver-system.c:193:25: error: 'mempcpy' was
not declared in this scope
buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start);
 ^~~
../../gcc/gcc/../libgcc/libgcov-driver-system.c:193:25: note: suggested
alternative: 'memccpy'
buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start);
 ^~~
 memccpy
gmake[3]: *** [Makefile:2949: libgcov-driver-tool.o] Error 1
gmake[3]: Leaving directory '/safe/sgk/gcc/obj/gcc'
gmake[2]: *** [Makefile:4621: all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/safe/sgk/gcc/obj'
gmake[1]: *** [Makefile:22969: stage1-bubble] Error 2
gmake[1]: Leaving directory '/safe/sgk/gcc/obj'
gmake: *** [Makefile:23306: bootstrap] Error 2

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 CC||mliska at suse dot cz
   Host||x86_64-*-freebsd
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org
   Host|x86_64-*-freebsd|x86_64-*-freebsd,
   ||*-*-solaris2.*

--- Comment #1 from Rainer Orth  ---
Affects Solaris, too (and almost certainly macOS as well).

[Bug middle-end/86058] New: TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning

[andrew.burgess at embecosm dot com]

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

Bug ID: 86058
   Summary: TARGET_MEM_REF causing incorrect message for
-Wmaybe-uninitialized warning
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.burgess at embecosm dot com
  Target Milestone: ---

The following:

/* { dg-do compile } */
/* { dg-options "-O2 -Wuninitialized -Wmaybe-uninitialized" } */

extern void foo (int *);

void
zip (int *out, int indx)
{
  int arr[10];

  for (int i = 0; i < indx; ++i)
out[i] = arr[i] + 1;  /* { dg-warning "'arr[i]' may be used
uninitialized in this function" } */

  foo (arr);
  foo (out);
}

When compiled gives this warning:

$ gcc -Wuninitialized -Wmaybe-uninitialized -O2 test.c
#‘target_mem_ref’ not supported by expression#’ test.c: In function ‘zip’:
test.c:12:17: warning:  may be used uninitialized in this function
[-Wmaybe-uninitialized]
 out[i] = arr[i] + 1;  /* { dg-warning "'arr[i]' may be used
uninitialized in this function" } */
  ~~~^~~

The problem seems to arise from tree-ssa-uninit.c:warn_uninitialized_vars which
ends up calling warning_at and using %qE to format a tree, which is of type
TRAGET_MEM_REF.

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Tue, Jun 05, 2018 at 05:25:12PM +, ro at gcc dot gnu.org wrote:
> 
> --- Comment #1 from Rainer Orth  ---
> Affects Solaris, too (and almost certainly macOS as well).
> 

mempcpy seems to be a glibc 2.1 extension.  I suspect
bootstrap is broken on all non-glibc based systems.

[Bug fortran/85701] [openacc] ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||cesar at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from cesar at gcc dot gnu.org ---
Fixed in trunk by having the Fortran FE error when function and subroutine are
used data clause arguments to acc declare.

[Bug fortran/77703] [6/7/8/9 Regression] ICE on assignment to pointer function

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---

Reducing a bit :


$ cat z1.f90
module m
contains
   function f() result(z)
  character(3), pointer :: z
   end
end
program p
   use m
   f() = 'abc'
end


$ gfortran-9-20180603 -c z1.f90
z1.f90:7:0:

 program p

internal compiler error: in gfc_trans_auto_character_variable, at
fortran/trans-decl.c:3917
0x7714ff gfc_trans_auto_character_variable
../../gcc/fortran/trans-decl.c:3917
0x7714ff gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4782
0x772f93 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6619
0x701bc0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701bc0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x748c6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85942] ICE with PDTs

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---
One possible reduction :


$ cat z1.f90
module m
   type t(a)
  private
  integer, len :: a = 1
   end type
end
program p
   use m
   type(t(a=:)), allocatable :: z
end


$ gfortran-9-20180603 -c z1.f90
f951: internal compiler error: Segmentation fault
0xba15af crash_signal
../../gcc/toplev.c:325
0x693919 gfc_get_pdt_instance(gfc_actual_arglist*, gfc_symbol**,
gfc_actual_arglist**)
../../gcc/fortran/decl.c:3473
0x699c71 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3990
0x69abbc gfc_match_data_decl()
../../gcc/fortran/decl.c:5808
0x6f6fb9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fa6ae match_word
../../gcc/fortran/parse.c:376
0x6fa6ae decode_statement
../../gcc/fortran/parse.c:376
0x6fc5d4 next_free
../../gcc/fortran/parse.c:1230
0x6fc5d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fdecc parse_spec
../../gcc/fortran/parse.c:3854
0x7003b3 parse_progunit
../../gcc/fortran/parse.c:5667
0x701994 gfc_parse_file()
../../gcc/fortran/parse.c:6207
0x748c6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


Of course, compiles without "private"

[Bug fortran/86059] New: ICE in reduce_binary_ac, at fortran/arith.c:1308 (and others)

[gs...@t-online.de]

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

Bug ID: 86059
   Summary: ICE in reduce_binary_ac, at fortran/arith.c:1308 (and
others)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Extracted from pr86045 comment 1, loosely related to pr66193.
Invalid code with null(), affects gfortran down to at least 4.8.


$ cat zn1.f90
program p
   real :: z(1) = [real :: null()] + 2.0
end

$ cat zn2.f90
program p
   real :: z(1) = [real :: null()] + [real :: 2]
end

$ cat zn3.f90
program p
   real :: z(1) = 1.0 + [real :: null()]
end

$ cat zn4.f90
program p
   real :: z(1) = [real :: 1] + [real :: null()]
end

$ cat zn5.f90
program p
   real :: z(2) = [real :: null()] + [real :: null()]
end


$ gfortran-9-20180603 -c zn1.f90
f951: internal compiler error: Segmentation fault
0xba15af crash_signal
../../gcc/toplev.c:325
0x675138 reduce_binary_ac
../../gcc/fortran/arith.c:1308
0x6750d2 reduce_binary_ac
../../gcc/fortran/arith.c:1295
0x67531c reduce_binary
../../gcc/fortran/arith.c:1421
0x675b3b eval_intrinsic
../../gcc/fortran/arith.c:1596
0x675d9e eval_intrinsic_f3
../../gcc/fortran/arith.c:1733
0x6ac645 simplify_intrinsic_op
../../gcc/fortran/expr.c:1133
0x6ac645 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:1984
0x70f44f resolve_operator
../../gcc/fortran/resolve.c:4162
0x70f44f gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6716
0x6ab92f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2773
0x6ae431 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x69bfb9 variable_decl
../../gcc/fortran/decl.c:2681
0x69bfb9 gfc_match_data_decl()
../../gcc/fortran/decl.c:5880
0x6f6fb9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fa6ae match_word
../../gcc/fortran/parse.c:376
0x6fa6ae decode_statement
../../gcc/fortran/parse.c:376
0x6fc5d4 next_free
../../gcc/fortran/parse.c:1230
0x6fc5d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fe3ec parse_spec
../../gcc/fortran/parse.c:3670

[Bug fortran/86045] ICE in reduce_binary_ac, at fortran/arith.c:1308 (and others)

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---
> There's a are different issue than the one involving MOD().
Cases from comment 1 are now separated as pr86059.

[Bug c++/85976] [8 Regression] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug middle-end/86056] Codegen can result in multiple sequential mfence instructions

[redbeard0531 at gmail dot com]

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

--- Comment #2 from Mathias Stearn  ---
Oh, I agree that this optimization must be permitted. I was using this example
to prove this to someone else who didn't believe that. I only mentioned that to
explain how that weird source code came to be.

My point of this bug was that the code gen can be further optimized because
there is never a good reason to have multiple mfence instructions back to back
like that.

[Bug c++/86049] Array bindings are not const when initializer is

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #2 from Richard Smith  ---
I think this is a bug in the standard. The cv-qualifiers of the array type
should be discarded, as they would be for any normal auto deduction.

[Bug fortran/86045] ICE in reduce_binary_ac, at fortran/arith.c:1308

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Tue, Jun 05, 2018 at 06:02:47PM +, gs...@t-online.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86045
> 
> --- Comment #4 from G. Steinmetz  ---
> > There's a are different issue than the one involving MOD().
> Cases from comment 1 are now separated as pr86059.

Thanks.  I've submitted a patch that fixes MOD(..., 0),
but I'm guessing you'll find a way to break it. :-)
Perhaps, MOD(..., null()) as I hadn't thought about this
example until now.

[Bug middle-end/86058] TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Since the production of TRAGET_MEM_REF is target dependent, what target does
this happen for you?

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build

--- Comment #3 from Andrew Pinski  ---
mempcpy is in libiberty but we don't compile a target version of libiberty.

[Bug middle-end/86058] TARGET_MEM_REF causing incorrect message for -Wmaybe-uninitialized warning

[andrew.burgess at embecosm dot com]

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

--- Comment #2 from Andrew Burgess  ---
Sorry, this is on x86-64/GNU-Linux

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Jun 05, 2018 at 06:21:29PM +, pinskia at gcc dot gnu.org wrote:
> 
> --- Comment #3 from Andrew Pinski  ---
> mempcpy is in libiberty but we don't compile a target version of libiberty.
> 

Looking at the code, one can use strcat or strncat,
which are part of ISO C.

[Bug c++/86060] New: g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[helloqirun at gmail dot com]

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

Bug ID: 86060
   Summary: g++ ICE at on with "c++03" in tsubst_copy, at
cp/pt.c:15459
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The trunk version g++ crashes with "-std=c++98" or "-std=c++03". The other std
flags seem working.

It seems to be a regression in 5.X. Gcc-4.9 works fine.

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180604 (experimental) [trunk revision 261145] (GCC)



$ g++-trunk -std=c++11 -c abc.cpp

$ g++-trunk -std=c++98 -c abc.cpp
abc.cpp: In function ‘void foo(T (&)[8])’:
abc.cpp:2:16: warning: range-based ‘for’ loops only available with -std=c++11
or -std=gnu++11
   for (int i : a)
^
abc.cpp: In instantiation of ‘void foo(T (&)[8]) [with T = int]’:
abc.cpp:5:22:   required from here
abc.cpp:3:5: internal compiler error: in tsubst_copy, at cp/pt.c:15459
 i;
 ^
0x64601c tsubst_copy
../../gcc/gcc/cp/pt.c:15457
0x968c43 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18862
0x974ab7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17415
0x9727c6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16616
0x97251d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16811
0x971bbf tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16899
0x971517 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16587
0x971517 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:24001
0x997023 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:24117
0x8be968 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4703
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ cat abc.cpp
template  void foo(T (&a)[8]) {
  for (int i : a)
i;
}
void fn1() { foo; }

[Bug c++/86060] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|g++ ICE at on with "c++03"  |[6/7/8/9 Regression] g++
   |in tsubst_copy, at  |ICE at on with "c++03" in
   |cp/pt.c:15459   |tsubst_copy, at
   ||cp/pt.c:15459

--- Comment #2 from Marek Polacek  ---
Started with r212044.

[Bug tree-optimization/86061] New: dead memset followed by strncpy and assignment not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 86061
   Summary: dead memset followed by strncpy and assignment not
eliminated
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is similar to bug 86010 except the optimization is absent from all
versions of GCC all the way back to 4.1.  In the test case below the memset
call zeroes out the entire destination array, only to have its contents
overwritten by the subsequent call to strncpy followed by the write to its last
element.  Rather than eliminating the memset call and keeping the
single-character store GCC does the opposite, which is obviously suboptimal.

This code is reduced from code that's idiomatic in the Linux kernel when
copying between kernel data (that's not necessarily nul-terminated) and
user-space strings (which are expected to be nul-terminated).

$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c

struct S { int i; char n[256]; int j; };

void f (char*);

void g (struct S *p)
{
  char a[sizeof p->n + 1];

  __builtin_memset (a, 0, sizeof a);   // dead store, can be eliminated

  __builtin_strncpy (a, p->n, sizeof a - 1);
  a[sizeof a - 1] = '\0';

  f (a);
}


;; Function g (g, funcdef_no=0, decl_uid=1964, cgraph_uid=0, symbol_order=0)

g (struct S * p)
{
  char a[257];
  char[256] * _1;

   [local count: 1073741825]:
  __builtin_memset (&a, 0, 257);
  _1 = &p_4(D)->n;
  __builtin_strncpy (&a, _1, 256);
  f (&a);
  a ={v} {CLOBBER};
  return;

}

[Bug tree-optimization/86061] dead memset followed by strncpy and assignment not eliminated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86010,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80576

--- Comment #1 from Martin Sebor  ---
See also bug 80576 for a similar dead store elimination opportunity.

[Bug tree-optimization/86061] dead memset followed by strncpy and assignment not eliminated

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/86061] dead memset followed by strncpy and assignment not eliminated

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|missed-optimization |

--- Comment #2 from Andrew Pinski  ---
I think this memset is only partial dead and not fully dead.
What I mean is the string p->n is smaller than 254, then the memset is still
not dead.

[Bug tree-optimization/81384] built-in form of strnlen missing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00267.html

[Bug target/79924] aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd

[sje at gcc dot gnu.org]

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

--- Comment #1 from Steve Ellcey  ---
Author: sje
Date: Tue Jun  5 22:20:13 2018
New Revision: 261217

URL: https://gcc.gnu.org/viewcvs?rev=261217&root=gcc&view=rev
Log:
2018-06-05  Steve Ellcey  

PR target/79924
* config/aarch64/aarch64-protos.h (aarch64_err_no_fpadvsimd): Remove
second argument.
* config/aarch64/aarch64-protos..c (aarch64_err_no_fpadvsimd):
Remove second argument, change how error is called.
(aarch64_layout_arg): Remove second argument from
aarch64_err_no_fpadvsimd call.
(aarch64_init_cumulative_args): Ditto.
(aarch64_gimplify_va_arg_expr): Ditto.
* config/aarch64/aarch64.md (mov): Ditto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md

[Bug target/79924] aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd

[sje at gcc dot gnu.org]

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

--- Comment #2 from Steve Ellcey  ---
Author: sje
Date: Tue Jun  5 22:21:36 2018
New Revision: 261218

URL: https://gcc.gnu.org/viewcvs?rev=261218&root=gcc&view=rev
Log:
2018-06-05  Steve Ellcey  

PR target/79924
* gcc.target/aarch64/mgeneral-regs_1.c: Update error message.
* gcc.target/aarch64/mgeneral-regs_2.c: Ditto.
* gcc.target/aarch64/mgeneral-regs_3.c: Ditto.
* gcc.target/aarch64/nofp_1.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/mgeneral-regs_1.c
trunk/gcc/testsuite/gcc.target/aarch64/mgeneral-regs_2.c
trunk/gcc/testsuite/gcc.target/aarch64/mgeneral-regs_3.c
trunk/gcc/testsuite/gcc.target/aarch64/nofp_1.c

[Bug bootstrap/86057] Use of mempcpy in libgcc/ libgcov-driver-system.c breaks bootstrap

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Confirmed on darwin too.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

--- Comment #22 from Jonathan Wakely  ---
It still needs to be fixed, and hoping for a libc fix isn't going to work
because even if we get a solution in glibc it won't work for other C libraries.
So we need to reimplement our std::call_once. I'll make sure we get this done
for GCC 9.

[Bug tree-optimization/86062] New: Missed redundancy elimination with struct and array

[glisse at gcc dot gnu.org]

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

Bug ID: 86062
   Summary: Missed redundancy elimination with struct and array
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

#include 

struct I { double i,s; I(double d):i(d),s(d){} };
typedef std::array P;
typedef std::array AP;

static AP c(P const&p){
  return {p[0],p[1],p[2]};
}
template auto const& ac(T const&p, int n){return p[n];}
static double g(P const&p, int n)
{
  I res = ac(c(p),n);
  return res.s-res.i;
}

__attribute__((flatten)) double fff(P p){ return g(p,1); }


compiles at -O2 to the following

  double res$8;
  struct AP D.30336;
  struct I res;
  double _2;
  double _3;

   [local count: 1073741825]:
  _2 = MEM[(const value_type &)&p + 8];
  MEM[(const struct I &)&D.30336 + 16] = _2;
  MEM[(const struct I &)&D.30336 + 24] = _2;
  res = MEM[(const struct I &)&D.30336][1];
  res$8_13 = MEM[(struct I *)&res + 8B];
  D.30336 ={v} {CLOBBER};
  _3 = res$8_13 - _2;
  return _3;

Or with -O3

  double res$8;
  struct AP D.30336;
  struct I res;
  double _2;
  double _3;
  vector(2) double _9;

   [local count: 1073741825]:
  _2 = MEM[(const value_type &)&p + 8];
  _9 = {_2, _2};
  MEM[(const struct I &)&D.30336 + 16] = _9;
  res = MEM[(const struct I &)&D.30336][1];
  res$8_13 = MEM[(struct I *)&res + 8B];
  D.30336 ={v} {CLOBBER};
  _3 = res$8_13 - _2;
  return _3;

While we should be able to notice that res$8_13 and 2 are the same (and thus
simplify to 0 with -ffast-math).

[Bug c++/86063] New: g++ ICE at tree check: expected tree_list, have expr_pack_expansion in cp_check_const_attributes, at cp/decl2.c:1391

[helloqirun at gmail dot com]

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

Bug ID: 86063
   Summary: g++ ICE at  tree check: expected tree_list, have
expr_pack_expansion in cp_check_const_attributes, at
cp/decl2.c:1391
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

It appears to be a recent regression.

g++-7.3 compiles.






$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180604 (experimental) [trunk revision 261145] (GCC) 


$ g++-trunk abc.cpp
abc.cpp:1:64: internal compiler error: tree check: expected tree_list, have
expr_pack_expansion in cp_check_const_attributes, at cp/decl2.c:1391
 template  struct A2 { [[gnuA(alignof(T))...]] char t; };
^
0x798b88 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9338
0x6127bf tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3135
0x6127bf cp_check_const_attributes
../../gcc/gcc/cp/decl2.c:1391
0x6127bf cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1509
0x8bcbed grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:967
0x9327cd cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:24017
0x933828 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:23496
0x933828 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22640
0x935649 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22902
0x935649 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16883
0x94282c cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13721
0x946f45 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27319
0x9472cc cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:27011
0x947b6e cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:27248
0x947b6e cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:27267
0x94d0d9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12825
0x94d3ad cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12752
0x94d6a4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4574
0x94d6a4 c_parse_file()
../../gcc/gcc/cp/parser.c:39132
0xa4a7c6 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1133
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ cat abc.cpp
template  struct A2 { [[gnuA(alignof(T))...]] char t; };

[Bug tree-optimization/86042] [8/9 Regression] missing strlen optimization after second strcpy

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The strcpy() calls are first transformed into

  MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})"12"];

In GCC 7, the above is then transformed into

  MEM[(char * {ref-all})&a] = "12";

(I'm not sure what the difference is).  In GCC 7, the second instance of the
above is then removed in fre1.

In GCC 8, the second instance makes it all the way to the strlen pass where
handle_char_store() isn't prepared to deal with it if a length record exists
for the destination.  I think the strlen() limitation can be handled by the
same solution as bug 86043: i.e., have handle_char_store() handle cases where
substrings of any length is overwritten without changing their length, not just
those of length one by plain character assignment.

I don't know why the duplicate MEM assignment above isn't eliminated earlier
(that may be a separate bug).

[Bug tree-optimization/86042] [8/9 Regression] missing strlen optimization after second strcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c++/86063] [6/7/8/9 Regression] g++ ICE at tree check: expected tree_list, have expr_pack_expansion in cp_check_const_attributes, at cp/decl2.c:1391

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-06
 CC||mpolacek at gcc dot gnu.org
Summary|g++ ICE at  tree check: |[6/7/8/9 Regression] g++
   |expected tree_list, have|ICE at  tree check:
   |expr_pack_expansion in  |expected tree_list, have
   |cp_check_const_attributes,  |expr_pack_expansion in
   |at cp/decl2.c:1391  |cp_check_const_attributes,
   ||at cp/decl2.c:1391
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r222902.

[Bug c/86064] New: [8 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[alex_y_xu at yahoo dot ca]

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

Bug ID: 86064
   Summary: [8 Regression] compiling Linux kernel: Error: can't
resolve `.text.unlikely' {.text.unlikely section} -
`.LVL43x' {.text section}
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex_y_xu at yahoo dot ca
  Target Milestone: ---

description:

compiling Linux kernel fails with gcc 8.1. I think gcc 7.3.1-20180406 works.

steps to reproduce:

gcc -fno-var-tracking-assignments -gsplit-dwarf -O2 -c -o /dev/null -c common.i

flags trimmed from full compile line. file preprocessed from
linux-4.17/arch/x86/kernel/cpu/common.c.

expected result:

objcopy: Warning: '/dev/null' is not an ordinary file

actual result:

Assembler messages:
Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL436'
{.text section}
Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL437'
{.text section}

additional information:

-O1 compiles with no errors. -O0 produces the following (trimmed):

./arch/x86/include/asm/cpufeature.h: In function ‘syscall_init’:
./arch/x86/include/asm/cpufeature.h:164:7: warning: asm operand 0 probably
doesn’t match constraints
  asm_volatile_goto("1: jmp 6f\n"
   ^~~
./arch/x86/include/asm/cpufeature.h:164:7: warning: asm operand 2 probably
doesn’t match constraints
./arch/x86/include/asm/cpufeature.h:164:7: error: impossible constraint in
‘asm’

you can find the contents of cpufeature.h in the Linux source code.

.config available on request.

[Bug fortran/86065] New: gfortran NAMELIST improperly reads arrays that span more than one line.

[charlie at sallyandcharlie dot com]

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

Bug ID: 86065
   Summary: gfortran NAMELIST improperly reads arrays that span
more than one line.
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: charlie at sallyandcharlie dot com
  Target Milestone: ---

gfortran NAMELIST improperly reads arrays that span more than one line.

It skips an array position for lines ending with ",\n"

- Example Input File -
$MY_INP
  i = 1,2,3,4,
  5,6,7,8,
  9,10,11,12,
$END

-- Example Output from Code Below --
Output:
1 2 3 4 0 5 6 7 8 0  9 10 11 12  0  0  0  0  0  0
^ ^
Skips an array entry with each new line

-- Example Code ---
compiled with: 
gfortran read_arr.f  -finit-local-zero -o read_arr.exe

-File: read_arr.f--
  program NL_ERR

  dimension i(20)

  namelist /MY_INP/i

  open(5,file='a.inp', status='OLD')
  read(5, MY_INP, end=9)

  9   write(*, '(10I2, 10I3)')(i(j), j=1,20)

  stop
  end

-- Working Input File 
If the trailing commas are removed, it works properly
---
$MY_INP
  i = 1,2,3,4
  5,6,7,8
  9,10,11,12,
$END

Output:
1 2 3 4 5 6 7 8 910 11 12  0  0  0  0  0  0  0  0

[Bug fortran/86065] gfortran NAMELIST improperly reads arrays that span more than one line.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-06
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
It appears that you need to update to a newer version of gfortran.
The code gives the expected with 6.4.1, 7.3.1, 8.1.1, and 9.0.0.
The 5-branch is closed to changes, so it will not be fixed in
that branch.

[Bug fortran/86065] gfortran NAMELIST improperly reads arrays that span more than one line.

[charlie at sallyandcharlie dot com]

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

--- Comment #2 from Charlie  ---
Thank You

-Original Message-
From: kargl at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Tuesday, June 5, 2018 7:26 PM
To: char...@sallyandcharlie.com
Subject: [Bug fortran/86065] gfortran NAMELIST improperly reads arrays that
span more than one line.

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-06
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
It appears that you need to update to a newer version of gfortran.
The code gives the expected with 6.4.1, 7.3.1, 8.1.1, and 9.0.0.
The 5-branch is closed to changes, so it will not be fixed in
that branch.

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #8 from Josh Marshall  ---
If this code is to work, given that this is the only way to track in detail use
of various stdlib internals, one of two things need to change.  Either all
assignments to _Distance need to be explicitly wrapped and the constructor from
a scalar make explicit with implicit conversion to an int, or implicit
conversion from int without conversion to int and all uses of _Distance do not
explicitly require a scalar but a set of operators which can be applied to a
scalar be implemented by _Distance.

I can quickly submit a patch for the first one, but I'm not sure it is the
right approach.  I'm going to ask this in the C++ standards forum tomorrow and
maybe they'll have insight about changing the nature of std::ptrdiff_t.

[Bug tree-optimization/86066] New: wrong code at -Os and above on x86-64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 86066
   Summary: wrong code at -Os and above on x86-64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression.

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180606 (experimental) [trunk revision 261226] (GCC) 
$ 
$ gcctk -O1 small.c; ./a.out
$ 
$ gcctk -Os small.c
$ timeout -s 9 5 ./a.out
Killed
$ 



struct A
{
  int b:2;
  int c:2;
  unsigned d:8;
};

int main ()
{
  struct A t = { 0, 0, 2 };
 L:
  t.d = ~(~(~0 % t.d) % 2);
  if (!t.d)
goto L;
  return 0;
}

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Jun  6 06:05:07 2018
New Revision: 261227

URL: https://gcc.gnu.org/viewcvs?rev=261227&root=gcc&view=rev
Log:
PR libstdc++/86008 add std::quoted support for string_view

PR libstdc++/86008
* include/bits/quoted_string.h (_Quoted_string):
Define new partial specialization.
* include/std/iomanip (quoted(basic_string_view, C, C)): Define
new overload.
(operator<<(basic_ostream&, const _Quoted_string&)): Use
value not reference for iteration.
* testsuite/27_io/manipulators/standard/char/quoted.cc: Adjust
comment.
* testsuite/27_io/manipulators/standard/char/quoted_sv.cc: New test.
* testsuite/27_io/manipulators/standard/wchar_t/quoted.cc: Adjust
comment.

Added:
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/char/quoted_sv.cc
  - copied, changed from r261226,
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/char/quoted.cc
   
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/wchar_t/quoted_sv.cc
  - copied, changed from r261226,
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/wchar_t/quoted.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/quoted_string.h
trunk/libstdc++-v3/include/std/iomanip
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/char/quoted.cc
trunk/libstdc++-v3/testsuite/27_io/manipulators/standard/wchar_t/quoted.cc