[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Kito Cheng from comment #17)
> Created attachment 47920 [details]
> update-local-align-pass.patch
> 
> Hi Jakub:
> 
> I got your point, and I agree with your point, estimate_stack_frame_size not
> the right place to update alignment.
> 
> I write a patch to add a new pass to update the data alignment, executed at
> begging of pass_all_early_optimizations, PoC patch attached, it's not fully
> tested yet, how do you think about this approach? 

Could you change pass_data_ipa_increase_alignment instead?  Which does a
similar thing except for global variables.

[Bug libfortran/93871] COTAN is slow for complex types

[thenlich at gcc dot gnu.org]

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

--- Comment #29 from Thomas Henlich  ---
(In reply to Steve Kargl from comment #28)
>  ! Fold  into [0,90] range
...
>  if (arg == 180) then

I don't understand how (arg == 180) could be true after folding into [0,90]
range.

[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code

[kito at gcc dot gnu.org]

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

--- Comment #17 from Kito Cheng  ---
Created attachment 47920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47920=edit
update-local-align-pass.patch

Hi Jakub:

I got your point, and I agree with your point, estimate_stack_frame_size not
the right place to update alignment.

I write a patch to add a new pass to update the data alignment, executed at
begging of pass_all_early_optimizations, PoC patch attached, it's not fully
tested yet, how do you think about this approach? 

Thanks :)

[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at gcc dot gnu.org

--- Comment #10 from Roman Zhuykov  ---
(In reply to Martin Liška from comment #3)
> Confirmed also with r247015 (GCC 7 branch point).
(In reply to Martin Liška from comment #9)
> I would close this as fixed.
Asked about backporting, see
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01523.html

[Bug fortran/93956] New: Wrong array creation with p => array_dt(1:n)%component

[mscfd at gmx dot net]

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

Bug ID: 93956
   Summary: Wrong array creation with p => array_dt(1:n)%component
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The following code (compiled without any options) prints "15000, 1" for the
second call to foo, instead of the expected "2, 1". The first call to
foo gives the expected result. This is also reproducible with gfortran-10
branch.

This code is a variation of the one reported in bug 93918 to further understand
temporary array creation.

program array_temps
implicit none

type :: tt
   integer :: u = 1
   integer :: v = 2
end type tt

type(tt), dimension(:), pointer :: r
integer :: n
integer, dimension(:), pointer :: p

allocate(r(1:n))
call foo(r(:)%v, n)
p => get(r(:))
call foo(p, n)
deallocate(r)

contains

   subroutine foo(a, n)
  integer, dimension(:), intent(in) :: a
  integer, intent(in) :: n
  print *, sum(a(1:n)), n
   end subroutine foo

   function get(x) result(q)
  type(tt), dimension(:), target, intent(in) :: x
  integer, dimension(:), pointer :: q
  q => x(:)%v
   end function get

end program array_temps

[Bug c++/90467] Documentation: many warning options that are enabled by default are documented in the -Woption form, not -Wno-option

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:cf70bb0fbd7fb0f4bca99c53a36d0a389dcc2fc5

commit r10-6882-gcf70bb0fbd7fb0f4bca99c53a36d0a389dcc2fc5
Author: Sandra Loosemore 
Date:   Wed Feb 26 19:51:06 2020 -0800

Document negative form of warning options enabled by default [PR90467].

2020-02-26  Sandra Loosemore  

PR c++/90467

gcc/
* doc/invoke.texi (Option Summary): Re-alphabetize warnings in
C++ Language Options, Warning Options, and Static Analyzer
Options lists.  Document negative form of options enabled by
default.  Move some things around to more accurately sort
warnings by category.
(C++ Dialect Options, Warning Options, Static Analyzer
Options): Document negative form of options when enabled by
default.  Move some things around to more accurately sort
warnings by category.  Add some missing index entries.
Light copy-editing.

[Bug c/86833] missing warning for out-of-bounds array access without optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2019-02-11 00:00:00 |2020-2-26
  Known to fail||10.0, 9.2.0

--- Comment #2 from Martin Sebor  ---
No progress in GCC 10.

[Bug tree-optimization/89550] [8/9/10 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
GCC 10 doesn't warn on the submitted test case so it looks like the change in
r269485 suppressed it.  The patch was submitted here:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00321.html

There's no test case in the commit and from the description on gcc-patches it's
not clear if the patch was supposed to be a fix for this bug or just some
general fix.  Jakub, should this be resolved as fixed or what?

[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |11.0

[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Created attachment 47919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47919=edit
Tested patch for GCC 11.

The attached patch adds the missing warning.

[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-27
 Ever confirmed|0   |1
  Known to fail|8.0 |10.0, 8.2.0, 9.2.0

--- Comment #2 from Martin Sebor  ---
Confirmed based on bug 93848 comment 9.

[Bug c++/93789] [8/9/10 Regression] internal compiler error: in tree_to_uhwi, at tree.c:7361

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 10.  Since it's ice-on-invalid, I'm not planning to backport the
fix.

[Bug c++/93789] [8/9/10 Regression] internal compiler error: in tree_to_uhwi, at tree.c:7361

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1231f71f96a4e461f94394b4fb8cfa25587fbd96

commit r10-6881-g1231f71f96a4e461f94394b4fb8cfa25587fbd96
Author: Marek Polacek 
Date:   Wed Feb 26 15:02:25 2020 -0500

c++: Fix ICE with invalid array bounds [PR93789]

r7-2111 introduced maybe_constant_value in cp_fully_fold.
maybe_constant_value uses cxx_eval_outermost_constant_expr, which
can clear TREE_CONSTANT:
6510   else if (non_constant_p && TREE_CONSTANT (r))
[...]
6529   TREE_CONSTANT (r) = false;

In this test the array size is '(long int) "h"'.  This used to be
TREE_CONSTANT but given the change above, the flag will be cleared
when we cp_fully_fold the array size in compute_array_index_type_loc.
That means we don't emit an error in the
10391   else if (TREE_CONSTANT (size)
block in the same function, and we go on.  Then we compute ITYPE
using cp_build_binary_op and use maybe_constant_value on it and
suddenly we have something that's TREE_CONSTANT again.  And then we
crash in reshape_init_array_1 in tree_to_uhwi, because what we have
doesn't fit in an unsigned HWI.

icc accepts this code, but since we used to reject it, I see no desire
to make this work, so don't use the folded result when we've lost
the TREE_CONSTANT flag while evaluating the size.

2020-02-26  Marek Polacek  

PR c++/93789 - ICE with invalid array bounds.
* decl.c (compute_array_index_type_loc): Don't use the folded
size when folding cleared TREE_CONSTANT.

* g++.dg/ext/vla22.C: New test.

[Bug c++/93955] detect conversion from pointer type to arithmetic type in constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Marek Polacek  ---
The problem is that

  /* Technically we should check this for all subexpressions, but that
 runs into problems with our internal representation of pointer
 subtraction and the 5.19 rules are still in flux.  */
  if (CONVERT_EXPR_CODE_P (TREE_CODE (r)) 
  && ARITHMETIC_TYPE_P (TREE_TYPE (r)) 
  && TREE_CODE (TREE_OPERAND (r, 0)) == ADDR_EXPR)
{
  if (!allow_non_constant)
error ("conversion from pointer type %qT "
   "to arithmetic type %qT in a constant expression",
   TREE_TYPE (TREE_OPERAND (r, 0)), TREE_TYPE (r));
  non_constant_p = true;
}

only works on the outermost expression, as the comment says.

Looks like a GCC 11 project.

[Bug c++/93955] New: detect conversion from pointer type to arithmetic type in constexpr

[mpolacek at gcc dot gnu.org]

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

Bug ID: 93955
   Summary: detect conversion from pointer type to arithmetic type
in constexpr
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

constexpr long int
foo ()
{
  return (long int) "foo"
#ifdef FOO
- 1
#endif
;
}

constexpr long int l = foo ();

is currently accepted with -DFOO but rejected otherwise.  It should be rejected
even in the -DFOO case: converting a pointer to an integral type must be done
via a reinterpret_cast and that can't be part of a core constant expression.

[Bug tree-optimization/80635] [8/9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning

[jason at gcc dot gnu.org]

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

--- Comment #43 from Jason Merrill  ---
(In reply to Jeffrey A. Law from comment #42)
> I suspect the V_C_E  inhibits tree-ssa-uninit.c code to avoid false
> positives.  If we know the range of the V_C_E operand is narrow enough that
> it fits into the type of the result of the V_C_E, could we optimize the
> V_C_E into a NOP_EXPR?   We'd then forward propagate away the NOP_EXPR and
> the result is something the suppression code in tree-ssa-uninit.c can
> analyze better.

Looks like the V_C_E comes from sra_modify_assign:

  if (!useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
{
=>rhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
 rhs);

Here rhs (the scalar replacement variable) has unsigned QI type and lhs has
type bool.

Changing the type of 'live' to unsigned char avoids the V_C_E and thus indeed
the warning.  This also works with the libstdc++ optional.

This seems like an SRA problem with fields of type bool.

[Bug analyzer/93950] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/93947] ICE: Segmentation fault (in symtab_node::ultimate_alias_target)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/93950] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:71b633aaea3aac2d983da7b1b99da8c9a8c80d1a

commit r10-6880-g71b633aaea3aac2d983da7b1b99da8c9a8c80d1a
Author: David Malcolm 
Date:   Wed Feb 26 16:32:16 2020 -0500

analyzer: fix ICE with -Wanalyzer-null-dereference [PR 93950]

PR analyzer/93950 reports an ICE when pruning the path of a
-Wanalyzer-null-dereference diagnostic.

The root cause is a bug in the state-tracking code, in which the
variable of interest is tracked from the callee to a "nullptr" param
at the caller, whereupon we have an INTEGER_CST "variable", and
the attempt to look up its lvalue fails.

This code could use a rewrite; in the meantime this patch extends
the bulletproofing from g:8525d1f5f57b11fe04a97674cc2fc2b7727621d0
for PR analyzer/93544 to all of the various places where var can
be updated, fixing the ICE.

gcc/analyzer/ChangeLog:
PR analyzer/93950
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Assert that var is
either NULL or not a constant.  When updating var, bulletproof
against constant values.

gcc/testsuite/ChangeLog:
PR analyzer/93950
* g++.dg/analyzer/pr93950.C: New test.

[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:71b633aaea3aac2d983da7b1b99da8c9a8c80d1a

commit r10-6880-g71b633aaea3aac2d983da7b1b99da8c9a8c80d1a
Author: David Malcolm 
Date:   Wed Feb 26 16:32:16 2020 -0500

analyzer: fix ICE with -Wanalyzer-null-dereference [PR 93950]

PR analyzer/93950 reports an ICE when pruning the path of a
-Wanalyzer-null-dereference diagnostic.

The root cause is a bug in the state-tracking code, in which the
variable of interest is tracked from the callee to a "nullptr" param
at the caller, whereupon we have an INTEGER_CST "variable", and
the attempt to look up its lvalue fails.

This code could use a rewrite; in the meantime this patch extends
the bulletproofing from g:8525d1f5f57b11fe04a97674cc2fc2b7727621d0
for PR analyzer/93544 to all of the various places where var can
be updated, fixing the ICE.

gcc/analyzer/ChangeLog:
PR analyzer/93950
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Assert that var is
either NULL or not a constant.  When updating var, bulletproof
against constant values.

gcc/testsuite/ChangeLog:
PR analyzer/93950
* g++.dg/analyzer/pr93950.C: New test.

[Bug analyzer/93947] ICE: Segmentation fault (in symtab_node::ultimate_alias_target)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:0ba70d1b5ae8df6406a880b2d23e4710b393e8c9

commit r10-6879-g0ba70d1b5ae8df6406a880b2d23e4710b393e8c9
Author: David Malcolm 
Date:   Wed Feb 26 09:43:57 2020 -0500

analyzer: fix ICE on unreachable calls [PR 93947]

PR analyzer/93947 reports an ICE at -O1 when attempting to analyze a
call that has been optimized away as unreachable.

The root cause is a NULL dereference due to the fndecl having a NULL
cgraph_node: the cgraph_node was created by
pass_build_cgraph_edges::execute, but was later removed by
symbol_table::remove_unreachable_nodes before the analyzer pass.

This patch fixes it by checking for NULL before handling the
cgraph_node.

The reproducer demonstrates a weakness in the analyzer's constraint
handling, where region_model::apply_constraints_for_gswitch fails
to spot when the cases fully cover the data type, and thus make the
default impossible.  For now this is xfail-ed in the testcase.

gcc/analyzer/ChangeLog:
PR analyzer/93947
* region-model.cc (region_model::get_fndecl_for_call): Gracefully
fail for fn_decls that don't have a cgraph_node.

gcc/testsuite/ChangeLog:
PR analyzer/93947
* gcc.dg/analyzer/torture/pr93947.c: New test.

[Bug debug/93954] gcc generates wrong debug information at -O3

[qrzhang at gatech dot edu]

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

--- Comment #2 from Qirun Zhang  ---
(In reply to Andrew Pinski from comment #1)
> >Bisection points to g:bd2b9f1e2d67ec8e88c977154ecfee
> 
> My bet is if you put a break point at "i--;" you would get the incorrect
> answer before that patch.
> Since the function just has one instruction at -O3, there is not an
> instruction to place both lines there.

Break at "i--;" (at line 3) does give the same incorrect result.

However, before that patch, gcc works fine. I tested
g:6d3aa24cd6535dcfc9f0701579eca53aa1917


It gives me:
$ bin/bin/gcc -g -O3 abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4003a0: file abc.c, line 3.

Breakpoint 1, main () at abc.c:4
4 ;// b here
$1 = 2580636199
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 19052) killed]

[Bug debug/93954] gcc generates wrong debug information at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>Bisection points to g:bd2b9f1e2d67ec8e88c977154ecfee

My bet is if you put a break point at "i--;" you would get the incorrect answer
before that patch.
Since the function just has one instruction at -O3, there is not an instruction
to place both lines there.

[Bug debug/93954] New: gcc generates wrong debug information at -O3

[qrzhang at gatech dot edu]

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

Bug ID: 93954
   Summary: gcc generates wrong debug information at -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It appears to be a regression in gcc-8. The code is pretty self-explanatory.

Bisection points to g:bd2b9f1e2d67ec8e88c977154ecfee



$ gcc-trunk -v
gcc version 10.0.1 20200226 (experimental) [master revision
4d213bf6011:5d3c19b2ec6:ce25177f505ea75b3c0833c3f3f0072b97ee1b44] (GCC)


#It incorrectly prints i = 2580636200

$ gcc-trunk -g-O3 abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4003a0: file abc.c, line 4.

Breakpoint 1, main () at abc.c:4
4 ;// b here
$1 = 2580636200
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 17508) killed]


$ cat abc.c
int main() {
  unsigned i = 2580636200;
  i--;
  ;// b here
}


$ cat cmds
b abc.c:4
r
p i
kill
q

[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
An array is implicitly converted to a pointer; it's not an lvalue.  But I think
we're splitting hairs.  I agree we want a warning for passing past-the-end
pointers to functions that might inadvertently dereference it; I plan to
implement it for GCC 11.

The reference in

int a[1][4];
printf("%p\n", (void *)[1][1]);

is of course undefined, but when the warning sees the address-of operator it
allows off-by-one indices.  That's necessary only for the rightmost index but
not otherwise.  The missing warning here is the subject of pr84079.  I have a
simple fix that handles this case.

[Bug libfortran/93871] COTAN is slow for complex types

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #28 from Steve Kargl  ---
On Wed, Feb 26, 2020 at 04:02:23PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> > This is a best effort to still be able to use the standard library functions
> > but also get an increased accuracy expected from the degree functions.
> > 
> > Thus:
> > 1. Calculate cosd(x) = sind(90 - x)
> > 2. Calculate cotand(x) = tand(90 - x)
> > 3. Reduce range of sind() argument from (0...360) further to x-360 if it is
> > above 270, and to 180-x if it is above 90
> > 
> 

Exhaustive testing in the domain [2**(-8),720] for REAL(4) gives

troutmask:sgk[347] gfcx -o z -O2 -fdec e.f90 && ./z
Total values tested: 146014209
   ulp > 1.5   max ulp   x at max ulp 
WIP Patch[1]:   6558266   4331134.9   359.69
fcn below[2]:   717   1.6212178   1.79070497

[1] Work in progress has implemented range reduction in the
interval [0,360], but does not fold the reduced range
as is done in fcn(x).  The reference solution in the
ulp computation is fcn(x) converted to double precision.

[2] Only 9 exceed a max ulp of 1.6.

  ! Compute SIND(x) where x is in degrees.
  function fcn(x) result(f)
 real(sp) f
 real(sp), intent(in) :: x
 integer sgn
 real(sp) arg
 real(sp), parameter :: deg2rad = atan(1._sp) / 45
 !
 ! Required for sin(-x) = - sin(x)
 !
 sgn = 1
 if (x < 0) sgn = -1
 arg = abs(x)

 ! 0 <= arg < 360
 arg = modulo(arg, 360._sp)

 ! Fold  into [0,90] range
 if (arg <= 180) then
if (arg > 90) arg = 180 - arg
 else
sgn = -sgn
arg = arg - 180
if (arg > 90) arg = 180 - arg
 end if
 if (arg == 180) then
f = sign(0._sp, real(sgn,sp))
 else
f = sgn * sin(arg * deg2rad)
 end if
  end function fcn

Probably need to punt the above into libgfortran.  Note,
for x < 2**(-8) we can do sin(x) ~ x

[Bug target/91276] Doc typos in __builtin_crypto_vpmsum*

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Carl Love :

https://gcc.gnu.org/g:526fadb010978c63dd06c0a85da3c4e1b5b1c63d

commit r9-8298-g526fadb010978c63dd06c0a85da3c4e1b5b1c63d
Author: Carl Love 
Date:   Wed Feb 26 18:22:46 2020 -0600

PPC64, fix documentation for __builtin_crypto_vpmsum* builtin functions.

PR target/91276 - Doc typos in __builtin_crypto_vpmsum*

gcc/ChangeLog:

2020-02-26  Carl Love  

PR target/91276
* doc/extend.texi (PowerPC AltiVec Built-in Functions available on
ISA 3.0): The builtin-function name __builtin_crypto_vpmsumb is only
for the vector unsigned short arguments.  It is also listed as the
name of the built-in for arguments vector unsigned short,
vector unsigned int and vector unsigned long long built-ins.  The
name of the builtins for these arguments should be:
__builtin_crypto_vpmsumh, __builtin_crypto_vpmsumw and
__builtin_crypto_vpmsumd respectively.

[Bug target/91276] Doc typos in __builtin_crypto_vpmsum*

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Carl Love :

https://gcc.gnu.org/g:f551b0889f56d2a89529e8cfce87f763f1a0bee9

commit r8-10092-gf551b0889f56d2a89529e8cfce87f763f1a0bee9
Author: Carl Love 
Date:   Wed Feb 26 18:12:17 2020 -0600

PR target/91276 - Doc typos in __builtin_crypto_vpmsum*

gcc/ChangeLog:

2020-02-26  Carl Love  

PR target/91276
* doc/extend.texi (PowerPC AltiVec Built-in Functions): The
builtin-function name __builtin_crypto_vpmsumb is only for the
vector unsigned short arguments.  It is also listed as the name of
the built-in for arguments vector unsigned short,
vector unsigned int and vector unsigned long long built-ins.  The
name of the builtins for these arguments should be:
__builtin_crypto_vpmsumh, __builtin_crypto_vpmsumw and
__builtin_crypto_vpmsumd respectively.

[Bug target/91276] Doc typos in __builtin_crypto_vpmsum*

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Carl Love :

https://gcc.gnu.org/g:15fc2e04a592f8bfcc3eafead71d0313566d8372

commit r10-6877-g15fc2e04a592f8bfcc3eafead71d0313566d8372
Author: Carl Love 
Date:   Wed Feb 26 17:21:20 2020 -0600

PPC64, fix documentation for __builtin_crypto_vpmsum* builtin functions.

PR target/91276 - Doc typos in __builtin_crypto_vpmsum*

gcc/ChangeLog:

2020-02-26  Carl Love  

PR target/91276
* doc/extend.texi (PowerPC AltiVec Built-in Functions available on
ISA 3.0): The builtin-function name __builtin_crypto_vpmsumb is only
for the vector unsigned short arguments.  It is also listed as the
name of the built-in for arguments vector unsigned short,
vector unsigned int and vector unsigned long long built-ins.  The
name of the builtins for these arguments should be:
__builtin_crypto_vpmsumh, __builtin_crypto_vpmsumw and
__builtin_crypto_vpmsumd respectively.

Signed-off-by: Carl Love 

[Bug c/93812] [9/10 Regression] ICE on redeclaration of an attribute format function without protoype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01503.html

[Bug libstdc++/93936] [ranges] std::ranges::split_view<...>::_OuterIter<...>::__current() is private within this context

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/93140] [8/9 Regression] Segfault in cc1plus on incorrect decltype among function args

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixed for 8.4/9.3.

[Bug c++/92003] [8/9 Regression] constexpr-ness of char const* doesn't propagate

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
And 8.4 and 9.3.

[Bug c++/90951] [8/9 Regression] error initializing a constexpr array of a struct with const member

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
And 8.4 and 9.3.

[Bug c++/92745] [9 Regression] Initializing array with vec4 results in compile error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #13 from Jason Merrill  ---
And for 9.3.

[Bug c++/93789] [8/9/10 Regression] internal compiler error: in tree_to_uhwi, at tree.c:7361

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01494.html

[Bug c/93812] [9/10 Regression] ICE on redeclaration of an attribute format function without protoype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[9/10 Regression] ICE in|[9/10 Regression] ICE on
   |get_constant, at|redeclaration of an
   |c-family/c-format.c:325 |attribute format function
   ||without protoype

--- Comment #4 from Martin Sebor  ---
I'm not sure it makes sense to accept attribute format on functions without a
prototype.  It certainly doesn't make sense to keep it after a declaration to
which it can't be applied has been seen.  The only other kind of a declaration
that the attribute can meaningfully be applied is a variadic one but such is
not accepted after one without a prototype.

GCC 8 does accept the attribute on functions without a prototype and even seems
to do behave sensibly for "sensible" calls with the format argument in the
right place, but without -Wformat-nonliteral it doesn't do anything useful if
the format argument is not of the right type (e.g., because it's misplaced)
such as in:

  __attribute__((__format__(__printf__, 1, 2))) void foo ();

  void bar (void)
  {
foo (1, "%s", 2);   // no warning
  }

(As an aside, not diagnosing at least the call if not the declaration seems
like a bug because GCC doesn't accept attribute format on variadic functions
where the format doesn't have a declared type compatible with char* and where
the first-to-check argument isn't the position of the ellipsis (i.e., it can't
be an arbitrary position within the variable argument list).)

A simple solution is to simply drop the attribute from functions without a
prototype with a warning like Clang does:

  warning: '__format__' attribute only applies to Objective-C
methods, blocks, and non-K functions [-Wignored-attributes]

A slightly more involved but less intrusive (to user code) solution is to drop
it when a redeclaration is seen with a prototype.

[Bug tree-optimization/93953] [10 Regression] ice during during GIMPLE pass: vect since r10-6838

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:
/* PR tree-optimization/93953 */
/* { dg-do compile } */
/* { dg-options "-O3 --param=ggc-min-expand=0 --param=ggc-min-heapsize=0" } */

int *b, c, e;
float d, g, f;

void
foo (int l)
{
  for (; l; ++l)
{
  float a = g > l;
  d += a * b[4 * (l + c * e)];
  f += a * b[4 * (l + c * e) + 1];
}
}

[Bug debug/93751] -g1 does not behave per manual

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
See https://gcc.gnu.org/contribute.html for the procedure.  The patch is small
so you can probably skip the legal prerequisites, but you must post it on the
mailing list gcc-patc...@gcc.gnu.org in order to get it approved.

[Bug tree-optimization/93953] [10 Regression] ice during during GIMPLE pass: vect since r10-6838

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
The results from creduce, lightly hand modified to add
some implied types, is

int *b;
int c;
float d, e;
void h() {
  int f, g;
  for (; f; ++f) {
float a = -(0 > g);
e += a * b[4 * (g + c * f)];
d += a * b[4 * (g + c * f) + 1];
  }
}

[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Thomas, the -std= options will cause gfortran to ignore all
nonstandard intrinsic subprograms.  If you want nonstandard
intrinsic subprograms and use -std=f2008, then you need to
use the -fall-intrinsics option. For your example, I see

% gfcx -o z -std=f2008 -fall-intrinsics d.f90
/usr/local/bin/ld: /tmp/cceHxuCs.o: in function `MAIN__':
d.f90:(.text+0x5f): undefined reference to `sind_'
collect2: error: ld returned 1 exit status
% gfcx -o z -std=f2008 -fall-intrinsics -fdec d.f90
% ./z
0.
% gfcx -o z -std=f2008 -fall-intrinsics -fdec-math d.f90
% ./z
0.

We should probably consider removing -fdec-math option,
and handle the degree trig function like any other
nonstandard intrinsic subprogram.

[Bug tree-optimization/93953] [10 Regression] ice during during GIMPLE pass: vect since r10-6838

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-26
 CC||jakub at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |10.0
Summary|ice during during GIMPLE|[10 Regression] ice during
   |pass: vect  |during GIMPLE pass: vect
   ||since r10-6838
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Indeed, started with r10-6838-g81c833b311b16cfd87a947374d5ffbbd48facd03

[Bug tree-optimization/93953] [10 Regression] ice during during GIMPLE pass: vect since r10-6838

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org

[Bug c/93953] ice during during GIMPLE pass: vect

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
The bug first seems to occur sometime between 20200224 and 20200225.
That is yesterday and the day before.

[Bug c/93953] New: ice during during GIMPLE pass: vect

[dcb314 at hotmail dot com]

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

Bug ID: 93953
   Summary: ice during during GIMPLE pass: vect
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47918=edit
C source code

For the attached C code, with recent gcc trunk
and compiler flag -O3, does this:

during GIMPLE pass: vect
../../../cl_screen.c: In function ‘CL_UpdateScreen’:
../../../cl_screen.c:2697:6: internal compiler error: Segmentation fault
0xee9b17 crash_signal
../../trunk.git/gcc/toplev.c:328
0x11c46b7 slp_copy_subtree
../../trunk.git/gcc/tree-vect-slp.c:1786
0x11c46ae slp_copy_subtree
../../trunk.git/gcc/tree-vect-slp.c:1785
0x11c46ae slp_copy_subtree
../../trunk.git/gcc/tree-vect-slp.c:1785

I'll have my usual go at finding a range where the problem
first starts and reducing the code.

[Bug c++/90951] [8/9 Regression] error initializing a constexpr array of a struct with const member

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:c51ac41714469104ee6120db3eedfb0964290502

commit r9-8292-gc51ac41714469104ee6120db3eedfb0964290502
Author: Jason Merrill 
Date:   Wed Feb 26 13:03:23 2020 -0500

c++: Fix constexpr vs. omitted aggregate init.

Value-initialization is importantly different from {}-initialization for
this testcase, where the former calls the deleted S constructor and the
latter initializes S happily.

gcc/cp/ChangeLog
2020-02-26  Jason Merrill  

PR c++/90951
* constexpr.c (cxx_eval_array_reference): {}-initialize missing
elements instead of value-initializing them.

[Bug c++/93140] [8/9 Regression] Segfault in cc1plus on incorrect decltype among function args

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:1a8996b0a7b238180f4a10b19b1e90b33e5b2df0

commit r9-8291-g1a8996b0a7b238180f4a10b19b1e90b33e5b2df0
Author: Jason Merrill 
Date:   Wed Feb 26 13:03:23 2020 -0500

c++: Fix decltype of empty pack expansion of parm.

In unevaluated context, we only substitute a single PARM_DECL, not the
entire chain, but the handling of an empty pack expansion was missing that
check.

gcc/cp/ChangeLog
2020-02-26  Jason Merrill  

PR c++/93140
* pt.c (tsubst_decl) [PARM_DECL]: Check cp_unevaluated_operand in
handling of TREE_CHAIN for empty pack.

[Bug c++/92745] [9 Regression] Initializing array with vec4 results in compile error

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:c890c9650f3c4b1be1f39eabb74b438c033a8c08

commit r9-8294-gc890c9650f3c4b1be1f39eabb74b438c033a8c08
Author: Marek Polacek 
Date:   Fri Dec 20 23:30:04 2019 +

PR c++/92745 - bogus error when initializing array of vectors.

In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ return init;

But as this test shows, that's incorrect: if TYPE is an array, we need
to proceed to reshape_init_array_1 which will iterate over the array
initializers:
 6006   /* Loop until there are no more initializers.  */
 6007   for (index = 0;
 6008d->cur != d->end && (!sized_array_p || index <=
max_index_cst);
 6009++index)
 6010 {
and update d.cur accordingly.  In other words, when reshape_init gets

{{col[0][0], col[1][0], col[2][0], col[3][0]},
 {col[0][1], col[1][1], col[2][1], col[3][1]},
 {col[0][2], col[1][2], col[2][2], col[3][2]},
 {col[0][3], col[1][3], col[2][3], col[3][3]}}

we recurse on the first element:
  {col[0][0], col[1][0], col[2][0], col[3][0]}
and we can't just move d.cur to point to
  {col[0][1], col[1][1], col[2][1], col[3][1]}
and return; we need to iterate, so that d.cur ends up being properly
updated, and after all initializers have been seen, points to d.end.
Currently we skip the loop, wherefore we hit this:

 6502   /* Make sure all the element of the constructor were used.
Otherwise,
 6503  issue an error about exceeding initializers.  */
 6504   if (d.cur != d.end)
 6505 {
 6506   if (complain & tf_error)
 6507 error ("too many initializers for %qT", type);
 6508   return error_mark_node;
 6509 }

gcc/cp/ChangeLog
2019-12-19  Marek Polacek  

PR c++/92745 - bogus error when initializing array of vectors.
* decl.c (reshape_init_r): For a nested compound literal, do
call reshape_init_{class,array,vector}.

gcc/testsuite/ChangeLog
2019-12-19  Marek Polacek  
Jakub Jelinek  

PR c++/92745 - bogus error when initializing array of vectors.
* g++.dg/cpp0x/initlist118.C: New test.
* g++.dg/cpp0x/initlist118.C: Add -Wno-psabi -w to dg-options.

[Bug c++/92003] [8/9 Regression] constexpr-ness of char const* doesn't propagate

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:f2f70af7c52720a0905a455425de0d6ca4fb1dc4

commit r9-8293-gf2f70af7c52720a0905a455425de0d6ca4fb1dc4
Author: Jason Merrill 
Date:   Wed Feb 26 13:03:23 2020 -0500

cgraph: A COMDAT decl always has non-zero address.

We should be able to assume that a template instantiation or other COMDAT
has non-zero address even if MAKE_DECL_ONE_ONLY for the target sets
DECL_WEAK and we haven't yet decided to emit a definition in this
translation unit.

gcc/ChangeLog
2020-02-26  Jason Merrill  

PR c++/92003
* symtab.c (symtab_node::nonzero_address): A DECL_COMDAT decl has
non-zero address even if weak and not yet defined.

[Bug c++/92852] [8/9/10 Regression] location references block not in block tree

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:b6678d67c4b7471c25130b6c60a9087e02f31179

commit r9-8290-gb6678d67c4b7471c25130b6c60a9087e02f31179
Author: Jason Merrill 
Date:   Wed Feb 26 13:03:23 2020 -0500

c++: Preserve location in maybe_constant_value.

If cxx_eval_outermost_constant_expr doesn't change the argument, we really
shouldn't unshare it when we try to fold it again.

gcc/cp/ChangeLog
2020-02-26  Jason Merrill  

PR c++/92852
* constexpr.c (maybe_constant_value): Don't unshare if the cached
value is the same as the argument.

[Bug c++/93901] [10 Regression] noexcept specifier on ctor does not work with constexpr variable or expression since r10-4394

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
It is the
* pt.c (maybe_instantiate_noexcept): Only update clones if we
instantiated.
part of that commit that breaks this, but I'm afraid I have no idea why.

[Bug debug/93751] -g1 does not behave per manual

[stilor at att dot net]

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

--- Comment #12 from Alexey Neyman  ---
Patch ping.

[Bug c/93949] [8/9/10 Regression] Register const local var will not compile since r0-58166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-26
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|Register const local var|[8/9/10 Regression]
   |will not compile|Register const local var
   ||will not compile since
   ||r0-58166
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r0-58166-g6de9cd9a886ea695aa892c3c7c07818a7b7e9e6f.
The problem is in the
 /* If a const aggregate variable is being initialized, then it
   should never be a lose to promote the variable to be static.  */
optimization.  Either we shouldn't do that optimization if DECL_REGISTER is
set, or we should clear DECL_REGISTER.  If the latter, we should still punt on
DECL_HARD_REGISTER.

[Bug c++/87652] [8 Regression] inner class template of outer class template can't access friend's protected data member

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87651] [8 Regression] inner class with template template friend declaration of same name fails to compile

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87651] [8 Regression] inner class with template template friend declaration of same name fails to compile

[jason at gcc dot gnu.org]

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

Bug 86747 Summary: [8 Regression] rejects-valid with redundant friend 
declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86747

   What|Removed |Added

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

[Bug c++/86747] [8 Regression] rejects-valid with redundant friend declaration

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87652] [8 Regression] inner class template of outer class template can't access friend's protected data member

[jason at gcc dot gnu.org]

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

Bug 86747 Summary: [8 Regression] rejects-valid with redundant friend 
declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86747

   What|Removed |Added

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

[Bug target/93913] [10 regression] r10-6762 breaks gcc.target/powerpc/fold-vec-st-*.c test cases

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:051b9873e78fe1acb1a3fecd0c6e5685b6c12fb3

commit r10-6874-g051b9873e78fe1acb1a3fecd0c6e5685b6c12fb3
Author: Peter Bergner 
Date:   Wed Feb 26 11:58:08 2020 -0600

rs6000: Fix more testsuite fallout from rs6000_legitimate_address_p() fix.
[PR93913]

PR target/93913
* gcc.target/powerpc/fold-vec-st-char.c (scan-assembler-times): Allow
stxv and stxvx instructions as well.
* gcc.target/powerpc/fold-vec-st-float.c: Likewise.
* gcc.target/powerpc/fold-vec-st-int.c: Likewise.
* gcc.target/powerpc/fold-vec-st-short.c: Likewise.

[Bug c++/88394] [8 Regression] g++ ICE (Segmentation fault) in insert_capture_proxy

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87748] [8 Regression] G++-8 treats SFINAE as error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87480] [8 Regression] SFINAE constructor not matched, only in templated function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87327] [8 Regression] Calling member functions on captured constexpr variables "is not a constant expression"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/86429] [8 Regression] lambda capture breaks constexpr-ness

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 86429 Summary: [8 Regression] lambda capture breaks constexpr-ness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86429

   What|Removed |Added

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

[Bug c++/87554] [8 Regression] internal compiler error: in record_reference, at cgraphbuild.c:64

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #13 from Jason Merrill  ---
Fixed for 8.4.

[Bug c++/87685] [8 Regression] Calling a static method from inside a generic lambda requires to capture 'this'

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 8.4.

[Bug inline-asm/93952] Giving an array in an operand

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

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

--- Comment #1 from Frédéric Recoules 
 ---
(In reply to Frédéric Recoules from comment #0)
> Now I wonder if the code where we replace the constraint by "rm" is valid
> because the returned value depends of the constraint the compiler have
> chosen.

Ok, it seems that if the compiler have the choice between "r" and "m", it
returns the same result whatever it chooses.

I do shake my head a bit because I don't understand why solo "m" is treated in
a different way.

[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[wjwray at gmail dot com]

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

--- Comment #8 from Will Wray  ---
OK. I'll try to get full confirmation and clarification on legality,
with links to wording if possible, then open a new bug if valid.

[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Oof, curious.  Could you please create a new PR for that?

[Bug libstdc++/93205] std::discrete_distribution's operator>> causes OOM

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:f80c40f93f9e8781b14f1a8301467f117fd24051

commit r8-10091-gf80c40f93f9e8781b14f1a8301467f117fd24051
Author: Jonathan Wakely 
Date:   Wed Feb 26 16:09:52 2020 +

libstdc++: Fix undefined behaviour in random dist serialization (PR93205)

The deserialization functions for random number distributions fail to
check the stream state before using the extracted values. In some cases
this leads to using indeterminate values to resize a vector, and then
filling that vector with indeterminate values.

No values that affect control flow should be used without checking that a
good value was read from the stream.

Additionally, where reasonable to do so, defer modifying any state in
the distribution until all values have been successfully read, to avoid
modifying some of the distribution's parameters and leaving others
unchanged.

Backport from mainline
2020-01-09  Jonathan Wakely  

PR libstdc++/93205
* include/bits/random.h (operator>>): Check stream operation succeeds.
* include/bits/random.tcc: (operator>>): Likewise.
(__extract_params): New function to fill a vector from a stream.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line.

[Bug libstdc++/92886] Inappropriate comment for std::ios_base::trunc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:a13dd21c3f4fe405980b469c544a00c4356d7006

commit r8-10090-ga13dd21c3f4fe405980b469c544a00c4356d7006
Author: Jonathan Wakely 
Date:   Wed Feb 26 15:46:27 2020 +

libstdc++: Fix description of std::ios::trunc (PR 92886)

Backport from mainline
2019-12-10  Jonathan Wakely  

PR libstdc++/92886
* include/bits/ios_base.h (std::ios_base::trunc): Fix comment.

[Bug libstdc++/93205] std::discrete_distribution's operator>> causes OOM

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.4 and 9.3

[Bug target/92922] [10 regression] [ilp32] FAIL: gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c -std=c90 -O1 -g -DTEST_FULL (internal compiler error)

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sudi at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from sudi at gcc dot gnu.org ---
Fixed as commented

[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[wjwray at gmail dot com]

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

--- Comment #6 from Will Wray  ---
Thanks for the quick work.
However, I'm not sure that (2) and (3) _are_ invalid.

(Sorry, I didn't have time to follow the email thread).
I should have provided this link to an exchange with Richard Smith.
I'd waited for his response before filing the bug. He says:
"In both cases, it's valid to use static_cast to recover the original type."

https://cpplang.slack.com/archives/C2PQKRWJU/p1579186047347300

zygoloid  Feb 20
Lifetime extension applies; the lifetime extension rules don't care about
qualification conversions. Another example: const int *const  =
static_cast(nullptr); performs lifetime extension even though the type
of the temporary object (int*) has been lost (mutability-erased) in the
reference binding.

zygoloid  Feb 20
In both cases, it's valid to use static_cast to recover the original type.

willw  Feb 20
Thanks for the confirmation. That makes sense.

willw  Feb 21
I filed the gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93862

[Bug target/92922] [10 regression] [ilp32] FAIL: gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c -std=c90 -O1 -g -DTEST_FULL (internal compiler error)

[joel.hutton at arm dot com]

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

--- Comment #2 from Joel Hutton  ---
This was fixed by Richard Sandiford's patch. 

commit fb15e2bab5267213b8706fa6a29eeef94f62a524
Author: Richard Sandiford 
Date:   Mon Jan 20 19:29:25 2020 +

aarch64: Fix SVE ACLE handling of SImode pointers

[Bug libstdc++/92886] Inappropriate comment for std::ios_base::trunc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.0|8.4

[Bug libstdc++/93205] std::discrete_distribution's operator>> causes OOM

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:a29236a23c03fe08998b81a0ef1f67e7ea185ba3

commit r9-8289-ga29236a23c03fe08998b81a0ef1f67e7ea185ba3
Author: Jonathan Wakely 
Date:   Wed Feb 26 16:31:19 2020 +

libstdc++: Fix undefined behaviour in random dist serialization (PR93205)

The deserialization functions for random number distributions fail to
check the stream state before using the extracted values. In some cases
this leads to using indeterminate values to resize a vector, and then
filling that vector with indeterminate values.

No values that affect control flow should be used without checking that a
good value was read from the stream.

Additionally, where reasonable to do so, defer modifying any state in
the distribution until all values have been successfully read, to avoid
modifying some of the distribution's parameters and leaving others
unchanged.

Backport from mainline
2020-01-09  Jonathan Wakely  

PR libstdc++/93205
* include/bits/random.h (operator>>): Check stream operation succeeds.
* include/bits/random.tcc: (operator>>): Likewise.
(__extract_params): New function to fill a vector from a stream.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line.

[Bug libstdc++/92886] Inappropriate comment for std::ios_base::trunc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:7a7ef79651abd20b95d1f76479887d1ea008a62f

commit r9-8288-g7a7ef79651abd20b95d1f76479887d1ea008a62f
Author: Jonathan Wakely 
Date:   Wed Feb 26 16:31:19 2020 +

libstdc++: Fix description of std::ios::trunc (PR 92886)

Backport from mainline
2019-12-10  Jonathan Wakely  

PR libstdc++/92886
* include/bits/ios_base.h (std::ios_base::trunc): Fix comment.

[Bug analyzer/93950] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-26
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; thanks for filing this.

[Bug target/93012] PPC: inefficient 64-bit constant generation (upper = lower)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Segher Boessenkool  ---
Fixed on trunk.  No backport planned.

[Bug target/93877] [9/10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
Indeed, this seems to be related to LRA.

I just tried to build gcc-9 with LRA enabled by default and the build fails
when trying to build gnat with:

checking for shl_load in -ldld... s-gearop.adb: In function
'Ada.Numerics.Complex_Arrays.Back_Substitute.Sub_Row':
s-gearop.adb:124:11: error: insn does not satisfy its constraints:
(insn 463 462 465 5 (parallel [
(set (reg:SF 65 fr1 [343])
(reg:SF 0 r0 [344]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
]) "a-ngcoty.adb":68:10 214 {movsf_ie}
 (expr_list:REG_DEAD (reg:SF 0 r0 [344])
(nil)))
+===GNAT BUG DETECTED==+
| 9.2.1 20191130 (sh4-linux-gnu) in extract_constrain_insn, at recog.c:2211|
| Error detected around s-gearop.adb:124:11|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

[Bug libfortran/93871] COTAN is slow for complex types

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #27 from Steve Kargl  ---
On Wed, Feb 26, 2020 at 12:58:21PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
> 
> --- Comment #26 from Thomas Henlich  ---
> Created attachment 47914
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47914=edit
> Demonstration of range reduction
> 
> There is a danger of some inaccuracy in the degree trigonometric functions
> (sind, cosd, tand, cotand) because a full period of 360 degrees can not be
> expressed accurately in radians.
> 
> This can be circumvented by using some trigonometric identities to reduce the
> range and also place the inaccurate x range to where |dy/dx|→min, and away 
> from
> y values near zero toward high y values so that the error is mostly cancelled.

I implemented FreeBSD's cosl, sinl, and tanl, did the legwork to produce
all of the sincos family of functions, and have implemented sinpi and
friends for FreeBSD .  I'm well aware of argument reduction and ULPs.  If
you're going to go this route, then you'll need to write functions that
can be called from libgfortran.

My patch rewrites the special handling of degree trig functions to bring
these functions into the general framework that gfortran uses for all other
intrinsic routines (except a few in IEEE_ARITHEMETIC).

> This is a best effort to still be able to use the standard library functions
> but also get an increased accuracy expected from the degree functions.
> 
> Thus:
> 1. Calculate cosd(x) = sind(90 - x)
> 2. Calculate cotand(x) = tand(90 - x)
> 3. Reduce range of sind() argument from (0...360) further to x-360 if it is
> above 270, and to 180-x if it is above 90
> 

(snip)

> $ gf10 -fdec-math -fdefault-real-8 periods.f90 && ./a.exe

Any result that uses -fdefault-real-8 will be ingored by me.
That option should have been removed years ago.  I even posted
a patch that removed it.  It was not well-received.

[Bug inline-asm/93952] New: Giving an array in an operand

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

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

Bug ID: 93952
   Summary: Giving an array in an operand
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ABI, accepts-invalid, documentation
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.recou...@univ-grenoble-alpes.fr
  Target Milestone: ---

I am trying to understand the meaning of giving an array in an operand of an
inline assembly statement.

Please consider the following small snippet of code:
int main (int argc, char * argv[])
{
char t[] = "abc";
int x;
__asm__ ("movl %1, %0"
 : "=r" (x)
 : "r" (t));
return x;
}
Here are my observation and my understanding:
The object t that has type "array of char" is converted to an expression with
type "pointer to char" that points to the initial element of t.
It is equivalent to: x = (int) [0];

If we change the constraint "r" to "m", the result is different.
Here is the limit of my understanding and it is only speculation:
The constraint "m" take the address of t, but as it is an array, it actually
returns it unchanged and then it access to the value pointed by.
It is like: x = (int) *(/*&*/([0]));

Now I wonder if the code where we replace the constraint by "rm" is valid
because the returned value depends of the constraint the compiler have chosen.

In my mind, I would have expected that "m" constraint pass the same value but
in a way it is accessible through memory, that is: char *p = t; x = (int)
*();
Could someone point me out where I am going wrong here?

[Bug c++/93320] internal compiler error: in is_base_type, at dwarf2out.c:12987

[przemyslaw.wirkus at arm dot com]

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

Przemyslaw Wirkus  changed:

   What|Removed |Added

 CC||przemyslaw.wirkus at arm dot 
com

--- Comment #6 from Przemyslaw Wirkus  ---
Hi,

I was able to reduce your testcase to this code:

template  class a;
class {
  void b(a... c);
}

/Przemyslaw

[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds

[ch3root at openwall dot com]

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

--- Comment #9 from Alexander Cherepanov  ---
(In reply to Martin Sebor from comment #8)
> In
> 
>   int i[4];
>   int (*p)[4] = 
>   bar_aux (p[1]);
> 
> p[0] points to i and p[1] to (char*) + sizeof (i) (which is the same as
> [4]).

It seems we start to differ here. p[1] itself doesn't point anywhere. It's an
array, it has type int[4], its size is 4*sizeof(int). (That's easy to check.)
It's an lvalue that "potentially designates an object". Given that there is no
real object here, its evaluation is UB (C11, 6.3.2.1p1).

IOW there is no pointer here, UB happens before we get a pointer.

>  The latter is a pointer just past the end of i.  Evaluating
> past-the-end pointers is well-defined, as is all pointer arithmetic on them,
> just as long as the result is also a valid pointer to the same object (or
> just past its end).  The only way past-the-end pointers differ from others
> is that the former cannot be dereferenced (by any means, either the *
> operator, or [] or ->).

Right, but this is applicable to p+1, not to p[1]. Indeed, p+1 is a
past-the-end pointer, it points past the end of the array consisting of one
element (i). In particular, you can add 0 and -1 to it to roam over the array.
And you are right that you cannot apply * to it. That is, there is *(p+0) (it's
i) but there is no *(p+1). And p[1] is *(p+1) by definition, so evaluating it
is UB.

> In
> int a[1][4];
> printf("%p\n", (void *)[1][1]);
> 
> on the other hand, the reference to a[1][1] is undefined because a[1] is not
> a reference to an element in a but rather just past the end of a, and so it
> can be neither dereferenced nor used to obtain pointers other than to a or
> just past it.

Sorry I don't quite understand. Are you saying that a[1]-1 is valid? And the
result is a?

> [1] alone is valid (it's equivalent to (char*) + sizeof
> a) and points just past the end of a, but [1][1] is equivalent to
> (char*) + sizeof a + 1 which is not valid.

So we at least agree that [1][1] is UB and should give a warning and that
-Warray-bounds doesn't work as intended here?

[Bug debug/93951] New: ICE with '-flto -femit-struct-debug-baseonly'

[guillaume at morinfr dot org]

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

Bug ID: 93951
   Summary: ICE with '-flto -femit-struct-debug-baseonly'
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guillaume at morinfr dot org
  Target Milestone: ---

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

This program ICEs with '-g -flto -femit-struct-debug-baseonly -std=gnu++2a'
with gcc 9.2 and 8.3 (seems to work on the trunk). Remove any of -g, -flto,
-femit-struct-debug-only and it builds fine.

#include 

struct S1 {
bool fct() const;
};

struct S2 {
bool fct() const;
};

struct V {
bool visit() const {
auto visitor = [](auto&& s) -> bool { return s.fct(); };
return std::visit(visitor, v);
}

using Variant = std::variant;
Variant v;
};

#0  htab_hash_string (p=0x0) at ../../src/libiberty/hashtab.c:838
#1  0x0085acad in external_ref_hasher::hash (r=) at
../../src/gcc/dwarf2out.c:8917
#2  hash_table::find_slot
(insert=INSERT, value=, this=0x206fa40) at
../../src/gcc/hash-table.h:423
#3  lookup_external_ref (map=map@entry=0x206fa40, die=0x758f93c0) at
../../src/gcc/dwarf2out.c:8945
#4  0x0085ad6f in optimize_external_refs_1 (die=0x758f9370,
map=0x206fa40) at ../../src/gcc/dwarf2out.c:8983
#5  0x0085ad40 in optimize_external_refs_1 (die=0x758f9320,
map=0x206fa40) at ../../src/gcc/dwarf2out.c:8987
#6  0x0085ad40 in optimize_external_refs_1 (die=0x758f92d0,
map=0x206fa40) at ../../src/gcc/dwarf2out.c:8987
#7  0x0085ae59 in optimize_external_refs (die=die@entry=0x758f92d0)
at ../../src/gcc/dwarf2out.c:9036
#8  0x00860ac8 in output_comp_unit (die=0x758f92d0,
output_if_empty=, dwo_id=0x0) at ../../src/gcc/dwarf2out.c:11055
#9  0x0088caa4 in dwarf2out_early_finish (filename=0x7fffd76d
"g++9_lto_crash.cc") at ../../src/gcc/dwarf2out.c:32264
#10 0x00801025 in symbol_table::finalize_compilation_unit
(this=0x7665f100) at ../../src/gcc/cgraphunit.c:2860
#11 0x00b69cbd in compile_file () at ../../src/gcc/toplev.c:481

[Bug libstdc++/93325] libstdc++ wrongly uses direct clock_gettime syscall on non-glibc, breaks time64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.4

--- Comment #7 from Jonathan Wakely  ---
Fixed for 8.4 and 9.3 too. Thanks for the report.

[Bug libstdc++/93325] libstdc++ wrongly uses direct clock_gettime syscall on non-glibc, breaks time64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:08a70a65670ee801d4190ec122d42aa4a9a997a9

commit r9-8286-g08a70a65670ee801d4190ec122d42aa4a9a997a9
Author: Jonathan Wakely 
Date:   Wed Feb 26 15:32:34 2020 +

libstdc++: Replace glibc-specific check for clock_gettime (PR 93325)

It's wrong to assume that clock_gettime is unavailable on any *-*-linux*
target that doesn't have glibc 2.17 or later. Use a generic test instead
of using __GLIBC_PREREQ. Only do that test when is_hosted=yes so that we
don't get an error for cross targets without a working linker.

This ensures that C library's clock_gettime will be used on non-glibc
targets, instead of an incorrect syscall to SYS_clock_gettime.

Backport from mainline
2020-01-28  Jonathan Wakely  

PR libstdc++/93325
* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Use AC_SEARCH_LIBS for
clock_gettime instead of explicit glibc version check.
* configure: Regenerate.

[Bug libstdc++/93325] libstdc++ wrongly uses direct clock_gettime syscall on non-glibc, breaks time64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:655434f5ae93a4222a48c39c37a3a6fe0bdfc071

commit r8-10089-g655434f5ae93a4222a48c39c37a3a6fe0bdfc071
Author: Jonathan Wakely 
Date:   Wed Feb 26 15:32:34 2020 +

libstdc++: Replace glibc-specific check for clock_gettime (PR 93325)

It's wrong to assume that clock_gettime is unavailable on any *-*-linux*
target that doesn't have glibc 2.17 or later. Use a generic test instead
of using __GLIBC_PREREQ. Only do that test when is_hosted=yes so that we
don't get an error for cross targets without a working linker.

This ensures that C library's clock_gettime will be used on non-glibc
targets, instead of an incorrect syscall to SYS_clock_gettime.

Backport from mainline
2020-01-28  Jonathan Wakely  

PR libstdc++/93325
* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Use AC_SEARCH_LIBS for
clock_gettime instead of explicit glibc version check.
* configure: Regenerate.

[Bug libstdc++/93562] [8/9 Regression] unique_ptr::swap incorrectly uses generic std::swap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.4 and 9.3 as well.

[Bug libstdc++/93562] [8/9 Regression] unique_ptr::swap incorrectly uses generic std::swap

[cvs-commit at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.4 and 9.3 as well.

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:e47c9cd77f5e60780f054aacb096315b1fcca8bb

commit r8-10088-ge47c9cd77f5e60780f054aacb096315b1fcca8bb
Author: Jonathan Wakely 
Date:   Wed Feb 26 15:04:53 2020 +

libstdc++: Fix regressions in unique_ptr::swap (PR 93562)

The requirements for this function are only that the deleter is
swappable, but we incorrectly require that the element type is complete
and that the deleter can be swapped using std::swap (which requires it
to be move cosntructible and move assignable).

The fix is to add __uniq_ptr_impl::swap which swaps the pointer and
deleter individually, instead of using the generic std::swap on the
tuple containing them.

PR libstdc++/93562
* include/bits/unique_ptr.h (__uniq_ptr_impl::swap): Define.
(unique_ptr::swap, unique_ptr::swap): Call it.
* testsuite/20_util/unique_ptr/modifiers/93562.cc: New test.

[Bug c++/93676] [8/9 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] crash   |[8/9 Regression] crash in
   |in build_value_init |build_value_init

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

[Bug libstdc++/93936] [ranges] std::ranges::split_view<...>::_OuterIter<...>::__current() is private within this context

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Patrick Palka  ---
This should be fixed now.

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:38e1002657828150b2cda9f80c1f752184286e80

commit r10-6872-g38e1002657828150b2cda9f80c1f752184286e80
Author: Marek Polacek 
Date:   Wed Feb 19 15:59:33 2020 -0500

c++: Fix value-init crash in template [PR93676]

Since  we
attempt to value-initialize in build_vec_init even when there's no
initializer but the type has a constexpr default constructor.  But
build_value_init doesn't work in templates, and build_vec_init
creates a lot of garbage that would not be used anyway, so don't
call it in a template.

PR c++/93676 - value-init crash in template.
* init.c (build_new_1): Don't call build_vec_init in a template.

* g++.dg/cpp0x/nsdmi-template19.C: New test.

[Bug analyzer/93950] New: ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer

[zsojka at seznam dot cz]

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

Bug ID: 93950
   Summary: ICE: in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4786 with -fanalyzer
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 47916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47916=edit
reduced testcase (from OpenTTD sources)

Compiler output:
$ x86_64-pc-linux-gnu-g++ testcase.C -fanalyzer
during IPA pass: analyzer
testcase.C:10:11: internal compiler error: in
make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
   10 | void *j = nullptr;
  |   ^
0x8b188d
ana::region_model::make_region_for_unexpected_tree_code(ana::region_model_context*,
tree_node*, dump_location_t const&)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:4786
0x8b188d
ana::region_model::make_region_for_unexpected_tree_code(ana::region_model_context*,
tree_node*, dump_location_t const&)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:4782
0x169f0cd ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:4650
0x169f6c3 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:4811
0x1e8852d ana::state_change_event::get_lvalue(tree_node*) const
/repo/gcc-trunk/gcc/analyzer/checker-path.h:206
0x1e8852d ana::diagnostic_manager::prune_for_sm_diagnostic(ana::checker_path*,
ana::state_machine const*, tree_node*, unsigned int) const
/repo/gcc-trunk/gcc/analyzer/diagnostic-manager.cc:1160
0x1e8876e ana::diagnostic_manager::prune_path(ana::checker_path*,
ana::state_machine const*, tree_node*, unsigned int) const
/repo/gcc-trunk/gcc/analyzer/diagnostic-manager.cc:1056
0x1e88a2f ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
/repo/gcc-trunk/gcc/analyzer/diagnostic-manager.cc:520
0x1e894ce ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/repo/gcc-trunk/gcc/analyzer/diagnostic-manager.cc:446
0x1e894ce ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/repo/gcc-trunk/gcc/analyzer/diagnostic-manager.cc:489
0x1681248 ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:3807
0x1681fcc ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3850
0x16766e8 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:84
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20200226101433-gb9934ad88d6-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20200226101433-gb9934ad88d6-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200226 (experimental) (GCC)

[Bug libstdc++/93936] [ranges] std::ranges::split_view<...>::_OuterIter<...>::__current() is private within this context

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:8ce13842b50cbd2676f2e322995182af20df31fe

commit r10-6871-g8ce13842b50cbd2676f2e322995182af20df31fe
Author: Patrick Palka 
Date:   Wed Feb 26 08:38:06 2020 -0500

libstdc++: Fix use of inaccessible private member in split_view (PR93936)

We are calling _OuterIter::__current from _InnerIter::operator==, but the
former
is private within this non-member friend.  Fix this by calling
_OuterIter::operator== instead, which does the right thing here.

libstdc++-v3/ChangeLog:

PR libstdc++/93936
* include/std/ranges (split_view::_InnerIter::operator==): Compare
the operands' _M_i rather than their _M_i.current().
* testsuite/std/ranges/adaptors/split.cc: Augment test.

[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c/93949] New: Register const local var will not compile

[tydeman at tybor dot com]

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

Bug ID: 93949
   Summary: Register const local var will not compile
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tydeman at tybor dot com
  Target Milestone: ---

This valid code will not compile.

int main(void){
  register const double d[3] = { 0., 1., 2. };
  return 0;
}

[Bug libstdc++/93562] [8/9 Regression] unique_ptr::swap incorrectly uses generic std::swap

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:30cb4c78ea6563177c43f897e480d9993c38c0ed

commit r9-8285-g30cb4c78ea6563177c43f897e480d9993c38c0ed
Author: Jonathan Wakely 
Date:   Wed Feb 26 15:04:53 2020 +

libstdc++: Fix regressions in unique_ptr::swap (PR 93562)

The requirements for this function are only that the deleter is
swappable, but we incorrectly require that the element type is complete
and that the deleter can be swapped using std::swap (which requires it
to be move cosntructible and move assignable).

The fix is to add __uniq_ptr_impl::swap which swaps the pointer and
deleter individually, instead of using the generic std::swap on the
tuple containing them.

PR libstdc++/93562
* include/bits/unique_ptr.h (__uniq_ptr_impl::swap): Define.
(unique_ptr::swap, unique_ptr::swap): Call it.
* testsuite/20_util/unique_ptr/modifiers/93562.cc: New test.