[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Richard Biener  ---
(In reply to Kees Cook from comment #9)
> Does anyone have some time to do this backport for GCC 12?

I sofar refrained from doing this because of the large amount of fallout and
followup changes and I think those are not warranted on the GCC 12 branch.

[Bug c++/106841] [12 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Richard Biener  ---
(In reply to Kenneth Hoste from comment #9)
> I seem to be running into the same problem using GCC 11.3 (when compiling
> OpenMM 7.7.0 with CUDA support). Is there a reason why the fix wasn't
> backported to GCC 11 too?

Because we don't have a testcase that fails on the GCC 11 branch.  Can you
confirm that cherry-picking the fix fixes the issue you see?

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #2 from Jeremy R.  ---
The easy solution is to mention both the bitfield and "hey maybe you meant to
use a ;"

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
clang diagnostic is way worse in my mind. It does not even point to the : .
GCC is assuming if you don't have a constructor you have a type and that type
here would be T (S::)()

Take:
```
struct S {
int (*foo)() : 
int t;
};

```
Trying to define a pointer to function field foo but used : instead of ;.
GCC diagonstic seems reasonable.
because GCC assumes you started to define a bitfield which is reasonable
assumention really.
clang diagnostic here is never even close to helpful.

At least GCC points out the colon and even suggest you started a bitfield which
is what a colon normally does here 

[Bug c++/107178] New: Diagnosis for colon vs semi-colon in a member function declaration

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 107178
   Summary: Diagnosis for colon vs semi-colon in a member function
declaration
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following code emits a poor diagnosis:

struct T {};

struct S {
T foo():
};

:4:7: error: bit-field 'T S::foo()' has non-integral type 'T (S::)()'
4 | T foo():
  |   ^~~

https://godbolt.org/z/39ME3K6TE

At least for the case of a member function declaration, a better diagnosis
would probably be ideal.


For T foo():, clang emits:

:5:1: error: expected '(' or '{'
};
^


For T foo:, clang emits:

:5:1: error: expected expression
};
^
:5:3: error: expected '}'
};
  ^
:3:10: note: to match this '{'
struct S {
 ^
:5:3: error: expected ';' after struct
};
  ^
  ;

[Bug c++/107177] ICE: tree check: expected type_argument_pack or nontype_argument_pack, have integer_type in unify_pack_expansion, at cp/pt.cc:23912

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
According to PR 104837 (which was reduced from
SemaTemplate/pack-deduction.cpp), this is a dup of bug 86426 so marking it as
such.

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

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Andrew Pinski  ---
*** Bug 107177 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/107167] It looks like GCC wastes registers on trivial computations when result can be cached

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Andrew Pinski from comment #5)
> You already filed this one.
> 
> *** This bug has been marked as a duplicate of bug 103550 ***

