[Bug tree-optimization/90385] New: [9/10 Regression] ICE: tree check: expected ssa_name, have real_cst in transform_to_exit_first_loop_alt, at tree-parloops.c:1772

[asolokha at gmx dot com]

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

Bug ID: 90385
   Summary: [9/10 Regression] ICE: tree check: expected ssa_name,
have real_cst in transform_to_exit_first_loop_alt, at
tree-parloops.c:1772
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-10.0.0-alpha20190505 snapshot (r270883) ICEs when compiling
gcc/testsuite/gfortran.dg/array_constructor_47.f90 w/ -O1
-ftree-parallelize-loops=2 -fno-tree-ccp -fno-tree-ch -fno-tree-copy-prop
-fno-tree-forwprop -fno-tree-sink --param parloops-min-per-thread=5:

% powerpc-e300c3-linux-gnu-gfortran-10.0.0-alpha20190505 -O1
-ftree-parallelize-loops=2 -fno-tree-ccp -fno-tree-ch -fno-tree-copy-prop
-fno-tree-forwprop -fno-tree-sink --param parloops-min-per-thread=5 -c
gcc/testsuite/gfortran.dg/array_constructor_47.f90
during GIMPLE pass: parloops
gcc/testsuite/gfortran.dg/array_constructor_47.f90:13:0:

   13 |   if (abs (product([[sum([eleven_ones()]), thirteen], a]) - 30030._dp)
> 1e-8) STOP 1
  | 
internal compiler error: tree check: expected ssa_name, have real_cst in
transform_to_exit_first_loop_alt, at tree-parloops.c:1772
0x6a3e3e tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree.c:9900
0x651f73 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree.h:3180
0x651f73 transform_to_exit_first_loop_alt
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-parloops.c:1772
0xe3fdc6 try_transform_to_exit_first_loop_alt
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-parloops.c:1839
0xe3fdc6 gen_parallel_loop
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-parloops.c:2422
0xe4121c parallelize_loops
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-parloops.c:3424
0xe42858 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-parloops.c:3506
0xe42858 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-parloops.c:3485

(While my target here is powerpc, the ICE is not target-specific.)

