[Bug inline-asm/94113] Apparently incorrect register allocation in inline asm when using CMOV.

[contact at pgazz dot com]

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

--- Comment #4 from Paul  ---
That worked.  Thank you for the explanation!

[Bug inline-asm/31386] wrong registers used in cmov instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Invalid as mentioned, you need the early clobbers, otherwise GCC thinks the
output and input registers can be the same.  In this case the output registers
which is held in operand 0 has to be different from operands 4 and 5.

[Bug inline-asm/94113] Apparently incorrect register allocation in inline asm when using CMOV.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
You need an early clobber:
  __asm__ volatile("movl %3, %0;\n\t" \
   "cmpl $0, %1;\n\t" \
   "cmovne %2, %0;\n\t" \
   : "="(final_result) \
   : "r"(cond), "r"(if_true), "r"(if_false) \
   : "cc" \
   );

Otherwise GCC thinks 0th operand and the second operand can be in the same
register.  With the early clobber it basically says the 0th operand cannot be
the same register as the other ones.

[Bug tree-optimization/94114] New: [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5936

[asolokha at gmx dot com]

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

Bug ID: 94114
   Summary: [10 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5936
   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: ---

gcc-10.0.1-alpha20200301 snapshot (g:151bf47e78f5d919f6cc591d11cc1f6aff61078f)
ICEs when compiling the following testcase w/ -O2 -ftrapv:

void
tt (int *ga, int *p6, int *s7, long int ut)
{
  while (p6 + ut > s7)
{
  ga[ut] = 0;
  --ut;
}
}

% gcc-10.0.1 -O2 -ftrapv -c eipsxtfv.c
during GIMPLE pass: ldist
eipsxtfv.c: In function 'tt':
eipsxtfv.c:6:14: internal compiler error: in gimplify_modify_expr, at
gimplify.c:5936
6 |   ga[ut] = 0;
  |   ~~~^~~
0x64695a gimplify_modify_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:5936
0xad681a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:13602
0xad9f96 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:6823
0xaec9ed gimplify_cond_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:4240
0xad6d22 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:13559
0xad9f96 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:6823
0xaec6d6 gimplify_cond_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:4137
0xad6d22 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:13559
0xad6648 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:14369
0xad6cce gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify.c:14309
0xaf09d0 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify-me.c:78
0xaf0b1d force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify-me.c:115
0xaf0b1d force_gimple_operand_gsi(gimple_stmt_iterator*, tree_node*, bool,
tree_node*, bool, gsi_iterator_update)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/gimplify-me.c:141
0xe2b216 generate_memset_builtin
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/tree-loop-distribution.c:1155
0xe2b216 generate_code_for_partition
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/tree-loop-distribution.c:1329
0xe2b216 loop_distribution::distribute_loop(loop*, vec, control_dependences*, int*, bool*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/tree-loop-distribution.c:3105
0xe2cad3 loop_distribution::execute(function*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/tree-loop-distribution.c:3294
0xe2cffb execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/tree-loop-distribution.c:3382

[Bug inline-asm/94113] Apparently incorrect register allocation in inline asm when using CMOV.

[contact at pgazz dot com]

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

--- Comment #2 from Paul  ---
Created attachment 48003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48003=edit
The assembly output.

[Bug inline-asm/94113] Apparently incorrect register allocation in inline asm when using CMOV.

[contact at pgazz dot com]

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

--- Comment #1 from Paul  ---
Created attachment 48002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48002=edit
The original C file.

[Bug inline-asm/94113] New: Apparently incorrect register allocation in inline asm when using CMOV.

[contact at pgazz dot com]

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

Bug ID: 94113
   Summary: Apparently incorrect register allocation in inline asm
when using CMOV.
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: contact at pgazz dot com
  Target Milestone: ---

Created attachment 48001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48001=edit
The preprocessed C file

Version: gcc (Debian 9.2.1-21) 9.2.1 20191130
System type: Debian GNU/Linux bullseye/sid
Options and complete command-line: gcc -Wall -Wextra -o broken broken.i
Compiler output: no errors or warnings
Preprocessed file: broken.i

The included example (broken.c) illustrates what appears to be a bug in inline
assembly when using the CMOV instruction.  Two different C variables are
allocated the same register, causing incorrect behavior.

  __asm__ volatile("movl %3, %0;\n\t" \
   "cmpl $0, %1;\n\t" \
   "cmovne %2, %0;\n\t" \
   : "=r"(final_result) \
   : "r"(cond), "r"(if_true), "r"(if_false) \
   : "cc" \
   );

The inline assembly uses CMOV to assign final_result to either if_true or
if_false depending on the cond variable, which is read in from the first
command-line argument and converted via atoi.

I was expecting the behavior to be equivalent to testing the value of cond,
then assigning final_result to either if_true or if_false depending on whether
cond is non-zero or zero respectively.  But instead, it always assigns it to
if_true.  Looking at the compiler output in broken.s, the eax register seems to
be allocated to both cond and to final_result.  In the first line of the inline
assembly movl %ecx, %eax; it looks like final_result is eax.  But in the next
line cmpl $0, %eax; it looks like eax is allocated to cond, which has already
been overwritten by the value of if_false in the previous line.

movl$0, -16(%rbp)   # final_result
# ...
movl%eax, -12(%rbp) # cond, after atoi
movl$333, -8(%rbp)  # if_true
movl$444, -4(%rbp)  # if_false
movl-12(%rbp), %eax # cond -> eax
movl-8(%rbp), %edx  # if_true -> edx
movl-4(%rbp), %ecx  # if_false -> ecx
#APP
# 17 "broken.c" 1
movl %ecx, %eax;# move if_false to eax, which 
cmpl $0, %eax;  # should be comparing to the value of cond, not
if_false
cmovne %edx, %eax;  # conditional move if_true to final_result, but
condition (not equal) is always true

# 0 "" 2
#NO_APP
movl%eax, -16(%rbp) # eax -> final_result

Is the register allocator somehow assuming that the write-only modifier =r
means the value is only written at the end of the inline assembly?

I could circumvent it by explicitly using another register (esi) and adding an
extra MOV from that register as shown below.

  __asm__ volatile("movl %3, %%esi;\n\t" \
   "cmpl $0, %1;\n\t" \
   "cmovne %2, %%esi;\n\t" \
   "movl %%esi, %0;\n\t" \
   : "=r"(final_result) \
   : "r"(cond), "r"(if_true), "r"(if_false) \
   : "cc", "esi" \
   );

A somewhat similar-looking bug was reported almost 13 years ago, but that
particular bug does not seem to happen anymore:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31386

When compiling with optimizations, the bug still exists when running with
./broken 1, which just turns the cond variable to true.

[Bug c++/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Despite fixing at least one bug it looks like the patch for PR92721 didn't
actually eliminate the underlying problem.  The comment above the internal
error suggests that changing the type attributes of a function when applying
attributes to its declaration might need additional changes to "the canonical
type propagation code."  At this point I have no idea wherever that might need
to happen.

/* The two types are structurally equivalent, but their
   canonical types were different. This is a failure of the
   canonical type propagation code.*/
internal_error 
  ("canonical types differ for identical types %qT and %qT",
   t1, t2);

[Bug c++/94112] New: Please add a warning for potentially throwing code in noexcept function

[rafael at espindo dot la]

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

Bug ID: 94112
   Summary: Please add a warning for potentially throwing code in
noexcept function
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

GCC produces a warning for

void foo() noexcept {
throw 42;
}

But not for

static void bar() {
throw 42;
}
void foo() noexcept {
bar();
}

Such a warning would be quite handy for checking the usage of noexcept in a
codebase.

[Bug c++/93870] [8/9/10 Regression] User-defined conversion function not working in evaluation of template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create _EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create _EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/92031] [9 Regression] Incorrect "taking address of r-value" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10 Regression] Incorrect |[9 Regression] Incorrect
   |"taking address of r-value" |"taking address of r-value"
   |error   |error

--- Comment #2 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create _EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create _EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/91465] [9 Regression] unexpected expression of kind overload (ICE)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10 Regression]   |[9 Regression] unexpected
   |unexpected expression of|expression of kind overload
   |kind overload  (ICE)| (ICE)

--- Comment #9 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create _EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create _EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug c++/94068] [9 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[9/10 Regression] Internal  |[9 Regression] Internal
   |compiler error when trying  |compiler error when trying
   |to resolve function |to resolve function
   |overload since r9-2384  |overload since r9-2384

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 10.  I'm undecided about backporting this, but we have other PRs
about this anyway (listed in the commit message).

[Bug c++/94068] [9/10 Regression] Internal compiler error when trying to resolve function overload since r9-2384

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
commit d417b4f5414d9076300ab41974a14424f722688c
Author: Marek Polacek 
Date:   Fri Feb 28 16:57:04 2020 -0500

c++: Fix convert_like in template [PR91465, PR93870, PR92031, PR94068]

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create _EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper::operator E(~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create _EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  

PR c++/92031 - bogus taking address of rvalue error.
PR c++/91465 - ICE with template codes in check_narrowing.
PR c++/93870 - wrong error when converting template non-type arg.
PR c++/94068 - ICE with template codes in check_narrowing.
* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
in a template when not ck_identity and we're dealing with a class.
(convert_like_real) : Return IMPLICIT_CONV_EXPR
in a template if we need a temporary.
* decl.c (compute_array_index_type_loc): Remove
instantiate_non_dependent_expr_sfinae call.  Call
fold_non_dependent_expr instead of maybe_constant_value.
(build_explicit_specifier): Don't instantiate or create a sentinel
before converting the expression.
* except.c (build_noexcept_spec): Likewise.
* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
build_converted_constant_expr returned.
* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
of maybe_constant_value.

* g++.dg/cpp0x/conv-tmpl2.C: New test.
* g++.dg/cpp0x/conv-tmpl3.C: New test.
* g++.dg/cpp0x/conv-tmpl4.C: New test.
* g++.dg/cpp0x/conv-tmpl5.C: New test.
* g++.dg/cpp0x/conv-tmpl6.C: New test.
* g++.dg/cpp1z/conv-tmpl1.C: New test.

[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #5 from Alexander Cherepanov  ---
I thought that memcpy ignored after the assignment here but the problem remain
even after replacing `y = x;` with `-x;`. After fre1 we get a normalized value:

  MEM <__int128 unsigned> [(char * {ref-all})] = 0x18000;

So this is an exact dup of pr94103.

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

[Bug middle-end/94103] Wrong optimization: reading value of a variable changes its representation for optimizer

[ch3root at openwall dot com]

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

--- Comment #3 from Alexander Cherepanov  ---
*** Bug 92824 has been marked as a duplicate of this bug. ***

Will lost comments be restored?

[Stephen Casner]

The bug 94085 that I reported at 2020-03-07 06:26 appears to be one of
a half dozen that lost their comments due to the server move.  I've
been standing by as instructed, but I wonder when or if corrections
will happen.  Will these comments be restored, or should I reconstruct
them?

Also, I created my gcc bugzilla account just before reporting the bug,
so it may be in limbo as well.  I saw that my name as the reporter of
bug 94085 has been replaced by Carlos O'Ryan.  Also, my login attempt
fails and when I try to do the password reset I do not receive the
reset email.  Do I need to create a new account?

A few years ago I created a Sourceware bugzilla account to report a
bug in binutils.  Are these being merged?

Stephen Casner
cas...@acm.org

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #42 from Segher Boessenkool  ---
Okay, I see your dumps are 64-bit as well.  But mine are very different, huh.
Still, it crashes in pretty much the same way.

[Bug middle-end/94111] New: Wrong optimization: decimal floating-point infinity casted to double -> zero

[ch3root at openwall dot com]

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

Bug ID: 94111
   Summary: Wrong optimization: decimal floating-point infinity
casted to double -> zero
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Cast to double of a decimal floating-point infinity gives zero:

--
#include 
#include 
#include 

int main()
{
_Decimal32 d = (_Decimal32)INFINITY;

unsigned u;
memcpy(, , sizeof u);
printf("repr: %08x\n", u);

printf("cast: %g\n", (double)d);
}
--
$ gcc -std=c2x -pedantic -Wall -Wextra test.c && ./a.out
repr: 7800
cast: inf
$ gcc -std=c2x -pedantic -Wall -Wextra -O3 test.c && ./a.out
repr: 7800
cast: 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200305 (experimental)
--

The representation is right for infinity in _Decimal32.

[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
commit r10-7094-g81fa6d7321dd9b645d86de4a8a6967c603f176e3
Author: Jakub Jelinek 
Date:   Mon Mar 9 21:52:18 2020 +0100

c++: Readd [LR]ROTATE_EXPR support to constexpr.c [PR94067]

Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c

2020-03-09  Jakub Jelinek  

PR c++/94067
Revert
2019-10-11  Paolo Carlini  

* constexpr.c (cxx_eval_constant_expression): Do not handle
RROTATE_EXPR and LROTATE_EXPR.

* g++.dg/warn/Wconversion-pr94067.C: New test.

[Bug c++/94074] bogus modifying a const object error with const COMPONENT_REF

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
And this should be diagnosed but isn't:

struct X {
  int i;
};

template 
struct S {
  const X x;
  constexpr S(int) : x{}
  {
const_cast(x).i = 19; // { dg-error "modifying a const object" }
  }
};

constexpr S p = { 10 }; // { dg-message "originally declared" }

[Bug fortran/94110] New: Erroneous code compiling

[jrfsousa at gmail dot com]

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

Bug ID: 94110
   Summary: Erroneous code compiling
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 48000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48000=edit
Code demonstrating problems.

Hi all!

I am pretty sure this code is erroneous both because you can not pass an
assumed-size to an assumed-shape and because of pointer association rules.

Compiles without any warnings even using -pedantic -Wall -Wextra and others in
both:

GNU Fortran (GCC) 9.2.1 20200307

and

GNU Fortran (GCC) 10.0.1 20200307 (experimental)

Thank you very much.

Best regards,
José Rui

[Bug fortran/94109] New: Memory leak introduced in 8.3.0->8.3.1

[antony at cosmologist dot info]

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

Bug ID: 94109
   Summary: Memory leak introduced in 8.3.0->8.3.1
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antony at cosmologist dot info
  Target Milestone: ---

I see an apparent memory leak introduced in running code between

ubuntu-toolchain-r/test gfortran 8.3.0 OK

Source 20200106 build gfortran 8.3.1 bad (also current 8 and 10 git heads).

I have not tracked down where it is coming from, but there is a complete
example on git with travis reports:

8.3.1 issue
https://travis-ci.org/cmbant/CAMB/jobs/660297689

GCC 9 9.2.1 20191102 issue (with otherwise same config as 8.3.0 below)
https://travis-ci.org/cmbant/CAMB/jobs/660297688

8.3.0 OK
https://travis-ci.org/cmbant/CAMB/jobs/660297687

(see memory counts at bottom of trace as function of loop count, produced from
python).

To produce output locally do
git clone --branch test https://github.com/cmbant/CAMB.git

and run setup.py and then setup.py test (with py3.6+).

I'm hoping this narrowish version window will enable someone to guess at the
cause of the issue. I looked at this because someone reported a large memory
leak on gfortran 9.2 OS X that cannot be reproduced with ifort, or gfortran
versions 6-8.3.0 (on linux the leak seems much smaller).

The code uses multiple nested allocatable F2003 class types.

[Bug other/94108] New: transaction memory attributes not documented

[msebor at gcc dot gnu.org]

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

Bug ID: 94108
   Summary: transaction memory attributes not documented
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC exposes a number of attributes for transactional memory (see below) but the
documentation doesn't mention any of them.

The list of attributes from c-family/c-attribs.c:

  { "transaction_callable",   0, 0, false, true,  false, false,
  handle_tm_attribute, NULL },
  { "transaction_unsafe", 0, 0, false, true,  false, true,
  handle_tm_attribute, NULL },
  { "transaction_safe",   0, 0, false, true,  false, true,
  handle_tm_attribute, NULL },
  { "transaction_safe_dynamic", 0, 0, true, false,  false, false,
  handle_tm_attribute, NULL },
  { "transaction_may_cancel_outer", 0, 0, false, true, false, false,
  handle_tm_attribute, NULL },
  /* ??? These two attributes didn't make the transition from the
 Intel language document to the multi-vendor language document.  */
  { "transaction_pure",   0, 0, false, true,  false, false,
  handle_tm_attribute, NULL },
  { "transaction_wrap",   1, 1, true,  false,  false, false,
 handle_tm_wrap_attribute, NULL },

[Bug c/94106] [8/9/10 Regression] error on a function redeclaration with attribute transaction_safe

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|error on a function |[8/9/10 Regression] error
   |redeclaration with  |on a function redeclaration
   |attribute transaction_safe  |with attribute
   ||transaction_safe
   Keywords||rejects-valid

--- Comment #1 from Martin Sebor  ---
Bisection points to r228462 as the first revision to reject the code:

commit b8fd7909c04a29e82fb3ebace161801f949ad4f5
Author: Jason Merrill 
Date:   Sun Oct 4 15:17:19 2015 -0400

Implement N4514, C++ Extensions for Transactional Memory.

gcc/
* builtins.def (BUILT_IN_ABORT): Add transaction_pure attribute.
gcc/c-family/
* c-common.c (c_common_reswords): Add C++ TM TS keywords.
(c_common_attribute_table): Add transaction_safe_dynamic.
transaction_safe now affects type identity.
(handle_tm_attribute): Handle transaction_safe_dynamic.
* c-common.h (enum rid): Add RID_ATOMIC_NOEXCEPT,
RID_ATOMIC_CANCEL, RID_SYNCHRONIZED.
(OBJC_IS_CXX_KEYWORD): Add RID_SYNCHRONIZED.
(D_TRANSMEM): New.

[Bug c++/94107] New: Infinite loop with malformed requires-expression inside a static_assert

[ppalka at gcc dot gnu.org]

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

Bug ID: 94107
   Summary: Infinite loop with malformed requires-expression
inside a static_assert
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat loop.C
static_assert(requires { );
$ g++ -std=c++2a loop.C
loop.C:1:26: error: expected primary-expression before ‘)’ token
1 | static_assert(requires { );
  |  ^
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
  |   ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
  |   ~^
  |;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
  |   ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
  |   ~^
  |;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
  |   ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
  |   ~^
  |;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
  |   ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
  |   ~^
  |;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
  |   ^
...

[Bug c/94106] New: error on a function redeclaration with attribute transaction_safe

[msebor at gcc dot gnu.org]

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

Bug ID: 94106
   Summary: error on a function redeclaration with attribute
transaction_safe
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Of the six declarations below each is accepted on its own.  The latter two
redeclarations are accepted as well, but the first redeclaration is rejected
with an error.  I can't find documentation of the attributes in the manual so
it's not entirely clear to me whether the error is a bug or whether its absence
on the other two redeclarations is a bug, or whether this works as intended,
but intuitively I would expect all three to accepted as happens with other
attributes.

$ cat z.c && gcc -Wall -Wextra -S -Wall z.c
   void f0 (void);
__attribute__ ((transaction_safe)) void f0 (void);   // (bogus?) error

 void f1 (void);
__attribute__ ((transaction_unsafe)) void f1 (void); // accepted

   void f2 (void);
__attribute__ ((transaction_callable)) void f2 (void);   // accepted

z.c:2:41: error: conflicting types for ‘f0’
2 | __attribute__ ((transaction_safe)) void f0 (void);   // (bogus?)
error
  | ^~
z.c:1:41: note: previous declaration of ‘f0’ was here
1 |void f0 (void);
  | ^~

[Bug analyzer/94105] New: ICE in get_region, at analyzer/region-model.h:1744

[asolokha at gmx dot com]

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

Bug ID: 94105
   Summary: ICE in get_region, at analyzer/region-model.h:1744
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.1-alpha20200308 snapshot (g:9de42a8e995451cb13dceb3970ae23ff88240bff)
ICEs when compiling gcc/testsuite/c-c++-common/torture/pr58794-1.c w/
-fanalyzer:

% gcc-10.0.1 -fanalyzer -c gcc/testsuite/c-c++-common/torture/pr58794-1.c
during IPA pass: analyzer
gcc/testsuite/c-c++-common/torture/pr58794-1.c: In function 'main':
gcc/testsuite/c-c++-common/torture/pr58794-1.c:27:16: internal compiler error:
in get_region, at analyzer/region-model.h:1744
   27 |   *c[b.g.f1.f][d + 1] = 0;
  |  ~~^~
0x71dc62 ana::frame_region*
ana::region_model::get_region(ana::region_id) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.h:1744
0x71ed45 ana::array_region*
ana::region_model::get_region(ana::region_id) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4860
0x71ed45 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4752
0x110e973 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4899
0x110fffc ana::region_model::get_rvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4965
0x11100d3 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4979
0x10f1ff0 ana::impl_sm_context::warn_for_state(ana::supernode const*, gimple
const*, tree_node*, unsigned int, ana::pending_diagnostic*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:278
0x111ed2a on_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/sm-malloc.cc:737
0x10ee396 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:1086
0x10eebf1 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:2516
0x10ef0da ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:2334
0x10ef809 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:3785
0x10f028c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:3842
0x10e50e8 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/analyzer-pass.cc:84

[Bug fortran/94104] New: Request for diagnostic improvement

[jrfsousa at gmail dot com]

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

Bug ID: 94104
   Summary: Request for diagnostic improvement
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 47999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47999=edit
Code demonstrating problems.

Hi all!

Minor nitpick, the attached program raises an error:

$ gfortran ./diag.f90
./diag.f90:10:16:

   10 |   print *, sumf(a)
  |1
Error: Actual argument for ‘a’ must be a pointer at (1)

in both:

GNU Fortran (GCC) 9.2.1 20200307

and

GNU Fortran (GCC) 10.0.1 20200307 (experimental)

The diagnostic is a bit misleading as the variable can be pointer or target.

Thank you very much.

Best regards,
José Rui

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #41 from Martin Liška  ---
Ok, the way how we build our compiler is to use:
./configure --with-cpu=default32

that should also lead to the ICE. I'm checking that.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #40 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #36)
> > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > > but that builds stage2 as 64-bit?
> > 
> > Hm, that's possible. But the stage2 should not crash right?
> 
> It doesn't work, of course (mixed 32-bit and 64-bit thing).
> 
> And I need a 32-bit stage2 in any case, to have a compiler that miscompiles
> pt.c:tsubst_template_arg, to figure out why it thinks it as allowed to use
> GPR0 somewhere it obviously is live.

Ok, I've just run the build on gcc110 machine and you take a look at
/tmp/build.log. You are right that, using CC="gcc -m32" will cause that stage1
compiler is a cross from powerpc to powerpc64.
The miscompiled compiler is stage2:

$ file ./xgcc
./xgcc: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped

and it ICEs on a simple test-case:

$ ./xgcc -B. /tmp/reduced.ii
/tmp/reduced.ii: In substitution of ‘template, class> struct
__enable_if [with bool  = true;  = _Tp]’:
/tmp/reduced.ii:5:24:   required from here
/tmp/reduced.ii:5:24: internal compiler error: Segmentation fault
5 | struct __enable_if
  |^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cat /tmp/reduced.ii
  template
  struct __enable_if
  { };
template
struct __enable_if
{ typedef _Tp __type; };

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #39 from Vladimir Makarov  ---
I've reverted the patch in trouble:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=5dc1390b41db5c1765e25fd21dad1a930a015aac

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #38 from Segher Boessenkool  ---
Then, how did you do that?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #37 from Segher Boessenkool  ---
Oh wait.  I am dumb I guess?  You did those dumps with a stage1 compiler?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #36 from Segher Boessenkool  ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
> 
> Hm, that's possible. But the stage2 should not crash right?

It doesn't work, of course (mixed 32-bit and 64-bit thing).

And I need a 32-bit stage2 in any case, to have a compiler that miscompiles
pt.c:tsubst_template_arg, to figure out why it thinks it as allowed to use
GPR0 somewhere it obviously is live.

[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The problem as I understand it is that
#1  0x00abeb95 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5686
#2  0x00987243 in build_over_call (cand=0x375c910, flags=35,
complain=3) at ../../gcc/cp/call.c:9020
#3  0x0098c640 in build_new_method_call_1 (instance=, fns=, 
args=0x0, conversion_path=, flags=35, fn_p=0x0,
complain=3) at ../../gcc/cp/call.c:10305
#4  0x0098cb2e in build_new_method_call (instance=, fns=, args=0x0, 
conversion_path=, flags=35, fn_p=0x0,
complain=3) at ../../gcc/cp/call.c:10380
#5  0x0098a256 in build_special_member_call (instance=, name=, 
args=0x0, binfo=, flags=35, complain=3) at
../../gcc/cp/call.c:9781
#6  0x00afa23c in build_dtor_call (exp=,
dtor_kind=sfk_complete_destructor, flags=35, complain=3)
at ../../gcc/cp/init.c:4786
#7  0x00afaaca in build_delete (loc=0, otype=, addr=, 
auto_delete=sfk_complete_destructor, flags=35, use_global_delete=0,
complain=3) at ../../gcc/cp/init.c:4979
#8  0x00a9e585 in cxx_maybe_build_cleanup (decl=, complain=3) at ../../gcc/cp/decl.c:17394
#9  0x00d130b8 in split_nonconstant_init_1 (dest=, init=, nested=false)
at ../../gcc/cp/typeck2.c:714
#10 0x00d1351a in split_nonconstant_init (dest=, init=) at
../../gcc/cp/typeck2.c:784
happens too late, after pending templates have been instantiated.
So, either mark_used or maybe_instantiate_decl needs to not defer if at_eof (or
at_eof == 2?), or perhaps better discover that split_nonconstant_init_1 will
need to call the descriptor earlier (dunno where exactly, cp_fold or
cp_genericize_r?).
I think the latter would be better, e.g. with OpenMP implicit declare target
discovery I was hoping one could hook somewhere into cgraph in between where
the FE already saw all functions and before first functions are gimplified, but
if gimplification can result in new functions to be instantiated, genericized
and later on gimplified and again and again, this wouldn't be possible.

[Bug middle-end/94103] Wrong optimization: reading value of a variable changes its representation for optimizer

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
long double has padding bits on x86_64 so that is not shocking there.

_Decimal3 is a different issue all together.

[Bug middle-end/94103] Wrong optimization: reading value of a variable changes its representation for optimizer

[ch3root at openwall dot com]

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

--- Comment #1 from Alexander Cherepanov  ---
Example with decimal floating-point:

--
#include 
#include 

int main()
{
_Decimal32 x = 999; // maximum significand
unsigned u;

memcpy(, , sizeof u);
printf("%#08x\n", u);

++*(unsigned char *) // create non-canonical representation of 0
(void)-x;

memcpy(, , sizeof u);
printf("%#08x\n", u);
}
--
$ gcc -std=c2x -pedantic -Wall -Wextra test.c && ./a.out
0x6cb8967f
0x6cb89680
$ gcc -std=c2x -pedantic -Wall -Wextra -O3 test.c && ./a.out
0x6cb8967f
0x3280
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200305 (experimental)
--

Unoptimized results are right, optimized -- wrong.

[Bug middle-end/94103] New: Wrong optimization: reading value of a variable changes its representation for optimizer

[ch3root at openwall dot com]

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

Bug ID: 94103
   Summary: Wrong optimization: reading value of a variable
changes its representation for optimizer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

It seems the optimizer sometimes computes the representation of variables from
its value instead of tracking it directly. This is wrong when the value admits
different representations.
(Given that the value is used, the representation should be valid (non-trap).)

Example with lost padding in x86-64 long double:

--
#include 
#include 

int main()
{
long double x;

// fill x including the padding
unsigned long u[2] = {0x, 0x};
memcpy(, , sizeof x);

// print the representation of x (initial)
memcpy(, , sizeof u);
printf("%016lX %016lX\n", u[1], u[0]);

// change the representation of x a bit
++*(unsigned char *)
(void)-x; // use the value of x but don't write it

// print the representation of x (resulting)
memcpy(, , sizeof u);
printf("%016lX %016lX\n", u[1], u[0]);
}
--
$ gcc -std=c2x -pedantic -Wall -Wextra test.c && ./a.out
 
 EEEF
$ gcc -std=c2x -pedantic -Wall -Wextra -O3 test.c && ./a.out
 
 EEEF
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200305 (experimental)
--

Zeros in the last output line are wrong.

[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Testcase modified to be usable in the testsuite:
// PR c++/93922
// { dg-do link { target c++11 } }

template 
struct A {
  A () {}
  template 
  A (A const &) {}
  ~A () {}
};
int t;
struct B {};
struct C : B { C (B const &) { if (t) throw 1; } };
struct S { A x; C y; };

A
bar (B *)
{
  return A ();
}

S *
foo (B *x, B const )
{
  return new S {bar (x), y};
}

int
main ()
{
}

[Bug target/91638] powerpc -mlong-double-NN (documentation) issues

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
 CC||wschmidt at gcc dot gnu.org

--- Comment #8 from Bill Schmidt  ---
Work is complete.

[Bug target/94095] Modifier 'a' do not work as described

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Fixed for GCC 10.  If someone else wants to backport the patch (it is trival),
I am ok with it.

[Bug target/91638] powerpc -mlong-double-NN (documentation) issues

[cel at us dot ibm.com]

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

Carl Love  changed:

   What|Removed |Added

 CC||cel at us dot ibm.com

--- Comment #7 from Carl Love  ---
Patch approved by Segher with a few minor fixes to the patch.

Patch committed to mainline

commit 9439378f7a08cf9c8f524c9f3758a37d804ac106
Author: Carl Love 
Date:   Thu Mar 5 12:52:35 2020 -0600

rs6000: Fix -mlong-double documentation

gcc/ChangeLog

2020-03-09  Carl Love  

* config/rs6000/rs6000.opt: Update the description of the
command line option.

[Bug tree-optimization/92879] [10 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The placement new is inlined at this point, the operator new that remains is
replaceable and because a is a global variable, its address needs to be
considered escaped.
While access to not yet fully constructed var from another TU might be
problematic, in what the restrict pass we actually don't know (unless we look
at abstract origin and prove there is no post-ctor code in between) it is a
ctor which would have such restrictions.

[Bug target/94095] Modifier 'a' do not work as described

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The problem is just 'a' in the first (Modifier) column is wrong, it should have
been 'A'.  I will commit the patch in a few minutes.  Operand column is correct
to use 'A'.

[Bug c++/94101] Variadic template deduction guide issue - error: 'In instantiation of'

[rosemberg at ymail dot com]

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

rosemberg at ymail dot com changed:

   What|Removed |Added

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

--- Comment #1 from rosemberg at ymail dot com ---
.

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

[Bug c++/94102] Variadic template deduction guide issue - error: 'In instantiation of'

[rosemberg at ymail dot com]

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

--- Comment #2 from rosemberg at ymail dot com ---
*** Bug 94101 has been marked as a duplicate of this bug. ***

[Bug c++/94102] Variadic template deduction guide issue - error: 'In instantiation of'

[rosemberg at ymail dot com]

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

--- Comment #1 from rosemberg at ymail dot com ---
The work around to solve it was to add the follow deduction guide:

template 
Merged (T0, T ...) 
   -> Merged, std::decay_t...>;

[Bug c++/94102] New: Variadic template deduction guide issue - error: 'In instantiation of'

[rosemberg at ymail dot com]

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

Bug ID: 94102
   Summary: Variadic template deduction guide issue - error: 'In
instantiation of'
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rosemberg at ymail dot com
  Target Milestone: ---

The gcc9.2 (I tested with gcc7) return the follow error due the deduction guide
declaration:

In instantiation of 'Merged::Merged(T&& ...) (with T = {const main()::&, const
main()::&, main()::}; B = {}]':

#include 

template
struct Merged : B ... {
   template
   Merged(T&& ... t) : B(std::forward(t))... {}

using B::operator()...;
};

template
Merged(T...) -> Merged...>;

int main() {
const auto l1 = []() { return 4; };
const auto l2 = [](const int i) { return i * 10; };

Merged merged(l1,
  l2,
  [](const double d) { return d * 3.2; });

return 0;
}

[Bug c++/94101] New: Variadic template deduction guide issue - error: 'In instantiation of'

[rosemberg at ymail dot com]

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

Bug ID: 94101
   Summary: Variadic template deduction guide issue - error: 'In
instantiation of'
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rosemberg at ymail dot com
  Target Milestone: ---

The gcc9.2 (I tested with gcc7) return the follow error due the deduction guide
declaration:

In instantiation of 'Merged::Merged(T&& ...) (with T = {const main()::&, const
main()::&, main()::}; B = {}]':