(In reply to Andrew Pinski from comment #1)
> This is a reassociation, scheduling issue and register allocation issue.
> 
> Plus your example might be slower due to dependencies.
> 
> Without a full example of where gcc ra goes wrong, gcc actually produces
> much better code for this example due to register renaming in hw.
> Note many x86_64 also does register renaming for the stack too

On x86_64, I just checked uops.info, only two ports are available for
rotr,rotl. They cannot really get paralleled executed.

[Bug c/107177] New: ICE: tree check: expected type_argument_pack or nontype_argument_pack, have integer_type in unify_pack_expansion, at cp/pt.cc:23912

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107177
   Summary: ICE: tree check: expected type_argument_pack or
nontype_argument_pack, have integer_type in
unify_pack_expansion, at cp/pt.cc:23912
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++ 13.0.0 20220925 snapshot (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs
when compiling the following testcase, reduced from
test/SemaTemplate/pack-deduction.cpp from the clang 15.0.1 test suite:

template struct X {};
template int f1(X... a);

int a1 = f1(X(), X());

% g++-13.0.0 -c r6lgqt43.cpp
r6lgqt43.cpp: In substitution of 'template int f1(X...)
[with T = ]':
r6lgqt43.cpp:6:14:   required from here
r6lgqt43.cpp:6:14: internal compiler error: tree check: expected
type_argument_pack or nontype_argument_pack, have integer_type in
unify_pack_expansion, at cp/pt.cc:23912
6 |   int a1 = f1(X(), X());
  |~~^
0x89062a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree.cc:8827
0x71cbda tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/tree.h:3539
0x71cbda unify_pack_expansion
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:23912
0xb60eb5 unify
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:24728
0xb60ce5 unify
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:24925
0xb60e73 unify
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:24722
0xb605b9 try_class_unification
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:23679
0xb61253 unify
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:24759
0xb5e1bc unify_one_argument
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:22894
0xb5eefa unify_pack_expansion
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:23943
0xb73e50 type_unification_real
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:23037
0xb8a74a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/pt.cc:22341
0x9722cf add_template_candidate_real
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:3573
0x97339a add_template_candidate
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:3661
0x97339a add_candidates
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:6219
0x979969 add_candidates
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:4726
0x979969 perform_overload_resolution
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:4743
0x97f1f2 build_new_function_call(tree_node*, vec**, int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/call.cc:4850
0xbac94a finish_call_expr(tree_node*, vec**, bool,
bool, int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/semantics.cc:2904
0xb051fb cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cp/parser.cc:7965

Previous gcc releases ICE (down to at leaset 4.7) in tsubst, at cp/pt.cc:15867.
clang accepts this snippet.

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[lhyatt at gcc dot gnu.org via Gcc-bugs]

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #8 from Lewis Hyatt  ---
The testcase for this PR was one of many that got fixed by r9-1926 (for
PR69558). The location of the token resulting from expanding the builtin macro
__LINE__ was, prior to r9-1926, pointing to the closing paren of the macro
invocation, i.e. not in the system header. After r9-1926, the location of the
token is a virtual location encoding that the token resulted from expansion of
a macro defined in a system header, and so the "system"-ness of the token no
longer gets lost.

Fredrik's original testcase is a nice one. Every element in it is essential to
reveal the issue, including the extra semicolon in the FOO macro and the
newline in the invocation. Although that testcase now works correctly, Manuel's
point still stands, c-ppoutput.cc should not have behaved this way, even absent
r9-1926. The problem is that here:

==
  if (do_line_adjustments
  && !in_pragma
  && !line_marker_emitted
  && print.prev_was_system_token != !!in_system_header_at (loc)
  && !is_location_from_builtin_token (loc))
/* The system-ness of this token is different from the one of
   the previous token.  Let's emit a line change to mark the
   new system-ness before we emit the token.  */
{
  do_line_change (pfile, token, loc, false);
  print.prev_was_system_token = !!in_system_header_at (loc);
}
===

print.prev_was_system_token should be set always, not only when the if
statement is reached and evaluates to true. In this PR's testcase prior to
r9-1926, the check evaluated to false when streaming the semicolon from the
macro expansion, because a line marker had been printed due to the fact that
the __LINE__ token and the semicolon were assigned locations on different
lines.

So the logic in c-ppoutput.cc assumes that you can never get two tokens on
different lines without a line change callback, which is not a crazy assumption
but was violated due to the issue fixed by r9-1926.

However, there are other code paths besides the line change logic that can
trigger the same issue still now. One way is to stream a deferred CPP_PRAGMA
token, since that code path doesn't even execute the above if statement. As of
r13-1544, we do see such tokens while preprocessing, so here is a modified
testcase that fails on master:

==
$ cat t2.h
#pragma GCC system_header
#define X _Pragma("GCC diagnostic push");

$ cat t2.c
#include "./t2.h"
X
const char* should_warn = 1;

$ gcc -Wint-conversion -c t2.c
t2.c:3:27: warning: initialization of ‘const char *’ from ‘int’ makes pointer
from integer without a cast [-Wint-conversion]
3 | const char* should_warn = 1;
  |   ^
$ gcc -Wint-conversion -c t2.c -save-temps
$
==

I can test the fix and prepare a patch for that.

[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Tobias Burnus  ---
I believe this is now fixed via
commit r13-3105-g5fc4d3e1837ea4850aac6460f563913f1d3fc5b8 for PR 107088

[Bug analyzer/105783] -Wanalyzer-null-dereference false positive with union and functions

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-10-06

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Confirmed with trunk.

Adding:
__analyzer_describe (0, t->counting);
immediately before the conditional shows we have:
:16:5: warning: svalue: 'CAST(int, BITS_WITHIN('_Bool', start: 0, size:
1, next: 1, inner_val: (unsigned char)1))'
   16 | __analyzer_describe (0, t->counting);
  | ^~~~

so presumably the analyzer isn't smart enough to determine that that's nonzero.

Note to self: MCVE is Stack Overflow's acronym for a "minimal, complete and
verifiable example"
(https://stackoverflow.com/help/minimal-reproducible-example)

[Bug fortran/100971] ICE: Bad IO basetype (7)

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Just from a purely technical point, the following would allow to trigger the
proper check, as it allows to look into arrays, and regtests OK:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d9d101775f6..bcf951ad756 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -10017,6 +10017,7 @@ resolve_transfer (gfc_code *code)

   if (exp == NULL || (exp->expr_type != EXPR_VARIABLE
  && exp->expr_type != EXPR_FUNCTION
+ && exp->expr_type != EXPR_ARRAY
  && exp->expr_type != EXPR_STRUCTURE))
 return;

@@ -10030,6 +10031,7 @@ resolve_transfer (gfc_code *code)

   const gfc_typespec *ts = exp->expr_type == EXPR_STRUCTURE
|| exp->expr_type == EXPR_FUNCTION
+   || exp->expr_type == EXPR_ARRAY
 ? &exp->ts : &exp->symtree->n.sym->ts;

   /* Go to actual component transferred.  */
@@ -10128,6 +10130,9 @@ resolve_transfer (gfc_code *code)
   if (exp->expr_type == EXPR_STRUCTURE)
 return;

+  if (exp->expr_type == EXPR_ARRAY)
+return;
+
   sym = exp->symtree->n.sym;

   if (sym->as != NULL && sym->as->type == AS_ASSUMED_SIZE && exp->ref

[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
  Component|c   |tree-optimization
   Keywords||wrong-code
  Known to fail||7.1.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Wrong code at -O0/-Os on|[10/11/12/13 Regression]
   |x86_64-pc-linux-gnu |Wrong code at -Os on
   ||x86_64-pc-linux-gnu
   Last reconfirmed||2022-10-06
  Known to work||6.3.0

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Here is a better testcase:
#include 

int a;
long b;
static inline long c(unsigned d) { 
return d; 
}
static inline void e(int d) { 
a = d; 
}
int main() {
  b = 0;
  for (; b < 1; b = c(b - 90) + 90 + 1)
;
  e(b >> 2);
  printf("%d\n", a);
  if (a != 1073741824)
__builtin_abort();
}

[Bug tree-optimization/107170] [13 Regression] ICE on valid code: in as_a, at value-range.h:381

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
fixed

[Bug c/107176] New: Wrong code at -O0/-Os on x86_64-pc-linux-gnu

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107176
   Summary: Wrong code at -O0/-Os on x86_64-pc-linux-gnu
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

%gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-b48d7ff3570fa0ebe7790275cf020d8885120338/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-b48d7ff3570fa0ebe7790275cf020d8885120338
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220928 (experimental) (GCC)
%
%gcc-tk -O0 a.c && ./a.out
1073741824
%
%gcc-tk -Os a.c && ./a.out 
0
%
%cat a.c
int a;
long b;
long c(unsigned d) { 
return d; 
}
void e(d) { 
a = d; 
}
int main() {
  b = 0;
  for (; b < 1; b = c(b - 90) + 90 + 1)
;
  e(b >> 2);
  printf("%d\n", a);
}
%

Compiler explorer: https://godbolt.org/z/zzMdosoKj

[Bug tree-optimization/107170] [13 Regression] ICE on valid code: in as_a, at value-range.h:381

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:49b9a8c8cc498b1ed2f566bee858e651e14ba37b

commit r13-3139-g49b9a8c8cc498b1ed2f566bee858e651e14ba37b
Author: Aldy Hernandez 
Date:   Thu Oct 6 19:11:08 2022 +0200

[PR107170] Avoid copying incompatible types in legacy VRP.

Legacy VRP is calling ranger deep inside the bowels, and then trying to
copy an incompatible type.  My previous patch in this area assumed that
the only possibility out of vr_values::get_value_range for an
unsupported type was VARYING, but UNDEFINED can also be returned.

PR tree-optimization/107170

gcc/ChangeLog:

* vr-values.cc (vr_values::range_of_expr):  Do not die on
unsupported types.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr107170.c: New test.

[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||physhivam at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 107175 has been marked as a duplicate of this bug. ***

[Bug c++/107175] overloaded resolution has a bug incase of deleted functions

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 68942.

Since it was not a regression the patch which fixes this is 99% sure will not
be backported into GCC 11.x or GCC 10.x.

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

[Bug c++/107175] New: overloaded resolution has a bug incase of deleted functions

[physhivam at gmail dot com via Gcc-bugs]

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

Bug ID: 107175
   Summary: overloaded resolution has a bug incase of deleted
functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physhivam at gmail dot com
  Target Milestone: ---

Hey, I was trying to build clang's libcxx on my ubuntu 22.04 and it has
gcc-11.2 by default most prolly, but while building libcxx there was an error
about using the deleted function but it seems that overloaded resolution in
gcc-11 has a bug

namespace N {
  struct S {};
  void func(S);
}

namespace ADL {
  void func() = delete;
}

template 
void call_func(T t) {
  using ADL::func;
  func(t);
}

int main() {
  call_func(N::S{});
}

error: 
: In instantiation of 'void call_func(T) [with T = N::S]':
:18:12:   required from here
:14:7: error: use of deleted function 'void ADL::func()'
   14 |   func(t);
  |   ^~~
:8:8: note: declared here
8 |   void func() = delete;
  |^~~~
Compiler returned: 1

 https://godbolt.org/z/GPTPYaobb , it consider wrong overloaded function ,
although the bug is fixed in the most recent version but I guess this needs to
be backport in the previous version where gcc starts support for c++11, as many
of the previous versions are the default versions on several machines.

[Bug analyzer/106000] RFE: -fanalyzer should complain about memory accesses that are definitely out-of-bounds

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Tim implemented this in the above patch; marking this as resolved.

[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

Bug 106000 Summary: RFE: -fanalyzer should complain about memory accesses that 
are definitely out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000

   What|Removed |Added

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

[Bug analyzer/106625] RFE: support some symbolic values in -Wanalyzer-out-of-bounds

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Tim implemented a version of this that supports the specific case above, in the
above patch; marking this as resolved.

[Bug analyzer/107158] False postives from -Wanalyzer-malloc-leak on tin-2.6.2

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from David Malcolm  ---
I believe the above patch fixes the remaining ICEs on the attachment.  Please
let me know if you find other ways to crash it.

Keeping this open to track the memory leak false +ves.

[Bug analyzer/107158] False postives from -Wanalyzer-malloc-leak on tin-2.6.2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:629b4813e91aba0a8fc9b18434ec1808776a4b3d

commit r13-3138-g629b4813e91aba0a8fc9b18434ec1808776a4b3d
Author: David Malcolm 
Date:   Thu Oct 6 15:46:49 2022 -0400

analyzer: fix another ICE in PR 107158

I overreduced PR analyzer/107158 in r13-3096-gef878564140cbc, and there
was another ICE in the original reproducer, which this patch fixes.

gcc/analyzer/ChangeLog:
PR analyzer/107158
* store.cc (store::replay_call_summary_cluster): Eliminate
special-casing of RK_HEAP_ALLOCATED in favor of sharing code with
RK_DECL, avoiding an ICE due to attempting to bind a
compound_svalue into a binding_cluster when an svalue in the
summary cluster converts to a compound_svalue in the caller.

gcc/testsuite/ChangeLog:
PR analyzer/107158
* gcc.dg/analyzer/call-summaries-pr107158-2.c: New test.

Signed-off-by: David Malcolm 

[Bug debug/107169] [13 Regression] -fcompare-debug failure at -O and above since r13-2921-gf1adf45b17f7f1ed

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #2 from Eugene Rozenfeld  ---
When -gstatement-frontiers is on, the IR coming from the front end may be
different with and without debug information turned on. That may cause e.g.,
different discriminator values and -fcompare-debug failures.

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

In  https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=f1adf45b17f7f1ed I added
-gno-statement-frontiers to gcc/testsuite/c-c++-common/ubsan/pr85213.c
b/gcc/testsuite/c-c++-common/ubsan/pr85213.c to work around this problem for
that test.

Re: gcc-12: FTBFS on hurd-i386

[Jonathan Wakely via Gcc-bugs]

Hello,

This mailing list is for automated mail from Bugzilla. Emails sent
directly to this list are liable to be missed or just ignored.

Please report bugs to Bugzilla instead, see https://gcc.gnu.org/bugs/

Patches should be sent to the gcc-patches mailing list, not gcc-bugs:
https://gcc.gnu.org/contribute.html#patches

Thanks!

[Bug fortran/107075] ICE in get, at cgraph.h:461

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
I tried the following patch, which however regresses on a couple testcases:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d9d101775f6..cfc6fc055bd 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -16349,6 +16349,16 @@ resolve_symbol (gfc_symbol *sym)

   if (sym->param_list)
 resolve_pdt (sym);
+
+  if (sym->attr.flavor == FL_VARIABLE
+  && sym->attr.save == SAVE_NONE
+  && !sym->attr.allocatable
+  && !sym->attr.pointer
+  && !sym->attr.class_pointer
+  && sym->ns->proc_name
+  && sym->ns->proc_name->attr.flavor == FL_PROGRAM
+  && sym->ns->proc_name->attr.is_main_program)
+sym->attr.save = SAVE_IMPLICIT;
 }

[Bug testsuite/107171] New test case gcc.target/powerpc/pr105586.c fails after its introduction in r13-2525-gbec35caafae8db

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #2)
> /* { dg-require-effective-target int128 } */
> might be better if it is just __int128 that is causing the issue.

Good point!  Thanks Andrew.

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

[seurer at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Note that 554.roms_r from spec2017 also fails after this commit.

[Bug testsuite/107171] New test case gcc.target/powerpc/pr105586.c fails after its introduction in r13-2525-gbec35caafae8db

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||testsuite-fail

--- Comment #2 from Andrew Pinski  ---
(In reply to Peter Bergner from comment #1)
> Assigning to Surya.
> 
> It looks like the test case just needs a...
> 
> /* { dg-require-effective-target lp64 } */
> 
> ...line to disable it on -m32 compiles, since __int128 isn't supported there.

/* { dg-require-effective-target int128 } */
might be better if it is just __int128 that is causing the issue.

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #8) 
> We need a solution that works for combine too — is it possible to invent a
> representation for a no-op in-place MEM "move" that only changes its alias
> set?

That is the same as my comment here:
> I don't know what is the best way to represent an aliasing set change
> even though the value didn't change on the RTL level.

Clobber might work though I don't know if that is 100% correct as the value
didn't change so maybe a new RTL code for this? But that would require many
changes in the backend ...

[Bug testsuite/107171] New test case gcc.target/powerpc/pr105586.c fails after its introduction in r13-2525-gbec35caafae8db

[bergner at gcc dot gnu.org via Gcc-bugs]

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

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-06
   Assignee|unassigned at gcc dot gnu.org  |jskumari at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Peter Bergner  ---
Assigning to Surya.

It looks like the test case just needs a...

/* { dg-require-effective-target lp64 } */

...line to disable it on -m32 compiles, since __int128 isn't supported there.

[Bug target/107174] [ARM] Wrong opcodes *.f64.s32 (signed) in conversion [unsigned ->double] with -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
 -fsanitize=undefined catches this at runtime:
/app/example.cpp:10:28: runtime error: signed integer overflow: 20 -
-10 cannot be represented in type 'int'
/app/example.cpp:7:28: runtime error: signed integer overflow: 20 -
-10 cannot be represented in type 'int'

[Bug target/107174] [ARM] Wrong opcodes *.f64.s32 (signed) in conversion [unsigned ->double] with -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
There is no bug here as signed integer overflow is undefined.
You should do the following if you want unsigned conversion.


__attribute__((noinline)) double deltaToDouble(int a, int b) {
  unsigned ua = a;
  unsigned ub = b;
  if (a < b) {
unsigned int delta = ub - ua;
return -((double)delta);
  } else {
unsigned int delta = ua - ub;
return (double)delta;
  }
}

Otherwise GCC will assume (a - b) and (b - a) will never be overflow (as it is
undefined) and you will get the signed coversions.

[Bug target/107174] New: [ARM] Wrong opcodes *.f64.s32 (signed) in conversion [unsigned ->double] with -O2

[rozne at pabich dot waw.pl via Gcc-bugs]

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

Bug ID: 107174
   Summary: [ARM] Wrong opcodes *.f64.s32 (signed) in conversion
[unsigned ->double] with -O2
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rozne at pabich dot waw.pl
  Target Milestone: ---

When building for 32-bit ARMhf with optimization -O2 and higher sometimes wrong
conversion opcodes are generated - *.f64.s32 (signed conversion) instead of
*.f64.u32 (unsigned). These are very rare cases, and are higly sensitive to
code arrangement.

The bug seems to be present at least since GCC 8.3. GCC 8.4 and 12 are
affected.

GCC 7.5 is not affected (and very old 4.4 also).

It is not present on x86 architecture, seems to be ARM specific.

Example cross-compiled on Ubuntu 18.04.6 (x86_64):
  arm-linux-gnueabihf-gcc-8 -Wall -Wextra -O2 -static

GCC 8.4 version:
  arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-1ubuntu1~18.04) 8.4.0


Code:

#include 

__attribute__((noinline)) double deltaToDouble(int a, int b) {
  if (a < b) {
unsigned int delta = b - a;
return -((double)delta);
  } else {
unsigned int delta = a - b;
return (double)delta;
  }
}

int main() {
  return (deltaToDouble( 20, -10) !=  30.0 ||
  deltaToDouble(-10,  20) != -30.0);
}


Disassembly:

:
  cmp r0, r1
  itete   lt
  sublt   r0, r1, r0
  subge   r0, r0, r1
  vmovlt  s15, r0
  vmovge  s15, r0
  ittelt
  vcvtlt.f64.s32  d0, s15
  vneglt.f64  d0, d0
  vcvtge.f64.s32  d0, s15
  bx  lr


It is easy to see that opcodes are for signed int32 conversion (vcvtlt.f64.s32,
vcvtge.f64.s32). Code generated by older GCC 7.5 is same except correct opcodes
for unsigned int32 (vcvtlt.f64.u32, vcvtge.f64.u32) were used.

[Bug tree-optimization/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[13 Regression] wrong code  |[13 Regression] wrong code
   |with "-O1 -ftree-vrp" on|with "-O1 -ftree-vrp" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r13-1268-g8c99e307b20c502e

--- Comment #2 from Martin Liška  ---
Started with r13-1268-g8c99e307b20c502e.

[Bug tree-optimization/107170] [13 Regression] ICE on valid code: in as_a, at value-range.h:381

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||marxin at gcc dot gnu.org

[Bug tree-optimization/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong code with "-O1|[13 Regression] wrong code
   |-ftree-vrp" on  |with "-O1 -ftree-vrp" on
   |x86_64-linux-gnu|x86_64-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-06
 Ever confirmed|0   |1
   Target Milestone|--- |13.0

--- Comment #1 from Andrew Pinski  ---
Confirmed. Reduced a little bit more:
```
int a, c, d;
int main() {
  long e = 1;
  int f = a = 1;
 L1:
  if (a)
a = 2;
  int h = e = ~e;
  c = -1;
  if (e >= a)
goto L2;
  if (-1 > a)
goto L1;
  if (a)
f = -1;
 L2:
  d = (-f + d) & h;
  if (d)
__builtin_abort();
  return 0;
}
```
Note the store for c is important there. I suspect otherwise the load to e is
figured out and does the correct thing.

[Bug fortran/107075] ICE in get, at cgraph.h:461

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
There is a check in expr.cc:2623 that is reached if one changes the
testcase to a subroutine, but not if it is a program:

4615  if (!attr.save && rvalue->expr_type == EXPR_VARIABLE
4616  && rvalue->symtree->n.sym->ns->proc_name
4617  &&
rvalue->symtree->n.sym->ns->proc_name->attr.is_main_program)
4618{
4619  rvalue->symtree->n.sym->ns->proc_name->attr.save =
SAVE_IMPLICIT;
4620  attr.save = SAVE_IMPLICIT;
4621}
4622
4623  if (!attr.save)
4624{
4625  gfc_error ("Pointer initialization target at %L "
4626 "must have the SAVE attribute", &rvalue->where);
4627  return false;
4628}

I think the first check tries to fake that the target has the right
attributes in a main program (implicit save) while it hasn't.
If we fix the attributes of variables in the main program, the above
check should be revisited.

[Bug c++/107173] New: ICE: unspellable token PRAGMA_EOL on type_traits:1446:26

[esa.pulkkinen at iki dot fi via Gcc-bugs]

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

Bug ID: 107173
   Summary: ICE: unspellable token PRAGMA_EOL on
type_traits:1446:26
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: esa.pulkkinen at iki dot fi
  Target Milestone: ---

Created attachment 53674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53674&action=edit
output from preprocessor

LC_MESSAGES=C /usr/local/bin/g++ -freport-bug
-I/home/esap/c++/change/libchange-gcc/libchange
-I/home/esap/c++/change/libchange -DLIBCHANGE_SHARED_BUILD -std=c++23
-finput-charset=UTF-8 -fPIC -x c++ -MQ ^ -MD -E -fdirectives-only
/home/esap/c++/change/libchange/libchange/koe.cxx > bug.out
In file included from /usr/local/include/c++/13.0.0/bits/stl_pair.h:60,
 from /usr/local/include/c++/13.0.0/tuple:38,
 from /home/esap/c++/change/libchange/libchange/koe.cxx:2:
/usr/local/include/c++/13.0.0/type_traits:1446:26: internal compiler error:
unspellable token PRAGMA_EOL
 1446 | : public __is_nt_convertible_helper<_From, _To>::type
  |  ^
0xc731b2 c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
../.././gcc/c-family/c-common.cc:6711
0x21df1eb cpp_diagnostic_at
../.././libcpp/errors.cc:67
0x21df1eb cpp_diagnostic
../.././libcpp/errors.cc:82
0x21df316 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
../.././libcpp/errors.cc:96
0x21e9911 cpp_spell_token(cpp_reader*, cpp_token const*, unsigned char*, bool)
../.././libcpp/lex.cc:4395
0x21ea5c6 cpp_token_as_text(cpp_reader*, cpp_token const*)
../.././libcpp/lex.cc:4411
0x21e286a _cpp_parse_expr
../.././libcpp/expr.cc:1375
0x21db7b1 do_if
../.././libcpp/directives.cc:2076
0x21dd768 _cpp_handle_directive
../.././libcpp/directives.cc:572
0x21eadc2 cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../.././libcpp/lex.cc:5241
0xc9de61 scan_translation_unit_directives_only
../.././gcc/c-family/c-ppoutput.cc:428
0xc9de61 preprocess_file(cpp_reader*)
../.././gcc/c-family/c-ppoutput.cc:104
0xc9c110 c_common_init()
../.././gcc/c-family/c-opts.cc:1234
0xaa35ee cxx_init()
../.././gcc/cp/lex.cc:338
0x99f944 lang_dependent_init
../.././gcc/toplev.cc:1815
0x99f944 do_compile
../.././gcc/toplev.cc:2110
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

input file "koe.cxx" contains only following (I've reduced it to minimal
example):
  koe.cxx ===
module;
#include 
module change:koe;
=== END koe.cxx ===

compiler command line above was mostly generated by build2-0.15.0.

I think what the above means is that type_traits header is not working with
modules, even if included and not imported.
I don't really understand what the compiler is trying to say, I can't see
anything wrong in my code nor in the  system header.

I suspect -fdirectives-only causes the problem, as removing it changes the
output, and this seems to be confirmed by the stack trace produced.

[Bug tree-optimization/107172] New: wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107172
   Summary: wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This seems to be a recent regression.

Compiler Explorer: https://godbolt.org/z/xj7ods8Pv

[596] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221006 (experimental) [master r13-3101-g966010b2eb4] (GCC) 
[597] % 
[597] % gcctk -O1 small.c; ./a.out
[598] % 
[598] % gcctk -O1 -ftree-vrp small.c
[599] % ./a.out
Segmentation fault
[600] % 
[600] % cat small.c
int a, *b, c, d;
int main() {
  long e = 1;
  int f = a = 1;
 L1:
  if (a)
a = 2;
  int h = e = ~e;
  c = -1;
  if (e >= a)
goto L2;
  if (c > a)
goto L1;
  if (a)
f = -1;
 L2:
  d = (-f + d) & h;
  if (d)
(*b)++;
  return 0;
}

[Bug c++/107140] Potential false positive uninitialized variable warning with -Wmaybe-uninitialized

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #3 from Kip Warner  ---
If you click the Save button in Godbolt's CE, you can download a compressed
archive. I've attached it for you.

[Bug c++/107140] Potential false positive uninitialized variable warning with -Wmaybe-uninitialized

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #2 from Kip Warner  ---
Created attachment 53673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53673&action=edit
Minimal

[Bug tree-optimization/107170] [13 Regression] ICE on valid code: in as_a, at value-range.h:381

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |13.0
Summary|ICE on valid code: in as_a, |[13 Regression] ICE on
   |at value-range.h:381|valid code: in as_a, at
   ||value-range.h:381

[Bug c/107170] ICE on valid code: in as_a, at value-range.h:381

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Aldy Hernandez  ---
Created attachment 53672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53672&action=edit
untested patch

[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com

--- Comment #9 from Kees Cook  ---
Does anyone have some time to do this backport for GCC 12?

[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
This fixes ICE:

diff --git a/gcc/config/i386/i386-features.cc
b/gcc/config/i386/i386-features.cc
index fd212262f50..cc690a6064c 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1975,6 +1975,9 @@ timode_scalar_to_vector_candidate_p (rtx_insn *insn)
   switch (GET_CODE (src))
 {
 case REG:
+  /* Return false if the source is uninitialized.  */
+  return DF_REG_DEF_CHAIN (REGNO (src)) != nullptr;
+
 case CONST_WIDE_INT:
   return true;

[Bug c/107170] ICE on valid code: in as_a, at value-range.h:381

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
   Last reconfirmed||2022-10-06
 Ever confirmed|0   |1
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 CC||aldyh at gcc dot gnu.org

[Bug testsuite/107171] New: New test case gcc.target/powerpc/pr105586.c fails after its introduction in r13-2525-gbec35caafae8db

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107171
   Summary: New test case gcc.target/powerpc/pr105586.c fails
after its introduction in r13-2525-gbec35caafae8db
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:bec35caafae8db0278e1d037a7ba00c3e6899bbd, r13-2525-gbec35caafae8db
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
powerpc.exp=gcc.target/powerpc/pr105586.c"
FAIL: gcc.target/powerpc/pr105586.c (test for excess errors)
# of unexpected failures1

commit bec35caafae8db0278e1d037a7ba00c3e6899bbd
Author: Surya Kumari Jangala 
Date:   Tue Aug 2 23:00:03 2022 -0500

sched1: Fix -fcompare-debug issue in schedule_region [PR105586]

This failure is on a big endian system and it seems to work fine on LE.  The
new test case does not guard against unsupported __int128.

Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c  -m32
  -fdiagnostics-plain-output   -mdejagnu-tune=power4 -O2 -fcompare-debug
-fno-if-conversion -fno-guess-branch-probability -S -o pr105586.s(timeout =
300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c -m32
-fdiagnostics-plain-output -mdejagnu-tune=power4 -O2 -fcompare-debug
-fno-if-conversion -fno-guess-branch-probability -S -o pr105586.s^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c:8:1:
error: '__int128' is not supported on this target^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c: In
function 'foo':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c:15:3:
error: expected expression before '__int128'^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c:16:70:
error: 'u128_1' undeclared (first use in this function); did you mean 'u8_1'?^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c:16:70:
note: each undeclared identifier is reported only once for each function it
appears in^M
compiler exited with status 1

[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #4 from Arseny Solokha  ---
JFTR, I've just got an ICE that I presume to be another manifestation of the
same issue. The current gcc trunk snapshots ICE the way reported in comment 0
on the following testcase w/ -msse4 -Os:

__int128 n;

__int128
empty (void)
{
}

int
foo (void)
{
  n = empty ();

  return n == 0;
}

while replacing the last return statement w/ "return n == 1;" gives the
following:

% x86_64-unknown-linux-gnu-gcc-13.0.0 -msse4 -Os -c lr4kukze.c
during RTL pass: cse2
lr4kukze.c: In function 'foo':
lr4kukze.c:14:1: internal compiler error: in as_a, at machmode.h:365
   14 | }
  | ^
0x73665b scalar_int_mode as_a(machine_mode)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/machmode.h:365
0x736783 scalar_mode as_a(machine_mode)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:2288
0x736783 wi::int_traits
>::get_precision(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:2273
0x736783 unsigned int wi::get_precision
>(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/wide-int.h:1794
0x736783 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/wide-int.h:1024
0x736783 generic_wide_int
>::generic_wide_int >(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/wide-int.h:782
0x736783 poly_int<1u, generic_wide_int >
>::poly_int >(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/poly-int.h:670
0x736783 wi::to_poly_wide(rtx_def const*, machine_mode)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:2373
0x736783 neg_poly_int_rtx
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:57
0xec311e simplify_context::simplify_binary_operation_1(rtx_code, machine_mode,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:3118
0xec501d simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:2626
0xed00c2 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:3475
0xed00c2 simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:6112
0xec948b simplify_context::simplify_relational_operation(rtx_code,
machine_mode, machine_mode, rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/simplify-rtx.cc:5704
0x1cfed28 simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/rtl.h:3490
0x1cfed28 fold_rtx
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:3385
0x1cfffb3 cse_insn
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:4669
0x1d04e24 cse_extended_basic_block
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:6566
0x1d04e24 cse_main
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:6711
0x1d05750 rest_of_handle_cse2
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220925/work/gcc-13-20220925/gcc/cse.cc:7600

gcc-12: FTBFS on hurd-i386

[Svante Signell via Gcc-bugs]

Source: gcc-12
Version: 12_12.2.0-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

gcc-12-12.2.0-4/5 in sid FTBFS on hurd-i386 due to failing linkage of
pthread_once (same error for gcc-11, gcc-12, gcc-snapshot):
/<>/build/i686-gnu/libstdc++-v3/include/i686-gnu/bits/gthr-
default.h:700: undefined reference to `pthread_once'

Patches have already submitted upstream by Samuel Thibault in August and
September, see
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600469.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601754.html

Unfortunately upstream is not very responsive. Therefore I have taken the time
to send these patches to Debian in the mean time.

Patches extracted and attached from that mail message are:
1.diff-6.diff. Note that 1.diff does not apply to gcc-12, it is related to the
git repo. This is reflected in attached debian_rules.patch by commenting out
1.diff.

Just a reflection: Matthias you are really doing a great job with the
gcc releases: Kudos!

Thanks!

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index ba5939d9003..dd288cce2ca 100644
--- a/src/libstdc++-v3/ChangeLog
+++ b/src/libstdc++-v3/ChangeLog
@@ -1,3 +1,11 @@
+2022-08-28  Samuel Thibault  
+
+   * config/os/gnu/os_defines.h: New file.
+   * config/os/gnu/ctype_base.h: New file.
+   * config/os/gnu/ctype_configure_char.cc: New file.
+   * config/os/gnu/ctype_inline.h: New file.
+   * configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.
+
 2022-08-27  Patrick Palka  
diff --git a/src/libstdc++-v3/config/os/gnu/ctype_base.h b/src/libstdc++-v3/config/os/gnu/ctype_base.h
new file mode 100644
index 000..955146543db
--- /dev/null
+++ b/src/libstdc++-v3/config/os/gnu/ctype_base.h
@@ -0,0 +1,66 @@
+// Locale support -*- C++ -*-
+
+// Copyright (C) 1997-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/ctype_base.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{locale}
+ */
+
+//
+// ISO C++ 14882: 22.1  Locales
+//
+
+// Information as gleaned from /usr/include/ctype.h
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  /// @brief  Base class for ctype.
+  struct ctype_base
+  {
+// Non-standard typedefs.
+typedef const int* 		__to_type;
+
+// NB: Offsets into ctype::_M_table force a particular size
+// on the mask type. Because of this, we don't use an enum.
+typedef unsigned short 	mask;
+static const mask upper	= _ISupper;
+static const mask lower 	= _ISlower;
+static const mask alpha 	= _ISalpha;
+static const mask digit 	= _ISdigit;
+static const mask xdigit 	= _ISxdigit;
+static const mask space 	= _ISspace;
+static const mask print 	= _ISprint;
+static const mask graph 	= _ISalpha | _ISdigit | _ISpunct;
+static const mask cntrl 	= _IScntrl;
+static const mask punct 	= _ISpunct;
+static const mask alnum 	= _ISalpha | _ISdigit;
+#if __cplusplus >= 201103L
+static const mask blank	= _ISblank;
+#endif
+  };
+
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace
diff --git a/src/libstdc++-v3/config/os/gnu/ctype_configure_char.cc b/src/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
new file mode 100644
index 000..5a88fc11ab3
--- /dev/null
+++ b/src/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
@@ -0,0 +1,196 @@
+// Locale support -*- C++ -*-
+
+// Copyright (C) 2011-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITH

[Bug c/107170] New: ICE on valid code: in as_a, at value-range.h:381

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

Bug ID: 107170
   Summary: ICE on valid code: in as_a, at value-range.h:381
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.even-mendoza at imperial dot ac.uk
  Target Milestone: ---

The following code crashed GCC-13 when compiling with -O2, -O3 or -Os in Ubuntu
18, x-86_64; GCC-12, from April, seems to work fine.

===
#include 
int main() {
  double a;
  if (__builtin_signbit(a))
abort();
}
===
The trace:

during GIMPLE pass: vrp
fuzzer-file-12773.c: In function 'main':
fuzzer-file-12773.c:2:5: internal compiler error: in as_a, at value-range.h:381
2 | int main() {
  | ^~~~
0x80bc97 irange& as_a(vrange&)
.././../gcc-source/gcc/value-range.h:381
0x80bc97 irange& as_a(vrange&)
.././../gcc-source/gcc/value-range.h:379
0x80bc97 vrange::operator=(vrange const&)
.././../gcc-source/gcc/value-range.cc:202
0x80bc97 vrange::operator=(vrange const&)
.././../gcc-source/gcc/value-range.cc:199
0x12c61f2 vr_values::range_of_expr(vrange&, tree_node*, gimple*)
.././../gcc-source/gcc/vr-values.cc:188
0x1cf1f17 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
.././../gcc-source/gcc/gimple-range-fold.cc:550
0x1cf3c10 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
.././../gcc-source/gcc/gimple-range-fold.cc:489
0x1cf402b fold_range(vrange&, gimple*, range_query*)
.././../gcc-source/gcc/gimple-range-fold.cc:316
0x12c9e9f vr_values::extract_range_basic(value_range_equiv*, gimple*)
.././../gcc-source/gcc/vr-values.cc:1245
0x12269fd vrp_prop::visit_stmt(gimple*, edge_def**, tree_node**)
.././../gcc-source/gcc/tree-vrp.cc:3865
0x111c5a6 ssa_propagation_engine::simulate_stmt(gimple*)
.././../gcc-source/gcc/tree-ssa-propagate.cc:230
0x111c892 ssa_propagation_engine::simulate_block(basic_block_def*)
.././../gcc-source/gcc/tree-ssa-propagate.cc:337
0x111ccc3 ssa_propagation_engine::ssa_propagate()
.././../gcc-source/gcc/tree-ssa-propagate.cc:504
0x12331f5 execute_vrp
.././../gcc-source/gcc/tree-vrp.cc:4215

[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Alex Coplan  ---
(In reply to Romain Dolbeau from comment #8)
> Hello,
> 
> I only posted the patch to the (web) bug report, I'm not sure if that
> automatically notify the ML or not...

No, you will need to submit the patch yourself to gcc-patc...@gcc.gnu.org, see
the contribution guidelines here: https://gcc.gnu.org/contribute.html

[Bug c++/106841] [12 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138

[kenneth.hoste at ugent dot be via Gcc-bugs]

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

Kenneth Hoste  changed:

   What|Removed |Added

 CC||kenneth.hoste at ugent dot be

--- Comment #9 from Kenneth Hoste  ---
I seem to be running into the same problem using GCC 11.3 (when compiling
OpenMM 7.7.0 with CUDA support). Is there a reason why the fix wasn't
backported to GCC 11 too?

[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

[romain at dolbeau dot org via Gcc-bugs]

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

--- Comment #8 from Romain Dolbeau  ---
Hello,

I only posted the patch to the (web) bug report, I'm not sure if that
automatically notify the ML or not...

Cordially,

[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #7 from Alex Coplan  ---
(In reply to Romain Dolbeau from comment #3)
> Created attachment 53191 [details]
> Patch to resolve the issue by moving strchr to strrchr

Hi Romain, have you submitted the patch to the gcc-patches mailing list for
review?

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[amonakov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Alexander Monakov  ---
Just optimizing out the redundant store seems difficult because on some targets
scheduling is invoked from reorg (and it relies on alias sets).

We need a solution that works for combine too — is it possible to invent a
representation for a no-op in-place MEM "move" that only changes its alias set?

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
If we don't want to treat such copies as noop moves, then either we need to
change rtx_equal_p such that it will say MEMs aren't equal if the the alias
sets are different, or should tweak in the same spirit the i386.md peephole2
and set_noop_p (and perhaps some other spot).  But if we do either of that, it
would be nice to get rid of the for assembly actually noop move later on
shortly before expansion or emit it as nothing, because assembler then doesn't
care about alias sets.

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[amonakov at gcc dot gnu.org via Gcc-bugs]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
Cc'ing Jakub for the problematic i386.md peephole that loses alias set info.

As Andrew mentioned in comment #2, the next stop is combine, which sees

(set (mem:DI (plus:DI (mult:DI (sign_extend:DI (reg:SI 101))
(const_int 8 [0x8]))
(reg/v/f:DI 90 [ p4 ])) [1 MEM[(long int *)_11]+0 S8 A64])
(mem:DI (plus:DI (mult:DI (sign_extend:DI (reg:SI 101))
(const_int 8 [0x8]))
(reg/v/f:DI 90 [ p4 ])) [2 *_11+0 S8 A64]))

as a no-op move and removes it (but note differing alias sets in the MEMs).

And with -fdisable-rtl-combine it is then broken by peephole2 of all things:

;; Attempt to optimize away memory stores of values the memory already
;; has.  See PR79593.
(define_peephole2
  [(set (match_operand 0 "register_operand")
(match_operand 1 "memory_operand"))
   (set (match_operand 2 "memory_operand") (match_dup 0))]
  "!MEM_VOLATILE_P (operands[1])
   && !MEM_VOLATILE_P (operands[2])
   && rtx_equal_p (operands[1], operands[2])
   && !reg_overlap_mentioned_p (operands[0], operands[2])"
  [(set (match_dup 0) (match_dup 1))])

[Bug c++/104433] [modules] Importing and using std::make_shared causes linker errors

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2022-10-06

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

[seurer at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
One of the compilation commands:

/home/seurer/gcc/git/install/gcc-test/bin/g++ -c -o auto_derivative_function.o
-DSPEC_CPU -DNDEBUG  -Iinclude -DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3
-m64 -O3 -mcpu=power8 -ffast-math -funroll-loops -fpeel-loops -fvect-cost-model
-mpopcntd -mrecip=rsqrt-DSPEC_CPU_LP64 -DSPEC_CPU_LINUX  -include cstddef
-std=gnu++98  auto_derivative_function.cc

[Bug analyzer/107158] False postives from -Wanalyzer-malloc-leak on tin-2.6.2

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from David Malcolm  ---
Thanks;  I can reproduce the ICE using the attachment.  Looks like I reduced
the reproducer too much; sorry.

[Bug c++/107161] gcc doesn't constant fold member if any other member is mutable

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ivan Sorokin  ---
> Do constexpr/consteval work in such circumstances?

Yes, constexpr works for variables like "p.a":

extern constexpr mytype p = {1, 2};

int foo()
{
constexpr int t = p.a + 10;
return t;
}

foo():
mov eax, 11
ret

https://godbolt.org/z/K9a69E4ar

[Bug sanitizer/87191] UBSan doesn't catch invalid pointer arithmetic outside known object bounds

[Dmitriy.Poterukha at uvoteam dot com via Gcc-bugs]

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

--- Comment #6 from creeon  ---
#0 0x401191 in bar (/home/marxin/Programming/testcases/a.out+0x401191)
#1 0x40122a in main https://stemhave.com/programming-help.html
(/home/marxin/Programming/testcases/a.out+0x40122a)
#2 0x76c71fea in __libc_start_main ../csu/libc-start.c:308
#3 0x4010a9 in _start (/home/marxin/Programming/testcases/a.out+0x4010a9)

At a minimum we should diagnose if offsetting a pointer to a toplevel object
not by 0/1 (ideally also if not by 0 and then dereferencing?), e.g.:

warning: creating out-of-bounds pointer based on complete object 'a'

How i canl all fix it?

[Bug sanitizer/87191] UBSan doesn't catch invalid pointer arithmetic outside known object bounds

[Dmitriy.Poterukha at uvoteam dot com via Gcc-bugs]

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

creeon  changed:

   What|Removed |Added

 CC||Dmitriy.Poterukha at uvoteam 
dot c
   ||om

--- Comment #5 from creeon  ---
#0 0x401191 in bar (/home/marxin/Programming/testcases/a.out+0x401191)
#1 0x40122a in main https://stemhave.com/programming-help.html
(/home/marxin/Programming/testcases/a.out+0x40122a)
#2 0x76c71fea in __libc_start_main ../csu/libc-start.c:308
#3 0x4010a9 in _start (/home/marxin/Programming/testcases/a.out+0x4010a9)

At a minimum we should diagnose if offsetting a pointer to a toplevel object
not by 0/1 (ideally also if not by 0 and then dereferencing?), e.g.:

warning: creating out-of-bounds pointer based on complete object 'a'

[Bug tree-optimization/56826] [4.9 Regression] Run-fail after r197189.

[Dmitriy.Poterukha at uvoteam dot com via Gcc-bugs]

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

creeon  changed:

   What|Removed |Added

 CC||Dmitriy.Poterukha at uvoteam 
dot c
   ||om

--- Comment #6 from creeon  ---
Most wanted essay writing servicec in U.S.
https://writingservice.essayhave.com/

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
The bug in instruction scheduling remains (if it is really there).

[Bug debug/107169] [13 Regression] -fcompare-debug failure at -O and above since r13-2921-gf1adf45b17f7f1ed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-3131-g0af8d957d5911fc7659b4174cfc2213289bbed23
Author: Richard Biener 
Date:   Thu Oct 6 11:48:03 2022 +0200

middle-end/107115 - avoid bogus redundant store removal during RTL
expansion

The following preserves the (premature) redundant store removal
done in store_expr by appropriately guarding it with
mems_same_for_tbaa_p.  The testcase added needs scheduling disabled
for now since there's a similar bug there still present.

PR middle-end/107115
* expr.cc (store_expr): Check mems_same_for_tbaa_p before
eliding a seemingly redundant store.

* gcc.dg/torture/pr107115.c: New testcase.

[Bug preprocessor/56549] #pragma once ineffective with BOM in include file

[Dmitriy.Poterukha at uvoteam dot com via Gcc-bugs]

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

creeon  changed:

   What|Removed |Added

 CC||Dmitriy.Poterukha at uvoteam 
dot c
   ||om

--- Comment #8 from creeon  ---
Here is the patch for the current master. I have tested it on large C++ code
bases. So far, it builds successfully and significantly faster.

diff --git a/libcpp/files.c b/libcpp/files.c
index 301b2379a23..cbc2b0f4540 https://goo.gl/2DqXGj 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -1978,25 +1978,28 @@ _cpp_save_file_entries (cpp_reader *pfile, FILE *fp)
   result->entries[count].once_only = f->once_only;
   /* |= is avoided in the next line because of an HP C compiler bug */
   result->have_once_only = result->have_once_only | f->once_only;
+
   if (f->buffer_valid)
-   md5_buffer ((const char *)f->buffer,
-   f->st.st_size, result->entries[count].sum);
+{
+  md5_buffer ((const char *)f->buffer,
+  f->st.st_size, result->entries[count].sum);
+}
   else
-   {
- FILE *ff;
- int oldfd = f->fd;
-
- if (!open_file (f))
-   {
- open_file_failed (pfile, f, 0, 0);
- free (result);
- return false;
-   }
- ff = fdopen (f->fd, "rb");
- md5_stream (ff, result->entries[count].sum);
- fclose (ff);
- f->fd = oldfd;
-   }
+{
+  if (!read_file (pfile, f, 0))
+{
+  return false;
+}
+
+  md5_buffer ((const char *)f->buffer,
+  f->st.st_size, result->entries[count].sum);
+
+  const void* to_free = f->buffer_start;
+  f->buffer_start = NULL;
+  f->buffer = NULL;
+  f->buffer_valid = false;
+  free ((void*) to_free);
+}
   result->entries[count].size = f->st.st_size;
 }

Hi how are you fixed it?

[Bug debug/107169] [13 Regression] -fcompare-debug failure at -O and above since r13-2921-gf1adf45b17f7f1ed

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-06
 Ever confirmed|0   |1
Summary|[13 Regression] |[13 Regression]
   |-fcompare-debug failure at  |-fcompare-debug failure at
   |-O and above|-O and above since
   ||r13-2921-gf1adf45b17f7f1ed
 Status|UNCONFIRMED |NEW
 CC||erozen at microsoft dot com,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r13-2921-gf1adf45b17f7f1ed.

[Bug debug/107169] New: [13 Regression] -fcompare-debug failure at -O and above

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107169
   Summary: [13 Regression] -fcompare-debug failure at -O and
above
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fcompare-debug testcase.C
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure

$ diff -u a-testcase*.C.gkd
--- a-testcase.C.gkd2022-10-06 13:22:34.389297164 +0200
+++ a-testcase.gk.C.gkd 2022-10-06 13:22:34.419297164 +0200
@@ -66,7 +66,7 @@
  -> 6)
 (note # 0 0 [bb 3] NOTE_INSN_BASIC_BLOCK)
 (insn # 0 0 3 (set (mem/f/c:DI (symbol_ref:DI ("_class") [flags 0x2] 
) [ _class+0 S8 A64])
-(const_int 0 [0])) "testcase.C":170:31 discrim 2# {*movdi_internal}
+(const_int 0 [0])) "testcase.C":170:31 discrim 3# {*movdi_internal}
  (nil))
 (code_label # 0 0 4 6 (nil) [1 uses])
 (note # 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK)


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-3128-20221006123905-gdb2f5d66123-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/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-r13-3128-20221006123905-gdb2f5d66123-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221006 (experimental) (GCC)

[Bug c++/107168] [11/12/13 Regression] Wrong errors for concepts with default lambda not-type argument since r11-3714-gc1c62aec6751678e

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

Summary|Wrong errors for concepts   |[11/12/13 Regression] Wrong
   |with default lambda |errors for concepts with
   |not-type argument   |default lambda not-type
   ||argument since
   ||r11-3714-gc1c62aec6751678e
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-06

--- Comment #1 from Martin Liška  ---
Started with r11-3714-gc1c62aec6751678e.

[Bug c/107162] -Wmisleading-indentation is blinded by comments

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
I suppose the better diagnostic would point out that

if (num > 20)
return num * num;
else
return num + num;

is unreachable?

[Bug c++/107161] gcc doesn't constant fold member if any other member is mutable

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
GCC relies on 'p' being in .rodata for the folding which of course cannot be
the case with a mutable member.  Note the frontend clears the 'const' from the
declaration because of the mutable member and we have no way to distinguish
constant from non-constant members here.

Do constexpr/consteval work in such circumstances?

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |13.0

--- Comment #1 from Richard Biener  ---
what other flags do you use?

[Bug debug/107154] [12 Regression] GDB jumping to end of block when stepping over construction of local variable

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 Regression] GDB  |[12 Regression] GDB jumping
   |jumping to end of block |to end of block when
   |when stepping over  |stepping over construction
   |construction of local   |of local variable
   |variable|
   Target Milestone|--- |12.3
   Priority|P3  |P2
  Known to work||13.0
  Known to fail|13.0|

[Bug tree-optimization/107153] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #1 from Richard Biener  ---
Likely my (virtual LC update-ssa) fault.

[Bug c++/107148] [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |10.5

[Bug tree-optimization/107107] [10/11/12 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Wrong
   |Wrong codegen from TBAA |codegen from TBAA when
   |when stores to distinct |stores to distinct
   |same-mode types are |same-mode types are
   |collapsed?  |collapsed?

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/107147] [13 Regression] ICE in register_local_var_uses, at cp/coroutines.cc:3923

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:85333b9265720fc4e49397301cb16324d2b89aa7

commit r13-3126-g85333b9265720fc4e49397301cb16324d2b89aa7
Author: Richard Biener 
Date:   Thu Oct 6 11:20:16 2022 +0200

tree-optimization/107107 - tail-merging VN wrong-code

The following fixes an unintended(?) side-effect of the special
MODIFY_EXPR expression entries we add for tail-merging during VN.
We shouldn't value-number the virtual operand differently here.

PR tree-optimization/107107
* tree-ssa-sccvn.cc (visit_reference_op_store): Do not
affect value-numbering when doing the tail merging
MODIFY_EXPR lookup.

* gcc.dg/pr107107.c: New testcase.

[Bug c++/107140] Potential false positive uninitialized variable warning with -Wmaybe-uninitialized

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||24639
   Last reconfirmed||2022-10-06
   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you attach the testcase as a tarfile please?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/107138] [12/13 regression] std::variant triggers false-positive 'may be used uninitialized' warning

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|[12 regression] |[12/13 regression]
   |std::variant triggers   |...> triggers
   |false-positive 'may be used |false-positive 'may be used
   |uninitialized' warning  |uninitialized' warning
 Blocks||24639
   Target Milestone|--- |12.3


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-06
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/107128] armhf: floatn-common.h:214:9: error: multiple types in one declaration

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Target||arm
 Status|WAITING |RESOLVED

--- Comment #5 from Richard Biener  ---
Invalid then.

[Bug preprocessor/107089] Line-terminating '\' leaves the characters when the next-line is a multi-line comment

[wcs84014 at xcoxc dot com via Gcc-bugs]

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

JohnDoe  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from JohnDoe  ---
Close report.

[Bug c/107127] [11/12/13 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #4 from Richard Biener  ---
Mind testing a patch then...?

[Bug bootstrap/107120] [13 Regression] trunk fails to bootstrap on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/107117] "atan2" fails to set the floating-point inexact exception due to constant folding, in some cases

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
Btw, we only avoid inexact constant foldings for -frounding-math, not with
-ftrapping-math (which guards FP exception state).  See do_mpfr_ckconv.
So we could do better here if we want (but then if at runtime the inexact
exception is raised is unspecified).

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
So possibly expand_assignment is eliding the store somewhere downthread
(it's operand_equal_p check shouldn't fire).  It's

rtx
store_expr (tree exp, rtx target, int call_param_p,
bool nontemporal, bool reverse)
{
...
  if ((! rtx_equal_p (temp, target)
   || (temp != target && (side_effects_p (temp)
  || side_effects_p (target

which doesn't fire.  We have

(gdb) p debug_rtx (temp)
(mem:DI (reg/f:DI 87 [ _11 ]) [2 *_11+0 S8 A64])
(gdb) p debug_rtx (target)
(mem:DI (reg/f:DI 87 [ _11 ]) [1 MEM[(long int *)_11]+0 S8 A64])

Note that even just matching up MEM_ALIAS_SET isn't enough.  I'd call the
above optimization premature at least.

(gdb) p mems_same_for_tbaa_p (temp, target)
$13 = false

so

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 80bb1b8a4c5..71a7fc19c42 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6207,7 +6207,8 @@ store_expr (tree exp, rtx target, int call_param_p,

   if ((! rtx_equal_p (temp, target)
|| (temp != target && (side_effects_p (temp)
- || side_effects_p (target
+ || side_effects_p (target)
+ || !mems_same_for_tbaa_p (temp, target
   && TREE_CODE (exp) != ERROR_MARK
   /* If store_expr stores a DECL whose DECL_RTL(exp) == TARGET,
 but TARGET is not valid memory reference, TEMP will differ

fixes this mistake.  But then we run into the sched issue which
-fno-schedule-insns2 "fixes".

[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P4  |P3
   Keywords||missed-optimization
   Target Milestone|--- |13.0

--- Comment #5 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #4)
> I'll double check, but IIRC we throw away the loop structures at the end of
> DOM and they're supposed to be rebuilt (which appears to be happening as we
> re-construct LCSSA).

If you elide a loop it gets removed by fixup but we never fully re-build
loops.  Eliding a loop might have removed a stmt based on which undefined
behavior on overflow we could have derived an upper bound for the outer loop.
But you really have to sit down and see why we are no longer deriving
number of iterations [upper bound].

[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Richard Biener  ---
The issue is how we value-number for tail-merging.  We do

Processing block 1: BB4
Value numbering stmt = MEM[(long int *)_3] = 2;
RHS 2 simplified to 2
No store match
Value numbering store MEM[(long int *)_3] to 2
Setting value number of .MEM_12 to .MEM_12 (changed)
marking outgoing edge 4 -> 5 executable
Processing block 2: BB3
Value numbering stmt = *_3 = 2;
RHS 2 simplified to 2
Setting value number of .MEM_11 to .MEM_12 (changed)
marking outgoing edge 3 -> 5 executable
Processing block 3: BB5
Value numbering stmt = .MEM_10 = PHI <.MEM_11(3), .MEM_12(4)>
Setting value number of .MEM_10 to .MEM_12 (changed)
Value numbering stmt = _9 = *p_5(D);
Setting value number of _9 to 1 (changed)

oops.  So we figure that the two stores from '2' are "redundant" which causes
us to only consider one (the wrong one) when later looking up *p_5(D).

That's

  if (!resultsame)
{
  /* Only perform the following when being called from PRE
 which embeds tail merging.  */
  if (default_vn_walk_kind == VN_WALK)
{
  assign = build2 (MODIFY_EXPR, TREE_TYPE (lhs), lhs, op);
  vn_reference_lookup (assign, vuse, VN_NOWALK, &vnresult, false);
  if (vnresult)
{
  VN_INFO (vdef)->visited = true;
  return set_ssa_val_to (vdef, vnresult->result_vdef);
}

that's a case I never understood fully (and that seems wrong).  That
visited flag set is also odd.

I'm testing a patch.

[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/107099] uncprop a bit too eager

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-06
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
uncprop should really be merged into the out-of-SSA coalescing machinery, it's
sole purpose is to avoid edge copies (which for constants you always have to
perform) when there's the possibility to generate reg-reg moves or coalescing
instead.

As such it's a heuristic that needs to be weighted against other heuristics
in place.

In this case we emit a copy instead of a zeroing (and zeroing is cheap on the
target, so zero might be a good candidate to special-case anyway), but we
have the zeroing in the loop body now.

The odd thing is that we perform desired coalescing:

Partition 0 (_1(D) - 1 6 11 )

(_1(D) is created for DECL_RESULT)

but expansion of __builtin_ia32_ptestz128 does

;; _11 = __builtin_ia32_ptestz128 (_4, _4);

(insn 17 16 18 (set (reg:SI 90)
(const_int 0 [0])) "include/smmintrin.h":69:10 -1
 (nil))

(insn 18 17 19 (set (reg:CC 17 flags)
(unspec:CC [
(reg:V2DI 82 [ _4 ]) repeated x2
] UNSPEC_PTEST)) "include/smmintrin.h":69:10 -1
 (nil))

(insn 19 18 20 (set (strict_low_part (subreg:QI (reg:SI 90) 0))
(eq:QI (reg:CC 17 flags)
(const_int 0 [0]))) "include/smmintrin.h":69:10 -1
 (nil))

(insn 20 19 0 (set (reg:SI 86 [  ])
(reg:SI 90)) "include/smmintrin.h":69:10 -1
 (nil))

which eventually ends up as

(insn 21 20 22 4 (set (reg:SI 86 [  ])
(eq:SI (reg:CC 17 flags)
(const_int 0 [0]))) "t.c":7:12 940 {*setcc_si_1_movzbl}
 (nil))
(jump_insn 22 21 23 4 (set (pc)
(if_then_else (ne (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref:DI 32)
(pc))) "t.c":7:12 946 {*jcc}
 (int_list:REG_BR_PROB 59055804 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))

that's not forseen by coalescing - that _11 is actually not needed inside
the loop but only the CC result.

So heuristically we might want to disable uncprop when definitions from
calls (to [target] builtins) would be used.

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
Fixed.

[Bug target/107131] [11/12/13 Regression] wrong code with -Os -fno-ipa-vrp -fno-tree-bit-ccp

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12 Regression] wrong|[11/12/13 Regression] wrong
   |code with -Os -fno-ipa-vrp  |code with -Os -fno-ipa-vrp
   |-fno-tree-bit-ccp   |-fno-tree-bit-ccp
   Target Milestone|--- |11.4

--- Comment #4 from Richard Biener  ---
Note __builtin_shufflevector might just be the point we were able to produce
the
input GIMPLE required to trigger the previously latent issue.

The difference between -O (working) and -Os (failing) starts at RTL expansion
only.

[Bug c++/107168] New: Wrong errors for concepts with default lambda not-type argument

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 107168
   Summary: Wrong errors for concepts with default lambda not-type
argument
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following code in accepted in Clang and MSVC, but GCC emits seemingly wrong
errors:

template  concept x = true;
struct S {
// GCC error: template argument 2 is invalid
operator x auto() { return 42; }
// GCC error: wrong number of template arguments (0, should be at least 1)
operator x<> auto() const { return 43; }
};

Online demo: https://godbolt.org/z/a3494qrG3

[Bug c++/106654] [C++23] P1774 - Portable assumptions

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r13-3106-g08b51baddc53d64aa4c5e7a81ef3c4bf320293be
Author: Jakub Jelinek 
Date:   Thu Oct 6 08:56:48 2022 +0200

c++, c: Implement C++23 P1774R8 - Portable assumptions [PR106654]

The following patch implements C++23 P1774R8 - Portable assumptions
paper, by introducing support for [[assume (cond)]]; attribute for C++.
In addition to that the patch adds [[gnu::assume (cond)]]; and
__attribute__((assume (cond))); support to both C and C++.
As described in C++23, the attribute argument is conditional-expression
rather than the usual assignment-expression for attribute arguments,
the condition is contextually converted to bool (for C truthvalue
conversion
is done on it) and is never evaluated at runtime.
For C++ constant expression evaluation, I only check the simplest
conditions
for undefined behavior, because otherwise I'd need to undo changes to
*ctx->global which happened during the evaluation (but I believe the spec
allows that and we can further improve later).
The patch uses a new internal function, .ASSUME, to hold the condition
in the FEs.  At gimplification time, if the condition is simple/without
side-effects, it is gimplified as if (cond) ; else __builtin_unreachable
();
and otherwise for now dropped on the floor.  The intent is to incrementally
outline the conditions into separate artificial functions and use
.ASSUME further to tell the ranger and perhaps other optimization passes
about the assumptions, as detailed in the PR.

When implementing it, I found that assume entry hasn't been added to
https://eel.is/c++draft/cpp.cond#6
Jonathan said he'll file a NB comment about it, this patch assumes it
has been added into the table as 202207L when the paper has been voted in.

With the attributes for both C/C++, I'd say we don't need to add
__builtin_assume with similar purpose, especially when __builtin_assume
in LLVM is just weird.  It is strange for side-effects in function call's
argument not to be evaluated, and LLVM in that case (annoyingly) warns
and ignores the side-effects (but doesn't do then anything with it),
if there are no side-effects, it will work like our
if (!cond) __builtin_unreachable ();

2022-10-06  Jakub Jelinek  

PR c++/106654
gcc/
* internal-fn.def (ASSUME): New internal function.
* internal-fn.h (expand_ASSUME): Declare.
* internal-fn.cc (expand_ASSUME): Define.
* gimplify.cc (gimplify_call_expr): Gimplify IFN_ASSUME.
* fold-const.h (simple_condition_p): Declare.
* fold-const.cc (simple_operand_p_2): Rename to ...
(simple_condition_p): ... this.  Remove forward declaration.
No longer static.  Adjust function comment and fix a typo in it.
Adjust recursive call.
(simple_operand_p): Adjust function comment.
(fold_truth_andor): Adjust simple_operand_p_2 callers to call
simple_condition_p.
* doc/extend.texi: Document assume attribute.  Move fallthrough
attribute example to its section.
gcc/c-family/
* c-attribs.cc (handle_assume_attribute): New function.
(c_common_attribute_table): Add entry for assume attribute.
* c-lex.cc (c_common_has_attribute): Handle
__have_cpp_attribute (assume).
gcc/c/
* c-parser.cc (handle_assume_attribute): New function.
(c_parser_declaration_or_fndef): Handle assume attribute.
(c_parser_attribute_arguments): Add assume_attr argument,
if true, parse first argument as conditional expression.
(c_parser_gnu_attribute, c_parser_std_attribute): Adjust
c_parser_attribute_arguments callers.
(c_parser_statement_after_labels) : Handle
assume attribute.
gcc/cp/
* cp-tree.h (process_stmt_assume_attribute): Implement C++23
P1774R8 - Portable assumptions.  Declare.
(diagnose_failing_condition): Declare.
(find_failing_clause): Likewise.
* parser.cc (assume_attr): New enumerator.
(cp_parser_parenthesized_expression_list): Handle assume_attr.
Remove identifier variable, for id_attr push the identifier into
expression_list right away instead of inserting it before all the
others at the end.
(cp_parser_conditional_expression): New function.
(cp_parser_constant_expression): Use it.
(cp_parser_statement): Handle assume attribute.
(cp_parser_expression_statement): Likewise.
(cp_parser_gnu_attribute_list): Use assume_attr for assume