[Bug regression/95733] New: Building on PowerPC 64 Tests Fail With GCC 11

[xerofoify at gmail dot com]

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

Bug ID: 95733
   Summary: Building on PowerPC 64 Tests Fail With GCC 11
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xerofoify at gmail dot com
  Target Milestone: ---

After building gcc as such:
../gcc/configure --enable-lanuages=c,c++ --enable-threads -disable-multilibs
--enable-checking=yes --prefix=/home/xerofoify/obdjir

it fails on running tests with make -k check with:
=== libgomp Summary ===

# of expected passes7764
# of expected failures  4
# of unsupported tests  573
make[4]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp/testsuite'
make[3]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp/testsuite'
make[3]: Entering directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
:
:
:
make  DO=all multi-do # make
make[4]: Entering directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
if [ -z "" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../gcc/libgomp; ${PWDCMD-pwd}`/; export srcrootpre; \
  lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="/home/xerofoify/obdjir/./gcc/xgcc -B/home/xerofoify/obdjir/./gcc/
-B/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/bin/
-B/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/include -isystem
/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/sys-include   "; \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make  \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS=" ${flags}" \
FCFLAGS="-L. -Wall -L../libgfortran  ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/home/xerofoify/obdjir" \
exec_prefix="/home/xerofoify/obdjir" \
GOCFLAGS="-O2 -g ${flags}" \
GDCFLAGS="-O2 -g ${flags}" \
CXXFLAGS="-g -O2 -D_GNU_SOURCE ${flags}" \
LIBCFLAGS="-g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -D_GNU_SOURCE
-fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
INSTALL="/usr/bin/install -c" \
INSTALL_DATA="/usr/bin/install -c -m 644" \
INSTALL_PROGRAM="/usr/bin/install -c" \
INSTALL_SCRIPT="/usr/bin/install -c" \
all); then \
  true; \
else \
  exit 1; \
fi; \
  else true; \
  fi; \
fi; \
  done; \
fi
make[4]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[3]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[2]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[1]: Leaving directory `/home/xerofoify/obdjir'
make: *** [do-check] Error 2
make: Target `check' not remade because of errors.
[xerofoify@gcc2-power8 obdjir]$ cd bin
[xerofoify@gcc2-power8 bin]$ ./g++ -v
Using built-in specs.
COLLECT_GCC=./g++
COLLECT_LTO_WRAPPER=/home/xerofoify/obdjir/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc/configure --enable-lanuages=c,c++ --enable-threads
-disable-multilibs --enable-checking=yes --prefix=/home/xerofoify/obdjir
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200613 (experimental) (GCC) 

OpenMP should be enabled by default with C++ and therefore this seems to be a
regression.

[Bug middle-end/94895] ICE in expand_block_tm, at trans-mem.c:2643

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Confirmed however seems to be latent as it seems to be hitting:
case GIMPLE_ASM:
  gcc_unreachable ();
in expand_block_tm and the commit mentioned is touching coroutines.

[Bug c++/95672] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:584

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #5 from Nicholas Krause  ---
Created attachment 48736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48736=edit
Proposed Fix

This is a proposed fix for the bug. Not sure if we need to emit multiple
messages for different possible template expansion failures.

[Bug middle-end/95442] LRA inserts a reload insn for REG_DEAD register

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
That seems right to be, last commit to touch it was 55a2c3226a3e. After looking
at it the reload insn and the related commit we should not be adding the reload
insn here.

[Bug middle-end/89428] missing -Wstringop-overflow on a PHI with variable offset

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
Changing i equal to 1 in the second function gives the warning and gets similar
GIMPLE like this to the first function:

 [local count: 1073741824]:
  i_3 = MAX_EXPR ;
  _1 =  + i_3;   
  __builtin_memset (_1, 0, 99); [tail call]
  return;  

Are we assuming somewhere that zero size offsets should for the first argument
of __builtin_memset to be forgotten about? Because I tried it with multiple
numbers other than zero and they all worked to get GIMPLE similar to the above.

[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #5 from Nicholas Krause  ---
Seems to be regressing  due to missing a check for another constructor type in
type_has_nontrivial_copy_init or somewhere up the stack.Both the other two in
the last reported case are fine. Therefore I'm assuming is not be found as a
trivial move or copy constructor somewhere and this looks to the compiler like
a different constructor type:
B b{foo()};

Seems to be a trivial constructor to me but the compiler seems to be ICEing
because its not or detected as such and therefore is not correctly building
special temp member functions. The original patch seems to causing some issue 
in this way.

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[xerofoify at gmail dot com]

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

--- Comment #10 from Nicholas Krause  ---
(In reply to Martin Liška from comment #8)
> (In reply to Nicholas Krause from comment #7)
> > After adding this it seems to work for me, Patrick:
> >case TYPE_ARGUMENT_PACK:
> > if (value_dependent_expression_p(TREE_TYPE(*tp)))
> >  return *tp;
> > if (TEMPLATE_TYPE_PARAMETER_PACK(*tp))
> >  return *tp;
> > return NULL_TREE;
> > 
> > and gives me:
> > test.c: In function ‘std::common_type_t > (forward(f)(std::integral_constant(),
> > (forward)(args)...)), decltype
> > (forward(f)(int_constant(), (forward)(args)...))...>
> > select(int, F&&, Args&& ...)’:
> > test.c:14:12: warning: ‘if constexpr’ only available with ‘-std=c++17’ or
> > ‘-std=gnu++17’
> >14 | if constexpr(sizeof...(Is)>0)
> >   |^
> > test.c: In function ‘std::common_type_t > (forward(f)(std::integral_constant(),
> > (forward)(select::args)...)), decltype
> > (forward(f)(int_constant(),
> > (forward)(select::args)...))...> select(int, F&&,
> > Args&& ...) [with int I = 1; int ...Is = {}; F = t(int)::;
> > Args = {}]’:
> > test.c:17:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >17 | }
> >   | ^
> > 
> > with no segfault. I'm not sure if this is the correct part to add this test
> > for TYPE_ARGUMENT_PACK or if we would prefer it to be lower in the stack.
> 
> The suggested change is wrong:
> 
> /home/marxin/Programming/gcc2/objdir/./gcc/xgcc -shared-libgcc
> -B/home/marxin/Programming/gcc2/objdir/./gcc -nostdinc++
> -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src
> -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src/.
> libs
> -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu/bin/
> -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
> /usr/local/x86_64-pc-linux-gnu/include -isystem
> /usr/local/x86_64-pc-linux-gnu/sys-include-x c++-header -nostdinc++ -g
> -O2 -D_GNU_SOURCE 
> -I/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include/x86_64-pc-linux-gnu
> -I/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include -I/home/marxin/Programming/gcc2/libstdc++-v3/libsupc++  -O2 -g
> -std=gnu++0x
> /home/marxin/Programming/gcc2/libstdc++-v3/include/precompiled/stdc++.h \
> -o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
> In file included from
> /home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include/cmath:42,
>  from
> /home/marxin/Programming/gcc2/libstdc++-v3/include/precompiled/stdc++.h:41:
> /home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include/bits/cpp_type_traits.h:89:63: internal compiler error: tree check:
> expected template_type_parm or template_template_parm or
> bound_template_template_parm, have tree_list in instantiation_dependent_r,
> at cp/pt.c:26926
>89 |   enum { __value = bool(_Sp::__value) || bool(_Tp::__value) };
>   |   ^
> 0x8404c2 tree_check_failed(tree_node const*, char const*, int, char const*,
> ...)
>   ../../gcc/tree.c:9727
> 0x69234b tree_check3(tree_node*, char const*, int, char const*, tree_code,
> tree_code, tree_code)
>   ../../gcc/tree.h:3327
> 0x69234b instantiation_dependent_r
>   ../../gcc/cp/pt.c:26926
> 0x13749b3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*,
> tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*))
>   ../../gcc/tree.c:11996
> 0xb10a88 cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
> int*, void*), void*, hash_set default_hash_traits >*)
>   ../../gcc/cp/tree.c:5061
> 0x1374a47 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*,
> tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*))
>   ../../gcc/tree.c:12019
> 0x1377c85 walk_tree_without_duplicates_1(tree_node**, tree_node*
> (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
> tree_node* (*)(tree_node**, int*, void*), void*, hash_set default_hash_traits >*))
>   ../../gcc/tree.c:12352
> 0xa97c87 instantiation_dependent_uneval_expression_p(tree_node*)
>   ../../gcc/cp/pt.c:27033
> 0xa9e278 instantiation_dependent_expression_p(tree_node*)
>   ../../gcc/cp/pt.c:27043
> 0x973ba7 is_nondependent_constant_expression(tree_node*)
>   ../../gcc/cp/constexpr.c:8300
> 0x973fca fold_non_dependent_expr_template
>   ../../gcc/cp/constexpr.c:6970
> 0xa98147 build_non_dependent_expr(tree_node*)
>   ../../gcc/cp/pt.c:27531
> 0xb271ef build_x_binary_op(op_location_t const&, tree_code, tree_node*,
> tree_code, tree_node*, tree_code, tree_node**, int)
>   ../../gcc/cp/typeck.c:4245
> 

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[xerofoify at gmail dot com]

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

--- Comment #9 from Nicholas Krause  ---
Created attachment 48318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48318=edit
Possible Fix

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[xerofoify at gmail dot com]

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

--- Comment #7 from Nicholas Krause  ---
After adding this it seems to work for me, Patrick:
   case TYPE_ARGUMENT_PACK:
if (value_dependent_expression_p(TREE_TYPE(*tp)))
 return *tp;
if (TEMPLATE_TYPE_PARAMETER_PACK(*tp))
 return *tp;
return NULL_TREE;

and gives me:
test.c: In function ‘std::common_type_t(f)(std::integral_constant(),
(forward)(args)...)), decltype
(forward(f)(int_constant(), (forward)(args)...))...>
select(int, F&&, Args&& ...)’:
test.c:14:12: warning: ‘if constexpr’ only available with ‘-std=c++17’ or
‘-std=gnu++17’
   14 | if constexpr(sizeof...(Is)>0)
  |^
test.c: In function ‘std::common_type_t(f)(std::integral_constant(),
(forward)(select::args)...)), decltype
(forward(f)(int_constant(),
(forward)(select::args)...))...> select(int, F&&,
Args&& ...) [with int I = 1; int ...Is = {}; F = t(int)::; Args
= {}]’:
test.c:17:1: warning: control reaches end of non-void function [-Wreturn-type]
   17 | }
  | ^

with no segfault. I'm not sure if this is the correct part to add this test for
TYPE_ARGUMENT_PACK or if we would prefer it to be lower in the stack.

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #5 from Nicholas Krause  ---
Shouldn't we also we testing for TYPE_ARGUMENT_PACK as well?  Seems to be
missing in the reported patch id and is not checked higher up the stack after
looking through the code it seems.

[Bug middle-end/87118] ICE in expand_expr_addr_expr_1, at expr.c:7862

[xerofoify at gmail dot com]

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

--- Comment #5 from Nicholas Krause  ---
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d3f2e41eae66b3699aaa6e2bfc4ce5b86cedd37e

[Bug middle-end/87118] ICE in expand_expr_addr_expr_1, at expr.c:7862

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #4 from Nicholas Krause  ---
Seems that this commit is causing it: d3f2e41eae66b3 based on Martin's
comments.

[Bug ipa/92981] ICE in get_partitioning_class, at symtab.c:1966

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
After looking through this with a debugger this seems odd to me:
if (alias && definition && !ultimate_alias_target ()->definition)

I'm not sure but after looking through it this seems to assume definition and
alias would be pointing  be true which does not seem to be the case with this
code and thus asserts here:
gcc_checking_assert (vnode->definition);

Seems this commit id,d3f2e41ea introduced it. Jan Hubicka are we certain
that definition and alias must both be true here as that does not appear 
to be the case for returning SYMBOL_EXTERNAL?

[Bug other/46489] tree optimizer and frontend files use target macros

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #11 from Nicholas Krause  ---
(In reply to Eric Gallager from comment #10)
> (In reply to Eric Gallager from comment #9)
> > (In reply to Joseph S. Myers from comment #7)
> > > FWIW, the following files include tm.h and appear not to have any direct
> > > uses of target macros, or uses of the most common headers (such as rtl.h 
> > > or
> > > cp-tree.h) that depend on tm.h.  They require more careful checks of what
> > > headers they are using for any hidden tm.h dependencies, but may be good
> > > candidates for the removal of tm.h includes.
> > > 
> > > gcc/java/except.c
> > > gcc/java/jvgenmain.c
> > > gcc/java/jvspec.c
> > > gcc/java/mangle.c
> > > gcc/java/zextract.c
> > 
> > I don't know about the rest of them, but these at least are gone.
I looked through the code and most of the original files either no longer
exist or are removed.  A lot of the remaining ones seem to be in the c,
C++ and other frontends.
> 
> I checked for other removals:
> 
> (In reply to Joseph S. Myers from comment #7)
> > gcc/c-aux-info.c
> > gcc/c-convert.c
> > gcc/c-errors.c
> > gcc/c-lang.c
> > gcc/c-parser.c
> 
The only files mentioned are that require tm.h still are
gcc/c/c-errors.
gcc/c/c-aux-info.c
> These have all been moved to gcc/c/
> 
> > gcc/cppspec.c
> 
> This has been moved to gcc/c-family/
> 
> > gcc/tree-nomudflap.c
> > gcc/tree-optimize.c
> > gcc/tree-ssa-copyrename.c
> 
> These 3 appear to have been removed.

[Bug rtl-optimization/90214] UBSAN: signed integer overflow: 162675373468811328 - -9060696663385964544 cannot be represented in type 'long int'

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
I've tried this on godbolt for gcc 9.1, gcc 9.2 and gcc 9.3. I've also tried
this on trunk from a recent build and it does not occur anymore. Seems to be
fixed now. Does this still occur for you, Martin as it does now occur for me on
x86 or power?

[Bug middle-end/90794] [8/9/10 Regression] -O3 with "VLA type" in C++ leads to an ICE

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #6 from Nicholas Krause  ---
I can confirm about building trunk from yesterday that this code no longer ICEs
on 03. Can someone please close this bug as it no longer blocks C++ VLA for gcc
10.

[Bug middle-end/86715] ICE passing too large argument on stack

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Hi,

This does not seem to be happening in the middle end but in RTL expand. I've
tried on x86_64 trunk and now powerpc. Seems to only happen on PowerPC now as
seen here:
test.cpp: In function ‘int main(int, char**)’:
test.cpp:33:23: sorry, unimplemented: passing too large argument on stack
   33 |   result = mulm(m1, m2);
  |   ^
during RTL pass: expand
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.


I'm not aware of stack size limitations on Power so I'm CCed the maintainer to
take a look. Not sure if this occurs on other architectures in expand like ARM
as well. Segher would you please take a look at this for me.

[Bug c++/94255] template specialization in different namespace causes crash

[xerofoify at gmail dot com]

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

--- Comment #3 from Nicholas Krause  ---
I've managed to track this down to what appears to me to be a issue in:
tree
push_inner_scope (tree inner)
{
  tree outer = current_scope ();
  if (!outer)
outer = current_namespace;

  push_inner_scope_r (outer, inner);
  return outer;
}


I'm not certain if we should just check against NULL_TREE for outer or do we
need to also check against DECL_NAMESPACE as well. CCing Jason Merrill to take
a look at this with his comments.

[Bug c++/94255] template specialization in different namespace causes crash

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
I've managed to track this down to what appears to me to be a issue in:
tree
push_inner_scope (tree inner)
{
  tree outer = current_scope ();
  if (!outer)
outer = current_namespace;

  push_inner_scope_r (outer, inner);
  return outer;
}


I'm not certain if we should just check against NULL_TREE for outer or do we
need to also check against DECL_NAMESPACE as well. CCing Jason Merrill to take
a look at this with his comments.

[Bug c++/94250] valgrind error for ./g++.dg/ipa/remref-1.C

[xerofoify at gmail dot com]

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

--- Comment #2 from Nicholas Krause  ---
(In reply to Nicholas Krause from comment #1)
> After looking through the git history that last time this functions in your
> trace were changed is by commit id,
> db30281f0b2ff6dfc0c4146291baf020a27e4065. Martin Liska  was the original
> committer so he should comment on this.
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=db30281f0b2ff6dfc0c4146291baf020a27e4065
> 
> However this was changed:
> summary->duplicate (edge1, edge2, edge1_summary,
>   summary->get_create (edge2));

and it appears to be assuming based on the above lines:
if (summary->m_initialize_when_cloning)
 edge1_summary = summary->get_create (edge1);
else
 edge1_summary = summary->get (edge1);

That this can never occur for edge2. Martin is edge2 assumed to be good by this
comment?

[Bug c++/94250] valgrind error for ./g++.dg/ipa/remref-1.C

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||mliska at suse dot cz,
   ||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
After looking through the git history that last time this functions in your
trace were changed is by commit id,
db30281f0b2ff6dfc0c4146291baf020a27e4065. Martin Liska  was the original
committer so he should comment on this.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=db30281f0b2ff6dfc0c4146291baf020a27e4065

However this was changed:
summary->duplicate (edge1, edge2, edge1_summary,
  summary->get_create (edge2));

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[xerofoify at gmail dot com]

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

--- Comment #3 from Nicholas Krause  ---
(In reply to Marek Polacek from comment #2)
> (In reply to Nicholas Krause from comment #1)
> > Hi Marin,
> > I've not sure if this is correct but it does not ICE with this fix:
> > tree off = fold_convert (ptr_type_node, op1);
> > -   return build_fold_addr_expr_loc
> > -   (loc,
> > +   return build1_loc
> > +   (loc, ADDR_EXPR, TREE_TYPE (op0),
> >  fold_build2 (MEM_REF,
> >   TREE_TYPE (TREE_TYPE (op0)),
> >   unshare_expr (op0), off));
> > 
> > should actually be:  
> > (EXPR_LOCATION(off), ADDR_EXPR, TREE_TYPE (op0),
> >  fold_build2 (MEM_REF,
> >   TREE_TYPE (TREE_TYPE (op0)),
> >   unshare_expr (op0), off));
> 
> Huh?  Why do you think that changing the location should fix the ICE? 
> That's a completely random change that you never bothered to test, because
> it doesn't fix the crash.

Here is my exact output of testing the change:
[xerofoify@gcc2-power8 bin]$ ./g++ star.ii -c -flto -O2 -o x.o && ./gcc -shared
x.o
star.ii: In member function ‘int B< ,
, , ,
 >::_S_key()’:
star.ii:9:19: warning: no return statement in function returning non-void
[-Wreturn-type]
9 |   int _S_key() {  }
  |   ^
star.ii: In member function ‘int B< ,
, , ,
 >::_M_insert_(int*, int*, _Arg&&, _NodeGen&)’:
star.ii:24:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   24 | }
  | ^

If you look at the revision mentioned for this bug in gimple-fold.c here:
tree off = fold_convert (ptr_type_node, op1);
-   return build_fold_addr_expr_loc
-   (loc,
+   return build1_loc
+   (loc, ADDR_EXPR, TREE_TYPE (op0),
that's incorrect as loc is not the tree we want but off and from that the
EXPR_LOCATION of that tree. Does that make more sense now?

[Bug ipa/94217] [10 Regression] ICE in ipa_find_agg_cst_for_param, at ipa-prop.c:3467 since r10-7237-g4e3d3e40726e1b68

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Hi Marin,
I've not sure if this is correct but it does not ICE with this fix:
tree off = fold_convert (ptr_type_node, op1);
-   return build_fold_addr_expr_loc
-   (loc,
+   return build1_loc
+   (loc, ADDR_EXPR, TREE_TYPE (op0),
 fold_build2 (MEM_REF,
  TREE_TYPE (TREE_TYPE (op0)),
  unshare_expr (op0), off));

should actually be:  
(EXPR_LOCATION(off), ADDR_EXPR, TREE_TYPE (op0),
 fold_build2 (MEM_REF,
  TREE_TYPE (TREE_TYPE (op0)),
  unshare_expr (op0), off));

I've tested with your file and I get:
star.ii: In member function ‘int B< ,
, , ,
 >::_S_key()’:
star.ii:9:19: warning: no return statement in function returning non-void
[-Wreturn-type]
9 |   int _S_key() {  }
  |   ^
star.ii: In member function ‘int B< ,
, , ,
 >::_M_insert_(int*, int*, _Arg&&, _NodeGen&)’:
star.ii:24:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   24 | }


However this seems to be on multiple ade package files so can you test it
against that as well.

[Bug tree-optimization/94216] [10 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4899 since r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
Jakub, 
I just tested your patch like this:
./gcc -B. comm.ii -c -g -O

as mentioned by Martin Liska's report. It does not crash now so this
should be fixed by it and the compiler was configured like:
Configured with: ../gcc/configure --enable-lanuages=c,c++ --enable-threads
-disable-multilibs --enable-checking=yes --prefix=/home/xerofoify/obdjir

[Bug middle-end/93092] g++ takes tremendous compilation times in var-tracking

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #4 from Nicholas Krause  ---
(In reply to Richard Biener from comment #2)
> On trunk:
> 
> (gdb) p cfun->cfg->x_last_basic_block 
> $1 = 8940
> (gdb) p cfun->cfg->x_n_edges
> $2 = 14897
> 
> so we miss
> 
>   if (n_basic_blocks_for_fn (cfun) > 500
>   && n_edges_for_fn (cfun) / n_basic_blocks_for_fn (cfun) >= 20)
> {
>   vt_debug_insns_local (true);
>   return 0;
> }
> 
> this isn't really a good absolute limit, it's just singling out very
> insane cases of very many edges (but allow scaling with the number of BBs).
> 
> There's another limit for the dataflow problem size that is also not hit
> (--param max-vartrack-size).
> 
> There are plenty of similar bugreports (unfortunately).

Richard,
Not sure if this would be considered a regression fix for stage 4 but we should
update these numbers to a more sane limit. I've assuming based on the ration of
25 to 1 that we should just make it something like:
if (n_basic_blocks_for_fn (cfun) > 5
   && n_edges_for_fn (cfun) / n_basic_blocks_for_fn (cfun) >= 2500)
 {
  vt_debug_insns_local (true);
   return 0;
 }

Not sure if we can do this for stage 4 of GCC 10 based on the comments. However
we should update these numbers at least at some point in stage 1 of GCC 11.
I'll send a patch either way.

[Bug rtl-optimization/89116] [8/9/10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4482

[xerofoify at gmail dot com]

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

--- Comment #7 from Nicholas Krause  ---
(In reply to Arseny Solokha from comment #6)
> (In reply to Nicholas Krause from comment #5)
> > PR84508 does not seem to be reproducible on trunk now as last commented by
> > Arseny on trunk. Not sure about backporting a fix but does not seem to
> > happen on trunk for now.
> 
> PR85408, you mean. Sure, but why post it here? It is PR89116, not PR85408.
> The latter is tracked in PR90040 by the modulo scheduler maintainer, and
> he's perfectly aware of that. But one generally cannot simply close random
> PRs they seemingly cannot reproduce anymore (and it seems you even didn't
> try to reproduce it yourself), well-established GCC development process
> doesn't work that way, and the whole issue w/ the modulo scheduler is not so
> trivial anyway, so all those PRs are there for a reason.

Sorry I see it now that this does block 90040 so it makes more sense now. My
mistake as I thought this was just a duplicate and not a set of bugs.

[Bug rtl-optimization/89116] [8/9/10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4482

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #5 from Nicholas Krause  ---
PR84508 does not seem to be reproducible on trunk now as last commented by
Arseny on trunk. Not sure about backporting a fix but does not seem to happen
on trunk for now.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

--- Comment #17 from Nicholas Krause  ---
Sorry about that. I've managed to track it down to a problem with a alias issue 
And from reading the code in the original cvs commit. I'm not able to read it
currently but the original function mentioned seems to now be
cgraph_edge::verify_corresponds_to_fndecl. I've tried to access the original
commit but it complains about permissions. Maybe I'm wrong but this seems very
odd to me:
node = node->ultimate_alias_target ();

is basically referring to itself meaning:
if (callee->former_clone_of != node->decl
  && (node != node->ultimate_alias_target ())
  && !clone_of_p (node, callee))

the && (node != node->ultimate_alias_target ()) is basically referring to
itself when comparing yet its already being defined equal to the return value
of ultimate_alias_target meaning its always true. Not sure if this fixes this
bug or something else. Thoughts?

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

--- Comment #15 from Nicholas Krause  ---
(In reply to Nicholas Krause from comment #14)
> Created attachment 48052 [details]
> Patch for this bug

After tracking this down to the new function that replaced
verify_edge_corresponds_to_fndecl, cgraph_edge::verify_corresponds_to_fndecl
which is basically the same we run into this:
if (callee->former_clone_of != node->decl
  && (node != callee->ultimate_alias_target ())
  && !clone_of_p (node, callee))


 Basically it appears to be checking we are a former cgraph clone at the same
time as being a current clone or the same node with clone_of_p on the callee
cgraph node. I'm attaching a test patch for this. Gerhard does this fix the
issue?

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #14 from Nicholas Krause  ---
Created attachment 48052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48052=edit
Patch for this bug

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

--- Comment #13 from Nicholas Krause  ---
Please forget the previous comment in verify_edge_corresponds_to_fndecl we need
to switch it to this:
if (e->callee->former_clone_of != node->symbol.decl
&& (!n->symbol.cpp_implicit_alias
|| e->callee->former_clone_of != alias_node->symbol.alias_target ))

from the current:
 if (e->callee->former_clone_of != node->symbol.decl

as those other cases are missing in the patch posted after looking at it.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

--- Comment #12 from Nicholas Krause  ---
Sorry about not reading the comment carefully.

I'm not if this helps but after looking at the change to this file:
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraph.c?r1=199577=199576=199577

n = cgraph_create_function_alias (alias, decl);

was never changed for creating with the new function arguments as found here:
struct cgraph_node *
cgraph_create_function_alias (tree alias, tree target)

and therefore it should be:

n = cgraph_create_function_alias (alias, target);

and not decl.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

--- Comment #9 from Nicholas Krause  ---
Sorry source code is:
void foo () {}
#pragma weak foo = _foo
int _foo = 0;

Copy and Pasted line numbers by mistake.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

--- Comment #8 from Nicholas Krause  ---
(In reply to Jakub Jelinek from comment #7)
> This does happen even with 9.2 and current trunk, you just need to read the
> first line in #c0.

While I ran it as on a Ubuntu 9.2 Toolchain configured as:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-gcc -c test.c-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) 

like this:
gcc -c test.c

and this is my source code:
void foo () {}
  2 #pragma weak foo = _foo
  3 int _foo = 0;

and I get this:
test.c:1:6: error: ‘foo’ defined both normally and as ‘alias’ attribute
1 | void foo () {}
  |  ^~~
test.c:1:6: error: ‘foo’ alias between function and variable is not supported
test.c:3:5: note: aliased declaration here
3 | int _foo = 0;
  | ^~~~
test.c:1: confused by earlier errors, bailing out

So no it does not appear to segfault on 9.2 not sure about trunk.

[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #6 from Nicholas Krause  ---
Does not happen on gcc 9.2. Does the gcc 8.5 branch have these functions,  
 cgraph_function_or_thunk_node or varpool_variable_node as those were removed
on trunk and I'm suspecting that's were the problem is.

[Bug c++/94008] "use of deleted function" error when using "std::unique_ptr", std::move() and lambda

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
I tried compiling this on both clang trunk and gcc trunk on godbolt. Your
problem seems to be this:
test_lambda([test_uniq = std::move(test_uniq)] {
  test_lambda([test_uniq = std::move(test_uniq)] {});
})

Your passing into std::move and then again. That's incorrect as your moving and
moving again into the test_lamba. I tried with:

test_lambda([test_uniq = test_uniq.get()]() mutable {
  test_lambda([test_uniq = std::move(test_uniq)] {});
});

And this does not miscompile due to test uniq getting the actual reference
rather than the r value and going back into another r value reference. This
therefore is not a bug.

[Bug middle-end/93518] missing warning on a possible overflow by sprintf %s with an allocated argument

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Hi Martin,

I'm not sure if my analysis is correct but it seems that:
int idx = get_stridx (src);

is only for string lengths and not POINTER_TYPE_P. There
are versions for ADDR expressions but don't seem to be
any for POINTER_TYPE_P. I'm wondering if we can implement
around version of stridx for this as it seems that the
line mentioned would need to call one for POINTER_P types
to fix the issue. Not sure how trivial it would be implement
that.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #9 from Nicholas Krause  ---
Peter and Jakub,

Sorry if I'm misunderstanding the power code but is there a way to rewrite the
test to:
if (VECTOR_MEM_ALTIVEC(mode)
and another branch for VSX_P instructions.

I'm assuming that because its checking both we can get a infinite loop. I'm
assuming that in order to hand this off to the LRA we will need to
rewrite in to have two paths one for VSX_P and one for standard MEM_ALTIVEC. 

Maybe Vlad as mentioned has a better idea about the LRA issues. But I'm very
suspicious of checking both VSX and non VSX_P instructions in the same way for
legitimate_address_p.

Maybe I'm misunderstanding the issue outside of backporting,

[Bug target/93605] GCC suboptimal tail call optimization in trivial function forwarding with __attribute__((noinline))

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #3 from Nicholas Krause  ---
I just tried with bool& as auto should just be a bool without a reference.
Seems to be a issue with gcc assuming that it must move into the bool if not a
ref in the function's signature. And it works for other targets as Andrew
pointed out.

[Bug c++/91529] [8/9/10 Regression] -fmerge-all-constants leads to corrupt output without inlining

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
I was unable to find the proper marcos to fix the issue for this patch in the
manual. However these lines:
-  /* FIXME P0135 doesn't say how to handle direct initialization from a
-type with a suitable conversion operator.  Let's handle it like
-copy-initialization, but allowing explict conversions.  */
-  tsubst_flags_t sub_complain = tf_warning;
-  if (!is_dummy_object (instance))
-   /* If we're using this to initialize a non-temporary object, don't
-  require the destructor to be accessible.  */
-   sub_complain |= tf_no_cleanup;
   if (BRACE_ENCLOSED_INITIALIZER_P (arg)
- && !CONSTRUCTOR_IS_DIRECT_INIT (arg))
-   /* An init-list arg needs to convert to the parm type (83937), so fall
-  through to normal processing.  */
-   arg = error_mark_node;
-  else if (!reference_related_p (class_type, TREE_TYPE (arg)))
-   arg = perform_implicit_conversion_flags (class_type, arg,
-sub_complain,
-flags);
+ && !TYPE_HAS_LIST_CTOR (class_type)
+ && CONSTRUCTOR_NELTS (arg) == 1)
+   arg = CONSTRUCTOR_ELT (arg, 0)->value;
+

or the ones added with a + seem to be the issue. Why are we not checked for
initializing references in braces and not checked if its direct as those should
be done regularly for inlining in normal processing. Maybe I'm missing
something but this seems odd. A lot of the other parts of the patch just seems
to be rewrites so this seems most likely.

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

--- Comment #11 from Nicholas Krause  ---
(In reply to Jason Merrill from comment #10)
> I don't think this is a valid testcase: operator+= requires Concept, but
> checking Concept depends on operator+=.  It would be good for the compiler
> to detect this recursive dependency rather than recursing infinitely, of
> course.

I agree however I was going to test on clang but seems clang does not support
concepts yet so didn't know if it would crash on that too. Still a nullptr on
concepts expansion isn't good. Perhaps a better idea would be to warn about the
infinite expansion than my PARM_CONSTR patch posted previously.

[Bug tree-optimization/56457] Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-*

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from Nicholas Krause  ---
defs = DF_REF_CHAIN (use);  
if (!defs)  
{   
unsigned int regno = DF_REF_REGNO (use);

/* If this is the use of an uninitialized argument register that is 
likely to be spilled, do not move it lest this might extend its 
lifetime and cause reload to die.  This can occur for a call to 
a function taking complex number arguments and moving the insns 
preparing the arguments without moving the call itself wouldn't 
gain much in practice.  */  
if ((DF_REF_FLAGS (use) & DF_HARD_REG_LIVE) 
&& FUNCTION_ARG_REGNO_P (regno) 
&& targetm.class_likely_spilled_p (REGNO_REG_CLASS (regno)))
return false;   

return true;
}

This is the actual code and it seems to be used not in the if block below it
Eric. I haven't run a build for it on the current gcc sources but it seems to
be used currently. As for memory I don't recall it happening during my latest
gcc builds on the upstream sources.

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

--- Comment #8 from Nicholas Krause  ---
Created attachment 46334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46334=edit
Proposed Proper Bug Fix

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

--- Comment #9 from Nicholas Krause  ---
(In reply to Nicholas Krause from comment #8)
> Created attachment 46334 [details]
> Proposed Proper Bug Fix

This is the proper bug fix after tracing it seems and looking at other callers
in that file. I tried pinging on the list twice but didn't get any reply so I'm
attaching it here for people to merge if it's correct.

[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture

[xerofoify at gmail dot com]

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

--- Comment #4 from Nicholas Krause  ---
(In reply to Nicholas Krause from comment #3)
> (In reply to Arsène Pérard-Gayot from comment #2)
> > (In reply to Nicholas Krause from comment #1)
> > > I just compiled this like so:
> > > ./bin/g++ test.cpp -fopenmp -Wall -fconcepts -o name test2.cpp 
> > > and got this on a build from yesterday:
> > > 
> > > g++: internal compiler error: Segmentation fault signal terminated program
> > > cc1plus
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See  for instructions.
> > > 
> > > This code is linked to another version of this
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 as it crashes before 
> > > your
> > > warning issue. I posted to
> > > the list here about a possible fix yesterday for it:
> > > 
> > > https://gcc.gnu.org/ml/gcc/2019-03/msg00185.html
> > 
> > Could you please explain the connection with this bug? From what I see, what
> > you are reporting here is unrelated to the warning issue, and the
> > segmentation fault only occurs because of your use of the "-fconcepts" flag.
> > Please correct me if I am wrong.
> 
> Yes that's correct. However the problem is that it needs to compile and you
> would get this:
> test.cpp:2:5: error: ‘concept’ does not name a type
> 2 | concept bool Concept2 = requires (T t, U u)
>   | ^~~
> test.cpp:2:5: note: ‘concept’ only available with ‘-fconcepts’
> test.cpp:8:5: error: ‘concept’ does not name a type
> 8 | concept bool Concept = Concept2 ;
>   | ^~~
> test.cpp:8:5: note: ‘concept’ only available with ‘-fconcepts’
> test.cpp:12:19: error: ‘Concept’ has not been declared
>12 | template 
>   |   ^~~
> test.cpp:13:35: error: ‘T’ was not declared in this scope
>13 | constexpr S& operator += (T o);
>   |   ^
> test.cpp:13:38: error: declaration of ‘operator+=’ as non-function
>13 | constexpr S& operator += (T o);
>   |  ^
> test.cpp: In function ‘constexpr S operator*(S, S)’:
> test.cpp:17:18: error: no match for ‘operator+=’ (operand types are ‘S’ and
> ‘S’)
>17 | return a += b;
>   |~~^~~~
> test2.cpp: In member function ‘void S::test(size_t&)’:
> test2.cpp:21:21: warning: value computed is not used [-Wunused-value]
>21 | #pragma omp atomic capture
>   | ^~~
> Therefore it must be build must and that bug fixed first before we take on
> this bug unless you can send me a example without concepts required and just
> openmp code.

Sorry I was compiling a incorrect program your code is fine and this is now
confirmed.

[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture

[xerofoify at gmail dot com]

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

--- Comment #3 from Nicholas Krause  ---
(In reply to Arsène Pérard-Gayot from comment #2)
> (In reply to Nicholas Krause from comment #1)
> > I just compiled this like so:
> > ./bin/g++ test.cpp -fopenmp -Wall -fconcepts -o name test2.cpp 
> > and got this on a build from yesterday:
> > 
> > g++: internal compiler error: Segmentation fault signal terminated program
> > cc1plus
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > 
> > This code is linked to another version of this
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 as it crashes before your
> > warning issue. I posted to
> > the list here about a possible fix yesterday for it:
> > 
> > https://gcc.gnu.org/ml/gcc/2019-03/msg00185.html
> 
> Could you please explain the connection with this bug? From what I see, what
> you are reporting here is unrelated to the warning issue, and the
> segmentation fault only occurs because of your use of the "-fconcepts" flag.
> Please correct me if I am wrong.

Yes that's correct. However the problem is that it needs to compile and you
would get this:
test.cpp:2:5: error: ‘concept’ does not name a type
2 | concept bool Concept2 = requires (T t, U u)
  | ^~~
test.cpp:2:5: note: ‘concept’ only available with ‘-fconcepts’
test.cpp:8:5: error: ‘concept’ does not name a type
8 | concept bool Concept = Concept2 ;
  | ^~~
test.cpp:8:5: note: ‘concept’ only available with ‘-fconcepts’
test.cpp:12:19: error: ‘Concept’ has not been declared
   12 | template 
  |   ^~~
test.cpp:13:35: error: ‘T’ was not declared in this scope
   13 | constexpr S& operator += (T o);
  |   ^
test.cpp:13:38: error: declaration of ‘operator+=’ as non-function
   13 | constexpr S& operator += (T o);
  |  ^
test.cpp: In function ‘constexpr S operator*(S, S)’:
test.cpp:17:18: error: no match for ‘operator+=’ (operand types are ‘S’ and
‘S’)
   17 | return a += b;
  |~~^~~~
test2.cpp: In member function ‘void S::test(size_t&)’:
test2.cpp:21:21: warning: value computed is not used [-Wunused-value]
   21 | #pragma omp atomic capture
  | ^~~
Therefore it must be build must and that bug fixed first before we take on this
bug unless you can send me a example without concepts required and just openmp
code.

[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
I just compiled this like so:
./bin/g++ test.cpp -fopenmp -Wall -fconcepts -o name test2.cpp 
and got this on a build from yesterday:

g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

This code is linked to another version of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 as it crashes before your
warning issue. I posted to
the list here about a possible fix yesterday for it:

https://gcc.gnu.org/ml/gcc/2019-03/msg00185.html

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

--- Comment #7 from Nicholas Krause  ---
(In reply to Nicholas Krause from comment #6)
> Created attachment 45242 [details]
> Proposed Bug Fix

This is my proposed fix after tracing it and reading it carefully seems that
passing the NULL_TREE in rather than the correct decl tree of concepts is
causing the bug. If this is correct I will just run the gcc test suite and post
to the list.

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

--- Comment #6 from Nicholas Krause  ---
Created attachment 45242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45242=edit
Proposed Bug Fix

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

--- Comment #3 from Nicholas Krause  ---
(In reply to Emmanuel Le Trong from comment #2)
> (In reply to Nicholas Krause from comment #1)
> > First off that's just a valid snippet without a class definition so I was
> > unable to build it against gcc itself to even check this is a bug. Further
> > more can you check this is still happening and if so just report back with
> > the exact code that builds but is giving you a segfault on the trunk branch.
> 
> I'm sorry I don't understand your requests. The compilation of this small
> piece of code causes the compiler (trunk 20181213) to crash, without further
> information.

test.cpp:2:5: error: ‘concept’ does not name a type; did you mean ‘constexpr’?
 concept bool Concept2 = requires (T t, U u)
 ^~~
 constexpr
test.cpp:2:5: note: ‘concept’ only available with -fconcepts
test.cpp:8:5: error: ‘concept’ does not name a type; did you mean ‘constexpr’?
 concept bool Concept = Concept2 ;
 ^~~
 constexpr
test.cpp:8:5: note: ‘concept’ only available with -fconcepts
test.cpp:12:19: error: ‘Concept’ has not been declared
 template 
   ^~~
test.cpp:13:35: error: ‘T’ was not declared in this scope
 constexpr S& operator += (T o);
   ^
test.cpp:13:38: error: declaration of ‘operator+=’ as non-function
 constexpr S& operator += (T o);
  ^
test.cpp: In function ‘constexpr S operator*(S, S)’:
test.cpp:17:18: error: no match for ‘operator+=’ (operand types are ‘S’ and
‘S’)
 return a += b;

Is what I am getting because I don't have the class definition. I would like
all of the code so that it builds properly and can check against a compiling
working program.

[Bug c++/88395] ICE: Segmentation fault signal terminated program cc1plus, with -std=c++2a -fconcepts

[xerofoify at gmail dot com]

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

nik  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from nik  ---
(In reply to Emmanuel Le Trong from comment #0)
> Both trunk and 8.2.1 segfault on this valid snippet
> 
> $ cat bug_4.cpp
> template 
> concept bool Concept2 = requires (T t, U u)
> {
> { t += u } -> T&;
> };
> 
> template 
> concept bool Concept = Concept2 ;
> 
> struct S
> {
> template 
> constexpr S& operator += (T o);
> };
> constexpr S operator * (S a, S b)
> {
> return a += b;
> }
> 
> 
> 
> $ g++-9 -std=c++2a -fconcepts -c bug_4.cpp
> g++-9: internal compiler error: Segmentation fault signal terminated program
> cc1plus
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <https://gcc.gnu.org/bugs/> for instructions.
> 
> $ g++-9 -v
> Using built-in specs.
> COLLECT_GCC=g++-9
> COLLECT_LTO_WRAPPER=/home/manu/system/opt/gcc-9/libexec/gcc/x86_64-pc-linux-
> gnu/9.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-9/configure --prefix=/home/manu/system/opt/gcc-9
> --program-suffix=-9
> Thread model: posix
> gcc version 9.0.0 20181204 (experimental) (GCC)

First off that's just a valid snippet without a class definition so I was
unable to build it against gcc itself to even check this is a bug. Further more
can you check this is still happening and if so just report back with the exact
code that builds but is giving you a segfault on the trunk branch.

[Bug translation/80188] calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

[xerofoify at gmail dot com]

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

--- Comment #5 from nik  ---
On 2018-01-17 02:15 AM, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
> 
> --- Comment #4 from Eric Gallager  ---
> (In reply to nik from comment #3)
>> Created attachment 42372 [details]
>> Proposed Fix Send to the GCC-Patches List
> 
> Link to the mailing list archives showing where/when this was sent to
> gcc-patches?
> 
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00420.html

Is a link to the email if you want one.

Sorry for the late follow up,

Nick

[Bug translation/80188] calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

[xerofoify at gmail dot com]

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

--- Comment #3 from nik  ---
Created attachment 42372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42372=edit
Proposed Fix Send to the GCC-Patches List

[Bug translation/80188] calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

[xerofoify at gmail dot com]

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

nik  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from nik  ---
I am working on this but the tester was breaking for me.

[Bug c++/82230] [8 Regression] ICE: in tsubst, at cp/pt.c:13686 when binding lambda to variable inside a generic lambda inside a template member function inside a template class

[xerofoify at gmail dot com]

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

nik  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #4 from nik  ---
I have new to the project but after looking at the code in semantics.c that was
changed by that commit pointed out. It seems that a else above this if
statement was removed:

if (containing_function && DECL_TEMPLATE_INFO (context)
&& LAMBDA_FUNCTION_P (containing_function))

which in term means that:
containing_function = NULL_TREE;

is a NULL_TREE I assume that means it points to a nullptr or null pointer.
Therefore we may be passing in a null tree to an incorrect branch due to the
missing else. Seems it your trace, semantics.c is being called so it may be
this. Anybody have any comments?