[Bug c++/90383] [9 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[eric at efcs dot ca]

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

--- Comment #1 from Eric Fiselier  ---
It's important to note that this bug affects any struct with tail padding. For
example `struct optional { T value; bool has_value; /*...*/ };` would hit it.

https://godbolt.org/z/VX9VTh

[Bug target/48429] ARM __attribute__((interrupt("FIQ"))) not optimizing register allocation

[sven.koehler at gmail dot com]

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

--- Comment #2 from Sven  ---
Even 8 years later, this bug is not fixed (gcc 8.3). I believe clang/llvm has
the same problem.

Anyhow, that's not the only problem. The moment that a function is called,
registers r0 to r3 (and maybe others) have to be saved. Then again, you
probably don't call a function in your FIQ since you want it to be fast.

With the help of gcc's generated assembly, I write my FIQ handler in assembler.
I don't mind, but fixing this would be very convenient.

[Bug libstdc++/90384] New: std::transform fails to apply to all elements

[mfdeakin at cs dot unc.edu]

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

Bug ID: 90384
   Summary: std::transform fails to apply to all elements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mfdeakin at cs dot unc.edu
  Target Milestone: ---

The following minimal reproducer fails randomly when using the par and
par_unseq execution policies, but passes when using the seq or just the default
transform.
(I don't know how to tag the following as code)

#include 
#include 

#include 

int main(int argc, char **argv) {
  constexpr int size = 1024;
  std::vector v(size);
  for (int i = 0; i < size; i++) {
const double value = static_cast(i);
v[i] = value * value + 5.0 * value;
  }

  constexpr double min_v = 100.0;
  std::vector transform_par(size);
  std::transform(std::execution::par, v.begin(), v.end(),
 transform_par.begin(),
 [](const double v) { return v >= min_v; });
  std::vector transform_seq(size);
  std::transform(std::execution::seq, v.begin(), v.end(),
 transform_seq.begin(),
 [](const double v) { return v >= min_v; });
  auto [seq_diff, par_diff] = std::mismatch(transform_seq.begin(),
transform_seq.end(),
transform_par.begin(),
transform_par.end());
  assert(seq_diff == transform_seq.end());
  assert(par_diff == transform_par.end());
  return 0;
}

This is with the version of the parallel stl included with GCC 9.1. My GCC
version is 9.1.1 20190503 (Red Hat 9.1.1-1). My version of tbb is
tbb-devel-2019.5-1.fc30.x86_64, which I believe is just the latest release,
2019 update 5.

[Bug c++/90383] New: [9 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[eric at efcs dot ca]

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

Bug ID: 90383
   Summary: [9 Regression] GCC generates invalid constexpr
copy/move assignment operators for types with trailing
padding. (Again)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

When a type has trailing padding GCC generates an invalid copy-assignment
operator for that type. (Similar to gcc.gnu.org/PR77945)

This time the copy assignment operator calls the default constructor, and does
not copy assign the value.

If the default constructor is deleted, GCC rejects-valid and the code fails to
compile. If the default constructor is available, GCC miscompiles the program.

This is a regression from the GCC 8.


Godbolt examples:
  * rejects-valid: https://godbolt.org/z/FGIyiM
  * miscompile: https://godbolt.org/z/7gL7iy

Reproducer:

// g++ -std=c++1z
struct alignas(8) data {
  constexpr data(bool) : value(true) {}

  // shouldn't be called. change to 'default' to see miscompile.
  data() = delete;

  bool value;
  // ... implicit padding ...
};

struct wrap { data member; };

constexpr bool always_true() {
wrap w{data(true)};
w.member = data(true);
return w.member.value; // should always return true
}

bool test() {
// emits-error {{use of deleted function 'data::data()'}}
// emits-note {{in 'constexpr' expansion of 'always_true()' }}
return always_true();

// returns 0 when miscompiled.
}

[Bug other/90375] Environment variables not listed in ENVIRONMENT section of man page

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #0)
> The following env vars are documented as affecting GCC's behaviour, but are
> not listed in the ENVIRONMENT section of the gcc(1) man page:
> 
> GCC_COLORS (for -fdiagnostics-color)
> COLUMNS (for -fno-diagnostics-show-caret)
> MAKE (for -flto=n)
> ASAN_OPTIONS
> TSAN_OPTIONS
> LSAN_OPTIONS
> VTV_LOGS_DIR (for -fvtv-debug)
> PATH (for finding subprograms when -Bprefix and the standard locations don't
> have them)

Bug 80271 would have CLICOLOR_FORCE added to that list as well.

> 
> -M mentions "or use an environment variable like DEPENDENCIES_OUTPUT" which
> isn't very clear if that actually gets used by GCC or is just an example. I
> suggest saying "or use one of the environment variables DEPENDENCIES_OUTPUT
> or SUNPRO_DEPENDENCIES" instead.
> 
> There's also "The runtime library  behavior can be influenced using various
> CHKP_RT_* environment variables.  See
> 
> for more details."

I thought the CHKP/MPX stuff had been removed...

[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
The abominable function types handling is fixed for gcc 8.4 and the full C++2a
common_type spec is implemented on trunk now.

[Bug other/90375] Environment variables not listed in ENVIRONMENT section of man page

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #1)
> I thought the CHKP/MPX stuff had been removed...

It has, I was looking at the man page for gcc-8, sorry.

[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 22:46:39 2019
New Revision: 270987

URL: https://gcc.gnu.org/viewcvs?rev=270987=gcc=rev
Log:
PR libstdc++/89102 implement new common_type rules (P0435R1, P0548R1)

This change ensures that std::common_type<> is a complete type (LWG
2408), and that std::common_type, std::common_type, and
std::common_type will use program-defined specializations
for std::common_type (LWG 2465).

The implementation of common_type is changed to use
void_t, and the specializations for duration and time_point are modified
to also use void_t instead of depending on implementation details of
common_type.

PR libstdc++/89102
* doc/xml/manual/intro.xml: Document DR 2408 and 2465 changes.
* include/std/chrono (__duration_common_type_wrapper): Replace with ...
(__duration_common_type): New helper.
(common_type, chrono::duration>): Use
__duration_common_type.
(__timepoint_common_type_wrapper): Replace with ...
(__timepoint_common_type): New helper.
(common_type, chrono::time_point>):
Use __time_point_common_type.
* include/std/type_traits (common_type<>): Define, as per LWG 2408.
(__common_type_impl): If either argument is transformed by decay,
use the common_type of the decayed types.
(__common_type_impl<_Tp, _Up, _Tp, _Up>): If the types are already
decayed, use __do_common_type_impl to get the common_type.
(common_type<_Tp>): Use common_type<_Tp, _Tp>.
(__do_member_type_wrapper, __member_type_wrapper)
(__expanded_common_type_wrapper): Remove.
(__common_type_pack, __common_type_fold): New helpers.
(common_type<_Tp, _Up, _Vp...>): Use new helpers instead of
__member_type_wrapper and __expanded_common_type_wrapper.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test single argument cases and argument types that should decay.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.
* testsuite/20_util/duration/literals/range_neg.cc: Use zero for
dg-error lineno.
* testsuite/20_util/duration/requirements/typedefs_neg1.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg2.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg3.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/intro.xml
trunk/libstdc++-v3/include/std/chrono
trunk/libstdc++-v3/include/std/type_traits
   
trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
trunk/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
trunk/libstdc++-v3/testsuite/20_util/duration/requirements/typedefs_neg1.cc
trunk/libstdc++-v3/testsuite/20_util/duration/requirements/typedefs_neg2.cc
trunk/libstdc++-v3/testsuite/20_util/duration/requirements/typedefs_neg3.cc

[Bug c++/90171] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6630

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue May  7 22:37:24 2019
New Revision: 270986

URL: https://gcc.gnu.org/viewcvs?rev=270986=gcc=rev
Log:
PR c++/90171 - reorganize usual_deallocation_fn_p

When fixing 90171 it struck me as undesirable to have so many separate
functions that all needed to know about the definition of a usual
deallocation function.  So this patch condenses them into one.  I left
destroying_delete_p because it is used by other files as well.

* call.c (struct dealloc_info): New.
(usual_deallocation_fn_p): Take a dealloc_info*.
(aligned_deallocation_fn_p, sized_deallocation_fn_p): Remove.
(build_op_delete_call): Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/86485] [7/8 Regression] "anonymous" maybe-uninitialized false positive with ternary operator

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue May  7 22:37:19 2019
New Revision: 270985

URL: https://gcc.gnu.org/viewcvs?rev=270985=gcc=rev
Log:
PR c++/86485 - -Wmaybe-unused with empty class ?:

* typeck.c (build_static_cast_1): Use cp_build_addr_expr.

For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
function was also doing the wrong thing.

Using build_address does not push the ADDR_EXPR down into the arms of a
COND_EXPR, which we need for proper handling of conversion of an lvalue ?:
to another reference type.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
In the ttp23.C testcase we're comparing B and B.  In one case the
template argument is

 >>

and the other is

 >>

same_type_p says they're same, so comp_template_args returns true.  One of the
template_template_parms has TYPE_CANONICAL, so we hash it as:

 1905   if (TYPE_CANONICAL (arg))
 1906 return iterative_hash_object (TYPE_HASH (TYPE_CANONICAL (arg)),
 1907   val);

but the other type doesn't have a canonical type:

 1910   /* Otherwise just compare the types during lookup.  */
 1911   return val;

so the hashes end up being different.

[Bug middle-end/89765] [9/10 Regression] Multiple problems with vec-insert implementation on PowerPC

[kelvin at gcc dot gnu.org]

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

--- Comment #12 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Tue May  7 21:40:46 2019
New Revision: 270982

URL: https://gcc.gnu.org/viewcvs?rev=270982=gcc=rev
Log:
gcc/ChangeLog:

2019-05-07  Kelvin Nilsen  

PR target/89765
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
to compute vector element selector for both constant and variable
operands.

gcc/testsuite/ChangeLog:

2019-05-07  Kelvin Nilsen  

PR target/89765
* gcc.target/powerpc/pr89765-mc.c: New test.
* gcc.target/powerpc/vsx-builtin-10c.c: New test.
* gcc.target/powerpc/vsx-builtin-10d.c: New test.
* gcc.target/powerpc/vsx-builtin-11c.c: New test.
* gcc.target/powerpc/vsx-builtin-11d.c: New test.
* gcc.target/powerpc/vsx-builtin-12c.c: New test.
* gcc.target/powerpc/vsx-builtin-12d.c: New test.
* gcc.target/powerpc/vsx-builtin-13c.c: New test.
* gcc.target/powerpc/vsx-builtin-13d.c: New test.
* gcc.target/powerpc/vsx-builtin-14c.c: New test.
* gcc.target/powerpc/vsx-builtin-14d.c: New test.
* gcc.target/powerpc/vsx-builtin-15c.c: New test.
* gcc.target/powerpc/vsx-builtin-15d.c: New test.
* gcc.target/powerpc/vsx-builtin-16c.c: New test.
* gcc.target/powerpc/vsx-builtin-16d.c: New test.
* gcc.target/powerpc/vsx-builtin-17c.c: New test.
* gcc.target/powerpc/vsx-builtin-17d.c: New test.
* gcc.target/powerpc/vsx-builtin-18c.c: New test.
* gcc.target/powerpc/vsx-builtin-18d.c: New test.
* gcc.target/powerpc/vsx-builtin-19c.c: New test.
* gcc.target/powerpc/vsx-builtin-19d.c: New test.
* gcc.target/powerpc/vsx-builtin-20c.c: New test.
* gcc.target/powerpc/vsx-builtin-20d.c: New test.
* gcc.target/powerpc/vsx-builtin-9c.c: New test.
* gcc.target/powerpc/vsx-builtin-9d.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr89765-mc.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20d.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9c.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9d.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/90382] New: internal compiler error: in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061

[sbergman at redhat dot com]

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

Bug ID: 90382
   Summary: internal compiler error: in
linemap_macro_map_loc_to_exp_point, at
libcpp/line-map.c:1061
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I encountered this ICE with recent GCC trunk with

  #include "boost/spirit/include/phoenix.hpp"

but could only strip it down to the following reproducer that still includes
some boost/preprocessor/ include files (from boost-devel-1.69.0-6.fc30.x86_64
on Fedora 30 in my case).  The failure was not reproducible with -E
preprocessed sources.

$ cat test.cc
> #include "boost/preprocessor/repetition/enum_params.hpp"
> #include "boost/preprocessor/repetition/repeat_from_to.hpp"
> 
> template struct S {};
> 
> #define N S
> 
> #define M(z, n, d) template void 
> f(N const &);
> 
> BOOST_PP_REPEAT_FROM_TO(0, 1, M,)

$ gcc/trunk/inst/bin/g++ -c test.cc
> test.cc:8:109: internal compiler error: in 
> linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061
> 8 |  d) template void 
> f(N const &);
>   |   
>^
> 
> /usr/include/boost/preprocessor/repetition/repeat_from_to.hpp:83:54: note: in 
> expansion of macro ‘M’
>83 | # define BOOST_PP_REPEAT_FROM_TO_M_1_II(z, n, m, dt) m(z, n, dt)
>   |  ^
> 0x18ecbef linemap_macro_map_loc_to_exp_point
>   ../../src/libcpp/line-map.c:1061
> 0x18ecbef linemap_macro_map_loc_to_exp_point
>   ../../src/libcpp/line-map.c:1054
> 0x18ee6a7 first_map_in_common_1
>   ../../src/libcpp/line-map.c:1269
> 0x18ee6a7 first_map_in_common
>   ../../src/libcpp/line-map.c:1306
> 0x18ee6a7 linemap_compare_locations(line_maps*, unsigned int, unsigned int)
>   ../../src/libcpp/line-map.c:1349
> 0x905d8d linemap_location_before_p(line_maps*, unsigned int, unsigned int)
>   ../../src/gcc/../libcpp/include/line-map.h:1273
> 0x905d8d min_location
>   ../../src/gcc/cp/decl.c:10069
> 0x91cdbb grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, 
> decl_context, int, tree_node**)
>   ../../src/gcc/cp/decl.c:10427
> 0x9c3e0e cp_parser_parameter_declaration_list
>   ../../src/gcc/cp/parser.c:22197
> 0x9c41ab cp_parser_parameter_declaration_clause
>   ../../src/gcc/cp/parser.c:22114
> 0x9b8d9d cp_parser_direct_declarator
>   ../../src/gcc/cp/parser.c:20806
> 0x9b8d9d cp_parser_declarator
>   ../../src/gcc/cp/parser.c:20674
> 0x9c6bb5 cp_parser_init_declarator
>   ../../src/gcc/cp/parser.c:20184
> 0x9ca294 cp_parser_single_declaration
>   ../../src/gcc/cp/parser.c:28268
> 0x9caed7 cp_parser_explicit_specialization
>   ../../src/gcc/cp/parser.c:17323
> 0x9cd826 cp_parser_declaration
>   ../../src/gcc/cp/parser.c:13184
> 0x9cde1f cp_parser_translation_unit
>   ../../src/gcc/cp/parser.c:4701
> 0x9cde1f c_parse_file()
>   ../../src/gcc/cp/parser.c:41181
> 0xad3beb c_common_parse_file()
>   ../../src/gcc/c-family/c-opts.c:1156
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

[Bug c++/87145] [7/8 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[jorrit at jorrit dot de]

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

--- Comment #14 from Jö  ---
Hmm, thinking about it.  But it looks like Debian buster is going to release
with 8.3 anyway as it is in freeze.  And I don't think they're gonna update gcc
in buster while it's stable.  Which means we're going to have to live with that
bug anyway until we can kill support for buster.

I'm going to check back with my co-developers whether one of them needs this
fixed particularly in gcc 8 (or 7).  Though as long as none of them speaks up,
lets assume we don't actually need it.

But thanks for the offer anyway, and thanks for fixing it in gcc 9!

For the record, we got bitten by it here:
https://gitlab.dune-project.org/core/dune-geometry/issues/17

[Bug tree-optimization/90377] [10 Regression] New -Wstringop-overflow with -O3 since r270852

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #2)
> Most likely used creduce to reduce the failure.

creduce didn't use to produce such awful code. Part is because of -fpermissive,
but part seems to be because the reducer (creduce?) did a bad job (reusing the
same name for several things, missing simplifications).


Anyway, we end up with something like:

if(n!=0)memset(p,n,)

where p points after the end, and the argument of memset is always non-0, but
quite artificially so. Arguably, ldist could have produced just memset(p,n,)
without the condition, and we wouldn't have the bad warning.

[Bug c++/87145] [7/8 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
(In reply to Jö from comment #12)
> Just to be get this straight: "no backport possible" means this won't be
> fixed at all for 7 and 8, correct?

If it's important, I could actually fix it for GCC 8.4 too.  I just didn't know
how important this is.

[Bug c++/87145] [7/8 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[jorrit at jorrit dot de]

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

--- Comment #12 from Jö  ---
Just to be get this straight: "no backport possible" means this won't be fixed
at all for 7 and 8, correct?

[Bug c++/84177] Attributes on C++17 nested namespaces

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
Martin Sebor has been doing stuff with diagnostics for attributes lately;
cc-ing him

[Bug other/90381] New: New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934

[seurer at gcc dot gnu.org]

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

Bug ID: 90381
   Summary: New test case gcc.dg/tree-ssa/pr88676-2.c fails with
its introduction in r270934
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This only fails on powerpc64 BE; it works fine on LE.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/pr88676-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -fdump-tree-phiopt1 -S -o pr88676-2.s
PASS: gcc.dg/tree-ssa/pr88676-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr88676-2.c scan-tree-dump-not phiopt1 " = PHI <"

[Bug c++/79817] GCC does not recognize [[deprecated]] attribute for namespace

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug target/79869] i18n: document placeholders for translators

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

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

--- Comment #4 from Roland Illig  ---
Thank you for improving the diagnostics in r261495 and r270540. Now the
diagnostics are much easier to translate.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[roland.illig at gmx dot de]

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

Bug 79869 Summary: i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869

   What|Removed |Added

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

[Bug tree-optimization/90377] [10 Regression] New -Wstringop-overflow with -O3 since r270852

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
What kind of obfuscator did this go through?

[Bug tree-optimization/90377] [10 Regression] New -Wstringop-overflow with -O3 since r270852

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #1)
> What kind of obfuscator did this go through?

Most likely used creduce to reduce the failure.  NOTE sometimes creduce reduced
are reduced into invalid/undefined code.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[egallager at gcc dot gnu.org]

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

--- Comment #22 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #21)
> (In reply to Eric Gallager from comment #20)
> > (In reply to Dominique d'Humieres from comment #18)
> > > For the record with darwin15 I had to add
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/
> > > NSEnumerator.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h
> > > 
> > > from the 10.9 SDK to
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
> > > /usr/include/objc/NSObject.h
> > 
> > that seems dangerous
> 
> Not so dangerous as it seems.
> 
> Many (most, in fact) of the failures seen from GCC Objective-C are caused by
> missing support for new features that have been introduced into the vendor's
> headers.  Short list: Apple Blocks, Lightweight Generics, Nullability,
> Syntactic sugar on ID.

Blocks support at least is bug 78352; are there bugs open for the other 3? 

> I'm working on a set of replacement test-suite headers that allow us to
> test the things that _do_ work on GCC Objective-C, and expose any real
> regressions.
> 
> Tests on Darwin13 and earlier show that we are not in such bad shape as the
> header fails make it appear.
> 
> I hope to get these test fixes (there's a set of three PRs related to excess
> fails on Yosemite+) in place soon - and to back port them to the open
> branches.

[Bug c++/89214] [7/8 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed for 8.4.

[Bug c++/88857] [7/8 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/89876] [8 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/89511] [7/8 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed for 8.4.

[Bug c++/89705] [7/8 Regression] ICE in convert_like_real, at cp/call.c:7334

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed for 8.4.

[Bug c++/89876] [8 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:29:39 2019
New Revision: 270974

URL: https://gcc.gnu.org/viewcvs?rev=270974=gcc=rev
Log:
PR c++/89876 - ICE with deprecated conversion.
* call.c (convert_like_real): Only give warnings with tf_warning.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/warn/conv5.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug c++/89705] [7/8 Regression] ICE in convert_like_real, at cp/call.c:7334

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:28:11 2019
New Revision: 270973

URL: https://gcc.gnu.org/viewcvs?rev=270973=gcc=rev
Log:
PR c++/89705 - ICE with reference binding with conversion function.
* call.c (reference_binding): If the result of the conversion function
is a prvalue of non-class type, use the cv-unqualified type.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/rv-conv2.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug c++/89511] [7/8 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:26:38 2019
New Revision: 270972

URL: https://gcc.gnu.org/viewcvs?rev=270972=gcc=rev
Log:
PR c++/89511 - ICE with using-declaration and unscoped enumerator.
* parser.c (cp_parser_using_declaration): For an unscoped enum
only use its context if it's not a function declaration.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/parser.c

[Bug c++/89214] [7/8 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:25:26 2019
New Revision: 270971

URL: https://gcc.gnu.org/viewcvs?rev=270971=gcc=rev
Log:
PR c++/89214 - ICE when initializing aggregates with bases.
* typeck2.c (digest_init_r): Warn about object slicing instead of
crashing.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/aggr-base8.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/aggr-base9.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/typeck2.c

[Bug c++/88857] [7/8 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:23:19 2019
New Revision: 270970

URL: https://gcc.gnu.org/viewcvs?rev=270970=gcc=rev
Log:
PR c++/88857 - ICE with value-initialization of argument in template.
* call.c (convert_like_real): Don't call build_value_init in template.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist-value4.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug target/89424] __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Tue May  7 16:22:21 2019
New Revision: 270969

URL: https://gcc.gnu.org/viewcvs?rev=270969=gcc=rev
Log:
gcc/ChangeLog:

2019-05-07  Kelvin Nilsen  

Backport from mainline.
2019-05-06  Kelvin Nilsen  

PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.

gcc/testsuite/ChangeLog:

2019-05-07  Kelvin Nilsen  

Backport from mainline.
2019-05-06  Kelvin Nilsen  

PR target/89424
* gcc.target/powerpc/pr89424-0.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to
enable testing of newly patched capability.
* gcc.target/powerpc/vsx-builtin-13b.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20a.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20b.c: Likewise.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/pr89424-0.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Also fixed for 8.4 now.

[Bug libstdc++/88740] [7/8 Regression] libstdc++ tests no longer print assertion failure messages

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:40 2019
New Revision: 270967

URL: https://gcc.gnu.org/viewcvs?rev=270967=gcc=rev
Log:
PR libstdc++/88740 Print assertion messages to stderr

Backport from mainline
2019-01-22  Jonathan Wakely  

PR libstdc++/88740
* testsuite/util/testsuite_hooks.h [stderr] (VERIFY): Use fprintf to
write to stderr instead of using printf.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/testsuite/util/testsuite_hooks.h

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:36 2019
New Revision: 270966

URL: https://gcc.gnu.org/viewcvs?rev=270966=gcc=rev
Log:
PR libstdc++/90165 constrain variant(T&&) constructor

Backport from mainline
2019-04-23  Jonathan Wakely  

PR libstdc++/90165
* include/std/variant (variant::__is_in_place_tag)
(variant::__not_in_place_tag): New helpers for variant(T&&)
constructor constraint.
(variant::variant(T&&)): Use __not_in_place_tag in constraints.
* testsuite/20_util/variant/compile.cc: Check variant(T&&) constructor
isn't used for in_place_type or in_place_index arguments.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/variant
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/variant/compile.cc

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.4 too.

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 8.4 too.

[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:44 2019
New Revision: 270968

URL: https://gcc.gnu.org/viewcvs?rev=270968=gcc=rev
Log:
PR libstdc++/89102 fix common_type<> and common_type specializations

This is a partial implementation of the revised std::common_type rules
from P0435R1.

Backport from mainline
2019-02-06  Jonathan Wakely  

PR libstdc++/89102 (partial)
* include/std/type_traits (common_type<>): Define.
(common_type): Derive from common_type.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test additional single argument cases.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc

[Bug libstdc++/89629] std::hash segfault for long strings

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:45:59 2019
New Revision: 270959

URL: https://gcc.gnu.org/viewcvs?rev=270959=gcc=rev
Log:
PR libstdc++/89629 fix _Hash_bytes for lengths > INT_MAX

Backport from mainline
2019-03-11  Jonathan Wakely  

PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/hash/89629.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/libsupc++/hash_bytes.cc

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:32 2019
New Revision: 270965

URL: https://gcc.gnu.org/viewcvs?rev=270965=gcc=rev
Log:
PR libstdc++/90105 make forward_list::sort stable

While testing the fix I also discovered that operator== assumes the
elements are comparable with operator!= which is not required.

Backport from mainline
2019-04-17  Jonathan Wakely  

PR libstdc++/90105
* include/bits/forward_list.tcc (operator==): Do not use operator!= to
compare elements.
(forward_list::sort(Comp)): When elements are equal take the one
earlier in the list, so that sort is stable.
* testsuite/23_containers/forward_list/operations/90105.cc: New test.
* testsuite/23_containers/forward_list/comparable.cc: Test with
types that meet the minimum EqualityComparable and LessThanComparable
requirements. Remove irrelevant comment.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/operations/90105.cc
  - copied, changed from r270964,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/forward_list.tcc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:05 2019
New Revision: 270960

URL: https://gcc.gnu.org/viewcvs?rev=270960=gcc=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

Backport from mainline
2019-03-26  Jonathan Wakely  

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/hashtable.h
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_tree.h
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:05 2019
New Revision: 270960

URL: https://gcc.gnu.org/viewcvs?rev=270960=gcc=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

Backport from mainline
2019-03-26  Jonathan Wakely  

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/hashtable.h
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_tree.h
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug c++/87145] [7/8 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
GCC 8 doesn't have CONSTRUCTOR_IS_DEPENDENT so I guess I won't backport it.

[Bug c++/90372] [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
(In reply to marc from comment #0)

Please always include all details relevant to the report here for future
reference (in case the external references should become inaccessible).  The
test case:

#include 
#include 
#include 

using file_ptr = std::unique_ptr;

const std::string_view s = "Hello, World";

extern void may_throw() noexcept(false);

void two() {
if (auto f = fopen(nullptr, nullptr)) {
fwrite(s.data(), s.size(), 1, f);
try {
may_throw();
} catch (...) {
fclose(f);
throw;
}
fclose(f);
}
}

void one() {
if (auto f = file_ptr{fopen(nullptr, nullptr)}) {
fwrite(s.data(), s.size(), 1, f.get());
may_throw();
}
}

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #19 from Than McIntosh  ---
Created attachment 46313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46313=edit
SVG graph from profiling run

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #18 from Than McIntosh  ---

I tested the most recent commit (270944). That cuts the compile time on the
larger example in half, but still at around 1200 seconds. I took another
profile (will attach an SVG image from 'pprof web').

[Bug middle-end/90376] spurious -Warray-bounds on memset() of several struct's subobjects

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
  Component|c   |middle-end
 Blocks||56456
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
The warning in this case points out that the memset call accesses memory
outside the bounds of the subobject pointed to by the first argument.  Making
it explicit that the access is intended to span multiple members by passing to
memset a pointer derived from the address of the enclosing object avoids the
warning:

  void g (void)
  {
static struct trace_iterator iter;
__builtin_memset ((char*)
  + __builtin_offsetof (struct trace_iterator, seq),
  0,
  sizeof (struct trace_iterator)
  - __builtin_offsetof(struct trace_iterator, seq));
  }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 90376 Summary: spurious -Warray-bounds on memset() of several struct's 
subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90376

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Confirmed, I see following back-trace:

#0  0x0044f9d4 in handle_cycle (count=, edges=...) at
/usr/src/debug/gcc8-8.3.1+r269200-1.1.x86_64/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/bits/stl_vector.h:948
#1  circuit (v=, path=..., start=0x6e0f10, blocked=...,
block_lists=..., linfo=..., count=@0x7fffd868: 0) at ../../gcc/gcov.c:695
#2  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
#3  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
#4  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
#5  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
...
#443 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#444 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#445 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#446 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#447 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#448 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#449 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#450 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#451 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#452 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#453 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#454 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#455 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#456 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#457 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#458 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#459 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#460 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#461 0x0044fb32 in get_cycles_count (linfo=...,
handle_negative_cycles=handle_negative_cycles@entry=true) at
../../gcc/gcov.c:742
#462 0x00450c5f in accumulate_line_info (add_coverage=false,
src=, line=0x4c0670) at ../../gcc/gcov.c:2601
#463 accumulate_line_counts (src=0x67fdd0) at ../../gcc/gcov.c:2631
#464 generate_results (file_name=0x78df10 "p4est_triangulation.f90.gcda") at
../../gcc/gcov.c:1328
#465 0x00438ac2 in main (argc=, argv=) at
../../gcc/gcov.c:796

[Bug c++/61990] Incorrect caret location for type mismatches in function calls

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
We now print:

61990.C: In function ‘void test(foo*)’:
61990.C:9:18: error: cannot convert ‘foo*’ to ‘bar*’
9 |   some_fn (f, f, f, f, f);
  |  ^
  |  |
  |  foo*
61990.C:5:36: note:   initializing argument 3 of ‘void some_fn(foo*, foo*,
bar*, foo*, foo*)’
5 | extern void some_fn (foo *, foo *, bar *, foo *, foo *);
  |^


so fixed.

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

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #13 from The Written Word  
---
(In reply to dave.anglin from comment #12)
> It might help to compile stage1 with -O2 or -Os.  This might reduce offset
> and get a newer version
> of gcc to build.  gcc-8.3.0 seems to have built okay on Debian.  gcc-9 so
> far has failed to build on ia64.

Ok, I'll try. I'll try to reach out to the Debian/ia maintainers again.

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

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #14 from The Written Word  
---
(In reply to dave.anglin from comment #10)
> I don't know the status of Jim Wilson who is listed as ia64 maintainer.

We reached out to Jim Wilson in 2016 and got a reply back. He no longer has
access to any ia64 machines.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-07
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Thanks for the report, I'll take a look..

[Bug c++/89612] [7/8 Regression] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[vsande at cimne dot upc.edu]

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

--- Comment #1 from Victor  ---
Sorry,

the command to launch the docker container has an extra `gcov` at the end.

To correctly launch the container, please use this command:

$ docker run --rm -ti fempar/fempar:gnu-8.3.0_gcov-issue

Best,
Víctor

[Bug gcov-profile/90380] New: gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[vsande at cimne dot upc.edu]

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

Bug ID: 90380
   Summary: gcov issue: gets stuck (infinite loop?) while
analyzing coverage on Fortran project
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsande at cimne dot upc.edu
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Dear GCC/Gcov team,

we are developing Fempar, a Fortran200X project with some mixed C code, that
takes advantage of CPP preprocessor.

We have recently updated our CI environment from GCC 5.4.1 to 8.3.0. Coverage
with GCC 8.3.0 fails because it gets stuck in a infinite loop while analyzing
some files in our software project

We did not determine the exact version of GCC in which this issue appears. The
latest version that was working correctly for us was 6.2.0. This issue can be
reproduced, at least, with GCC 8.X.X and 9.X.X.

We have reproduced the issue environment by means of Docker containers. In
particular, to reproduce the issue please run the following commands:

```
$ # Launch the docker container
$ docker run --rm -ti fempar/fempar:gnu-8.3.0_gcov-issue gcov
$ # Run the following command inside the docker container
$ gcov -l -o
"/data/fempar/Sources/Lib/CMakeFiles/FEMPAR.dir/Geometry/Triangulation"
"/data/fempar/Sources/Lib/CMakeFiles/FEMPAR.dir/Geometry/Triangulation/p4est_triangulation.f90.gcda"
```

After running these commands, gcov output is shown in the following lines:

```
File
'/tmp/fempar-experimental/Sources/Lib/Geometry/Triangulation/sbm_p4est_base_triangulation.i90'
Lines executed:81.37% of 1653
Creating 'p4est_triangulation.f90.gcda##sbm_p4est_base_triangulation.i90.gcov'
```

At this point gcov gets stuck and, it seems, that never ends.

The code has been compiled with the following flags:

-fdefault-real-8 -ffree-line-length-0 -cpp -Wimplicit-interface -g -fbacktrace
-fbounds-check -fprofile-arcs -ftest-coverage -Wimplicit-interface

Is this a known bug?
Is there any possible workaround?

Let me know if you need any other further information.

Thanks in advance,
Víctor.

[Bug c++/81933] [7 Regression] Invalid "constexpr call flows off the end of the function" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c/78666] conflicting attribute alloc_size accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[dave.anglin at bell dot net]

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

--- Comment #12 from dave.anglin at bell dot net ---
On 2019-05-07 9:32 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #11 from The Written Word  com> ---
> (In reply to dave.anglin from comment #10)
>> On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
>>> Dave, are you aware of anybody testing ia64-hpux?
>>> Should it be deprecated if nobody is maintaining it?
>> I don't have or access to a ia64 box.
>>
>> I don't know the status of Jim Wilson who is listed as ia64 maintainer.
>>
>> Albert Chin  is the only person that I know who
>> might be actively using it.
>>
>> My access to the hppa box that I use for hppa-hpux support requires support
>> from NRC Canada but
>> all colleagues there have retired.  It was down for a few weeks until
>> yesterday when I got a network person
>> to reboot it.
>>
>> So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.
> We are still using it but haven't been able to build anything post 4.9.4. We
> tried to find someone to pay to bring this port up-to-date but had no success.
> Open to other suggestions but deprecating it might be the only way forward.
As I said before, I can't accept US contracts because of HST tax implications. 
I can only accept
Canadian source income.

It might help to compile stage1 with -O2 or -Os.  This might reduce offset and
get a newer version
of gcc to build.  gcc-8.3.0 seems to have built okay on Debian.  gcc-9 so far
has failed to build on ia64.

[Bug testsuite/90379] New: Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[make_distclean at yahoo dot com]

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

Bug ID: 90379
   Summary: Gcc 9.1 fails "make check" on linux due to missing
MacOS-specific header file
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: make_distclean at yahoo dot com
  Target Milestone: ---

Hi

I'm hitting a missing header when making the target 'check' in  fixincludes:
'ucred.h' in $TESTBASE (which is pointing to gcc-9.1.0/fixincludes/tests/base).

I can successfully compile (with gcc 8.3) gcc release 9.1 on
x86_64-unknown-linux-gnu. Then, the output of 'make check' in
my_build_dir/fixincludes looks like this:

--- snip ---
autogen -T ../../fixincludes/check.tpl ../../fixincludes/inclhack.def
/bin/sh ./check.sh ../../fixincludes/tests/base
Fixed:  testing.h
Fixed:  testing.h
Fixed:  alloca.h
Fixed:  ansi/math.h
Fixed:  ansi/stdlib.h
Fixed:  arch/i960/archI960.h
Fixed:  architecture/ppc/math.h
Fixed:  assert.h
Fixed:  AvailabilityInternal.h
Fixed:  AvailabilityMacros.h
Fixed:  bits/fenv.h
Fixed:  bits/huge_val.h
Fixed:  bits/string2.h
Fixed:  bsd/libc.h
Fixed:  c_asm.h
Fixed:  com_err.h
Fixed:  complex.h
Fixed:  ctrl-quotes-def-1.h
Fixed:  ctype.h
Fixed:  curses.h
Fixed:  errno.h
Fixed:  fcntl.h
Fixed:  features.h
Fixed:  fixinc-test-limits.h
Fixed:  hsfs/hsfs_spec.h
Fixed:  i386/setjmp.h
Fixed:  ia64/sys/getppdp.h
Fixed:  inttypes.h
Fixed:  ioLib.h
Fixed:  io-quotes-def-1.h
Fixed:  iso/math_c99.h
Fixed:  iso/math_iso.h
Fixed:  iso/stdio_iso.h
Fixed:  iso/stdlib_c99.h
Fixed:  iso/stdlib_iso.h
Fixed:  linux/vt.h
Fixed:  locale.h
Fixed:  mach-o/dyld.h
Fixed:  mach-o/swap.h
Fixed:  malloc.h
Fixed:  math.h
Fixed:  netdnet/dnetdb.h
Fixed:  net/if_arp.h
Fixed:  net/if.h
Fixed:  netinet/in.h
Fixed:  netinet/ip.h
Fixed:  obstack.h
Fixed:  os/trace.h
Fixed:  pixrect/memvar.h
Fixed:  pthread.h
Fixed:  regex.h
Fixed:  regexp.h
Fixed:  reg_types.h
Fixed:  rpc/auth.h
Fixed:  rpc/rpc.h
Fixed:  rpcsvc/rstat.h
Fixed:  rpcsvc/rusers.h
Fixed:  rpc/xdr.h
Fixed:  rtldef/decc$types.h
Fixed:  rtldef/if.h
Fixed:  rtldef/resolv.h
Fixed:  rtldef/setjmp.h
Fixed:  rtldef/signal.h
Fixed:  rtldef/stdio.h
Fixed:  rtldef/string.h
Fixed:  rtldef/wait.h
Fixed:  setjmp.h
Fixed:  signal.h
Fixed:  sparc/asm_linkage.h
Fixed:  spawn.h
Fixed:  stdarg.h
Fixed:  stdint-aix.h
Fixed:  stdint-darwin.h
Fixed:  stdint.h
Fixed:  stdint-hpux11.h
Fixed:  stdint-newlib.h
Fixed:  stdio.h
Fixed:  stdio_tag.h
Fixed:  stdlib.h
Fixed:  string.h
Fixed:  strings.h
Fixed:  sundev/vuid_event.h
Fixed:  sunwindow/win_lock.h
Fixed:  sym.h
Fixed:  sys/cdefs.h
Fixed:  sys/feature_tests.h
Fixed:  sys/file.h
Fixed:  sys/int_const.h
Fixed:  sys/int_limits.h
Fixed:  sys/_inttypes.h
Fixed:  sys/machine.h
Fixed:  sys/mman.h
Fixed:  sys/pthread.h
Fixed:  sys/signal.h
Fixed:  sys/socket.h
Fixed:  sys/spinlock.h
Fixed:  sys/stat.h
Fixed:  sys/sysmacros.h
Fixed:  sys/time.h
Fixed:  sys/types.h
Fixed:  sys/ucontext.h
Fixed:  sys/ucred.h
Fixed:  sys/wait.h
Fixed:  testing.h
Fixed:  tgmath.h
Fixed:  time.h
Fixed:  tinfo.h
Fixed:  types/vxTypesBase.h
Fixed:  unistd.h
Fixed:  X11/ShellP.h
Fixed:  X11/Xmu.h
Fixed:  Xm/BaseClassI.h
Fixed:  Xm/Traversal.h
Newly fixed header:  sys/ucred.h

There were fixinclude test FAILURES
make: *** [Makefile;177: check] Error 1
--- snip ---

I'm not really sure how gcc-9.1.0/fixincludes/inclhack.def works, but 'mach' at
line 1631 shouldn't match my host triplet x86_64-unknown-linux-gnu.  But then
again, none of the fixes for "*-*-darwin*" in inclhack.def should match yet
they're all applied...

As I don't understand why/how we need to fix includes from other OS'es, my
quick hack was to just copy
my_build_dir/fixincludes/tests/res/sys/ucred.h to $TESTBASE, which tricked
check.sh.

This failure is also mentioned in Bug 90330 but that bug was raised
specifically for build failing on darwin.

The ucred.h part seems to have been added to inclhack.def as part of git commit
62f180560c835a2f8402978c422448a35d9fe2b1, to fix bug 89864.

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[wilco at gcc dot gnu.org]

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

--- Comment #20 from Wilco  ---
(In reply to Martin Liška from comment #19)
> Created attachment 46265 [details]
> Patch candidate v2
> 
> Update patch that should be fine. Tests on x86_64 work except:
> FAIL: gcc.c-torture/execute/builtins/mempcpy.c execution,  -O1 
> 
> Where the test expects that mempcpy without LHS should be transformed into
> memcpy.

Thanks, this version works as expected on AArch64. In principle we could keep
mempcpy for tailcalls with -Os, but I'm not sure it's worth the trouble.

[Bug rtl-optimization/90378] New: [9 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm

[mkuvyrkov at gcc dot gnu.org]

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

Bug ID: 90378
   Summary: [9 regression] -Os -flto miscompiles 454.calculix
after r266385 on Arm
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

I'm investigating a miscompilation of 454.calculix, which occurs only with LTO
on ARMv7.  Miscompilation results in SIGSEGV and seems to occur only on ARMv7
hardware (cortex-a15), same binary runs fine on ARMv8 hardware.

Miscompilation occurs at and after
===
commit 8fc3599dcab36e0b905fa442c0fc0a905280eea2 (HEAD)
Author: vmakarov 
Date:   Thu Nov 22 17:25:57 2018 +

2018-11-22  Vladimir Makarov  

PR rtl-optimization/87718
* ira-costs.c: Remove trailing white-spaces.
(record_operand_costs): Add a special treatment for moves
involving a hard register.

2018-11-22  Vladimir Makarov  

PR rtl-optimization/87718
* gcc.target/i386/pr82361-1.c: Check only the first operand of
moves.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266385
138bc75d-0d04-0410-961f-82ee72b054a4
===
but I do not have hard evidence that this patch is the root cause.  It may be
triggering a latent bug or even exposing undefined behavior in the benchmark.

I'm struggling to reduce the 300-object LTO compilation down to something
manageable.  Advice and ideas on where to look are appreciated.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Educating people about -fstack-reuse is also a possibility, thus leave the
issue to workarounds like that, experimenting with full rewrites that are
obviously not back-portable.

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I don't see a vec_initv16qiv8qi on power either, so that might be it - there's
no
effective target for building a vector from halves (and I wonder how
code-generation fares here).

So an option is to simply xfail for all but x86_64-*-* and i?86-*-* ...

Or try more fancy code-generation options (build from two large integer modes,
but I don't see vec_initv2didi either).

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Michael Matz from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > before that region.  If we can say for:
> >   for (...)
> > {
> >   unsigned char v[10];
> >   unsigned char *p = foo (v);
> >   *p = 1;
> >   unsigned char w[10];
> >   bar (w);
> > }
> > hoist the p = foo (v); call before the loop, then indeed we are in big
> > trouble.
> 
> This is effectively what the testcase is doing (just that 'foo' is no call,
> but a normal address expression), so yes, we can do that, and yes we are in
> big
> trouble :-/

Well, that p = foo (v); or store of memory is something that will have (unless
const call, indeed) a vuse or even a vdef and the alias oracle should usually
consider it to be conflicting with the clobber stmt, so I'd hope it isn't
hoisted in that case, while for the pure address arithmetics there is nothing
that can easily stop the hoisting.

Now, if there isn't really an easy way out of this and given how rarely this
has been reported (I think we have this PR and PR61203, don't remember anything
else), the options can be do nothing, or do something simple that isn't that
expensive, will fix this testcase and while not perfect solution will still
allow variable sharing in the general case almost as often as before, or change
the IL representation so that such hoisting or sinking of addresses is not
possible.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Jakub Jelinek from comment #9)
> > > Created attachment 46312 [details]
> > > gcc10-pr90348.patch
> > > 
> > > Untested patch that implements what was written in #c5.  I agree that
> > > without further changes to the IL, determining if one can hoist addresses 
> > > of
> > > local variables or not is going to be hard, would require computing the
> > > variable life info in each pass that would do something similar.  On the
> > > other side, admittedly such hoisting results in worse code generation
> > > because if the address is hoisted earlier than where it used to be live
> > > before, then there will be more stack conflicts.
> > 
> > Ick.  You need to handle pt->anything and pt->escaped (walk the escaped
> > solution) as well.  And !SSA_NAME_PTR_INFO (op) is of course the same
> > as pt->anything.
> 
> Do I?
> I thought I don't.  The thing is, I believe the partitioning only cares
> about where (originally in the source) the automatic variables are
> referenced.
> Now, if I have say:
> __attribute__((noipa)) type *foo (type *x) { return x; }
> or similar, in order for a variable to be live before the clobber, it needs
> to escape in the area where the variable is live, we don't care what we do
> with whatever it returned, unless we actually hoist such escaping calls
> before that region.  If we can say for:
>   for (...)
> {
>   unsigned char v[10];
>   unsigned char *p = foo (v);
>   *p = 1;
>   unsigned char w[10];
>   bar (w);
> }
> hoist the p = foo (v); call before the loop, then indeed we are in big
> trouble.
> But if we can't, the attached patch was just meant as a shorthand for trying
> to do a dataflow propagation of the can a pointer SSA_NAME point to variable
> xyz, if we don't consider escaping (to other functions and to global state).
> What I'm trying to "undo" is just the hoisting of the address loads, not
> hoisting of those address loads plus function calls in which it escapes or
> where that address is saved to memory.
> 
> If I have to consider pt->anything and pt->escaped, then it will be as
> useless for the variable conflicts as is removing the important clearing of
> the bitmap bit on clobber stmt, we won't share stack slots pretty much at
> all.

The point about !SSA_NAME_PTR_INFO is that passes might clear it, replace
such SSA name with a new one, forgetting to copy it, etc.  The point
about anything is that points-to analysis might just have given up
(consider the provenance thing where we might end up with anything for
going through some uintptr arithmetic), the point about escaped is that
this is just a placeholder for a set of variables and points-to tends
to shrink sets by removing bits also in escaped.  Also
global = ptr; ptr2 = global; will have escaped in the sets but not
necessarily the bit of the original decl.

So my comments are just about correctly interpreting points-to data.

[Bug rtl-optimization/87845] cselib_hasher::hash function does not match with cselib_hasher::equal operator

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Martin Liška from comment #0)
> Can please anybody familiar with cselib help me here?

Don't think that's me (not really familiar with it), but I agree
the code looks dubious.  cselib_hash_rtx is going to return a
different hash for each location, so I can't see how using
a fixed v->hash from one location for ::hash and a linear
search over the locations for ::equal is going to work.

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

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #11 from The Written Word  
---
(In reply to dave.anglin from comment #10)
> On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
> > Dave, are you aware of anybody testing ia64-hpux?
> > Should it be deprecated if nobody is maintaining it?
> I don't have or access to a ia64 box.
> 
> I don't know the status of Jim Wilson who is listed as ia64 maintainer.
> 
> Albert Chin  is the only person that I know who
> might be actively using it.
> 
> My access to the hppa box that I use for hppa-hpux support requires support
> from NRC Canada but
> all colleagues there have retired.  It was down for a few weeks until
> yesterday when I got a network person
> to reboot it.
> 
> So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.

We are still using it but haven't been able to build anything post 4.9.4. We
tried to find someone to pay to bring this port up-to-date but had no success.
Open to other suggestions but deprecating it might be the only way forward.

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
This still fails (just on power 9) even with the above change.  On all the
other powerpc64 targets it comes up as unsupported.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[matz at gcc dot gnu.org]

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

--- Comment #12 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #11)
> before that region.  If we can say for:
>   for (...)
> {
>   unsigned char v[10];
>   unsigned char *p = foo (v);
>   *p = 1;
>   unsigned char w[10];
>   bar (w);
> }
> hoist the p = foo (v); call before the loop, then indeed we are in big
> trouble.

This is effectively what the testcase is doing (just that 'foo' is no call, but
a normal address expression), so yes, we can do that, and yes we are in big
trouble :-/

> If I have to consider pt->anything and pt->escaped, then it will be as
> useless for the variable conflicts as is removing the important clearing of
> the bitmap bit on clobber stmt, we won't share stack slots pretty much at
> all.

Yeah; if we don't want to patch the specific situation for this testcase
(which might be okayish, we haven't seen this problem very often over the
last years), but want to really fix it we might have to take more involved
means like doing stack slot sharing before gimplification and rewriting
the IL to reflect this.  Or give up on sharing (which isn't a good idea).
Gnah.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Created attachment 46312 [details]
> > gcc10-pr90348.patch
> > 
> > Untested patch that implements what was written in #c5.  I agree that
> > without further changes to the IL, determining if one can hoist addresses of
> > local variables or not is going to be hard, would require computing the
> > variable life info in each pass that would do something similar.  On the
> > other side, admittedly such hoisting results in worse code generation
> > because if the address is hoisted earlier than where it used to be live
> > before, then there will be more stack conflicts.
> 
> Ick.  You need to handle pt->anything and pt->escaped (walk the escaped
> solution) as well.  And !SSA_NAME_PTR_INFO (op) is of course the same
> as pt->anything.

Do I?
I thought I don't.  The thing is, I believe the partitioning only cares about
where (originally in the source) the automatic variables are referenced.
Now, if I have say:
__attribute__((noipa)) type *foo (type *x) { return x; }
or similar, in order for a variable to be live before the clobber, it needs to
escape in the area where the variable is live, we don't care what we do with
whatever it returned, unless we actually hoist such escaping calls before that
region.  If we can say for:
  for (...)
{
  unsigned char v[10];
  unsigned char *p = foo (v);
  *p = 1;
  unsigned char w[10];
  bar (w);
}
hoist the p = foo (v); call before the loop, then indeed we are in big trouble.
But if we can't, the attached patch was just meant as a shorthand for trying to
do a dataflow propagation of the can a pointer SSA_NAME point to variable xyz,
if we don't consider escaping (to other functions and to global state).
What I'm trying to "undo" is just the hoisting of the address loads, not
hoisting of those address loads plus function calls in which it escapes or
where that address is saved to memory.

If I have to consider pt->anything and pt->escaped, then it will be as useless
for the variable conflicts as is removing the important clearing of the bitmap
bit on clobber stmt, we won't share stack slots pretty much at all.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Author: rguenth
Date: Tue May  7 13:03:19 2019
New Revision: 270944

URL: https://gcc.gnu.org/viewcvs?rev=270944=gcc=rev
Log:
2019-05-07  Richard Biener  

PR tree-optimization/90316
* tree-ssa-pre.c (translate_vuse_through_block): When
same_valid is NULL do not bother to search for a virtual
PHI continuation.
(phi_translate_1): When operands changed we cannot keep
the same value-number so do not bother to ask whether
that's possible from translate_vuse_through_block.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Martin Liška from comment #3)
> So the problem is that without a profile tree-vectorizer does a
> vectorization in 1162 functions, while with PGO only 49 functions are
> vectorized.
> Can you please Richi take a look? I can provide vectorizer dump files.

optimize_loop_nest_for_speed_p returning false?

Does the train profile match the ref profile or is there a clear mismatch
so we guess a ref hot loop as cold?

[Bug rtl-optimization/88879] [9/10 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
ping?

[Bug middle-end/90345] too pessimistic check whether pointer may alias a local variable

[vanyacpp at gmail dot com]

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

--- Comment #4 from Ivan Sorokin  ---
Making points-to analysis aware of SESE regions will definitely help here and
is a nice thing to have.

There is one more option. In my reduced test case the body of 'push_back' is
unavailable, but when it is it can be analysed and an attribute can be added
that 'push_back' only uses the received reference internally and does not
escape it.

>From my experiments this is what clang does: even when the body of 'push_back'
is not inlined it generates different code for 'operator*=' depending on
whether push_back escapes the received reference or not:

void push_back(uint32_t const&) __attribute__((noinline));

void big_integer::push_back(uint32_t const& a)
{
__asm__("" : : : "memory");
//__asm__("" : : "g"() : "memory");
}

I guess with LTO enabled this type of analysis is quite powerful, as many
'const&' and 'this' parameters in C++ don't really escape.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 46312 [details]
> gcc10-pr90348.patch
> 
> Untested patch that implements what was written in #c5.  I agree that
> without further changes to the IL, determining if one can hoist addresses of
> local variables or not is going to be hard, would require computing the
> variable life info in each pass that would do something similar.  On the
> other side, admittedly such hoisting results in worse code generation
> because if the address is hoisted earlier than where it used to be live
> before, then there will be more stack conflicts.

Ick.  You need to handle pt->anything and pt->escaped (walk the escaped
solution) as well.  And !SSA_NAME_PTR_INFO (op) is of course the same
as pt->anything.

I see it quickly degrading given the last PTA compute is far far away...

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
So the problem is that without a profile tree-vectorizer does a vectorization
in 1162 functions, while with PGO only 49 functions are vectorized.
Can you please Richi take a look? I can provide vectorizer dump files.

[Bug tree-optimization/90377] [10 Regression] New -Wstringop-overflow with -O3 since r270852

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2019-5-7
 CC||glisse at gcc dot gnu.org
  Known to work||9.1.0
Version|9.0 |10.0
   Target Milestone|--- |10.0
  Known to fail||10.0

[Bug tree-optimization/90377] New: [10 Regression] New -Wstringop-overflow with -O3 since r270852

[marxin at gcc dot gnu.org]

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

Bug ID: 90377
   Summary: [10 Regression] New -Wstringop-overflow with -O3 since
r270852
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Isolated from webkit2gtk3 package:

$ cat webkit.ii
# 1 "" 3
typedef int a;
namespace b {
template  void d(c);
}
enum e { f };
void *operator new(a, e, void *g) { return g; }
template  class h;
template  struct j {
  static void k(i *l, i *m, i *aa) {
while (l != m) {
  new (f, aa) i;
  ++aa;
  ++l;
}
  }
};
template  struct n {
  static void k(i *l, i *m, i *aa) { j::k(l, m, aa); }
};
class C {
public:
  ac();
  unsigned o;
  unsigned ad;
};
template  class p : C {
public:
  d(p af, a, a) {
af.ac();
i *q = af.r(), *a = q;
n::k(0, s, a);
b::d(o);
  }
  C::ad;
  a s;
  i *r() { return reinterpret_cast(ah); }
  int ah[];
};
class t;
template  class h : p {
  typedef p ae;

public:
  h();
  h =(h &&);
  d(h ) { ae::d(af, ad, ad); }
};
template 
h ::operator=(h &) {
  d(af);
}
class t {
public:
  t() : x(){} * x;
};
class D {
  void aj();
  h ak;
};
void D::aj() { ak = {}; }

$ g++ webkit.ii -O3 -Werror -Wall -std=c++14 -c  -Wstringop-overflow
-fpermissive
In member function ‘void D::aj()’:
cc1plus: error: ‘void* __builtin_memset(void*, int, long unsigned int)’ writing
8 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
cc1plus: all warnings being treated as errors

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
May I please ping this? I would like to finish the hast table sanitization
patch in this stage1.

[Bug rtl-optimization/87845] cselib_hasher::hash function does not match with cselib_hasher::equal operator

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
May I please ping this? I would like to finish the hast table sanitization
patch in this stage1.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #30 from Martin Liška  ---
A possible solution can be usage of '-flinker-output=nolto-rel -r' for huge
files.

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

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
> Dave, are you aware of anybody testing ia64-hpux?
> Should it be deprecated if nobody is maintaining it?
I don't have or access to a ia64 box.

I don't know the status of Jim Wilson who is listed as ia64 maintainer.

Albert Chin  is the only person that I know who might
be actively using it.

My access to the hppa box that I use for hppa-hpux support requires support
from NRC Canada but
all colleagues there have retired.  It was down for a few weeks until yesterday
when I got a network person
to reboot it.

So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Tue May  7 11:17:00 2019
New Revision: 270940

URL: https://gcc.gnu.org/viewcvs?rev=270940=gcc=rev
Log:
2019-05-07  Richard Biener  

PR tree-optimization/90316
* tree-ssa-alias.h (get_continuation_for_phi): Take walking
limit by reference.
(walk_non_aliased_vuses): Take walking limit argument.
* tree-ssa-alias.c (maybe_skip_until): Take limit and abort
walking if it is reached instead of just counting.
(get_continuation_for_phi): Likewise.
(walk_non_aliased_vuses): Likewise, instead of leaving counter
limiting to the callback.
* tree-ssa-sccvn.c (vn_reference_lookup_2): Adjust.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.
(vn_reference_lookup): Likewise.
* tree-ssa-pre.c (translate_vuse_through_block): Limit walking.
* tree-ssa-scopedtables.c (vuse_eq): Adjust.
(avail_exprs_stack::lookup_avail_expr): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-alias.h
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-scopedtables.c

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 46312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46312=edit
gcc10-pr90348.patch

Untested patch that implements what was written in #c5.  I agree that without
further changes to the IL, determining if one can hoist addresses of local
variables or not is going to be hard, would require computing the variable life
info in each pass that would do something similar.  On the other side,
admittedly such hoisting results in worse code generation because if the
address is hoisted earlier than where it used to be live before, then there
will be more stack conflicts.

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #4 from Viktor Ostashevskyi  ---
Bisected to:

commit c6e37a9f5734bfe731b042993f77cb41b5a566c5
Author: redi 
Date:   Sun Jan 6 22:34:29 2019 +

PR libstdc++/86756 add std::filesystem::path to libstdc++.so

Move the C++17 std::filesystem::path definitions from the libstdc++fs.a
archive to the main libstdc++ library. The path classes do not depend on
any OS functions, so can be defined unconditionally on all targets
(rather than depending on --enable-libstdcxx-filesystem-ts). The tests
should pass on all targets too.  
 ...
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@267615
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c/90376] spurious -Warray-bounds on memset() of several struct's subobjects

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-07
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
For me the warning looks fine, started with r269867.
Martin will clarify the warning..

[Bug c/90376] New: spurious -Warray-bounds on memset() of several struct's subobjects

[ryabinin.a.a at gmail dot com]

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

Bug ID: 90376
   Summary: spurious -Warray-bounds on memset() of several
struct's subobjects
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryabinin.a.a at gmail dot com
  Target Milestone: ---

This is new on gcc 9.

# cat array_bounds.c

struct trace_iterator {
char a;
int seq;
long b;
};

void f(void)
{
static struct trace_iterator iter;
__builtin_memset(, 0,
sizeof(struct trace_iterator) -
__builtin_offsetof(struct trace_iterator, seq));

}

# gcc -O2 -c -Warray-bounds array_test.c
array_test.c: In function ‘f’:
array_test.c:12:2: warning: ‘__builtin_memset’ offset [9, 16] from the object
at ‘iter’ is out of the bounds of referenced subobject ‘seq’ with type ‘int’ at
offset 4 [-Warray-bounds]
   12 |  __builtin_memset(, 0,
  |  ^~
   13 |   sizeof(struct trace_iterator) -
  |   ~~~
   14 |   __builtin_offsetof(struct trace_iterator, seq));
  |   ~~~

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64919

--- Comment #9 from Jonathan Wakely  ---
(In reply to Joseph John from comment #5)
> I am still struggling to compiler any version giver than GCC 4.9.0 on ia64
> platform still but as far as this issue is concerned I was able to get pass
> the LD abort when I used the below options for configure:
> 
> CC="gcc -mlp64" CXX="g++ -mlp64"
> 
> With this option I was able to pass the linker abort just after the
> libbackend.a creation but I run into a segmentation error which I believe is
> the documented issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919

That bug now seems to have some fixes/workarounds to allow building 4.9.4

[Bug lto/90369] error: could not unlink output file

[hoganmeier at gmail dot com]

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

--- Comment #4 from krux  ---
The code was automatically reduced, hence the empty linker script.
Looks promising, seems like you found the cause.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build
 CC||danglin at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
A user on IRC reported similar errors for GCC 9.1.0:

g++ -mlp64 -std=gnu++98   -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-libstdc++
-static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o
c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o
c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
c-family/c-spellcheck.o ia64-c.o default-c.o \
   cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  
-L/wrk/ia64-9.1.0//lib -L/wrk/ia64-9.1.0//lib -L/wrk/ia64-9.1.0//lib -lmpc
-lmpfr -lgmp   -L./../zlib -lz -lunwind
ld: The value 0xfda61f70 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x2a2 in section index 622 of file
libbackend.a[wide-int-range.o]
426 errors.
collect2: error: ld returned 1 exit status


Dave, are you aware of anybody testing ia64-hpux?
Should it be deprecated if nobody is maintaining it?

[Bug tree-optimization/90373] Better alias analysis based on libc functions with arguments which cannot alias

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Richard Biener  ---
It is.  Note we have no good way of recording these flow-sensitive information
right now.

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

[Bug middle-end/82885] memcpy does not propagate aliasing knowledge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #3 from Richard Biener  ---
*** Bug 90373 has been marked as a duplicate of this bug. ***

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Michael Matz from comment #7)
> No, this is not a problem in the stack slot sharing algorithm, but rather in
> the input.  As presented to expand, and only showing the important parts,
> and reordering some BBs to make the flow more obvious:
> 
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _30 = (unsigned long) 
>   ivtmp.27_29 = _30 + 1;
>   goto ; [100.00%]
> 
> So, 'in' becomes "live" here, it's address in _30 and _29.  Fallthrough to
> bb5,
> which also uses in, but otherwise is uninteresting, except that it can reach
> only BBs 6 and 7:
> 
> ;;   basic block 5, loop depth 1
>   ...
>   _2 = check_zero (, _31);
>   if (_2 != 0)
> goto ; [99.96%]
>   else
> goto ; [0.04%]
> 
> bb6 is a no-return block, hence uninteresting.  bb7 _is_ interesting in that
> it clobbers in:
> 
> ;;   basic block 7, loop depth 1
> ;;pred:   5
>   in ={v} {CLOBBER};
>   if (i_11 != 5)
> goto ; [83.33%]
>   else
> goto ; [16.67%]
> 
> Note that the semantics of the clobber is not only that the former contents
> are destroyed, but rather that the very storage associated with the clobbered
> entity is gone.  So, from now on, any pointers into 'in', and memory accesses
> into 'in' are invalid.  Nevertheless the flow from bb7 goes to bb 8 and 9,
> the latter being the return block, so:
> 
> ;;   basic block 8, loop depth 1
> ;;pred:   7
>   if (i_11 > 0)
> goto ; [100.00%]
>   else
> goto ; [0.00%]
> 
> and here we finally have a path into bb3, which is the other interesting one:
> 
> ;;   basic block 3, loop depth 2
>   # ivtmp.20_6 = PHI <_30(8), ivtmp.20_18(3)>
> 
>  BOOM!  Here _30 is used, and ...
> 
>   _4 = (void *) ivtmp.20_6;
>   MEM[base: _4, offset: 0B] = 0;
> 
> ... even written into ...  That's invalid.  _30 is associated with an
> object that is clobbered and gone ...
> 
>   set_one ();
>   buf ={v} {CLOBBER};
>   ivtmp.20_18 = ivtmp.20_6 + 1;
> 
> ... and as the MEM[] write can't have possibly been into 'in' (as that is
> invalid, as 'in' didn't exist at the MEM access), it's okay and sensible to
> allocate 'in' and 'buf' into the same memory.
> 
> It seems to be a common misconception of what the clobber is really about.
> I designed it to mean what I wrote above, the storage associated with the
> clobbered entities is gone after the clobber (not merely it's former
> contents!). 
> 
> But ivopts or dom extends the lifetime of 'in' (by moving an address-taken
> earlier) and hence the lifetime of its storage, but without doing anything
> about the clobber (and hence not _really_ extending the lifetime).  That
> doesn't work.
> It's basically a mirrored transformation of the usual take-address-of-local
> and access it out of it's declared scope, just that here the _start_ of the
> supposed lifetime is moved out of the declared scope, not the end.

While I spotted this "issue" as well I respectfully disagree about
the semantics.  Not because they are not sound but because of
the implementation challenge resolving around address-takens being
values with no data dependence on the clobbers.

I thought the liveness algorithm would be able to handle this situation.
If not we need to prune clobbers that became "invalid" somehow.
Not sure how - the address value never "dies", so we'd need to compute
liveness of the things the address escapes to - SSA names are easy,
calls - well, we have to give up.  This possiby defeats the whole idea
of doing stack sharing analysis (I remember kernel/fortran testcases
passing the stack slots by reference to a function).

Now if we would want to try forcing the original semantics we need a
verifier verifying the IL state against bogus transforms - but then we
would have a way to prune the invalid ones.