[Bug c/88660] [8/9 Regression] Invalid report of "set but used variable" with -O

[alexander.hirsch at gin dot de]

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

--- Comment #5 from Alexander Hirsch  ---
(In reply to Jeffrey A. Law from comment #4)
> Fixed on the trunk for gcc-10.
Thanks :-)

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #29 from Jerry DeLisle  ---
I think this last patch above fixes the last adjustment needed.  I could be
wrong I suppose. Is this ready to close?

[Bug c++/92099] [9/10 Regression] static_assert of struct template of false_type succeed with GCC8 but not GCC9

[sunxuanmailbox at 163 dot com]

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

--- Comment #5 from 孙晅  ---
(In reply to Jason Merrill from comment #4)
> How is this type-dependent?  id is value-dependent, but not type-dependent:
> it has type E.  This seems like a valid (though optional) diagnostic.

But since id is a template argument, by the time of compiling the type of id is
certain, using decltype(id) will give a certain type. And gcc8 already supports
this. It only has problem with gcc9.

[Bug fortran/93522] New: f951: internal compiler error: in gfc_release_symbol, at fortran/symbol.c:3121

[gsocshubham at gmail dot com]

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

Bug ID: 93522
   Summary: f951: internal compiler error: in gfc_release_symbol,
at fortran/symbol.c:3121
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsocshubham at gmail dot com
  Target Milestone: ---

Testcase run on godbolt compiler x86-64 gfortran (trunk) - 

---Testcase

program rank_new
implicit none
integer :: some_var_assumed
integer, DIMENSION(3,2,1) :: array
PRINT *, RANK(array)
   call CALL_ME(array)
   contains
!No error expected
  subroutine CALL_ME23(x)
implicit none
integer:: x(..), a=10,b=20
integer, dimension(10) :: arr = (/1,2,3,4,5/)
select rank(arr(1:3))
RANK(1)
print *, "1"
 rank(2)
print *, "2"
end select
end subroutine
end program

Output (ICE)

./example.f90:12:45:


   12 | integer, dimension(10) :: arr = (/1,2,3,4,5/)

  | 1

Error: Different shape for array assignment at (1) on dimension 1 (10 and 5)

f951: internal compiler error: in gfc_release_symbol, at fortran/symbol.c:3121

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[i at maskray dot me]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #2 from Fangrui Song  ---
On Clang's side. After https://reviews.llvm.org/D73760 , clang -target x86_64
-fpatchable-function-entry=2,0 -fcf-protection=branch -S a.c -g:

.cfi_startproc is placed at the function entry, so that NOPs after the function
entry are in the CFI region
.loc directive is similar. The idea is that addr2line at the function address
should show the correct filename and line, instead of ??:0.

foo:# @foo
.Lfoo$local:
.Lfunc_begin0:
.file   1 "/tmp/c" "a.c"
.loc1 3 0   # a.c:3:0
.cfi_startproc
# %bb.0:# %entry
endbr64
.Lpatch0:
xchgw   %ax, %ax
...
.section   
__patchable_function_entries,"awo",@progbits,foo,unique,0
.p2align3
.quad   .Lpatch0



The section flag "o" and the linkage "unique" (LLVM assembly extensions) are
used to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93197 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195 .

I have filed GNU as feature requests
(https://sourceware.org/bugzilla/show_bug.cgi?id=25380
https://sourceware.org/bugzilla/show_bug.cgi?id=25381). GNU ld needs required
garbage collection semantics
https://sourceware.org/ml/binutils/2019-11/msg00266.html)

[Bug tree-optimization/93521] New: 40% slower in O2 than O1 (tree-pre)

[hehaochen at hotmail dot com]

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

Bug ID: 93521
   Summary: 40% slower in O2 than O1 (tree-pre)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hehaochen at hotmail dot com
  Target Milestone: ---

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

The attached heap sort is ~40% slower in O2 than O1 (slow with tree-pre)


gcc-9 (Homebrew GCC 9.2.0_2) 9.2.0:

  g++-9 -O1 stepanov_vector.cpp -o a.out && ./a.out
>> 7.48 sec 

  g++-9 -O1 -ftree-pre stepanov_vector.cpp -o a.out && ./a.out
>> 12.21 sec

  g++-9 -O2 stepanov_vector.cpp -o a.out && ./a.out
>> 12.25 sec

  g++-9 -O2 -fno-inline-small-functions stepanov_vector.cpp -o a.out && ./a.out
>> 10.72 sec

  g++-9 -O2 -fno-tree-pre stepanov_vector.cpp -o a.out && ./a.out
>> 9.63 sec


while in clang:
Apple clang version 11.0.0 (clang-1100.0.33.17)

  clang++ -O1 stepanov_vector.cpp
>> 38.04 sec

  clang++ -O2 stepanov_vector.cpp
>> 4.85 sec

[Bug analyzer/93520] New: Compilation of Python 3.9 with gcc 10 and -fanalyzer fails with internal compiler error

[cstratak at redhat dot com]

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

Bug ID: 93520
   Summary: Compilation of Python 3.9 with gcc 10 and -fanalyzer
fails with internal compiler error
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: cstratak at redhat dot com
  Target Milestone: ---

Created attachment 47746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47746&action=edit
gcc 10 Python build log

With gcc 10 installed and compiling CPython from its source directory I get an
internal compiler error:

./configure && CFLAGS=-fanalyzer make

Snippet of error:

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
 -fanalyzer  -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter
-Wno-missing-field-initializers -Werror=implicit-function-declaration
-fvisibility=hidden  -I./Include/internal  -I. -I./Include-DPy_BUILD_CORE
-o Objects/floatobject.o Objects/floatobject.c
during IPA pass: analyzer
Objects/floatobject.c: In function ‘_PyFloat_Pack2’:
Objects/floatobject.c:2061:13: internal compiler error: in add_constraint, at
analyzer/constraint-manager.cc:674
 2061 | else if (Py_IS_NAN(x)) {
  | ^

Full log attached.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #27 from Rich Felker  ---
We've hit what seems like almost the exact same issue on gcc 8.3.0 with this
minimized testcase:

void fg(int *);
int get_response(int a)
{
  int b;
  if (a) fg(&b);
  return 0;
}

compiled with -O -c -fstack-protector-strong for sh2eb-linux-muslfdpic. With
gcc 9.2.0 it compiles successfully. I looked for a record of such a fix having
been made, but couldn't find one. Was it a known issue that was fixed silently,
or might it be a lurking bug that's just no longer being hit?

[Bug c++/92169] crash on referring to a local class member by unqualified name from outside the enclosing function

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #4 from Richard Smith  ---
Aha! godbolt.org implicitly adds -g to its command line. Try that; that causes
a crash for this testcase for me with GCC 9.2.1.

[Bug middle-end/93519] New: bogus -Wrestrict for strcpy(d, s) call guarded by d != s

[msebor at gcc dot gnu.org]

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

Bug ID: 93519
   Summary: bogus -Wrestrict for strcpy(d, s) call guarded by d !=
s
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This was reported in RHBZ #1796688 (and previously for memcpy in bug 83456). 
The warning is obviously incorrect here:

#include 

static char *
str_numth(char *dest, char *num, int type)
{
if (dest != num)
strcpy(dest, num);
strcat(dest, "foo");
return dest;
}

void
DCH_to_char(char *in, char *out, int collid)
{
char   *s  = out;

str_numth(s, s, 42);
}

$ gcc -Wall -c -O2 wtest.c
wtest.c: In function 'DCH_to_char':
wtest.c:7:3: warning: 'strcpy' source argument is the same as destination
[-Wrestrict]
7 |   strcpy(dest, num);
  |   ^

[Bug middle-end/93519] bogus -Wrestrict for strcpy(d, s) call guarded by d != s

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1796688
   Last reconfirmed||2020-01-31
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83456
 Blocks||84774
 Ever confirmed|0   |1


Referenced Bugs:

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

[Bug analyzer/93356] ICE in add_constraint, at analyzer/constraint-manager.cc:672

[dmalcolm at gcc dot gnu.org]

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

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/93356] ICE in add_constraint, at analyzer/constraint-manager.cc:672

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6361-ge978955dd720d5cc0e5141a1e9b943a3cc41
Author: David Malcolm 
Date:   Thu Jan 30 12:35:46 2020 -0500

analyzer: fix ICE in __builtin_isnan (PR 93356)

PR analyzer/93356 reports an ICE handling __builtin_isnan due to a
failing assertion:
  674 gcc_assert (lhs_ec_id != rhs_ec_id);
with op=UNORDERED_EXPR.
when attempting to add an UNORDERED_EXPR constraint.

This is an overzealous assertion, but underlying it are various forms of
sloppiness regarding NaN within the analyzer:

  (a) the assumption in the constraint_manager that equivalence classes
  are reflexive (X == X), which isn't the case for NaN.

  (b) Hardcoding the "honor_nans" param to false when calling
  invert_tree_comparison throughout the analyzer.

  (c) Ignoring ORDERED_EXPR, UNORDERED_EXPR, and the UN-prefixed
  comparison codes.

I wrote a patch for this which tracks the NaN-ness of floating-point
values and uses this to address all of the above.

However, to minimize changes in gcc 10 stage 4, here's a simpler patch
which rejects attempts to query or add constraints on floating-point
values, instead treating any floating-point comparison as "unknown", and
silently dropping the constraints at edges.

gcc/analyzer/ChangeLog:
PR analyzer/93356
* region-model.cc (region_model::eval_condition): In both
overloads, bail out immediately on floating-point types.
(region_model::eval_condition_without_cm): Likewise.
(region_model::add_constraint): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/93356
* gcc.dg/analyzer/conditionals-notrans.c (test_float_selfcmp):
Add.
* gcc.dg/analyzer/conditionals-trans.c: Mark floating point
comparison test as failing.
(test_float_selfcmp): Add.
* gcc.dg/analyzer/data-model-1.c: Mark floating point comparison
tests as failing.
* gcc.dg/analyzer/torture/pr93356.c: New test.

gcc/ChangeLog:
PR analyzer/93356
* doc/analyzer.texi (Limitations): Note that constraints on
floating-point values are currently ignored.

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[i at maskray dot me]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #8 from Fangrui Song  ---
Where shall we place .cfi_startproc?

Clang HEAD (and clang 10)'s placement is:

foo:
.loc 1 3 0  # line number
.cfi_startproc  # CFI
  bti c
.Lpatch0:   # __patchable_function_entries label
  nop

Not placing .cfi_startproc (as GCC current does) will make addr2line on the
function entry address print ??:0

For M>0, clang does not attach line number information for NOPs before the
function entry label.

[Bug analyzer/93457] ICE in make_region_for_type, at analyzer/region-model.cc:5983

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
It's probably a duplicate of PR93511 now.

[Bug tree-optimization/93440] scalar unrolled loop makes vectorized code unreachable

[ikonomisma at googlemail dot com]

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

--- Comment #4 from ikonomisma at googlemail dot com ---
I can reproduce this on both x86_64 and AArch64 Ubuntu 19.10.

According to an answer to my question on stack overflow
(https://stackoverflow.com/a/59995702/3185968), using std::transform without an
execution policy requires a recent libstdc++
(https://github.com/gcc-mirror/gcc/commit/b93041f0d3c9a2fc64f0f5fb538e78d5e2001d32).

The issue is reproducible on godbolt.org: https://godbolt.org/z/fZdAqp

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
This is the fix, thought I recall it broke something.  But we want to use fold_
here because we can have a non-dependent template code like CAST_EXPR.

--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -981,7 +981,7 @@ check_narrowing (tree type, tree init, tsubst_flags_t
complain,
   return ok;
 }

-  init = maybe_constant_value (init);
+  init = fold_non_dependent_expr (init, complain);

   /* If we were asked to only check constants, return early.  */
   if (const_only && !TREE_CONSTANT (init))

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

[msebor at gcc dot gnu.org]

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

Bug ID: 93518
   Summary: missing warning on a possible overflow by sprintf %s
with an allocated argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below only the sprintf call in first function is diagnosed for
the potential overflow, not the second.  They both should be.  The problem is
that the get_range_strlen_dynamic() function doesn't detect the size of the
allocated object.

$ cat a.c && gcc -O2 -S -Wall -Wextra a.c
char a5[5], a7[7];

void f (void*);

int g (void)
{
  f (a7);

  return __builtin_sprintf (a5, "%s", a7);   // warning (good)
}

int h (void)
{
  char *p7 = __builtin_malloc (7);

  f (p7);

  return __builtin_sprintf (a5, "%s", p7);   // missing warning
}
a.c: In function ‘g’:
a.c:9:34: warning: ‘%s’ directive writing up to 6 bytes into a region of size 5
[-Wformat-overflow=]
9 |   return __builtin_sprintf (a5, "%s", a7);   // warning (good)
  |  ^~   ~~
a.c:9:10: note: ‘__builtin_sprintf’ output between 1 and 7 bytes into a
destination of size 5
9 |   return __builtin_sprintf (a5, "%s", a7);   // warning (good)
  |  ^~~~

[Bug target/91320] [9/10 Regression] x86-64 code generation / register allocation regressed.

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jeffrey A. Law from comment #3)
> 
> One might consider raising the priority of allocnos which are more sensitive
> to what register they're allocated to.  But that's a risky proposition and
> would have to be extensively benchmarked to determine its impact, assuming
> we could even come up proposed heuristics in this space.
> 
> 
> Anyway, I'm cc-ing Vlad as our register allocation expert so that he can
> take a looksie.  I'll also attach a usable testcase.

Jeff, thank you for the test and the PR analysis.

I've been working on analogous PRs (e.g. PR91333).

I've tried many new heuristics, mostly on sorting colorable allocno stack
(taking allocno live ranges, allocno (or thread) hard preferences, conflicting
(or thread) allocnos hard reg preferences for any allocnos, allocnos living in
BB, etc).  The problem is that the heuristics worsen SPEC benchmarks in many
cases.

But I think I found simple heuristics which are improving the PRs code and do
not change SPEC.  I hope the patch will be ready on this week or the next week.

[Bug middle-end/93517] New: bogus -Wrestrict on sprintf with unknown strings bounded by array size

[msebor at gcc dot gnu.org]

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

Bug ID: 93517
   Summary: bogus -Wrestrict on sprintf with unknown strings
bounded by array size
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The warning below is incorrect because (assuming a is a nul-terminated string)
the length of s1 must be at most 1 and the length of s2 is necessarily zero. 
As a result, the sprintf call writes at most two bytes into the array while
reading from it beginning at offset 2.

$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
char a[4];

void f (void)
{
  char *d = a;
  char *s1 = a + 2;
  char *s2 = a + 3;

  __builtin_sprintf (d, "%s%s", s1, s2);
}
a.c: In function ‘f’:
a.c:9:3: warning: ‘__builtin_sprintf’ arguments 3, 4 may overlap destination
object ‘a’ [-Wrestrict]
9 |   __builtin_sprintf (d, "%s%s", s1, s2);
  |   ^
a.c:1:6: note: destination object referenced by ‘restrict’-qualified argument 1
was declared here
1 | char a[4];
  |  ^

;; Function f (f, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=1)

f ()
{
   [local count: 1073741824]:
  __builtin_sprintf (&a, "%s%s", &MEM  [(void *)&a + 2B], &MEM
 [(void *)&a + 3B]); [tail call]
  return;

}

[Bug c++/14179] [8/9/10 Regression] out of memory while parsing array with many initializers

[jason at gcc dot gnu.org]

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

--- Comment #80 from Jason Merrill  ---
(In reply to Richard Biener from comment #77)
> So the "low hanging fruit" remaining is reshape_init_array copying the whole
> array even if not necessary.
> 
> INTEGER_CSTs still account for most of the memory use (200MB) apart from C++
> preprocessor tokens (530MB) and the actual array of tree pointers for the
> constructors (2x 130MB at peak).

Still true, plus location wrappers.  I think I'll look at turning off location
wrappers in the initializer for a large array.

Significant lines from -fmem-report:

GGC memory  Leak  Garbage  
 FreedOverheadTimes

cp/parser.c:23438 (cp_parser_initializer_list)   0 :  0.0%  128M:
16.7%  128M:  9.1%  160 :  0.1%   22 
cp/parser.c:657 (cp_lexer_new_main)  0 :  0.0%0 : 
0.0%  511M: 36.3%   72 :  0.1%9 
tree.c:14891 (maybe_wrap_with_location)  0 :  0.0%  511M:
66.7%0 :  0.0%0 :  0.0%   15M
hash-table.h:802 (expand)0 :  0.0%0 : 
0.0%  511M: 36.4% 1616 :  1.4%   17 
cp/decl.c:6021 (reshape_init_array_1)0 :  0.0%  128M:
16.7%  128M:  9.1%  160 :  0.1%   22 
tree-inline.c:5499 (copy_tree_r)   128M: 28.4%0 : 
0.0%0 :  0.0%8 :  0.0%1 
hash-table.h:802 (expand)  128M: 28.4%0 : 
0.0%  127M:  9.1%  648 :  0.6%   13 
tree.c:1615 (wide_int_to_tree_1)   191M: 42.7%  240 : 
0.0%0 :  0.0%0 :  0.0% 8191k

[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Jeffrey A. Law  ---
*** Bug 93125 has been marked as a duplicate of this bug. ***

[Bug target/93125] ICE in insert_regs, at cse.c:1128

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #2 from Jeffrey A. Law  ---
Almost certainly a dup.  There's another likely dup lying around as well.

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

[Bug c++/93496] Miscompile of range-for over braced-init-list in constructor of class with virtual inheritance

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk by r266893 for PR 86669, which doesn't seem related.

That change was backported to the gcc-8 branch as r267702 for GCC 8.3 which
doesn't explain how it was fixed for GCC 8.2

[Bug c/88660] [8/9 Regression] Invalid report of "set but used variable" with -O

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] Invalid |[8/9 Regression] Invalid
   |report of "set but used |report of "set but used
   |variable" with -O   |variable" with -O

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk for gcc-10.

[Bug c/88660] [8/9/10 Regression] Invalid report of "set but used variable" with -O

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r10-6360-gf9eb0973edb2b4eed4cdbba7105b8af7afe5b547
Author: Jeff Law 
Date:   Thu Jan 30 14:09:41 2020 -0700

Mark switch expression as used to avoid bogus warning

PR c/88660
* c-parser.c (c_parser_switch_statement): Make sure to request
marking the switch expr as used.

PR c/88660
* gcc.dg/pr88660.c: New test.

[Bug fortran/93501] [10 regression] gfortran.dg/pr93473.f90 ICEs starting with r10-6295

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Yup, thanks!

[Bug tree-optimization/93516] New: [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342

[dimhen at gmail dot com]

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

Bug ID: 93516
   Summary: [10 regression] ICE in verify_sra_access_forest, at
tree-sra.c:2342
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r10-6309 PASS
r10-6342 FAIL

$ cat x.ii
struct b;
struct c {
  b *operator->();
};
class e {
  void *f;
  int d;

public:
  template  a g() { return *static_cast(this); }
};
struct h : e {};
struct b {
  void i(e);
  e j();
};
void m() {
  c k;
  h l = k->j().g();
  k->i(l);
}

$ g++ -fpreprocessed -fchecking=1 -O  -c x.ii
during GIMPLE pass: esra
x.ii: In function 'void m()':
x.ii:21:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2342
   21 | }
  | ^
0x816180 verify_sra_access_forest(access*)
/home/dimhen/src/gcc_current/gcc/tree-sra.c:2342
0x132d031 verify_all_sra_access_forests()
/home/dimhen/src/gcc_current/gcc/tree-sra.c:2387
0x13319cf analyze_all_variable_accesses
/home/dimhen/src/gcc_current/gcc/tree-sra.c:3381
0x1331eff perform_intra_sra
/home/dimhen/src/gcc_current/gcc/tree-sra.c:4432
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/92434] [DR 2355] noexcept couldn't be deduced in function template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|noexcept couldn't be|[DR 2355] noexcept couldn't
   |deduced in function |be deduced in function
   |template|template

--- Comment #6 from Marek Polacek  ---
Thanks for that reference, I'll update
https://gcc.gnu.org/projects/cxx-dr-status.html

[Bug c++/92434] noexcept couldn't be deduced in function template

[nok.raven at gmail dot com]

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

--- Comment #5 from Nikita Kniazev  ---
> but does [temp.deduct] actually require that this works?

Judging by CWG 2355 it does not.

[Bug c++/92434] noexcept couldn't be deduced in function template

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
That should probably be 
+ if (spec && TREE_PURPOSE (spec) && deducible_expression (TREE_PURPOSE
(spec)))

Note that clang fails if noexcept(B) is changed to e.g. noexcept(!B).

[Bug c++/92434] noexcept couldn't be deduced in function template

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
To match clang we could use 

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21470,6 +21470,12 @@ uses_deducible_template_parms (tree type)
   for (; parm; parm = TREE_CHAIN (parm))
if (uses_deducible_template_parms (TREE_VALUE (parm)))
  return true;
+  if (flag_noexcept_type)
+   {
+ tree spec = TYPE_RAISES_EXCEPTIONS (type);
+ if (deducible_expression (TREE_PURPOSE (spec)))
+   return true;
+   }
 }

   return false;

[Bug c++/92434] noexcept couldn't be deduced in function template

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Extended testcase:

template
void foo_false(void(*)() noexcept(B))
{
  static_assert (!B);
}

template
void foo_true(void(*)() noexcept(B))
{
  static_assert (B);
}

void f();
void fn() noexcept;

void bar()
{
  foo_false(&f);
  foo_true(&fn);
}

but does [temp.deduct] actually require that this works?

[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:5fb07870fa4c86f529930bae76689ed5bdfcb192

commit r10-6359-g5fb07870fa4c86f529930bae76689ed5bdfcb192
Author: Jakub Jelinek 
Date:   Thu Jan 30 21:32:36 2020 +0100

cgraph: Avoid creating multiple *.localalias aliases with the same name
[PR93384]

The following testcase FAILs on powerpc64le-linux with assembler errors, as
we
emit a call to bar.localalias, then .set bar.localalias, bar twice and then
another call to bar.localalias.  The problem is that bar.localalias can be
created
at various stages and e.g. ipa-pure-const can slightly adjust the original
decl,
so that the existing bar.localalias isn't considered usable (different
flags_from_decl_or_type).  In that case, we'd create another
bar.localalias, which
clashes with the existing name.

Fixed by retrying with another name if it is already present.  The various
localalias
aliases shouldn't be that many, from different partitions they would be
lto_priv
suffixed and in most cases they would already have the same
type/flags/attributes.

2020-01-30  Jakub Jelinek  

PR lto/93384
* symtab.c (symtab_node::noninterposable_alias): If localalias
already exists, but is not usable, append numbers after it until
a unique name is found.  Formatting fix.

* gcc.dg/lto/pr93384_0.c: New test.
* gcc.dg/lto/pr93384_1.c: New file.

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:56b92750f83724177d2c6eae30c208e935a56a37

commit r10-6358-g56b92750f83724177d2c6eae30c208e935a56a37
Author: Jakub Jelinek 
Date:   Thu Jan 30 21:28:17 2020 +0100

combine: Punt on out of range rotate counts [PR93505]

What happens on this testcase is with the out of bounds rotate we get:
Trying 13 -> 16:
   13: r129:SI=r132:DI#0<-<0x20
  REG_DEAD r132:DI
   16: r123:DI=r129:SI<0
  REG_DEAD r129:SI
Successfully matched this instruction:
(set (reg/v:DI 123 [  ])
(const_int 0 [0]))
during combine.  So, perhaps we could also change simplify-rtx.c to punt
if it is out of bounds rather than trying to optimize anything.
Or, but probably GCC11 material, if we decide that ROTATE/ROTATERT doesn't
have out of bounds counts or introduce targetm.rotate_truncation_mask,
we should truncate the argument instead of punting.
Punting is better for backports though.

2020-01-30  Jakub Jelinek  

PR middle-end/93505
* combine.c (simplify_comparison) : Punt on out of range
rotate counts.

* gcc.c-torture/compile/pr93505.c: New test.

[Bug target/70682] [9/10 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|10.0|11.0

[Bug sanitizer/79096] [8/9/10 Regression] address sanitizer and jni does not work

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|10.0|11.0

[Bug middle-end/93514] missing warning on a strlen with a negative or just past-the-end offset

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #3)
> There is no tail padding at ax2.a + 3, it's just past the end of the the
> four-byte object because ax2.a is at offset 1.

You're right, I was convinced I saw int i; char a[]; but it isn't there that
way.
Anyway, one needs to be careful about flexible array members and similar tail
arrays.

[Bug libgomp/93515] New: OpenMP target teams distribute parallel for with defaultmap not mapping correctly

[jhdavis at udel dot edu]

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

Bug ID: 93515
   Summary: OpenMP target teams distribute parallel for with
defaultmap not mapping correctly
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhdavis at udel dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47745&action=edit
Target teams distribute parallel for defaultmap reproducible

Hello,

This is a bug found by the SOLLVE team.

--- SUMMARY ---
When using defaultmap(tofrom:scalar) on a target teams distribute parallel for
construct, we are seeing a failure to map back changes to scalars made on the
device. See the attached reproducible. The test in out suite is availible here:
https://github.com/SOLLVE/sollve_vv/blob/new_test/test_target_teams_distribute_defaultmap.F90/tests/4.5/target_teams_distribute_parallel_for/test_target_teams_distribute_parallel_for_defaultmap.c

--- DETAILS ---
gfortran version: 9.2.0

System: x86_64-pc-linux-gnu

Config options: 
../gcc9.2/configure --enable-offload-targets=nvptx-none
--with-cuda-driver-include=/software/apps/cuda/9.2//include
--with-cuda-driver-lib=/software/apps/cuda/9.2//lib64 --disable-bootstrap
--disable-multilib --enable-languages=c,c++,fortran,lto
--prefix=/software/apps/gcc/9.2

No compiler output. Runtime output:
Test returned 6 errors.

Command line to trigger bug:
gcc -O3 -std=c99 -fopenmp -foffload="-lm" -lm ttdpf_defaultmap.c -o
ttdpf_defaultmap.c.o
./ttdpf_defaultmap.c.o

Best,

Josh Davis

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-05-07 00:00:00 |2020-01-30
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug target/91320] [9/10 Regression] x86-64 code generation / register allocation regressed.

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
Created attachment 47744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47744&action=edit
gzipped testcase that should work with gcc-10

[Bug target/91320] [9/10 Regression] x86-64 code generation / register allocation regressed.

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||law at redhat dot com,
   ||vmakarov at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
So here's the pushing to the coloring and assignment from IRA:

 Pushing a1(r103,l0)(cost 0)
  Pushing a9(r106,l0)(cost 0)
  Pushing a3(r95,l0)(cost 0)
  Pushing a10(r105,l0)(cost 0)
  Pushing a2(r93,l0)(cost 0)
  Pushing a5(r82,l0)(cost 0)
  Pushing a7(r96,l0)(cost 0)
  Pushing a6(r98,l0)(cost 0)
  Pushing a17(r100,l0)(cost 0)
  Pushing a0(r92,l0)(cost 0)
  Pushing a4(r91,l0)(cost 0)
  Popping a4(r91,l0)  -- assign reg 0
  Popping a0(r92,l0)  -- assign reg 36
  Popping a17(r100,l0)  -- assign reg 1
  Popping a6(r98,l0)  -- assign reg 2
  Popping a7(r96,l0)  -- assign reg 2
  Popping a5(r82,l0)  -- assign reg 37
  Popping a2(r93,l0)  -- assign reg 5
  Popping a10(r105,l0)  -- assign reg 5
  Popping a3(r95,l0)  -- assign reg 4
  Popping a9(r106,l0)  -- assign reg 4
  Popping a1(r103,l0)  -- assign reg 0

Note how allocno 4 gets pushed after allocno 4.  That's because allocno 4 has a
higher frequency.  As a result allocno 4 gets popped before allocno 0.  Allocno
4 gets the first crack at getting assigned %eax (and allocno 4 really doesn't
care what register it gets as long as it's GENERAL_REGS).


And since a4 and a0 conflict, a0 can't get %eax which results in the extra move
instruction.


Which isn't really a surprise as a4 is used more within the loop and is thus a
higher priority to allocate.

One might consider raising the priority of allocnos which are more sensitive to
what register they're allocated to.  But that's a risky proposition and would
have to be extensively benchmarked to determine its impact, assuming we could
even come up proposed heuristics in this space.


Anyway, I'm cc-ing Vlad as our register allocation expert so that he can take a
looksie.  I'll also attach a usable testcase.

[Bug middle-end/93514] missing warning on a strlen with a negative or just past-the-end offset

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
There is no tail padding at ax2.a + 3, it's just past the end of the the
four-byte object because ax2.a is at offset 1.

-Warray-bounds takes tail padding into consideration by calling
component_ref_size().  That can be seen on a test case like this:

$ cat a.c && gcc -O2 -S -Wall -Wextra a.c
struct Ax { int i; char j, a[]; };

struct Ax ax = { 1, 2, { 3 } };

void f (void)
{
  ax.a[0] = 3;
  ax.a[1] = 2;
  ax.a[2] = 1;
  ax.a[3] = 0;   // -Warray-bounds
}

int g (void)
{
  return __builtin_strlen (&ax.a[3]);   // missing -Warray-bounds
}

a.c: In function ‘f’:
a.c:10:7: warning: array subscript 3 is above array bounds of ‘char[0]’
[-Warray-bounds]
   10 |   ax.a[3] = 0;   // -Warray-bounds
  |   ^~~
a.c:1:28: note: while referencing ‘a’
1 | struct Ax { int i; char j, a[]; };
  |^
a.c:3:11: note: defined here ‘ax’
3 | struct Ax ax = { 1, 2, { 3 } };
  |   ^~

(The reference to 'char[0]' in the warning isn't quite correct: it should be
'char[]'.  This is the subject of pr92326.)

[Bug c++/92319] Macro expansion using the __VAOPT__ construct is incorrect when the variadic argument expands to nothing

[eldlistmailingz at tropicsoft dot com]

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

Edward Diener  changed:

   What|Removed |Added

 CC||eldlistmailingz@tropicsoft.
   ||com

--- Comment #2 from Edward Diener  ---
Created attachment 47743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47743&action=edit
C++ source file to illustrate bug report

Command lines on Fedora 31:

gcc.compile.c++
/home/fceldiener/build/boost/bin.v2/libs/test_local/test/test_gcc_vaopt_bug.test/gcc-c20-9.2/debug/threading-multi/visibility-hidden/test_gcc_vaopt_bug.o

"/usr/bin/g++"   -fvisibility-inlines-hidden -fPIC -m64 -pthread -O0
-fno-inline -Wall -g -fvisibility=hidden -std=c++2a -DBOOST_ALL_NO_LIB=1 
-I"../../.." -c -o
"/home/fceldiener/build/boost/bin.v2/libs/test_local/test/test_gcc_vaopt_bug.test/gcc-c20-9.2/debug/threading-multi/visibility-hidden/test_gcc_vaopt_bug.o"
"test_gcc_vaopt_bug.cpp"

gcc.link
/home/fceldiener/build/boost/bin.v2/libs/test_local/test/test_gcc_vaopt_bug.test/gcc-c20-9.2/debug/threading-multi/visibility-hidden/test_gcc_vaopt_bug

"/usr/bin/g++"-o
"/home/fceldiener/build/boost/bin.v2/libs/test_local/test/test_gcc_vaopt_bug.test/gcc-c20-9.2/debug/threading-multi/visibility-hidden/test_gcc_vaopt_bug"
-Wl,--start-group
"/home/fceldiener/build/boost/bin.v2/libs/test_local/test/test_gcc_vaopt_bug.test/gcc-c20-9.2/debug/threading-multi/visibility-hidden/test_gcc_vaopt_bug.o"
 -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -fPIC -m64 -pthread -g
-fvisibility=hidden -fvisibility-inlines-hidden 

Ouptut:



*

__cplusplus = 201709

*

Success: F()   
   f(0 )
Failure: F(EMP)
   f(0 , ) [expected]: f(0)


*

[Bug target/33989] Extra load/store for float with union

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED
   Target Milestone|--- |9.0

--- Comment #18 from Andrew Pinski  ---
.

[Bug c++/92402] parsing error in lambda trail return type with decltype, statement expressions and structured bindings

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Not a regression though, so I'll leave it for GCC 11.

[Bug c++/92402] parsing error in lambda trail return type with decltype, statement expressions and structured bindings

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Even shorter:

int a[1];
void f() {
  []() -> decltype(({auto&& [x] = a; 0;})) { return 0; };
}

clang++ compiles it.

[Bug middle-end/93514] missing warning on a strlen with a negative or just past-the-end offset

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The array is flexible array member and a2.a + 3 points to tail padding in the
structure, I think it is just fine to store something in there.

[Bug c/89129] [meta-bug] bogus/missing -Wtype-limits warnings

[jason at gcc dot gnu.org]

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

Bug 82521 Summary: [8/9 Regression] No -Wtype-limits warning when using 
templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82521

   What|Removed |Added

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

[Bug c++/82521] [8/9 Regression] No -Wtype-limits warning when using templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.4 |10.0
Summary|[8/9/10 Regression] No  |[8/9 Regression] No
   |-Wtype-limits warning when  |-Wtype-limits warning when
   |using templates |using templates

--- Comment #8 from Jason Merrill  ---
Fixed for GCC 10, I'm not inclined to backport missed warning fixes.

[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 #41 from Jason Merrill  ---
(In reply to Jason Merrill from comment #38)
> This is better:

Complete revised testcase:

#ifdef USE_STD

#include 
using std::optional;

#else

using size_t = decltype(sizeof(1));
inline void *operator new (size_t, void *p) { return p; }
template
struct optional
{
  optional () : m_dummy (), live (false) {}
  void emplace () { new (&m_item) T (); live = true; }
  ~optional () { if (live) m_item.~T (); }

  union
  {
struct {} m_dummy;
T m_item;
  };
  bool live;
};

#endif

extern int get ();
extern void set (int);

struct A
{
  A () : m (get ()) {}
  ~A () { set (m); }

  int m;
};

struct B
{
  B ();
  ~B ();
};

void func ()
{
  optional maybe_a;
  optional maybe_b;

  maybe_a.emplace ();
  maybe_b.emplace ();
}

[Bug c++/92194] [9/10 Regression] maybe-uninitialized false positive with c++2a since r9-84-gcdc184174ce56df1

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Yep, same issue.

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

[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

Jason Merrill  changed:

   What|Removed |Added

 CC||malcolm.parsons at gmail dot 
com

--- Comment #40 from Jason Merrill  ---
*** Bug 92194 has been marked as a duplicate of this bug. ***

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[jason at gcc dot gnu.org]

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

Bug 92194 Summary: [9/10 Regression] maybe-uninitialized false positive with 
c++2a since r9-84-gcdc184174ce56df1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92194

   What|Removed |Added

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

[Bug c++/82521] [8/9/10 Regression] No -Wtype-limits warning when using templates

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4dd468a042e19ef0fdbb1c53ca4060d4cb4972c5

commit r10-6357-g4dd468a042e19ef0fdbb1c53ca4060d4cb4972c5
Author: Jason Merrill 
Date:   Thu Jan 30 13:12:05 2020 -0500

c++: Fix -Wtype-limits in templates.

When instantiating a template tsubst_copy_and_build suppresses
-Wtype-limits
warnings about e.g. == always being false because it might not always be
false for an instantiation with other template arguments.  But we should
warn if the operands don't depend on template arguments.

PR c++/82521
* pt.c (tsubst_copy_and_build) [EQ_EXPR]: Only suppress warnings if
the expression was dependent before substitution.

[Bug c++/91212] [8/9/10 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Jason, do you want to change anything here?  Though clang/icc/msvc++ seem to
choose #1.

[Bug middle-end/93514] missing warning on a strlen with a negative or just past-the-end offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||56456

--- Comment #1 from Martin Sebor  ---
The warning code should trigger for all calls to functions that expect string
arguments (certainly all such built-ins).

Diagnosing also calls to user-defined functions with past-the-end pointers
could cause false positives when they delineate a range, as in:

  void f (char *begin, char *end);

  void g (void)
  {
char a[3];
f (a, a + 3);
  }

It might be worth at least diagnosing calls to functions that take just one
pointer, or where all pointers are of different types or point to distinct
objects.


Referenced Bugs:

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

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Another test:

enum class error {};
template 
void afunction(F) {
  error{char(0)};
}

93513.C: In function ‘void afunction(F)’:
93513.C:4:16: internal compiler error: unexpected expression ‘(char)(0)’ of
kind cast_expr
4 |   error{char(0)};
  |^
0x99fc89 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6141
0x9a0fcd cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6339
0x9a20c0 maybe_constant_value(tree_node*, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6616
0xcbcae7 check_narrowing(tree_node*, tree_node*, int, bool)
/home/mpolacek/src/gcc/gcc/cp/typeck2.c:984
0xa1f273 reshape_init(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl.c:6483
0xc3c209 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:2945
0xb585f6 cp_parser_functional_cast
/home/mpolacek/src/gcc/gcc/cp/parser.c:29437
0xb2b336 cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7145
0xb2ebfa cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:8525
0xb30064 cp_parser_cast_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9416
0xb30151 cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9519
0xb30f91 cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9824
0xb31348 cp_parser_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9992
0xb34fa2 cp_parser_expression_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11642
0xb3486f cp_parser_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11438
0xb35516 cp_parser_statement_seq_opt
/home/mpolacek/src/gcc/gcc/cp/parser.c:11789
0xb353fa cp_parser_compound_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11739
0xb4b1f5 cp_parser_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:22984
0xb4b519 cp_parser_ctor_initializer_opt_and_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:23035
0xb56e22 cp_parser_function_definition_after_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:28867
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/93513] internal compiler error internal compiler error: unexpected expression ‘(char)(e)’ of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek  ---
Must be the same problem as in 91465, but the additional test is very useful.

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

[Bug c++/91465] [9/10 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

 CC||andij.cr at gmail dot com

--- Comment #2 from Marek Polacek  ---
*** Bug 93513 has been marked as a duplicate of this bug. ***

[Bug c++/93513] internal compiler error internal compiler error: unexpected expression ‘(char)(e)’ of kind cast_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-30
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
IT ICEs in check_narrowing, that's got to be mine.

[Bug middle-end/93514] New: missing warning on a strlen with a negative or just past-the-end offset

[msebor at gcc dot gnu.org]

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

Bug ID: 93514
   Summary: missing warning on a strlen with a negative or just
past-the-end offset
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Of the three calls with invalid arguments in the test case below only the last
one is diagnosed.

The negative offset isn't diagnosed because it points to ax2.i, so it's in
bounds of ax2.  The offset +3 isn't diagnosed because the pointer is valid
(though just past the end) and the warning code in tree-vrp.c doesn't consider
how it's being used.

$ cat u.c && gcc -O2 -S -Wall -Wextra u.c
struct Ax { char i, a[]; };

static struct Ax ax2 = { 2, { 2, 1, 0 } };

void sink (int);

void f (void)
{
  sink (__builtin_strlen (ax2.a - 1));   // { dg-warning "\\\[-Warray-bounds" }
  sink (__builtin_strlen (ax2.a));
  sink (__builtin_strlen (ax2.a + 1));
  sink (__builtin_strlen (ax2.a + 2));
  sink (__builtin_strlen (ax2.a + 3));   // { dg-warning "\\\[-Warray-bounds" }
  sink (__builtin_strlen (ax2.a + 4));   // { dg-warning "\\\[-Warray-bounds" }
}
u.c: In function ‘f’:
u.c:14:9: warning: array subscript 5 is outside array bounds of ‘struct Ax[1]’
[-Warray-bounds]
   14 |   sink (__builtin_strlen (ax2.a + 4));   // { dg-warning
"\\\[-Warray-bounds" }
  | ^~~~
u.c:3:18: note: while referencing ‘ax2’
3 | static struct Ax ax2 = { 2, { 2, 1, 0 } };
  |  ^~~

[Bug fortran/92587] Compiler is unable to generate finalization wrapper

[liakhdi at ornl dot gov]

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

--- Comment #4 from DIL  ---
Sorry, I was removing unnecessary dependencies in order to reduce the
reproducer source size, but forgot to remove PRIVATE declaration for the
deleted procedures. Now fixed. It builds with gfortran-8.x but produces ICE
with gfortran-9.x.

[Bug fortran/92587] Compiler is unable to generate finalization wrapper

[liakhdi at ornl dot gov]

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

--- Comment #3 from DIL  ---
(In reply to Martin Liška from comment #1)
> For older GCC 8 I see:
> 
> tensor_recursive.F90:738:36:
> 
>  private TensBodyGetDataDescr
> 1
> Error: Symbol ‘tensbodygetdatadescr’ at (1) has no IMPLICIT type; did you
> mean ‘tensbodygetdatatype’?
> tensor_recursive.F90:734:35:
> 
>  private TensBodySetLocation
>1
> Error: Symbol ‘tensbodysetlocation’ at (1) has no IMPLICIT type; did you
> mean ‘tensbodygetdatatype’?
> tensor_recursive.F90:714:38:
> 
>  private TensLayoutGetDataDescr
>   1
> Error: Symbol ‘tenslayoutgetdatadescr’ at (1) has no IMPLICIT type; did you
> mean ‘tenslayoutgetdatatype’?
> tensor_recursive.F90:706:37:
> 
>  private TensLayoutSetLocation
>  1
> Error: Symbol ‘tenslayoutsetlocation’ at (1) has no IMPLICIT type; did you
> mean ‘tenslayoutgetbodysize’?
> tensor_recursive.F90:768:37:
> 
>  private TensRcrsvGetDataDescr
>  1
> Error: Symbol ‘tensrcrsvgetdatadescr’ at (1) has no IMPLICIT type; did you
> mean ‘tensrcrsvgetdatatype’?
> tensor_recursive.F90:769:36:
> 
>  private TensRcrsvSetLocation
> 1
> Error: Symbol ‘tensrcrsvsetlocation’ at (1) has no IMPLICIT type; did you
> mean ‘tensrcrsvgetlayout’?
> 
> Is it really a valid code?

[Bug fortran/92587] Compiler is unable to generate finalization wrapper

[liakhdi at ornl dot gov]

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

--- Comment #2 from DIL  ---
Created attachment 47742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47742&action=edit
Updated ICE reproducer

Fixed build issues for gfortran-8. Builds with gfortran-8.x but produces ICE
with gfortran-9.x.

[Bug tree-optimization/84050] [8/9/10 Regression] missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2018-01-26 00:00:00 |2020-1-30
  Known to fail||10.0, 9.2.0

--- Comment #5 from Martin Sebor  ---
No improvement in GCC 9.2.0 or 10.0.

[Bug c++/93513] New: internal compiler error internal compiler error: unexpected expression ‘(char)(e)’ of kind cast_expr

[andij.cr at gmail dot com]

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

Bug ID: 93513
   Summary: internal compiler error internal compiler error:
unexpected expression ‘(char)(e)’ of kind cast_expr
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andij.cr at gmail dot com
  Target Milestone: ---

compiling this c++ code

enum class error {};
template 
void afunction(F) {
  error{char(0)};
}


with g++ 9.2
with std=c++17 or std=c++20

will give 
internal compiler error: unexpected expression ‘(char)(0)’ of kind cast_expr
4 |   error{char(0)};
  |^

in contrast, with std=c++14:
error: cannot convert ‘char’ to ‘error’ in initialization
4 |   error{char(0)};
  | ^~~
  | |
  | char


checking with compiler explorer, it seems that gcc 8.3 does not generate this
error: https://gcc.godbolt.org/z/yZ9ckH

[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WORKSFORME

--- Comment #10 from Jeffrey A. Law  ---
Per various comments.  If you can still get this to trigger with the trunk or
something close to it, repoen.

[Bug middle-end/93512] New: Introduce rotate_truncation_mask

[dje at gcc dot gnu.org]

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

Bug ID: 93512
   Summary: Introduce rotate_truncation_mask
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, segher at gcc dot gnu.org
Depends on: 93505
  Target Milestone: ---

 i386.md has ;; Avoid useless masking of count operand.
 (define_insn_and_split "*3_mask"
 and (define_insn_and_split "*3_mask_1"
 for this purpose
 yeah...  but that catches not all cases at all.  but the common ones,
sure
 the other option is to say that in RTL all rotate counts are well
defined and so effectively have implicit ROTATE_COUNT_TRUNCATED
 or introduce rotate_truncation_mask with a default that will truncate
and let weirdo targets opt out
 yes, i think that would help all targets
 in any case, that looks like GCC 11 material to me
 because one would need to check all code that works with rotates, do
the masking, ensure simplify-rtx.c simplifies it etc.
 would need to be a property of ROTATE/ROTATERT, because e.g. for
library implementation if it is done using shifts we don't want to introduce UB
there
 so with the combine.c change you've acked perhaps we could defer the
rest for GCC11 (and at that point change even that hunk to do % prec


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
[Bug 93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and
rotation at -Og

[Bug ipa/92749] [10 Regression] warning: inlining failed in call to ‘salsa20’: --param max-inline-insns-single limit reached after r276516

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |INVALID

--- Comment #3 from Jeffrey A. Law  ---
Per c#2

[Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
The original problem still applies.

[Bug fortran/93501] [10 regression] gfortran.dg/pr93473.f90 ICEs starting with r10-6295

[abensonca at gmail dot com]

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

--- Comment #2 from Andrew Benson  ---
PR87103 is now resolved, which should also solve this problem.

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

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

--- Comment #10 from Andrew Benson  ---
PR87103 is now resolved, which should also solve this problem.

[Bug fortran/91773] Buffer overflow for long module/submodule names

[abensonca at gmail dot com]

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

Bug 87103 Summary: [OOP] ICE in gfc_new_symbol() due to overlong symbol name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

   What|Removed |Added

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

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

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

Andrew Benson  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Benson  ---
Resolved by the above commit.

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Andrew Benson :

https://gcc.gnu.org/g:004ac7b780308dc899e565b887c7def0a6e100f2

commit r10-6356-g004ac7b780308dc899e565b887c7def0a6e100f2
Author: Andrew Benson 
Date:   Thu Jan 30 17:47:00 2020 +

Remove check for maximum symbol name length.

PR fortran/87103
* expr.c (gfc_check_conformance): Check vsnprintf for truncation.
* iresolve.c (gfc_get_string): Likewise.
* symbol.c (gfc_new_symbol): Remove check for maximum symbol
name length.  Remove redundant 0 setting of new calloc()ed
gfc_symbol.

[Bug c++/93496] Miscompile of range-for over braced-init-list in constructor of class with virtual inheritance

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Justin LaPolla from comment #2)
> 3. My current project requires that we compile with GCC 8.1.0. To avoid this
> bug, we are disallowing virtual inheritance in our code by compiling with
> `-Werror=virtual-inheritance'. Is this sufficient?

Yes.

I'll do a bisection later to find when/how it was fixed.

[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Created attachment 47741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47741&action=edit
gcc10-pr93384.patch

Untested fix (only the make localalias name unique part, not the
ipa-pure-const.c change).

[Bug analyzer/93511] New: ICE in make_region_for_type analyzing zlib/gzwrite.c

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 93511
   Summary: ICE in make_region_for_type analyzing zlib/gzwrite.c
   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: dmalcolm at gcc dot gnu.org
Blocks: 93388
  Target Milestone: ---

I attempted a bootstrap with -fanalyzer as per PR 93388.

One of the two ICEs seen with 66af5a226acd0edfbafcbcac76ed268cee0612ed:

../../../src/zlib/gzwrite.c: In function ‘gz_write.part.0’:
../../../src/zlib/gzwrite.c:213:13: internal compiler error: in
make_region_for_type, at analyzer/region-model.cc:5961
  213 | memcpy(state->in + have, buf, copy);
  | ^~~
0x1881443 make_region_for_type
../../../src/gcc/analyzer/region-model.cc:5961
0x18814a5 ana::region_model::add_region_for_type(ana::region_id, tree_node*)
../../../src/gcc/analyzer/region-model.cc:5971
0x1882b0d ana::region_model::get_or_create_view(ana::region_id, tree_node*)
../../../src/gcc/analyzer/region-model.cc:6546
0x187866c ana::array_region::get_element(ana::region_model*, ana::region_id,
ana::svalue_id, ana::region_model_context*)
../../../src/gcc/analyzer/region-model.cc:2182
0x18829eb ana::region_model::get_or_create_mem_ref(tree_node*, ana::svalue_id,
ana::svalue_id, ana::region_model_context*)
../../../src/gcc/analyzer/region-model.cc:6504
0x1882a50 ana::region_model::get_or_create_pointer_plus_expr(tree_node*,
ana::svalue_id, ana::svalue_id, ana::region_model_context*)
../../../src/gcc/analyzer/region-model.cc:6524
0x187c701 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
../../../src/gcc/analyzer/region-model.cc:3955
0x184cdea ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
../../../src/gcc/analyzer/engine.cc:948
0x1850c03 ana::exploded_graph::process_node(ana::exploded_node*)
../../../src/gcc/analyzer/engine.cc:2411
0x1850536 ana::exploded_graph::process_worklist()
../../../src/gcc/analyzer/engine.cc:2231
0x1852fb8 ana::impl_run_checkers(ana::logger*)
../../../src/gcc/analyzer/engine.cc:3552
0x1853295 ana::run_checkers()
../../../src/gcc/analyzer/engine.cc:3609
0x184b42e execute
../../../src/gcc/analyzer/analyzer-pass.cc:84


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388
[Bug 93388] ensure -fanalyzer works with our C code

[Bug c++/91212] [8/9/10 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Happens with a class too:

struct T { int i; };

struct X {
  X(T&) { }  // #1
  X(const T&) { __builtin_abort (); } // #2
};

X
fn ()
{
  T buf;
  return buf;
}

int
main()
{
  X c = fn ();
}

is it actually a bug though, not just a consequence of Core 1579?  We treat
'buf' as an rvalue and you can't bind an rvalue to a non-const lvalue ref, so
#2 is chosen.

[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
(In reply to Jason Merrill from comment #3)
> Confirmed.  check_return_expr can't use convert_for_initialization to test
> whether to treat the returned lvalue as an rvalue.

Indeed: convert_for_initialization -> perform_implicit_conversion_flags ->
convert_like_real will build_temp for the rvalue version of OBJ, so it calls
build_special_member_call -> build_new_method_call_1.

Here we have three candidates:

  X::X(X&&)
  constexpr X::X(const X&)
  constexpr X::X()

the last one is not viable so splice_viable kills it.  And tourney selects

  X::X(X&&)

as expected.  But we pass it to build_over_call and that will not complain and
just return error_mark_node for a DECL_DELETED_FN function.  Then the second
stage of the two-stage overload resolution succeeds.  I guess we need to stop
and issue an error when we found a move ctor, but it's deleted (but not if we
don't find a move ctor at all).

(Came here in the context of PR91212 where this convert_for_initialization
selects the wrong overload.)

[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Is the above what you'd like to see or do you want something else?

[Bug bootstrap/93416] [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Well, the assert is gone, so I can't see how it could not be fixed.  Let's
assume it is.

[Bug libstdc++/92570] [8/9/10 Regression] clang fails to instantiate std::optional if A is not const copy constructible

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Ville Voutilainen  ---
This is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html
which clang implements only in c++2a mode, because those core issues were never
explicitly marked DR. We could almost fix this on the library side by removing
the =default from _Optional_payload_base, but _Optional_payload would still run
into this problem. This is not worth library heroics.

[Bug target/91824] unnecessary sign-extension after _mm_movemask_epi8 or __builtin_popcount

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug analyzer/93388] ensure -fanalyzer works with our C code

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Looks like "make BOOT_CFLAGS='-fanalyzer' bootstrap" could also be used, but
it's nice to have a way to do this via configure flags.

[Bug libstdc++/92570] [8/9/10 Regression] clang fails to instantiate std::optional if A is not const copy constructible

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Segher Boessenkool from comment #13)
> > (In reply to Jakub Jelinek from comment #11)
> > > and so I'd say even if we just don't fix expand_binop, this shows an
> > > optimization opportunity for the rs6000 backend
> > > if the rotlw instruction only uses bottom 5 bits from the last operand.
> > 
> > Yes, but there is no easy way to express that.  For shifts the mask is one
> > bit *more* (in the GPRs; it is not in vectors).  But we could do more in
> > the .md, sure.
> 
> But for rotlw the mask is exactly the precision?
> If yes, there could be something like:
> (define_insn "rotl3_cntmask"
>   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> (rotate:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
> (and:SI (match_operand:SI 2 "reg_or_cint_operand" "rn")
> (match_operand:SI 3 "const_int_operand" "n")))]
>   "INTVAL (operands[3]) == GET_MODE_PRECISION (mode)"
>   "rotl%I2 %0,%1,%2"
>   [(set_attr "type" "shift")
>(set_attr "maybe_var_shift" "yes")])
> (though, there are various patterns with rotate and something around it, so
> perhaps it would need to be done for those too).

Obviously not GET_MODE_PRECISION but GET_MODE_MASK.

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Jakub Jelinek from comment #11)
> > and so I'd say even if we just don't fix expand_binop, this shows an
> > optimization opportunity for the rs6000 backend
> > if the rotlw instruction only uses bottom 5 bits from the last operand.
> 
> Yes, but there is no easy way to express that.  For shifts the mask is one
> bit *more* (in the GPRs; it is not in vectors).  But we could do more in
> the .md, sure.

But for rotlw the mask is exactly the precision?
If yes, there could be something like:
(define_insn "rotl3_cntmask"
  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
(rotate:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
(and:SI (match_operand:SI 2 "reg_or_cint_operand" "rn")
(match_operand:SI 3 "const_int_operand" "n")))]
  "INTVAL (operands[3]) == GET_MODE_PRECISION (mode)"
  "rotl%I2 %0,%1,%2"
  [(set_attr "type" "shift")
   (set_attr "maybe_var_shift" "yes")])
(though, there are various patterns with rotate and something around it, so
perhaps it would need to be done for those too).

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #11)
> and so I'd say even if we just don't fix expand_binop, this shows an
> optimization opportunity for the rs6000 backend
> if the rotlw instruction only uses bottom 5 bits from the last operand.

Yes, but there is no easy way to express that.  For shifts the mask is one
bit *more* (in the GPRs; it is not in vectors).  But we could do more in
the .md, sure.

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 47740 [details]
> gcc10-pr93505.patch
> 
> Untested combiner fix.  IMHO even when we fix expand_binop we want it
> anyway, because we don't want to invoke UB in the compiler, even on UB in
> the testcase.

This patch is approved for trunk and any wanted backports (if it passes
regression testing ;-) )

[Bug tree-optimization/92323] bogus -Warray-bounds after unrolling despite __builtin_unreachable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #5 from Martin Sebor  ---
I didn't do anything to fix the test case but the warning for it is gone
because the loop isn't unrolled anymore.  I added a test but it would be good
if Richi could confirm that it's safe to expect the unroller to avoid this
problem.

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

[msebor at gcc dot gnu.org]

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

Bug 92323 Summary: bogus -Warray-bounds after unrolling despite 
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92323

   What|Removed |Added

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

[Bug tree-optimization/92323] bogus -Warray-bounds after unrolling despite __builtin_unreachable

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:97b40c39208e384fd3ead463b85cddda9e55a375

commit r10-6353-g97b40c39208e384fd3ead463b85cddda9e55a375
Author: Martin Sebor 
Date:   Thu Jan 30 08:46:23 2020 -0700

PR middle-end/92323 - bogus -Warray-bounds after unrolling despite
__builtin_unreachable

gcc/testsuite/ChangeLog:
* gcc.dg/Warray-bounds-57.c: New test.

[Bug testsuite/92415] new test case g++.dg/cpp2a/spaceship-scalar1-neg.C introduced in r277925 fails

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I do not see this currently so it looks like it was fixed.

[Bug middle-end/92380] Bogus -Warray-bounds warning with structures, one of which has a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |middle-end
   Severity|normal  |minor

[Bug middle-end/93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
As for the expand_binop bug, if I fix it like:
--- gcc/optabs.c.jj 2020-01-12 11:54:36.690409230 +0100
+++ gcc/optabs.c2020-01-30 16:05:43.520649234 +0100
@@ -1226,16 +1226,22 @@ expand_binop (machine_mode mode, optab b
   unsigned int bits = GET_MODE_PRECISION (int_mode);

   if (CONST_INT_P (op1))
-   newop1 = gen_int_shift_amount (int_mode, bits - INTVAL (op1));
+   newop1
+ = gen_int_shift_amount (int_mode, (bits - UINTVAL (op1)) % bits);
   else if (targetm.shift_truncation_mask (int_mode) == bits - 1)
 newop1 = negate_rtx (GET_MODE (op1), op1);
-  else
-newop1 = expand_binop (GET_MODE (op1), sub_optab,
-  gen_int_mode (bits, GET_MODE (op1)), op1,
+  else if (pow2p_hwi (bits))
+newop1 = expand_binop (GET_MODE (op1), and_optab,
+  negate_rtx (GET_MODE (op1), op1),
+  gen_int_mode (bits - 1, GET_MODE (op1)),
   NULL_RTX, unsignedp, OPTAB_DIRECT);
+  else
+   newop1 = NULL_RTX;

-  temp = expand_binop_directly (icode, int_mode, otheroptab, op0, newop1,
-   target, unsignedp, methods, last);
+  temp = NULL_RTX;
+  if (newop1)
+   temp = expand_binop_directly (icode, int_mode, otheroptab, op0, newop1,
+ target, unsignedp, methods, last);
   if (temp)
return temp;
 }
then unfortunately given -O2 on
unsigned int
bar (unsigned int x, int y)
{
  return x >> y | x << (-y & 31);
}
powerpc64le-linux emitted assembly changes like:
 bar:
 .LFB1:
.cfi_startproc
-   subfic 4,4,32
+   neg 4,4
+   rlwinm 4,4,0,27,31
rotlw 3,3,4
blr

Given
unsigned int
baz (unsigned int x, int y)
{
  y &= 31;
  return x >> y | x << (-y & 31);
}
the change is:
 bar:
 .LFB1:
.cfi_startproc
+   neg 4,4
rlwinm 4,4,0,27,31
-   subfic 4,4,32
rotlw 3,3,4
blr
and so I'd say even if we just don't fix expand_binop, this shows an
optimization opportunity for the rs6000 backend
if the rotlw instruction only uses bottom 5 bits from the last operand.

[Bug fortran/93498] [9/10 Regression] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1844 since r9-3688-g01ce9e31a02c8039

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug fortran/93501] [10 regression] gfortran.dg/pr93473.f90 ICEs starting with r10-6295

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com