#include 

template
struct Merged : B ... {
   template
   Merged(T&& ... t) : B(std::forward(t))... {}

using B::operator()...;
};

template
Merged(T...) -> Merged...>;

int main() {
const auto l1 = []() { return 4; };
const auto l2 = [](const int i) { return i * 10; };

Merged merged(l1,
  l2,
  [](const double d) { return d * 3.2; });

return 0;
}

Just to clarify, the work around to solve it was to add the follow deduction
guide:

template 
Merged (T0, T ...) 
   -> Merged, std::decay_t...>;

[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592

[hstong at ca dot ibm.com]

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

--- Comment #7 from Hubert Tong  ---
(In reply to Jakub Jelinek from comment #6)
> The standard seems to say a union member becomes active when the constructor
> finishes, not when it starts, so what wording prevents changing the active
> member during the construction?

I do not believe there is such wording. Especially in the case presented, the
actual construction of the `a` member can be considered to occur while `y` is
the active member. The lack of such wording may well be unintentional.

[Bug target/93930] [8/9/10 Regression] Unnecessary broadcast instructions for AVX512

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The cost changes affect the RTL LIM.-Set in insn 22 is invariant (0), cost 32,
depends on 
-Set in insn 27 is invariant (1), cost 32, depends on 
-Set in insn 32 is invariant (2), cost 32, depends on 
-Set in insn 37 is invariant (3), cost 32, depends on 
-Set in insn 61 is invariant (4), cost 32, depends on 
-Set in insn 66 is invariant (5), cost 32, depends on 
-Set in insn 71 is invariant (6), cost 32, depends on 
-Set in insn 76 is invariant (7), cost 32, depends on 
-Set in insn 101 is invariant (8), cost 32, depends on 
-Set in insn 106 is invariant (9), cost 32, depends on 
-Set in insn 111 is invariant (10), cost 32, depends on 
-Set in insn 116 is invariant (11), cost 32, depends on 
-Decided to move invariant 0 -- gain 32
-Decided to move invariant 1 -- gain 32
-Decided to move invariant 2 -- gain 32
-Decided to move invariant 3 -- gain 32
-Decided to move invariant 4 -- gain 32
-Decided to move invariant 5 -- gain 32
-Decided to move invariant 6 -- gain 32
-Decided to move invariant 7 -- gain 32
-Decided to move invariant 8 -- gain 32
-Decided to move invariant 9 -- gain 32
-Decided to move invariant 10 -- gain 10
-Decided to move invariant 11 -- gain 30
+Set in insn 22 is invariant (0), cost 4, depends on 
+Set in insn 27 is invariant (1), cost 4, depends on 
+Set in insn 32 is invariant (2), cost 4, depends on 
+Set in insn 37 is invariant (3), cost 4, depends on 
+Set in insn 61 is invariant (4), cost 4, depends on 
+Set in insn 66 is invariant (5), cost 4, depends on 
+Set in insn 71 is invariant (6), cost 4, depends on 
+Set in insn 76 is invariant (7), cost 4, depends on 
+Set in insn 101 is invariant (8), cost 4, depends on 
+Set in insn 106 is invariant (9), cost 4, depends on 
+Set in insn 111 is invariant (10), cost 4, depends on 
+Set in insn 116 is invariant (11), cost 4, depends on 
+Decided to move invariant 0 -- gain 4
+Decided to move invariant 1 -- gain 4
+Decided to move invariant 2 -- gain 4
+Decided to move invariant 3 -- gain 4
+Decided to move invariant 4 -- gain 4
+Decided to move invariant 5 -- gain 4
+Decided to move invariant 6 -- gain 4
+Decided to move invariant 7 -- gain 4
+Decided to move invariant 8 -- gain 4
+Decided to move invariant 9 -- gain 4
which means invariant 10 and 11 aren't moved anymore.
Those two are:
-(insn 111 106 116 3 (set (reg:V16SF 210)
-(vec_duplicate:V16SF (vec_select:SF (reg:V4SF 234)
-(parallel [
-(const_int 0 [0])
-] "include/avx512fintrin.h":207 4206
{avx512f_vec_dupv16sf}
- (expr_list:REG_EQUAL (const_vector:V16SF [
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-(const_double:SF 2.3e+1 [0x0.b8p+5])
-])
-(nil)))
-(insn 116 111 139 3 (set (reg:V16SF 214)
-(vec_duplicate:V16SF (vec_select:SF (reg:V4SF 235)
-(parallel [
-(const_int 0 [0])
-] "include/avx512fintrin.h":207 4206
{avx512f_vec_dupv16sf}
- (expr_list:REG_EQUAL (const_vector:V16SF [
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-(const_double:SF 2.4e+1 [0x0.cp+5])
-])
-(nil)))
and I bet the reason they are using the const costs are the REG_EQUAL notes.
The setters of their sources are:
(insn 169 168 170 3 (set (reg:V4SF 234)
(mem/u/c:V4SF (symbol_ref/u:DI ("*.LC10") [flags 0x2]) [2 

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #35 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to Martin Liška from comment #31)
> > (In reply to Segher Boessenkool from comment #30)
> > > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > > toolchain).
> > > Martin, you have a working recipe?
> > 
> > Go to gcc110 machine and do:
> > $ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
> > --disable-lto
> > $ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"
> 
> I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> but that builds stage2 as 64-bit?

Hm, that's possible. But the stage2 should not crash right?

> 
> Is that stage1 flags the secret sauce?

No that's not the secret sauce.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #34 from Segher Boessenkool  ---
(In reply to Vladimir Makarov from comment #29)
> Sorry for all the troubles with my latest patch and thank you for fair
> criticism.  I've decided to revert the patch as soon as git starts working. 
> I'll work to find a better solution after this.

Thanks!  Btw, on powerpc64-linux your patch changed the allocation order
of the non-volatile registers, which is a big regression (we need bigger
stack frames that way).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #33 from Segher Boessenkool  ---
(In reply to Martin Liška from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > toolchain).
> > Martin, you have a working recipe?
> 
> Go to gcc110 machine and do:
> $ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
> --disable-lto
> $ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"

I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
but that builds stage2 as 64-bit?

Is that stage1 flags the secret sauce?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #32 from Segher Boessenkool  ---
Sigh.  No, this is *not* a target bug (or we certainly do not know it is),
please stop marking it that.

It seems to be a bug in shrink-wrapping, but the dump does not show enough
information (only contradictory info :-/ ), and I cannot yet reproduce the
problem.

[Bug sanitizer/81601] [8/9/10 Regression] incorrect Warray-bounds warning with -fsanitize

[law at redhat dot com]

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

--- Comment #27 from Jeffrey A. Law  ---
So I just prototyped a bit of code that might help with this BZ.

This seems better suited for match.pd, except that match.pd doesn't seem to
want to handle BIT_FIELD_REF nodes.  So I did the prototype in forwprop.

Given a BIT_AND_EXPR which just masks off high bits that is fed by a
BIT_FIELD_REF, we can adjust the # of bits in the BIT_FIELD_REF and the type of
the reference.  The BIT_AND turns into a nop-conversion.

So the key blocks start like this:

;;   basic block 2, loop depth 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, VISITED)
;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
  _13 = __builtin_object_size (tp_11(D), 0);
  _14 = _11(D)->D.2292;
  .UBSAN_OBJECT_SIZE (_14, 13, _13, 0);
  _1 = tp_11(D)->chrono_type;
  _2 = (int) _1;
  if (_1 == 0)
goto ; [INV]
  else
goto ; [INV]
;;succ:   3 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, maybe hot
;;prev block 2, next block 4, flags: (NEW, VISITED)
;;pred:   2 (TRUE_VALUE,EXECUTABLE)
  _3 = BIT_FIELD_REF <*tp_11(D), 8, 96>;
  _4 = _3 & 3;
  if (_4 != 0)
goto ; [INV]
  else
goto ; [INV]
;;succ:   4 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)

And the bits in block #3 turn into:

;;   basic block 3, loop depth 0, maybe hot
;;prev block 2, next block 4, flags: (NEW, VISITED)
;;pred:   2 (TRUE_VALUE,EXECUTABLE)
  _9 = BIT_FIELD_REF <*tp_11(D), 2, 96>;
  _4 = (unsigned char) _9;
  if (_9 != 0)
goto ; [INV]
  else
goto ; [INV]
;;succ:   4 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)


That's good enough that FRE can see the redundancy between tp->chrono_type and
the BIT_FIELD_REF and all the right things just happen from that point onward.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #31 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #30)
> I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> toolchain).
> Martin, you have a working recipe?

Go to gcc110 machine and do:
$ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
--disable-lto
$ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #30 from Segher Boessenkool  ---
I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain).
Martin, you have a working recipe?

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The standard seems to say a union member becomes active when the constructor
finishes, not when it starts, so what wording prevents changing the active
member during the construction?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #29 from Vladimir Makarov  ---
Sorry for all the troubles with my latest patch and thank you for fair
criticism.  I've decided to revert the patch as soon as git starts working. 
I'll work to find a better solution after this.

[Bug target/93800] [9 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[9/10 Regression] GCC adds  |[9 Regression] GCC adds
   |unwanted nops to align  |unwanted nops to align
   |loops on powerpc 8xx since  |loops on powerpc 8xx since
   |r9-1623 |r9-1623
  Known to work||9.2.1
  Known to fail|9.2.0   |

--- Comment #5 from Martin Liška  ---
Fixed on trunk so far.

[Bug c++/94100] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:12765

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-09
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
The ICE started with r0-128638-gb0ff7fe1d223260aea5b7dc3f36892aa57d43c77 -- a
while ago.  Before that:

94100.C:19:24: error: no matching function for call to ‘Foo::foo()’
   Foo::foo();
^

[Bug c++/94050] [10 Regression] C++ ABI change on armv7hl-linux-gnueabi since r10-1302

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
commit r10-7089-g8475f2902a2e2ca5f7ace8bc5265bd1a815dda20
Author: Marek Polacek 
Date:   Thu Mar 5 14:07:25 2020 -0500

c++: Fix ABI issue with alignas on armv7hl [PR94050]

The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the

patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

  CLASSTYPE_AS_BASE (t) = t;

While TYPE_USER_ALIGN of TenuredCell was 0, because finalize_type_size
called from finish_record_layout reset it, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE still remained 1.  After we replace it, it's no longer
1.  Then we perform layout_empty_base_or_field for TenuredCell and since
TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this
adjustment:

  if (CLASSTYPE_USER_ALIGN (type))
{
  rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
  if (warn_packed)
rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN
(type));
  TYPE_USER_ALIGN (rli->t) = 1;
}

where rli->t is BaseShape.  Then finalize_record_size won't use the
correct rli->record_align and therefore
  /* Round the size up to be a multiple of the required alignment.  */
  TYPE_SIZE (rli->t) = round_up (unpadded_size, TYPE_ALIGN (rli->t));
after this we end up with the wrong size.

Since the original fix was to avoid creating extra copies for LTO
purposes, I think the following fix should be acceptable.

PR c++/94050 - ABI issue with alignas on armv7hl.
* class.c (layout_class_type): Don't replace a class's
CLASSTYPE_AS_BASE if their TYPE_USER_ALIGN don't match.

* g++.dg/abi/align3.C: New test.

[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
commit r10-7087-g314b91220a07bd63f13c58e37f1b5b9430a3702b
Author: Martin Liska 
Date:   Mon Mar 9 14:13:04 2020 +0100

Restore alignment in rs6000 target.

PR target/93800
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove set of str_align_loops and str_align_jumps as these
should be set in previous 2 conditions in the function.
PR target/93800
* gcc.target/powerpc/pr93800.c: New test.

[Bug rtl-optimization/94045] [i686] Compiler hang with -O2 -g -m32 -march=i686 -mtune=generic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
commit r10-7086-g2e94d3ee47be0742df843d95e3d1bf1da11e4796
Author: Jakub Jelinek 
Date:   Mon Mar 9 13:38:23 2020 +0100

alias: Punt after walking too many VALUEs during a toplevel find_base_term
call [PR94045]

As mentioned in the PR, on a largish C++ testcase the compile time
on i686-linux is about 16 minutes on a fast box, mostly spent in
find_base_term recursive calls dealing with very deep chains of preserved
VALUEs during var-tracking.

The following patch punts after we process many VALUEs (we already have
code
to punt if we run into a VALUE cycle).

I've gathered statistics on when we punt this way (with BITS_PER_WORD, TU,
function columns piped through sort | uniq -c | sort -n):
 36 32 ../../gcc/asan.c _Z29initialize_sanitizer_builtinsv.part.0
108 32 _first_test.go reflect_test.reflect_test..import
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   2534 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/stack-check-9.c f3
   6346 32 ../../gcc/brig/brig-lang.c brig_define_builtins
   6398 32 ../../gcc/d/d-builtins.cc d_define_builtins
   8816 32 ../../gcc/c-family/c-common.c c_common_nodes_and_builtins
   8824 32 ../../gcc/lto/lto-lang.c lto_define_builtins
  41413 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr43058.c test
Additionally, for most of these (for the builtins definitions tested just
one) I've verified with a different alias.c change which didn't punt but
in the toplevel find_base_term recorded if visited_vals reached the limit
whether the return value was NULL_RTX or something different, and in all
these cases the end result was NULL_RTX, so at least in these cases it
should just shorten the time until it returns NULL.

2020-03-09  Jakub Jelinek  

PR rtl-optimization/94045
* params.opt (-param=max-find-base-term-values=): New option.
* alias.c (find_base_term): Add cut-off for number of visited
VALUEs
in a single toplevel find_base_term call.

[Bug libstdc++/94063] filesystem::path concatenation doesn't work for Windows root-paths

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The test case for Cygwin (which is expected to fail on other targets) is 

#include 
#include 

using std::filesystem::path;

int main()
{
  path p;

  p = "/";
  p += path("/x");
  assert( p.has_root_name() );
  assert( p.root_name() == p );

  p = "/";
  p += "/x";
  assert( p.has_root_name() );
  assert( p.root_name() == p );

  p = "/";
  p += path("/");
  assert( !p.has_root_name() );
  assert( p.has_root_directory() );

  p = "/";
  p += "/";
  assert( !p.has_root_name() );
  assert( p.has_root_directory() );
}

[Bug tree-optimization/94094] [meta-bug] store-merging and/or bswap load/store-merging missed optimizations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The two passes share infrastructure for the bswap discovery etc., but otherwise
they aren't dependent on each other.

[Bug analyzer/94099] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874 since r10-7023-g3d66e153b40ed000

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE in  |ICE in
   |make_region_for_unexpected_ |make_region_for_unexpected_
   |tree_code, at   |tree_code, at
   |analyzer/region-model.cc:48 |analyzer/region-model.cc:48
   |74  |74 since
   ||r10-7023-g3d66e153b40ed000
   Last reconfirmed||2020-03-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7023-g3d66e153b40ed000.

[Bug c++/94100] New: ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:12765

[jjk at acm dot org]

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

Bug ID: 94100
   Summary: ICE: tree check: accessed elt 1 of 'tree_vec' with 0
elts in tsubst_pack_expansion, at cp/pt.c:12765
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jjk at acm dot org
  Target Milestone: ---

Created attachment 47998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47998=edit
Source file to be compiled.

The attached file elicits an ICE in the GCC "trunk" version used by Compiler
Explorer (https://godbolt.org/z/iPK_JV):

: In function 'int main()':
:20:24: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:12765
   20 |   Foo::foo();
  |^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


When using GCC 9.2, no ICE happens, but the file fails to be parsed:

: In function 'int main()':
:20:24: error: no matching function for call to
'Foo::foo()'
   20 |   Foo::foo();
  |^
:11:3: note: candidate: 'template static void
Foo::foo() [with ARGS ...args = {args ...}; ARGS = {bool}]'
   11 |   foo(void)
  |   ^~~
:11:3: note:   template argument deduction/substitution failed:
:21:31: error: no matching function for call to 'Foo::foo<42, 23>()'
   21 |   Foo::foo<42, 23>();
  |   ^
:11:3: note: candidate: 'template static void
Foo::foo() [with ARGS ...args = {args ...}; ARGS = {int, long int}]'
   11 |   foo(void)
  |   ^~~
:11:3: note:   template argument deduction/substitution failed:
:21:31: error: wrong number of template arguments (2, should be 1)
   21 |   Foo::foo<42, 23>();
  |   ^
:22:34: error: no matching function for call to 'Foo::foo<'h', 'i'>()'
   22 |   Foo::foo<'h', 'i'>();
  |  ^
:11:3: note: candidate: 'template static void
Foo::foo() [with ARGS ...args = {args ...}; ARGS = {char, char}]'
   11 |   foo(void)
  |   ^~~
:11:3: note:   template argument deduction/substitution failed:
:22:34: error: wrong number of template arguments (2, should be 1)
   22 |   Foo::foo<'h', 'i'>();
  |  ^


Clang correctly compiles the file.

[Bug analyzer/94099] New: ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[asolokha at gmx dot com]

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

Bug ID: 94099
   Summary: ICE in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4874
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.1-alpha20200308 snapshot (g:9de42a8e995451cb13dceb3970ae23ff88240bff)
ICEs when compiling the following testcase w/ -O1 -fanalyzer:

struct cg {
  int hk;
  int *bg;
};

union vb {
  struct cg gk;
};

void
l3 (union vb *);

void
pl (void)
{
  union vb th = { 0, };
  int sc;

  for (sc = 0; sc < 1; ++sc)
{
  th.gk.hk = 0;
  th.gk.bg[sc] = 0;
  l3 ();
}
}

% gcc-10.0.1 -O1 -fanalyzer -c z8rkwib5.c
during IPA pass: analyzer
z8rkwib5.c:21:16: internal compiler error: in
make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874
   21 |   th.gk.hk = 0;
  |   ~^~~
0x71e1d3
ana::region_model::make_region_for_unexpected_tree_code(ana::region_model_context*,
tree_node*, dump_location_t const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4874
0x110e3cb ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4738
0x110e973 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4899
0x110e8c8 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4821
0x110e973 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4899
0x110fffc ana::region_model::get_rvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4965
0x11100d3 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/region-model.cc:4979
0x17befd2 ana::for_each_state_change(ana::program_state const&,
ana::program_state const&, ana::extrinsic_state const&,
ana::state_change_visitor*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/diagnostic-manager.cc:772
0x17bffae ana::diagnostic_manager::add_events_for_eedge(ana::path_builder
const&, ana::exploded_edge const&, ana::checker_path*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/diagnostic-manager.cc:833
0x17c0534 ana::diagnostic_manager::build_emission_path(ana::path_builder
const&, ana::exploded_path const&, ana::checker_path*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/diagnostic-manager.cc:614
0x17c1382 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/diagnostic-manager.cc:517
0x17c35ae ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/diagnostic-manager.cc:446
0x17c1743 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/diagnostic-manager.cc:489
0x10ef82e ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:3799
0x10f028c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/engine.cc:3842
0x10e50e8 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/analyzer/analyzer-pass.cc:84

[Bug middle-end/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0
  Known to work||9.2.0
   Target Milestone|--- |10.0

[Bug middle-end/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Last reconfirmed||2020-03-09

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-4929-g54aa6b58fe2fe73b.

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Sorry, I read "Creating and using **a** `std::random_device` object fails when
used from multiple threads" to mean creating one object, and then apparently
didn't read the code properly to dispel my misunderstanding.

[Bug target/94087] std::random_device often fails when used from multiple threads

[coryan+gccbugzilla at google dot com]

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

Carlos O'Ryan  changed:

   What|Removed |Added

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

--- Comment #7 from Carlos O'Ryan  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Carlos O'Ryan from comment #0)
> > Creating and using a `std::random_device` object fails when used from
> > multiple threads.
> 
> That's undefined behaviour. Calling non-const member functions on a single
> object from multiple threads is always undefined unless specified otherwise.

Each thread is creating its own `std::random_device` so I do not believe this
is applicable.

[Bug c++/94082] __builtin_memcpy in constexpr context should compile

[D.Bahadir at GMX dot de]

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

--- Comment #6 from Deniz Bahadir  ---
(In reply to Jonathan Wakely from comment #5)
> 
> It definitely doesn't mean __builtin_memcpy has to be used. It means "we
> don't want to change std::memcpy, implementations must use some other method
> to make it work". 
> 
> That could mean using some new intrinsic like __builtin_constant_memcpy, or
> anything else that makes the algorithms work in constant expressions. The
> solution in libstdc++ is based on std::is_constant_evaluted() and ensures
> that memcpy and __builtin_memcpy are never needed in constant expressions
> because we implement those copies by hand when needed during constant
> evaluation.

OK, I see.
Would you then suggest GCC should provide such an intrinsic or would you expect
developers to do copies by hand, too, in `constexpr` context.

> > > It might be useful if it could be used, but the fact it can't currently
> > > isn't a bug.
> > 
> > OK, then consider this issue a feature-request and a question.
> > 
> > As the link to Compiler Explorer shows the compiler is already able to
> > calculate the result of the entire function call at compile-time when called
> > from a non-`constexpr` context.
> 
> For some cases. I don't think it's true for all inputs.

Well, that is unfortunate.

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Guess *testqi_ext_3 needs to be adjusted to test CCZmode instead of CCNOmode if
the constant we'll be created matches the new testdi_1 conditions.

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
   Last reconfirmed||2020-03-09

--- Comment #1 from Jakub Jelinek  ---
Started with r10-1938-g460bf043c8266dd080308f4783137aee0d0f862c

[Bug c++/94082] __builtin_memcpy in constexpr context should compile

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Deniz Bahadir from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > (In reply to Deniz Bahadir from comment #1)
> > > Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if
> > > `__builtin_memcpy` should be usable from a `constexpr` context.
> > 
> > Why? std::memcpy isn't usable in constant expressions.
> 
> 
> Revision 0 of P0202 (https://wg21.link/p0202r0) originally had the following
> text in section III.B:
> 
> "B. std::memmove and std::memcpy must have constexpr additions
> 
> std::memmove and std::memcpy accept void* and const void* parameters.
> This makes them impossible to implement in pure C++ as constexpr, because
> constant expressions can not evaluate a conversion from type cv void * to
> a pointer-to-object type according to [expr.const].
> 
> However those functions are not only popular, but also are widely used
> across Standard Library to gain better performance. Not making them
> constexpr will force standard Library developer to have compiler
> intrinsics for them anyway. This is a hard step that must be done."
> 
> That was rejected at the committee meeting in Jacksonville in early 2018 and
> the section was replaced by the following:
> 
> "During the Jacksonville meeting it was decided not to modify the
> 
> headers, leading to a decision to use compiler specific intrinsics
> instead
> of functions from  header."
> 
> To me that sounds as if compiler-intrinsics like `__builtin_memcpy` should
> instead be usable in `constexpr` contexts.

It definitely doesn't mean __builtin_memcpy has to be used. It means "we don't
want to change std::memcpy, implementations must use some other method to make
it work". 

That could mean using some new intrinsic like __builtin_constant_memcpy, or
anything else that makes the algorithms work in constant expressions. The
solution in libstdc++ is based on std::is_constant_evaluted() and ensures that
memcpy and __builtin_memcpy are never needed in constant expressions because we
implement those copies by hand when needed during constant evaluation.


> > It might be useful if it could be used, but the fact it can't currently
> > isn't a bug.
> 
> OK, then consider this issue a feature-request and a question.
> 
> As the link to Compiler Explorer shows the compiler is already able to
> calculate the result of the entire function call at compile-time when called
> from a non-`constexpr` context.

For some cases. I don't think it's true for all inputs.

> Shouldn't it then be able to still do so in a `constexpr` context, too?
> (As I mentioned, e.g. for `__builtin_bswap32` that is possible.)

bswap32 is much simpler than mempcy and can always be expanded by the compiler,
for all inputs.

[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Well, 64-bit time_t/off_t/ino_t on an arch where they weren't previously 64-bit
is an ABI change which of course needs to have support added to various parts
of the toolchain, including libsanitizer (for which it should go through the
upstream).

[Bug tree-optimization/93781] Optimizer produces suboptimal code related to -ftree-vrp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
For the second testcase, I think we could in undefined_shift_range_check or its
2 callers intersect the value range of the last [lr]shift operand with the
range of [0, prec-1], and if that yields empty range, do what we use right now,
but if it narrows the op2 range to something smaller, use that in the
range_operator::fold_range call instead of op2.

[Bug c++/94082] __builtin_memcpy in constexpr context should compile

[D.Bahadir at GMX dot de]

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

--- Comment #4 from Deniz Bahadir  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Deniz Bahadir from comment #1)
> > Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if
> > `__builtin_memcpy` should be usable from a `constexpr` context.
> 
> Why? std::memcpy isn't usable in constant expressions.


Revision 0 of P0202 (https://wg21.link/p0202r0) originally had the following
text in section III.B:

"B. std::memmove and std::memcpy must have constexpr additions

std::memmove and std::memcpy accept void* and const void* parameters.
This makes them impossible to implement in pure C++ as constexpr, because
constant expressions can not evaluate a conversion from type cv void * to
a pointer-to-object type according to [expr.const].

However those functions are not only popular, but also are widely used
across Standard Library to gain better performance. Not making them
constexpr will force standard Library developer to have compiler
intrinsics for them anyway. This is a hard step that must be done."

That was rejected at the committee meeting in Jacksonville in early 2018 and
the section was replaced by the following:

"During the Jacksonville meeting it was decided not to modify the 
headers, leading to a decision to use compiler specific intrinsics instead
of functions from  header."

To me that sounds as if compiler-intrinsics like `__builtin_memcpy` should
instead be usable in `constexpr` contexts.


> It might be useful if it could be used, but the fact it can't currently
> isn't a bug.

OK, then consider this issue a feature-request and a question.

As the link to Compiler Explorer shows the compiler is already able to
calculate the result of the entire function call at compile-time when called
from a non-`constexpr` context.
Shouldn't it then be able to still do so in a `constexpr` context, too?
(As I mentioned, e.g. for `__builtin_bswap32` that is possible.)

[Bug middle-end/94098] New: [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[asolokha at gmx dot com]

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

Bug ID: 94098
   Summary: [10 Regression] ICE: canonical types differ for
identical types 'int(void*, void*)' and 'int(void*,
void*)'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

PR92721 strikes back.

g++-10.0.1-alpha20200308 snapshot (g:9de42a8e995451cb13dceb3970ae23ff88240bff)
ICEs when compiling the following testcase reduced from
gcc/testsuite/gcc.dg/attr-access-read-write-2.c:

int rdwr1_rdwr1 (void*, void*);
int __attribute__ ((access (read_write, 1))) rdwr1_rdwr1 (void*, void*);
int __attribute__ ((access (read_write, 2))) rdwr1_rdwr1 (void*, void*);

% g++-10.0.1 -w -c drii2dyo.cc
drii2dyo.cc:3:71: internal compiler error: canonical types differ for identical
types 'int(void*, void*)' and 'int(void*, void*)'
3 | int __attribute__ ((access (read_write, 2))) rdwr1_rdwr1 (void*,
void*);
  |   ^
0xa63b0b comptypes(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/typeck.c:1519
0x8f21d8 duplicate_decls(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/decl.c:2308
0x972360 do_pushdecl
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/name-lookup.c:3044
0x9751b2 pushdecl(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/name-lookup.c:3173
0x9751b2 maybe_push_decl(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/name-lookup.c:3204
0x907331 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/decl.c:5377
0x9b5f81 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/parser.c:20703
0x996d46 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/parser.c:13689
0x9c1002 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/parser.c:13388
0x9c179f cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/parser.c:4731
0x9c179f c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/cp/parser.c:43760
0xad99db c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200308/work/gcc-10-20200308/gcc/c-family/c-opts.c:1186

[Bug inline-asm/94097] New: GCC fails to allocate "rm" input constraint when no more register is left

[frederic.recou...@univ-grenoble-alpes.fr]

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

Bug ID: 94097
   Summary: GCC fails to allocate "rm" input constraint when no
more register is left
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.recou...@univ-grenoble-alpes.fr
  Target Milestone: ---

Consider the following code snippet:

int main (int argc, char *argv[])
{
  int x = 0;
  __asm__ ("movl %1, %0" "\n\t"
   : "=" (argc)
   : "rm" (x)
   : "ebx", "ecx", "edx",
 "edi", "esi", "ebp");
  return argc;
}

GCC 9.0 fails because the constraints are "impossible" but 'x' can still be
given by memory reference.

For instance, in the following code, that is quasi equivalent, but with swapped
constraints:

int main (int argc, char *argv[])
{
  int x = 0;
  __asm__ ("movl %1, %0"
   : "=" (argc)
   : "a" (x)
   : "ebx", "ecx", "edx",
 "edi", "esi", "ebp");
  return argc;
}

It produces the following assembly, where a new cell is freshly allocated on
the stack to hold the value:

main:
  pushl %ebp
  xorl %eax, %eax
  pushl %edi
  pushl %esi
  pushl %ebx
  subl $4, %esp
#APP
  movl %eax, (%esp)
#NOAPP
  movl (%esp), %eax
  addl $4, %esp
  popl %ebx
  popl %esi
  popl %edi
  popl %ebp
  ret

[Bug target/94096] New: amdgcn build instructions missing

[rguenth at gcc dot gnu.org]

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

Bug ID: 94096
   Summary: amdgcn build instructions missing
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC

has documentation how to enable offloading for nvtpx, intel-mic and hsa but
lacks any information on amdgcn.  install.texi lacks everything.

Please update.

[Bug c++/88086] gcc only allows valid expressions as unknown C++ attribute argument clause

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Seems like a duplicate of PR c++/92648 which is already fixed.

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

[Bug c++/92648] Handling of unknown attributes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||bruno-gcc at defraine dot net

--- Comment #6 from Jonathan Wakely  ---
*** Bug 88086 has been marked as a duplicate of this bug. ***

[Bug inline-asm/94095] New: Modifier 'a' do not work as described

[frederic.recou...@univ-grenoble-alpes.fr]

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

Bug ID: 94095
   Summary: Modifier 'a' do not work as described
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.recou...@univ-grenoble-alpes.fr
  Target Milestone: ---

In https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html 6.47.2.8, it is said
that 'a' "Print an absolute memory reference" (aka *%eax for 'att') but
experiments shows that it actually print '(%eax)'.

But yet, what is the intended behavior?
Is it actually valid to use 'a' modifier with 'p' constraint in

void *x = NULL;
__asm__ ("leal %a1, %0" : "=r" (x) : "p" ());

?

[Bug target/94093] -malign-double changes alignment of double type only and not long double

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|2.95.2  |
  Known to work||2.95.2

--- Comment #4 from Richard Biener  ---
Pilot error, GCC 2.95 "properly" aligns long double but GCC 3.2+ do not.

[Bug target/94093] -malign-double changes alignment of double type only and not long double

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||2.95.2, 3.2.3, 3.4.6, 4.0.0
   Keywords|wrong-code  |documentation

--- Comment #3 from Richard Biener  ---
Probably.  IMHO support for -malign-double should go away since it's effects
on the psABI are not fully documented.

Btw, clang appears to have alignof(long double) == 8, not matching GCCs
behavior.

GCC 4.0.0 is also "wrong", so are GCC 2.95, 3.2, 3.3 and 3.4.

So I guess it works as designed and documentation should be fixed instead.

[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
With profile feedback we (target or middle-end) can produce specialized
RTL expansion doing small copies inline and larget ones offline.  The
idea of GIMPLE level pattern detection is that even for small sizes
the target usually knows how to expand the copy optimally while the
user may have written a byte copying loop.

Of course that requires targets to pay attention.

Note most compiler optimization involves some heuristics and clearly heuristics
can be off.  I wonder if you can obtain better coremark results by using
link-time optimization.  Iff you're only after benchmark numbers...

[Bug c++/94082] __builtin_memcpy in constexpr context should compile

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Deniz Bahadir from comment #1)
> Reading P0202 (wg21.link/p0202) (which made it into C++20) it sounds as if
> `__builtin_memcpy` should be usable from a `constexpr` context.

Why? std::memcpy isn't usable in constant expressions.

It might be useful if it could be used, but the fact it can't currently isn't a
bug.

[Bug target/94088] [10 Regression] ICE: in extract_insn, at recog.c:2294 (error: unrecognizable insn), or ICE: in elimination_costs_in_insn, at reload1.c:3538

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Carlos O'Ryan from comment #0)
> Creating and using a `std::random_device` object fails when used from
> multiple threads.

That's undefined behaviour. Calling non-const member functions on a single
object from multiple threads is always undefined unless specified otherwise.

It might work "by accident", if GCC detects that your CPU supports the RDRAND
instruction and that can be used (because doing so is stateless) but it will
fail if it has to read from the /dev/random or /dev/urandom devices.

[Bug tree-optimization/94094] New: [meta-bug] store-merging and/or bswap load/store-merging missed optimizations

[rguenth at gcc dot gnu.org]

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

Bug ID: 94094
   Summary: [meta-bug] store-merging and/or bswap
load/store-merging missed optimizations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Bug tracking missed cases, both passes could/should be merged.

[Bug tree-optimization/94086] Missed optimization when converting a bitfield to an integer on x86-64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-09

--- Comment #2 from Richard Biener  ---
Confirmed.  This is another task for a combined bswap/store-merging where the
bswap tracking would need to be extended to cover bits.

Also part of the reason for the missed optimization is that on GIMPLE we
think 'half' is memory but in reality it is in a register.

[Bug target/94093] -malign-double changes alignment of double type only and not long double

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This might be just like PR 47120.

[Bug target/94072] [10 Regression] ICE: SIGSEGV due to infinite recursion in expand_expr/expand_expr_real_1 with -msve-vector-bits=512

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0