[Bug c++/110555] New: internal compiler error: Segmentation fault when using std::ranges::range auto as a template parameter

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 110555
   Summary: internal compiler error: Segmentation fault when using
std::ranges::range auto as a template parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Original from
https://stackoverflow.com/questions/76617167/check-if-a-type-is-convertible-to-a-range-in-c20

#include 

template
void print(R&& range) {
  if (std::is_same_v) {
// ...
  }
}

int main() {
  int arr[] = {0, 1, 2};
  print(arr);
}

https://godbolt.org/z/4Wq5d6z3c

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 55472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55472=edit
Fix veclowering types

So the problem is veclowering should have just use boolean_type_node here for
the comparison.

There is another type issue when dealing with not a comparison and not  scalar
bitmask which fix is included here.

Still need to test it.

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

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

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

--- Comment #5 from Andrew Pinski  ---
Actually the issue is:
signed-boolean:32 _8 = _7 > 1;

That is not [-1,0] but still [0,1] ... (VRP says it is too).

Let me see where that is built.

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

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

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

--- Comment #4 from Andrew Pinski  ---
So originally we have:

signed-boolean:32 _8 = _7 > 1;
_Bool _9 = (_Bool) _8;
(int) _9;

I think if we swap around where the convert was, it will fix the issue.
That is:
 (bit_and (convert @0) { wide_int_to_tree
  (type,
   wi::mask (inter_prec, false,
 TYPE_PRECISION (type))); })))


But maybe we should check for which is a boolean type.

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

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

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

--- Comment #3 from Andrew Pinski  ---
It is this one:
/* Handle cases of two conversions in a row.  */
(for ocvt (convert float fix_trunc)
 (for icvt (convert float)
  (simplify
   (ocvt (icvt@1 @0))
...


/* A truncation to an unsigned type (a zero-extension) should be
   canonicalized as bitwise and of a mask.  */
(if (GIMPLE /* PR70366: doing this in GENERIC breaks -Wconversion.  */
 && final_int && inter_int && inside_int
 && final_prec == inside_prec
 && final_prec > inter_prec
 && inter_unsignedp)
 (convert (bit_and @0 { wide_int_to_tree
  (inside_type,
   wi::mask (inter_prec, false,
 TYPE_PRECISION (inside_type))); })))

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

[hliu at amperecomputing dot com via Gcc-bugs]

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

Hao Liu  changed:

   What|Removed |Added

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

--- Comment #12 from Hao Liu  ---
OK. Now I got your point of useless initialization may introduce extra cost.

[Bug tree-optimization/110554] veclowering introduces invalid wide Boolean values

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||internal-improvement,
   ||wrong-code
Summary|more invalid wide Boolean   |veclowering introduces
   |values  |invalid wide Boolean values
   Last reconfirmed||2023-07-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Simplified testcase (that will fail on all targets):
  typedef int __attribute__((__vector_size__ (1 * sizeof (int V;

  V v;

  void
  foo (void)
  {
v = ((1 | v) != 1);
  }

[Bug tree-optimization/110554] more invalid wide Boolean values

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
The case here is the match pattern which does:
((type)a)&1 into (type)(a&1).

Will double check.

[Bug tree-optimization/110554] New: more invalid wide Boolean values

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

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

Bug ID: 110554
   Summary: more invalid wide Boolean values
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The fix for PR 110487 improved the situation, but my tool still finds some
cases where GCC generates invalid  values.

One such case can be seen in gcc.c-torture/compile/pr104499.c:

  typedef int __attribute__((__vector_size__ (8 * sizeof (int V;

  V v;

  void
  foo (void)
  {
v = ((1 | v) != 1);
  }

Here veclower2 is introducing code

   _8;
   _10;
  ...
  gimple_assign 
  gimple_assign 


More examples of this failure can be seen in gcc.c-torture/compile/pr108237.c
and gcc.c-torture/compile/pr54713-1.c

[Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly invalid code on -O3

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

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

--- Comment #7 from Sergei Trofimovich  ---
(In reply to Richard Biener from comment #6)
> Turning off PRE also allows it to pass but I guess it's the same as with SRA.
> -fno-strict-aliasing also helps, -fno-ipa-modref doesn't.  I suspect
> bisection
> isn't going to help much, but maybe it points to a small set of changes on
> the testcase itself.

Bisect landed on the r12-4790-g4b3a325f07aceb :

$ git bisect bad
4b3a325f07acebf47e82de227ce1d5ba62f5bcae is the first bad commit
commit 4b3a325f07acebf47e82de227ce1d5ba62f5bcae
Author: Aldy Hernandez 
Date:   Thu Oct 28 15:35:21 2021 +0200

Remove VRP threader passes in exchange for better threading pre-VRP.

[Bug c++/110552] ICE on valid code in maybe_instantiate_noexcept

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Looks like it is a lambda inside a decltype is causing it.

The reason why I say that is if I change __apply_fn's operator() not to take a
second argument and remove the lambda from the call to it in __tag_from, then
this works.

[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
This appears to be fixed on trunk. Can we close it?

[Bug c++/110552] ICE on valid code in maybe_instantiate_noexcept

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-04
   Keywords||ice-on-invalid-code,
   ||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug c++/110552] ICE on valid code in maybe_instantiate_noexcept

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 55471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55471=edit
changed slightly to produce valid code

[Bug c++/110552] ICE on valid code in maybe_instantiate_noexcept

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 55470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55470=edit
reduced but invalid code

This is the reduced testcase I got but it became invalid code; maybe the
original is invalid too. But clang's error message is:
:31:25: error: member reference base type '__tag_t' (aka 'void') is not
a structure or union
   31 |   noexcept(__tag_t().get_env(__self))) {}
  |~^~~~
:30:15: note: in instantiation of exception specification for
'tag_invoke:33:25)>>' requested here
   30 |   friend auto tag_invoke(_Tag, const _Self &__self) noexcept(
  |   ^
:6:14: note: in instantiation of function template specialization
'stdexec::tag_invoke:33:25)>>' requested here
6 | decltype(tag_invoke(__declval<_Tag>(), __declval<_Args>()...));
  |  ^
:13:10: note: in instantiation of template type alias
'tag_invoke_result_t' requested here
   13 |   -> tag_invoke_result_t {}
  |  ^
:19:36: note: while substituting deduced template arguments into
function template 'operator()' [with _EnvProvider =
stdexec::__basic_sender:33:25)>]
   19 |  { get_env(__ep) };
  |^
:19:36: note: in instantiation of requirement here
   19 |  { get_env(__ep) };
  |^
:18:32: note: while substituting template arguments into constraint
expression here
   18 | concept environment_provider = requires(_EnvProvider &__ep) {
  |^~
   19 |  { get_env(__ep) };
  |  ~~
   20 |};
  |~
:35:15: note: while checking the satisfaction of concept
'environment_provider:33:25)>>' requested here
   35 | static_assert(stdexec::environment_provider);
  |   ^~~~

[Bug c++/110552] ICE on valid code in maybe_instantiate_noexcept

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda
 Blocks||107430

--- Comment #2 from Andrew Pinski  ---
Looks like it is a lambda inside a decltype is causing it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
[Bug 107430] [meta-bug] lambda in decltype

[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog

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

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

--- Comment #3 from Alexander Monakov  ---
Patch available:
https://inbox.sourceware.org/gcc-patches/8f73371d732237ed54ede44b7bd88...@ispras.ru/T/#u

[Bug c++/110552] ICE on valid code in maybe_instantiate_noexcept

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

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

--- Comment #1 from Andrew Pinski  ---
reducing ...

[Bug sanitizer/110553] -fsanitize=undefined needs -latomic on powerpc-unknown-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
I wonder what function uses 64bit values for atomics in ubsan. I only saw 32bit
values (well I saw pointers and size_t in backtrace and 32bit in ubsan).

[Bug sanitizer/110553] New: -fsanitize=undefined needs -latomic on powerpc-unknown-linux-gnu

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

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

Bug ID: 110553
   Summary: -fsanitize=undefined needs -latomic on
powerpc-unknown-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

```
#include 

int main (void) {
printf("hi\r\n");
}
```

```
$ gcc /tmp/foo.c -o /tmp/foo -fsanitize=undefined
/usr/lib/gcc/powerpc-unknown-linux-gnu/13/../../../../powerpc-unknown-linux-gnu/bin/ld:
/usr/lib/gcc/powerpc-unknown-linux-gnu/13/libubsan.so: undefined reference to
`__atomic_compare_exchange_8'
/usr/lib/gcc/powerpc-unknown-linux-gnu/13/../../../../powerpc-unknown-linux-gnu/bin/ld:
/usr/lib/gcc/powerpc-unknown-linux-gnu/13/libubsan.so: undefined reference to
`__atomic_load_8'
collect2: error: ld returned 1 exit status
```

```
$ gcc /tmp/foo.c -o /tmp/foo -fsanitize=undefined -latomic # works
```

```
$ nm -D /usr/lib/gcc/powerpc-unknown-linux-gnu/13/libubsan.so | grep -i atomic
 U __atomic_compare_exchange_8
 U __atomic_load_8
```

While in this instance I can inject -latomic, it's a pain to try do that for
various configure tests.

[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply

[moncef.mechri at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Moncef Mechri  ---
> Please next time attach (which you can do paste in the box) or paste inline
> the testcase rather than just link to godbolt .

Noted. Apologies.

> It is an older regression though.
> ```
> #include 
> 
> void mulx64(uint64_t *x, uint64_t *t)
> {
> __uint128_t r = (__uint128_t)*x * 0x9E3779B97F4A7C15ull;
> *t = (uint64_t)r ^ (uint64_t)( r >> 64 );
> }
> ```
> 
> It is just an extra mov.
> 
> Also the mulx should have allowed the register allocator to do better but it
> was worse ...

It is true that with this new test case, all GCC versions (including GCC 10)
seem to suffer from both issues reported in the original post.

But the original test case only exhibits suboptimal codegen for GCC >= 11, as
shown in the godbolt link shared above.

[Bug c++/110552] New: ICE on valid code in maybe_instantiate_noexcept

[eric.niebler at gmail dot com via Gcc-bugs]

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

Bug ID: 110552
   Summary: ICE on valid code in maybe_instantiate_noexcept
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Created attachment 55469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55469=edit
self-contained source file

Compile the attached source with -std=c++20. Result:

/home/eniebler/hello_world.cpp: In substitution of ‘template  requires  tag_invocable constexpr
stdexec::__tag_invoke::tag_invoke_result_t stdexec::__env::get_env_t::operator()(const _EnvProvider&) const
[with _EnvProvider = stdexec::__basic_sender<:: >]’:
/home/eniebler/hello_world.cpp:2221:16:   required from here
/home/eniebler/hello_world.cpp:1465:59: internal compiler error: in
maybe_instantiate_noexcept, at cp/pt.cc:26753
 1465 |   requires(_Tag __tag, _Args&&... __args) { tag_invoke((_Tag&&)
__tag, (_Args&&) __args...); };
  |
~~^
0xace10a maybe_instantiate_noexcept(tree_node*, int)
../../gcc/cp/pt.cc:26753
0x96272f mark_used(tree_node*, int)
../../gcc/cp/decl2.cc:5720
0x864a35 build_over_call
../../gcc/cp/call.cc:10394
0x867e0b build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.cc:5038
0xb304ff finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2924
0xacc4e5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21338
0xabb964 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19888
0x8c3193 tsubst_valid_expression_requirement
../../gcc/cp/constraint.cc:2002
0x8cc3c0 tsubst_simple_requirement
../../gcc/cp/constraint.cc:2036
0x8cc3c0 tsubst_requirement
../../gcc/cp/constraint.cc:2233
0x8cc3c0 tsubst_requires_expr
../../gcc/cp/constraint.cc:2363
0x8cc8aa tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:2382
0xac96c7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21749
0xabb964 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19888
0x8cde63 satisfy_atom
../../gcc/cp/constraint.cc:3041
0x8cde63 satisfy_constraint_r
../../gcc/cp/constraint.cc:3106
0x8ce723 satisfy_normalized_constraints
../../gcc/cp/constraint.cc:3131
0x8caefd satisfy_declaration_constraints
../../gcc/cp/constraint.cc:3352
0x8caefd constraint_satisfaction_value
../../gcc/cp/constraint.cc:3373
0x8ce78f constraints_satisfied_p(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:3410
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


See https://godbolt.org/z/1511TYvch for a demo of the bug on compiler explorer.

[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-04
  Known to fail||12.1.0, 14.0, 5.1.0, 7.1.0
Summary|[11/12/13/14 regression]|[11/12/13/14 Regression] an
   |Suboptimal codegen for 128  |extra mov when doing 128bit
   |bits multiplication on  |multiply
   |x86_64  |
  Known to work||4.9.4

--- Comment #2 from Andrew Pinski  ---
It is an older regression though.
```
#include 

void mulx64(uint64_t *x, uint64_t *t)
{
__uint128_t r = (__uint128_t)*x * 0x9E3779B97F4A7C15ull;
*t = (uint64_t)r ^ (uint64_t)( r >> 64 );
}
```

It is just an extra mov.

Also the mulx should have allowed the register allocator to do better but it
was worse ...

[Bug target/110551] [11/12/13/14 regression] Suboptimal codegen for 128 bits multiplication on x86_64

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 55468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55468=edit
testcase

Please next time attach (which you can do paste in the box) or paste inline the
testcase rather than just link to godbolt .

[Bug c/110376] Wrong code at -O1 on x86_64-linux-gnu

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Shaohua Li from comment #3)
> You post a commit for fixing this bug. Does this mean this report is not a
> DUP of 110228?

The commit was just a testcase (more testcases the better really); there were 3
different issues causing PR 110228 really, 2 for phiopt, one for ifcombine.
Anyways all 3 have been fixed on the trunk. one of those 3 fixed this issue and
a testcase was added just to make sure it does not get exposed again.

[Bug rtl-optimization/110551] New: [11 / 12 / 13 /14 regression] Suboptimal codegen for 128 bits multiplication on x86_64

[moncef.mechri at gmail dot com via Gcc-bugs]

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

Bug ID: 110551
   Summary: [11 / 12 / 13 /14 regression] Suboptimal codegen for
128 bits multiplication on x86_64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moncef.mechri at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/3hdondY6n

Codegen for the code shared above (which is a mixing step in boost.Unordered
when a non-avalanching hash function is being used [1] ) regressed since GCC
11. I believe there are 2 regressions:

Regression 1:

A redundant move is introduced:


movabs  rcx, -7046029254386353131
mov rax, rcx


The regression seems to be present at all optimization levels above -O0
(including -Os and -Og).

Possibly a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804


Regression 2

When using -march=haswell or newer, GCC >= 11 emits mulx. The resulting code is
longer (by 1 instruction) with no clear benefit to my untrained eyes. It looks
to me like the code generated by GCC 10 is optimal, even for haswell and newer.


I am reporting both issues in the same bug report because they seem related
enough. Let me know if you want me to split them into 2 bug reports instead.

[1]
https://github.com/boostorg/unordered/blob/9a7d1d336aaa73ad8e5f7c07bdb81b2e793f8d93/include/boost/unordered/detail/mulx.hpp#L111

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|12.4|14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #14 from Andrew Pinski  ---
Even though this could cause problems in GCC 12.x and GCC 13.x, we have not
seen any reports of causing issues and I don't know of a testcase where the
wrong code gets exposed either.

So closing as fixed.

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #13 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-2299-g71b68cc559b5d30d07e6b507df7cc6d008f56aad
Author: Andrew Pinski 
Date:   Fri Jun 30 19:22:48 2023 -0700

PR 110487: `(a !=/== CST1 ? CST2 : CST3)` pattern for type safety

The problem here is we might produce some values out of the type's
min/max (and/or valid values, e.g. signed booleans). The fix is to
use an integer type which has the same precision and signedness
as the original type.

Note two_value_replacement in phiopt had the same issue in previous
versions; though I don't know if a problem will show up there.

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/110487
* match.pd (a !=/== CST1 ? CST2 : CST3): Always
build a nonstandard integer and use that.

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #12 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:2e5c1b123d5bc4b7eca91f1eb2dab88d0bcdfcfa

commit r14-2298-g2e5c1b123d5bc4b7eca91f1eb2dab88d0bcdfcfa
Author: Andrew Pinski 
Date:   Fri Jun 30 17:50:08 2023 -0700

Fix PR 110487: invalid signed boolean value

This fixes the first part of this bug where `a ? -1 : 0`
would cause a value of 1 into the signed boolean value.
It fixes the problem by casting to an integer type of
the same size/signedness before doing the negative and
then casting to the type of expression.

OK? Bootstrapped and tested on x86_64.

gcc/ChangeLog:

* match.pd (a?-1:0): Cast type an integer type
rather the type before the negative.
(a?0:-1): Likewise.

[Bug other/110550] New: libintl build without -fPIC even though --enable-shared is configured

[swilde--- via Gcc-bugs]

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

Bug ID: 110550
   Summary: libintl build without -fPIC even though
--enable-shared is configured
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: swi...@sha-bang.de
  Target Milestone: ---

This is kind of a sequel to #100096

Building on NetBSD 9.3 amd64

Configured with:
LDFLAGS="-L/usr/local/lib -R/usr/local/lib" ../gcc-12.3.0/configure \
  --enable-shared \
  --enable-host-shared \
  --enable-checking=release \
  --enable-languages=jit \
  --disable-multilib \
  --disable-libssp \
  --disable-lto \
  --disable-libquadmath \
  --disable-liboffloadmic \
  --disable-libada \
  --disable-libsanitizer \
  --disable-libquadmath-support \
  --disable-libgomp \
  --disable-libvtv \
  --disable-libsanitizer \
  --with-gmp=/usr/local \
  --with-mpc=/usr/local \
  --with-mpfr=/usr/local

building fails, because libintl.a is build without -fPIC:

/usr/bin/ld: ./../intl/libintl.a(bindtextdom.o): relocation R_X86_64_32 against
symbol `libintl_nl_default_dirname' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: ./../intl/libintl.a(loadmsgcat.o): relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: ./../intl/libintl.a(textdomain.o): relocation R_X86_64_32 against
symbol `libintl_nl_default_default_domain' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: ./../intl/libintl.a(dcigettext.o): relocation R_X86_64_32S against
`.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: ./../intl/libintl.a(plural-exp.o): relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: ./../intl/libintl.a(localcharset.o): relocation R_X86_64_32
against `.rodata.str1.1' can not be used when making a shared object; recompile
with -fPIC
/usr/bin/ld: ./../intl/libintl.a(localename.o): relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: ./../intl/libintl.a(log.o): relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: ./../intl/libintl.a(finddomain.o): relocation R_X86_64_32 against
`.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: ./../intl/libintl.a(localealias.o): relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: ./../intl/libintl.a(plural.o): relocation R_X86_64_32S against
`.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
gmake[3]: *** [../../gcc-12.3.0/gcc/jit/Make-lang.in:168: libgccjit.so.0.0.1]
Error 1
gmake[3]: *** Waiting for unfinished jobs
rm gcc.pod
gmake[3]: Leaving directory '/home/wilde/src/gcc/gcc-12.3.0-build_noboot/gcc'
gmake[2]: *** [Makefile:5038: all-stage3-gcc] Error 2
gmake[2]: Leaving directory '/home/wilde/src/gcc/gcc-12.3.0-build_noboot'
gmake[1]: *** [Makefile:22605: stage3-bubble] Error 2
gmake[1]: Leaving directory '/home/wilde/src/gcc/gcc-12.3.0-build_noboot'
gmake: *** [Makefile:1067: all] Error 2

Strange enough, when manually entering the directory `intl` and
rebuilding the library simply by issuing `make clean ; make` it _will_
be build with -fPIC as expected.

[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||vaibhavawale3 at gmail dot com

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

[Bug libstdc++/110549] Undefined behavior sanitizer triggered in basic_string::_M_construct that uses iterator overload with input iterator tag

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed a few months ago, you should update your GCC.

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

[Bug libstdc++/110549] New: Undefined behavior sanitizer triggered in basic_string::_M_construct that uses iterator overload with input iterator tag

[vaibhavawale3 at gmail dot com via Gcc-bugs]

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

Bug ID: 110549
   Summary: Undefined behavior sanitizer triggered in
basic_string::_M_construct that uses iterator overload
with input iterator tag
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vaibhavawale3 at gmail dot com
  Target Milestone: ---

Created attachment 55467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55467=edit
Source code to reproduce bug. Writes a string to file and reads from file using
istreambuf_iterator.

With upgrade to gcc-13, I am running into undefined behavior when reading from
text file using `std::istreambuf_iterator`. The bad behavior is caused by the
check:

```
if (_M_string_length > _S_local_capacity)
__builtin_unreachable();
```
made in commit
https://github.com/gcc-mirror/gcc/commit/bf78b43873b0b7e8f9a430df38749b8b61f9c9b8

The source code (full file attached) that triggers this __builtin_unreachable()
path is:
```
std::ifstream istream{tempFile};
std::string contents = std::string{std::istreambuf_iterator{istream},
std::istreambuf_iterator{}};

```

In `std::__cxx11::basic_string::_M_construct(_InIterator __beg, _InIterator
__end, std::input_iterator_tag)`, `_M_string_length` is initialized at the end,
but it is used in function `_M_is_local` before its initialized. This leads to
the undefined behavior complaint.

To reproduce the issue, compile with sanitizer enabled:
```
g++ -g -O2 -Wall -Wextra -fsanitize=undefined  string_make.cpp -o string_make
./string_make
```

Output from sanitizer enabled binary:
```
/usr/include/c++/13.1.1/bits/basic_string.h:280:29: runtime error: execution
reached an unreachable program point
#0 0x55e5315ee19b in std::__cxx11::basic_string, std::allocator >::_M_is_local() const
/usr/include/c++/13.1.1/bits/basic_string.h:280
#1 0x55e5315ee19b in std::__cxx11::basic_string, std::allocator >::_M_is_local() const
/usr/include/c++/13.1.1/bits/basic_string.h:275
#2 0x55e5315ee19b in std::__cxx11::basic_string, std::allocator >::_M_dispose()
/usr/include/c++/13.1.1/bits/basic_string.h:295
#3 0x55e5315ee19b in void std::__cxx11::basic_string, std::allocator
>::_M_construct >
>(std::istreambuf_iterator >,
std::istreambuf_iterator >,
std::input_iterator_tag) /usr/include/c++/13.1.1/bits/basic_string.tcc:200
#4 0x55e5315ee19b in std::__cxx11::basic_string, std::allocator
>::basic_string >,
void>(std::istreambuf_iterator >,
std::istreambuf_iterator >, std::allocator
const&) /usr/include/c++/13.1.1/bits/basic_string.h:766
#5 0x55e5315ee19b in main /host_dir/string_make.cpp:21
#6 0x7f148356e84f  (/usr/lib/libc.so.6+0x2384f) (BuildId:
2f005a79cd1a8e385972f5a102f16adba414d75e)
#7 0x7f148356e909 in __libc_start_main (/usr/lib/libc.so.6+0x23909)
(BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
#8 0x55e5315efd24 in _start (/host_dir/string_make+0x6d24) (BuildId:
84a1c6cd0213d688554e0a44d2cf01327b106fba)
```

--
GCC version info:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230429 (GCC) 

--
System info:

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
VERSION_ID=20230611.0.157136
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/;
DOCUMENTATION_URL="https://wiki.archlinux.org/;
SUPPORT_URL="https://bbs.archlinux.org/;
BUG_REPORT_URL="https://bugs.archlinux.org/;
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/;
LOGO=archlinux-logo

[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm

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

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

--- Comment #8 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > Constraints are completely the wrong tool for this.  Just use modes, which
> > *are* the right tool?
> 
> Well you cannot specify modes in the asm, so I think you're saying we need
> use the correct type that maps to a internal to GCC mode that has the
> even/odd register behavior, so something like:
> 
>   unsigned int foo __attribute__ ((mode (XX)));
> 
> ...where XXmode is the new integer mode that gives us even/odd register
> pairs?  Of course we have to be careful about how this all works wrt -m32
> versus -m64.

No, the type there is "unsigned int".  I meant to say exactly what I did say:
just use modes.  Which you indeed do in user code by the mode attribute, yes.

And you do not need a new mode: PTImode should just work.  But the user
specifying that is currently broken it seems?

Without -mpowerpc64 you cannot *have* 128-bit integers in registers.  That
should be
fixed, but you cannot have it in just *two* registers, which is what is
required
here.  For most targets that then means -m64 is required.

[Bug c/110376] Wrong code at -O1 on x86_64-linux-gnu

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

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

--- Comment #3 from Shaohua Li  ---
You post a commit for fixing this bug. Does this mean this report is not a DUP
of 110228?

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #7)
> I have tried to start a git bisect and the current range is 
> g:f3d87219dd502d5c .. g:9757e4440bd8755d.
> 
> This is 15 commits.

I messed this one up and started again. As expected,
Patrick's commit seems to be the one:

$ git bisect bad db38b285ba61c5b8
db38b285ba61c5b888adc0d117177bfd774c1153 is the first bad commit
commit db38b285ba61c5b888adc0d117177bfd774c1153
Author: Patrick Palka 
Date:   Fri Jun 30 15:05:22 2023 -0400

c++: fix up caching of level lowered ttps

[Bug tree-optimization/110546] Function clone not treated as valid allocator with -Wmismatched-dealloc

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0, 12.1.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-04
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.


>I believe this happens because the compiler does not recognize that 
>alloc.constprop is a valid allocation function

No that is not the issue. This code to figure out the mistmatch seems too
complex for my liking.

The attribute is still there:
__attribute__((malloc (deallocD.2759, 1), noinline))
voidD.53 * alloc.constpropD.2777 ()

[Bug fortran/110548] New: Segfault with optional argument and OpenMP tasks

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

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

Bug ID: 110548
   Summary: Segfault with optional argument and OpenMP tasks
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following shows a segfault at run time resulting from use of an optional
argument in a function with OpenMP tasks:

module taskerMod

   type :: helper
   end type helper

   type :: tasker
  integer :: depth=-1
contains
  final ::taskerDestruct
  procedure :: compute => taskerCompute
   end type tasker

 contains

   subroutine taskerDestruct(self)
 !$ use :: OMP_Lib  
 implicit none
 type(tasker), intent(inout) :: self

 write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," :
",omp_get_thread_num()  
 return
   end subroutine taskerDestruct

   recursive subroutine taskerCompute(self,helper_)
 !$ use :: OMP_Lib  
 implicit none
 class(tasker), intent(inout)   :: self
 class(helper), intent(inout), optional :: helper_

 !$omp atomic   
 self%depth=self%depth+1
 write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() 
 if (self%depth < 3) then
!$omp task untied   
call self%compute(helper_)
!$omp end task  
 end if
 return
   end subroutine taskerCompute

 end module taskerMod

 program testTasks
   use :: taskerMod
   implicit none
   type(tasker) :: tasker_
   type(helper) :: helper_

   tasker_=tasker(0)
   !$omp parallel   
   !$omp single 
   !$omp taskgroup  
   !$omp task untied
   call tasker_%compute()
   !$omp end task   
   !$omp end taskgroup  
   !$omp end single 
   !$omp end parallel   
 end program testTasks

$ gfortran test1.F90  -fopenmp
$ ./a.out
 DESTRUCT FROM DEPTH   -1
 DEPTH1

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:
#0  0x2ac99289a1ef in ???
#1  0x401840 in ???
#2  0x2ac9925a9606 in GOMP_task
at ../../../gcc-git/libgomp/task.c:644
#3  0x401588 in ???
#4  0x40197b in ???
#5  0x2ac9925a77a4 in gomp_barrier_handle_tasks
at ../../../gcc-git/libgomp/task.c:1650
#6  0x2ac9925b058f in gomp_team_barrier_wait_end
at ../../../gcc-git/libgomp/config/linux/bar.c:116
#7  0x2ac9925aeffc in gomp_team_end
at ../../../gcc-git/libgomp/team.c:956
#8  0x401692 in ???
#9  0x4016cd in ???
#10  0x2ac992886d0c in ???
#11  0x401128 in ???
Segmentation fault

This appears to be due to the optional argument, helper_. If it is present in
the initial call, i.e.:
   call tasker_%compute(helper_)

then this runs without a segfault.

This happens with versions 12.0.0, 13.0.1, and the current HEAD of the GCC git
repo.

[Bug fortran/110547] New: Improper finalization calls with OpenMP tasks

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

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

Bug ID: 110547
   Summary: Improper finalization calls with OpenMP tasks
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

Here's an example code (highly simplified from the actual code I'm working
on) that causes seemingly wrong behavior resulting in calling a destructor when
it should not be called:

module taskerMod

   type :: tasker
  integer :: depth=-1
contains
  final ::taskerDestruct
  procedure :: compute => taskerCompute
   end type tasker

 contains

   subroutine taskerDestruct(self)
 !$ use :: OMP_Lib  
 implicit none
 type(tasker), intent(inout) :: self

 write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," :
",omp_get_thread_num()  
 return
   end subroutine taskerDestruct

   recursive subroutine taskerCompute(self)
 !$ use :: OMP_Lib  
 implicit none
 class(tasker), intent(inout) :: self

 !$omp atomic
 self%depth=self%depth+1
 write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() 
 if (self%depth < 3) then
!$omp task untied   
call self%compute()
!$omp end task  
 end if
 return
   end subroutine taskerCompute

 end module taskerMod

 program testTasks
   use :: taskerMod
   implicit none
   type(tasker) :: tasker_

   tasker_=tasker(0)
   !$omp parallel   
   !$omp single 
   !$omp taskgroup  
   !$omp task untied
   call tasker_%compute()
   !$omp end task   
   !$omp end taskgroup  
   !$omp end single 
   !$omp end parallel   
 end program testTasks

Compiling without OpenMP results in the expected behavior:
$ gfortran test.F90
$ ./a.out
 DESTRUCT FROM DEPTH   -1
 DEPTH1
 DEPTH2
 DEPTH3

There's a call to the finalizer for the tasker class (on assignment), and then
it simply reports the 3 levels of recursion that I've set it to go through.

But, if I compile with OpenMP and run just a single thread (the same problem
occurs with multiple threads also):
$ gfortran test.F90 -fopenmp
$ ./a.out
 DESTRUCT FROM DEPTH   -1
 DEPTH1
 DEPTH2
 DESTRUCT FROM DEPTH2
 DEPTH3
 DESTRUCT FROM DEPTH3

I now see calls to the finalizer from the 2nd and 3rd recursive calls to the
taskerCompute function. Since self is intent(inout) to this function I
wouldn't expect it to be finalized.

This happens with versions 12.0.0, 13.0.1, and the current HEAD of the GCC git
repo. But, ifort, does not produce the extra finalizer calls when used to
compile the above with OpenMP.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #34 from Sergei Trofimovich  ---
(In reply to rguent...@suse.de from comment #33)
> On Tue, 4 Jul 2023, slyfox at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
> > 
> > --- Comment #32 from Sergei Trofimovich  ---
> > (In reply to Richard Biener from comment #29)
> > > I can't reproduce the original failure on trunk or with GCC 13.1, but the
> > > testcase from comment#16 is now fixed.  I also cannot reproduce the 
> > > testcase
> > > from comment#21 before the fix.
> > > 
> > > Can people double-check this is now fixed, maybe also on the branch when 
> > > this
> > > fix is cherry-picked?
> > 
> > Test suite on llvm-16 still fails the same single 'LLVM ::
> > ExecutionEngine/JITLink/X86/MachO_weak_references.s' test for me. 
> > 
> > gcc was built from 2c12ccf800fc7890925402d30a02f0fa9e2627cc.
> 
> Can you try 819285ef10a87d663f8c181c06aa88d1d9f75aed - your small
> testcase looks OK now.

Ah, that commit fixes 'LLVM ::
ExecutionEngine/JITLink/X86/MachO_weak_references.s' and the rest of llvm-16
test suite for me. Thank you!

[Bug c++/107437] nested generic lambdas fail requiring unneded captures

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Jason Merrill  ---
Created attachment 55466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55466=edit
failed experiment

I wondered if keeping function-local typedefs would be a simple fix, but a
number of modules tests regress with this patch.  I guess that's because of
problems with entries in the specialization hash tables referring to
function-local typedefs that we can't then reconnect when loading the module. 
Really such entries (if we do add them) shouldn't persist after we're done
compiling the function.

[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> +   val = std::move(*__old_start);

If this is changed to just val = *__old_start then the error comes back.

110542.cc: In function 'int main()':
110542.cc:23:25: error: non-constant condition for static assertion
   23 |   static_assert(test1() == 1);
  | ^~~~
110542.cc:23:22:   in 'constexpr' expansion of 'test1()'
110542.cc:18:7:   in 'constexpr' expansion of 's.s_t::rz(2)'
110542.cc:11:49:   in 'constexpr' expansion of '(&
w)->std::vector::resize(n)'
/home/jwakely/gcc/14/include/c++/14.0.0/bits/stl_vector.h:1014:21:   in
'constexpr' expansion of
'((std::vector*)this)->std::vector::_M_default_append((__new_size -
((std::vector*)this)->std::vector::size()))'
110542.cc:23:25: error: use of allocated storage after deallocation in a
constant expression

[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector

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

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

--- Comment #3 from Jonathan Wakely  ---
The GCC error is fixed by this change:

--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -701,6 +701,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  pointer __old_start = this->_M_impl._M_start;
  pointer __old_finish = this->_M_impl._M_finish;

+ _Tp val;
+ if (__old_start != __old_finish)
+   val = std::move(*__old_start);
+
  const size_type __len =
_M_check_len(__n, "vector::_M_default_append");
  pointer __new_start(this->_M_allocate(__len));

Which makes no sense whatsoever, as it's just a redundant read from
*__old_start, which cannot change whether or not that pointer has already been
deallocated when read from again later!

So I think this part is a GCC bug.

[Bug tree-optimization/110546] New: Function clone not treated as valid allocator with -Wmismatched-dealloc

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

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

Bug ID: 110546
   Summary: Function clone not treated as valid allocator with
-Wmismatched-dealloc
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
Blocks: 99715
  Target Milestone: ---

If compiled with -Wall -Werror -O3, the code below produces the following
diagnostic:

t.c: In function ‘f’:
t.c:16:3: error: ‘dealloc’ called on pointer returned from a mismatched
allocation function [-Werror=mismatched-dealloc]
   16 |   dealloc (alloc (1));
  |   ^~~
t.c:16:3: note: returned from ‘alloc.constprop’
   16 |   dealloc (alloc (1));
  |   ^~~


I believe this happens because the compiler does not recognize that
alloc.constprop is a valid allocation function for alloc because its internal
name is distinct from the expected name dealloc.


extern void *alloc0 (int n);

void dealloc (void *);

void *__attribute__ ((noinline, malloc (dealloc, 1)))
alloc (int n)
{
  if (n <= 0)
__builtin_abort ();
  return alloc0 (n);
}

void
f (void)
{
  dealloc (alloc (1));
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99715
[Bug 99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings

[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector

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

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

--- Comment #2 from Jonathan Wakely  ---
I don't understand why GCC *doesn't* fail without the fix above, when that code
clearly gets used during constant evaluation and the runtime version of that
function *does* access objects outside their lifetime (the *__first = __tmp
expression shown in the Clang output).

And I don't understand why GCC *does* fail in __relocate_object, which looks
correct to me (and Clang happily compiles).

[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector

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

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

--- Comment #1 from Jonathan Wakely  ---
There seem to be two separate bugs here, which I don't understand.

The clang error is fixed by:

--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -661,6 +661,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
  if (__n > 0)
{
+#ifdef __cpp_lib_is_constant_evaluated
+ if (std::is_constant_evaluated())
+   return __uninitialized_default_n_1::
+__uninit_default_n(__first, __n);
+#endif
  typename iterator_traits<_ForwardIterator>::value_type* __val
= std::__addressof(*__first);
  std::_Construct(__val);

But this doesn't fix the error with GCC.

[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-07-04
 Status|UNCONFIRMED |NEW

[Bug gcov-profile/110545] New: gcda files not generated for some shared libs

[gejoed at rediffmail dot com via Gcc-bugs]

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

Bug ID: 110545
   Summary: gcda files not generated for some shared libs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gejoed at rediffmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I work on a code where shared libs (xxxlib.so) are being used.
During the build --coverage is used (for compiling, linking and for shared
libs) and the .gcno files are generated correctly for the source files
(involved with the shared libs). 
For one particular module, I could find out that gcda files are not getting
generated on the device. As the binary is loaded on the test device, the gcda
files are generated  using __gcov_dump() call and I could see gcda files being
generated for many files. The __gcov_dump() is invoked through a command on the
device and it completes as usual without any error message.
I did a strings check for the libraries of the particular module of interest
(say A123) and the gcda file paths were embedded in them. I saw that the
hardwired path contained relative paths in between like
/topdir/nextdir/A123/subcomp1/src/../../build/subcomp1/src/filename.gcda

I did make sure that the paths for the component gcda files are made on the
device  like both these dir paths (as ../.. was used in the path) :
  /topdir/nextdir/A123/subcomp1/src/ 
  /topdir/nextdir/A123/build/subcomp1/src/
These files get used during the loading of the image and also during the usage
of some show commands on the test device which was done prior to gcov_dump
execution.The directories have the write permission.

However, I could see gcda files getting generated for source files linked with
some other shared libraries( say /topdir/anotherdir/B123/subcomp1/obj-files/ ).


Sorry that I'm not able to give more info on the original files due to the
company policy. Let me know if I need to check anything further for this
specific module or in the execution place/device OR if anything is not clear
with my description here.

[Bug tree-optimization/110544] New: [14 regression] gcc.dg/vect/pr71264.c ICEs after r14-2150

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

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

Bug ID: 110544
   Summary: [14 regression] gcc.dg/vect/pr71264.c ICEs after
r14-2150
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:fe48f2651334bc4d96b6df6b2bb6b29fcb732a83, r14-2150-gfe48f2651334bc

make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr71264.c"
FAIL: gcc.dg/vect/pr71264.c (internal compiler error: tree check: expected none
of vector_type, have vector_type in type_has_mode_precision_p, at tree.h:6644)
FAIL: gcc.dg/vect/pr71264.c (test for excess errors)
FAIL: gcc.dg/vect/pr71264.c scan-tree-dump vect "vectorized 1 loops in
function"
FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-objects (internal compiler error:
tree check: expected none of vector_type, have vector_type in
type_has_mode_precision_p, at tree.h:6644)
FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/pr71264.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorized 1 loops in function"
# of unexpected failures6


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.dg/vect/pr71264.c
-fdiagnostics-plain-output -flto -ffat-lto-objects -maltivec -mpower9-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -S -o pr71264.s
during GIMPLE pass: vect
dump file: pr71264.c.173t.vect
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr71264.c: In function
'test':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr71264.c:7:6: internal
compiler error: tree check: expected none of vector_type, have vector_type in
type_has_mode_precision_p, at tree.h:6644
0x1027a693 tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
/home/seurer/gcc/git/gcc-test/gcc/tree.cc:8936
0x11c9dd33 tree_not_check(tree_node const*, char const*, int, char const*,
tree_code)
/home/seurer/gcc/git/gcc-test/gcc/tree.h:3837
0x11c9dd33 type_has_mode_precision_p(tree_node const*)
/home/seurer/gcc/git/gcc-test/gcc/tree.h:6644
0x11c9dd33 vectorizable_operation
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:6488
0x11cb56c3 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:11906
0x1105df73 vect_analyze_loop_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:2086
0x1105fabf vect_analyze_loop_2
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:2869
0x1106181b vect_analyze_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3303
0x1106212f vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3457
0x110b8837 try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1064
0x110b8837 try_vectorize_loop
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1180
0x110b8dc3 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1296


commit fe48f2651334bc4d96b6df6b2bb6b29fcb732a83 (HEAD)
Author: Richard Biener 
Date:   Fri Jun 9 09:31:14 2023 +0200

Prevent TYPE_PRECISION on VECTOR_TYPEs

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #33 from rguenther at suse dot de  ---
On Tue, 4 Jul 2023, slyfox at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
> 
> --- Comment #32 from Sergei Trofimovich  ---
> (In reply to Richard Biener from comment #29)
> > I can't reproduce the original failure on trunk or with GCC 13.1, but the
> > testcase from comment#16 is now fixed.  I also cannot reproduce the testcase
> > from comment#21 before the fix.
> > 
> > Can people double-check this is now fixed, maybe also on the branch when 
> > this
> > fix is cherry-picked?
> 
> Test suite on llvm-16 still fails the same single 'LLVM ::
> ExecutionEngine/JITLink/X86/MachO_weak_references.s' test for me. 
> 
> gcc was built from 2c12ccf800fc7890925402d30a02f0fa9e2627cc.

Can you try 819285ef10a87d663f8c181c06aa88d1d9f75aed - your small
testcase looks OK now.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #32 from Sergei Trofimovich  ---
(In reply to Richard Biener from comment #29)
> I can't reproduce the original failure on trunk or with GCC 13.1, but the
> testcase from comment#16 is now fixed.  I also cannot reproduce the testcase
> from comment#21 before the fix.
> 
> Can people double-check this is now fixed, maybe also on the branch when this
> fix is cherry-picked?

Test suite on llvm-16 still fails the same single 'LLVM ::
ExecutionEngine/JITLink/X86/MachO_weak_references.s' test for me. 

gcc was built from 2c12ccf800fc7890925402d30a02f0fa9e2627cc.

The following test still fails for me:

$ cat bug.c
static unsigned a[4] = {1,1,1,1};

__attribute__((noipa))
static void bug(unsigned * p, unsigned *t, int n) {
 unsigned LookupFlags;

for(int i = 0; i < n; i++) {
  unsigned v = t[i];
  if  (v == 0) LookupFlags = 0;
  else if (v == 1) LookupFlags = 1;
  *p = LookupFlags;
}
}

int main() {
unsigned r = 42;
bug(, a, 4);
if (r != 1) __builtin_abort();
return 0;
}

$ gcc bug.c -o bug -O1 -Wall && ./bug
bug.c: In function 'bug':
bug.c:10:15: warning: 'LookupFlags' may be used uninitialized
[-Wmaybe-uninitialized]
   10 |   else if (v == 1) LookupFlags = 1;
  |   ^
bug.c:5:15: note: 'LookupFlags' was declared here
5 |  unsigned LookupFlags;
  |   ^~~
Aborted (core dumped)

bug.c.255t.optimized still turns stores into '|=' against uninit value:


__attribute__((noipa, noinline, noclone, no_icf))
void bug (unsigned int * p, unsigned int * t, int n)
{
  unsigned long ivtmp.8;
  unsigned int v;
  unsigned int LookupFlags;
  _Bool _16;
  unsigned int _17;
  unsigned int _18;
  void * _19;
  unsigned long _20;
  unsigned long _26;
  unsigned long _28;

   [local count: 118111600]:
  if (n_10(D) > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119324]:
  ivtmp.8_21 = (unsigned long) t_11(D);
  _20 = (unsigned long) n_10(D);
  _26 = _20 * 4;
  _28 = ivtmp.8_21 + _26;

   [local count: 955630225]:
  # LookupFlags_22 = PHI 
  # ivtmp.8_6 = PHI 
  _19 = (void *) ivtmp.8_6;
  v_12 = MEM[(unsigned int *)_19];
  if (v_12 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  _16 = v_12 == 1;
  _17 = (unsigned int) _16;
  _18 = _17 | LookupFlags_22;

   [local count: 955630225]:
  # LookupFlags_4 = PHI 
  *p_13(D) = LookupFlags_4;
  ivtmp.8_5 = ivtmp.8_6 + 4;
  if (ivtmp.8_5 != _28)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  return;

}

[Bug c++/92562] Allow [[maybe_unused]] in class member declaration

[marc.mutz at hotmail dot com via Gcc-bugs]

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

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at hotmail dot com

--- Comment #2 from Marc Mutz  ---
Isn't this fixed meanwhile? I don't remember seeing this on GCC 11.

[Bug analyzer/110543] New: RFE: Add optional trim of the analyzer diagnostics through system headers.

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

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

Bug ID: 110543
   Summary: RFE: Add optional trim of the analyzer diagnostics
through system headers.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: vultkayn at gcc dot gnu.org
  Target Milestone: ---

See https://godbolt.org/z/sb9dM9Gqa for a reproducer on trunk.

Given an issue on std::shared_ptr<>, the analyzer emits a path that I'd like to
optionally shorten, by trimming it.
Looking at the reproducer, I believe it would be desirable the analyzer emits
similar diagnostics for smart pointers as it is for raw pointers, i.e. the
diagnostic should not dive into the standard library, but rather stop at the
faulting frame.

Thus behaves as follow, _by default_:

: In function 'int main()':
:5:8: warning: dereference of NULL 'a' [CWE-476]
[-Wanalyzer-null-dereference]
5 |   a->x = 4; /* Diagnostic would path should stop here rather than going
to shared_ptr_base.h */
  |   ~^~~
  'int main()': events 1-2
|
|4 |   std::shared_ptr a;
|  |  ^
|  |  |
|  |  (1) 'a' is NULL
|5 |   a->x = 4; /* Diagnostic path should stop here rather than going
to shared_ptr_base.h */
|  |   
|  ||
|  |(2) dereference of NULL 'a'
| 

A flag akin to -fanalyzer-trim-diagnostic-path=|std would then be
introduced to do so, with a default value of std.
Such option would be useful for future support of C++, but could be extended to
any "system header", thus also be used in C.


A slight variation would be to trim all but the last exceeding event, so that
the user would still get feedback on template deducted types.

What do you think ?

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
I have tried to start a git bisect and the current range is 
g:f3d87219dd502d5c .. g:9757e4440bd8755d.

This is 15 commits.

[Bug libstdc++/110542] New: use of allocated storage after deallocation in a constant expression: std::array of std::vector

[hal.finkel.oss at gmail dot com via Gcc-bugs]

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

Bug ID: 110542
   Summary: use of allocated storage after deallocation in a
constant expression: std::array of std::vector
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hal.finkel.oss at gmail dot com
  Target Milestone: ---

For this test case:

```
#include 
#include 

struct s_t {
  std::vector, 1>> v;

  constexpr void rz(std::size_t n) {
v.resize(n);
for (auto  : v) for (auto  : x) w.resize(n);
  }
};

constexpr std::size_t test1() {
  s_t s;
  s.rz(1);
  s.rz(2);
  return 1;
}

int main() {
  static_assert(test1() == 1);
}
```

g++ -std=c++20 13.1.0 (and GCC trunk as of today on https://gcc.godbolt.org/):
ERROR:

```
tc1.cpp: In function ‘int main()’:
tc1.cpp:21:25: error: non-constant condition for static assertion
   21 |   static_assert(test1() == 1);
  | ^~~~
tc1.cpp:21:22:   in ‘constexpr’ expansion of ‘test1()’
tc1.cpp:16:7:   in ‘constexpr’ expansion of ‘s.s_t::rz(2)’
tc1.cpp:9:49:   in ‘constexpr’ expansion of ‘(&
w)->std::vector::resize(n)’
/gcc-13.1.0/include/c++/13/bits/stl_vector.h:1011:21:   in ‘constexpr’
expansion of
‘((std::vector*)this)->std::vector::_M_default_append((__new_size -
((std::vector*)this)->std::vector::size()))’
/gcc-13.1.0/include/c++/13/bits/vector.tcc:676:16:   in ‘constexpr’ expansion
of ‘std::vector::_S_relocate(__old_start, __old_finish, __new_start, (*
&((std::vector*)this)->std::vector::.std::_Vector_base >::_M_get_Tp_allocator()))’
/gcc-13.1.0/include/c++/13/bits/stl_vector.h:504:26:   in ‘constexpr’ expansion
of ‘std::__relocate_a >(__first, __last, __result,
(* & __alloc))’
/gcc-13.1.0/include/c++/13/bits/stl_uninitialized.h:1142:33:   in ‘constexpr’
expansion of ‘std::__relocate_a_1(std::__niter_base(__first),
std::__niter_base(__last), std::__niter_base(__result), (* &
__alloc))’
/gcc-13.1.0/include/c++/13/bits/stl_uninitialized.h:1122:35:   in ‘constexpr’
expansion of ‘std::__relocate_a_1, allocator >(__first, __last, __out, (* & __alloc))’
/gcc-13.1.0/include/c++/13/bits/stl_uninitialized.h:1100:26:   in ‘constexpr’
expansion of ‘std::__relocate_object_a
>(std::__addressof((* & __cur.__gnu_cxx::__normal_iterator::operator*())), std::__addressof((* __first)), (* & __alloc))’
/gcc-13.1.0/include/c++/13/bits/stl_uninitialized.h:1072:26:   in ‘constexpr’
expansion of ‘std::allocator_traits >::construct((* & __alloc), __dest, (* & std::move((*(int*)__orig’
/gcc-13.1.0/include/c++/13/bits/alloc_traits.h:539:21:   in ‘constexpr’
expansion of ‘std::construct_at(__p, (* & std::forward((* &
__args#0’
tc1.cpp:21:25: error: use of allocated storage after deallocation in a constant
expression
In file included from /gcc-13.1.0/include/c++/13/vector:63,
 from tc1.cpp:1:
/gcc-13.1.0/include/c++/13/bits/allocator.h:195:52: note: allocated here
  195 | return static_cast<_Tp*>(::operator new(__n));
  |  ~~^

```

clang -std=c++20 15, (and 16 and trunk as of today on https://gcc.godbolt.org/,
noting that these appear to use headers from libstdc++ gcc-12.2.0; below is
from clang 15 using GCC 13.1.0 headers): ERROR:

```
tc1.cpp:21:17: error: static assertion expression is not an integral constant
expression
  static_assert(test1() == 1);
^~~~
/gcc-13.1.0/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_algobase.h:931:11:
note: assignment to object outside its lifetime is not allowed in a constant
expression
*__first = __tmp;
 ^
/gcc-13.1.0/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_algobase.h:977:7:
note: in call to '__fill_a1(&{*new int[2]#4}[1], &{*new int[2]#4}[2], {*new
int[2]#4}[0])'
{ std::__fill_a1(__first, __last, __value); }
  ^
/gcc-13.1.0/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_algobase.h:1128:7:
note: in call to '__fill_a(&{*new int[2]#4}[1], &{*new int[2]#4}[2], {*new
int[2]#4}[0])'
  std::__fill_a(__first, __first + __n, __value);
  ^
/gcc-13.1.0/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_algobase.h:1157:14:
note: in call to '__fill_n_a(&{*new int[2]#4}[1], 1, {*new int[2]#4}[0],
)'
  return std::__fill_n_a(__first, std::__size_to_integer(__n), __value,
 ^
/gcc-13.1.0/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_uninitialized.h:668:18:
note: in call to 'fill_n(&{*new int[2]#4}[1], 1, {*new int[2]#4}[0])'
  __first = std::fill_n(__first, __n - 1, *__val);
^
/gcc-13.1.0/lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_uninitialized.h:704:14:
note: in call to '__uninit_default_n(&{*new int[2]#4}[1], 2)'
  

[Bug c/110491] Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/110491] Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

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

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

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

https://gcc.gnu.org/g:819285ef10a87d663f8c181c06aa88d1d9f75aed

commit r14-2296-g819285ef10a87d663f8c181c06aa88d1d9f75aed
Author: Richard Biener 
Date:   Tue Jul 4 12:52:27 2023 +0200

tree-optimization/110491 - PHI-OPT and undefs

The following makes sure to not make conditional undefs in PHI arguments
unconditional by folding cond ? arg1 : arg2.

PR tree-optimization/110491
* tree-ssa-phiopt.cc (match_simplify_replacement): Check
whether the PHI args are possibly undefined before folding
the COND_EXPR.

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

[Bug tree-optimization/110541] New: Invalid VEC_PERM_EXPR mask element size

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

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

Bug ID: 110541
   Summary: Invalid VEC_PERM_EXPR mask element size
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

tree.def says:
  The number of MASK elements must be the same with the
  number of elements in V0 and V1.  The size of the inner type
  of the MASK and of the V0 and V1 must be the same.

But tree-vectorizer creates permutations where the MASK element size is
different than for V0 and V1, such as

   vector(8) unsigned short _79;
   ...
  _79 = VEC_PERM_EXPR <_78, { 0, 0, 0, 0, 0, 0, 0, 0 }, { 4, 5, 6, 7, 8, 9, 10,
11 }>;

where the MASK elements are of a 64-bit type.

This can be seen when compiling the following function (from
gcc.c-torture/compile/2717-1.c) as "gcc -S -O3" for x86_64:

short
inner_product (short *a, short *b)
{
  int i;
  short sum = 0;

  for (i = 9; i >= 0; i--)
sum += (*a++) * (*b++);

  return sum;
}

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
The only C++ related commit in that range is:

commit db38b285ba61c5b888adc0d117177bfd774c1153
Author: Patrick Palka 
Date:   Fri Jun 30 15:05:22 2023 -0400

c++: fix up caching of level lowered ttps

[Bug c/110491] Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|RESOLVED|ASSIGNED
 Resolution|DUPLICATE   |---
   Last reconfirmed||2023-07-04

--- Comment #2 from Richard Biener  ---
So the issue here is phiopt4 doing

[local count: 1073741824]:
-  if (c_lsm_flag.14_16 != 0)
-goto ; [66.67%]
-  else
-goto ; [33.33%]
-
-   [local count: 357913944]:
-
-   [local count: 1073741824]:
+  _26 = ~c_lsm_flag.14_16;
+  _14 = (int) _26;
   # RANGE [irange] int [0, 1] NONZERO 0x1
-  # prephitmp_27 = PHI <1(7), c_lsm.13_3(6)>
-  c = prephitmp_27;
+  _4 = c_lsm.13_3 | _14;
+  c = _4;
   return;

via

phiopt match-simplify trying:
   c_lsm_flag.14_16 != 0 ? c_lsm.13_3 : 1
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:1948, gimple-match-7.cc:20
Matching expression match.pd:2480, gimple-match-4.cc:35
Matching expression match.pd:2483, gimple-match-3.cc:66
Matching expression match.pd:2490, gimple-match-2.cc:58
Applying pattern match.pd:6459, gimple-match-10.cc:12767
Applying pattern match.pd:1378, gimple-match-5.cc:7352
Applying pattern match.pd:1886, gimple-match-1.cc:1232
Applying pattern match.pd:4748, gimple-match-4.cc:15651
Folded into the sequence:
_13 = (int) c_lsm_flag.14_16;
_26 = ~c_lsm_flag.14_16;
_14 = (int) _26;
_4 = c_lsm.13_3 | _14;
Removing basic block 7

but

   [local count: 9761289309]:
  # RANGE [irange] int [0, 1] NONZERO 0x1
  # c_lsm.13_3 = PHI <_17(D)(2), _11(5)>

so we have an uninitialized use here.  The following fixes this.

diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index 31a7c39e405..467c9fd108a 100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -785,6 +785,13 @@ match_simplify_replacement (basic_block cond_bb,
basic_block middle_bb,
   arg_false = arg0;
 }

+  /* Do not make conditional undefs unconditional.  */
+  if ((TREE_CODE (arg_true) == SSA_NAME
+   && ssa_name_maybe_undef_p (arg_true))
+  || (TREE_CODE (arg_false) == SSA_NAME
+ && ssa_name_maybe_undef_p (arg_false)))
+return false;
+
   tree type = TREE_TYPE (gimple_phi_result (phi));
   result = gimple_simplify_phiopt (early_p, type, stmt,
   arg_true, arg_false,

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
The compiler seems to break as follows:

/home/dcb38/gcc/results.20230701/bin/gcc
/home/dcb38/gcc/results.20230703.asan.ubsan/bin/gcc
/home/dcb38/rpmbuild/BUILD/dlib-65bce59a1512cf222dec01d3e0f29b612dd181f5/dlib/../dlib/dnn/core.h:799:22:
internal compiler error: in redeclare_class_template, at cp/pt.cc:6391

$ /home/dcb38/gcc/results.20230701/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.0 20230630 (experimental) (c3c0ba5436170e01) 
$ /home/dcb38/gcc/results.20230703.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.0 20230703 (experimental) (9a856f67ee2f13ea) 

$ git log c3c0ba5436170e01..9a856f67ee2f13ea | grep -c "^commit"
45
$

[Bug c/110376] Wrong code at -O1 on x86_64-linux-gnu

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

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

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

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

commit r14-2291-gd4800a23d8d14213f9e461cd47e97a5c7271b1a9
Author: Richard Biener 
Date:   Tue Jul 4 12:27:56 2023 +0200

tree-optimization/110376 - testcase for fixed bug

This is a new testcase for the fixed bug.

PR tree-optimization/110376
* gcc.dg/torture/pr110376.c: New testcase.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #31 from Richard Biener  ---
(In reply to Zhendong Su from comment #30)
> (In reply to Richard Biener from comment #29)
> > I can't reproduce the original failure on trunk or with GCC 13.1, but the
> > testcase from comment#16 is now fixed.  I also cannot reproduce the testcase
> > from comment#21 before the fix.
> > 
> > Can people double-check this is now fixed, maybe also on the branch when 
> > this
> > fix is cherry-picked?
> > 
> > Thanks.
> 
> I can still reproduce the test from comment#21 as well as PR 110491 and PR
> 110509.

PR110491 still reproduces after my fix (and PHI-OPT fixed the same way).
The two other non-deterministic ones don't reproduce before/after
(or I misunderstand how they work).

> PR 110376 doesn't reproduce for me anymore.

I'm going to add this as testcase.

So I think there's more analysis necessary and I didn't fix the underlying
issues in the other PRs.

[Bug c++/110523] [14 Regression] ICE in redeclare_class_template, at cp/pt.cc:6391 on json-3.11.2

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
I see something similar when building dlib:

/home/dcb38/rpmbuild/BUILD/dlib-65bce59a1512cf222dec01d3e0f29b612dd181f5/dlib/../dlib/dnn/core.h:799:22:
internal compiler error: in redeclare_class_template, at cp/pt.cc:6391

[Bug target/104914] [MIPS] wrong comparison with scrabbled int value

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

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

--- Comment #5 from YunQiang Su  ---
Another possible fix is to emit a SLL for extendsidi2, but
I am worrying about it may break something else.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #30 from Zhendong Su  ---
(In reply to Richard Biener from comment #29)
> I can't reproduce the original failure on trunk or with GCC 13.1, but the
> testcase from comment#16 is now fixed.  I also cannot reproduce the testcase
> from comment#21 before the fix.
> 
> Can people double-check this is now fixed, maybe also on the branch when this
> fix is cherry-picked?
> 
> Thanks.

I can still reproduce the test from comment#21 as well as PR 110491 and PR
110509.

PR 110376 doesn't reproduce for me anymore.

[Bug tree-optimization/110540] New: [14 Regression] Dead Code Elimination Regression since r14-1163-gd8b058d3ca4

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

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

Bug ID: 110540
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-1163-gd8b058d3ca4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/WP14EKx7M

Given the following code:

void foo(void);
static int a = 1;
static int *d = 
static int **f = 
static int ***g = 
static char(h)(char b, char c) { return b - c; }
static char(i)(int e) {
if (!(((e) >= 1) && ((e) <= 254))) {
__builtin_unreachable();
}
return 0;
}
int main() {
char j = 0;
for (; j != -9; j = h(j, 9)) {
i(1);
*d = a ^ 255;
if (i(a) >= **f) **f = 0;
}
if (**g)
;
else
foo();
;
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
movla(%rip), %eax
movqf(%rip), %rdx
movqd(%rip), %rcx
xorb$-1, %al
movl%eax, (%rcx)
movq(%rdx), %rax
movl(%rax), %ecx
testl   %ecx, %ecx
jle .L8
.L4:
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L8:
cmpq$0, (%rdx)
movl$0, (%rax)
jne .L4
pushq   %rax
callfoo
xorl%eax, %eax
popq%rdx
ret

gcc-13.1.0 -O2 eliminates the call to foo:

main:
movla(%rip), %eax
movqd(%rip), %rdx
xorb$-1, %al
movl%eax, (%rdx)
movqf(%rip), %rax
movq(%rax), %rax
movl(%rax), %ecx
testl   %ecx, %ecx
jg  .L2
xorl%edx, %edx
movl%edx, (%rax)
.L2:
xorl%eax, %eax
ret

Bisects to r14-1163-gd8b058d3ca4

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

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

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

--- Comment #11 from Kewen Lin  ---
(In reply to Hao Liu from comment #10)
> > foo is just an example for not getting inlined, the point here is extra 
> > cost paid.
> 
> My point is that the case is different from the original case in
> tree-vect-loop.cc.  For example, change the case as following:
> 
> __attribute__((noipa)) int foo(int *a) { *a == 1 ? return 1 : return 0;}
> 
> That's similar to the original problem (the value of "a" is undefiend).
> 
> I don't mean that "a" must be initialized in test().  We can also initalize
> "a" in foo, but should not use "a" before initialization. E.g.
> 
> __attribute__((noipa)) int foo(int *a) { 
>   *a == 1;
>   ...
>   if (*a)
> }
> 
> The above case has no problem.

Yeah, I got your point here, but my case above is mainly to show that we need
to pay a bit more cost to initialize variable (there foo is just a random one
which isn't inlined). Anyway, thanks for further clarifying.

[Bug tree-optimization/110539] New: [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407

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

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

Bug ID: 110539
   Summary: [14 Regression] Dead Code Elimination Regression at
since r14-338-g1dd154f6407
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/h9vrrj5je

Given the following code:

void foo(void);
static int a, c = 1;
static short b;
static int *d = , *e = 
static int **f = 
void __assert_fail() __attribute__((__noreturn__));
static void g(short h) {
if (*d)
;
else {
if (e) __assert_fail();
if (a) {
__builtin_unreachable();
} else
__assert_fail();
}
if 0, 0) || h) == h) + b) *f = 0;
}
int main() {
int i = 0 != 10 & a;
g(i);
*e = 9;
e = 0;
if (d == 0)
;
else
foo();
;
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
subq$8, %rsp
movqd(%rip), %rax
movqe(%rip), %rdx
movl(%rax), %edi
testl   %edi, %edi
jne .L2
xorl%eax, %eax
call__assert_fail
.L2:
xorl%ecx, %ecx
xorl%esi, %esi
movq%rcx, d(%rip)
cmpq$0, d(%rip)
movl$9, (%rdx)
movq%rsi, e(%rip)
je  .L3
callfoo
.L3:
xorl%eax, %eax
popq%rdx
ret

gcc-13.1.0 -O2 eliminates the call to foo:

main:
movqd(%rip), %rax
movqe(%rip), %rdx
movl(%rax), %esi
testl   %esi, %esi
jne .L2
pushq   %rcx
xorl%eax, %eax
call__assert_fail
.L2:
xorl%eax, %eax
movq%rax, d(%rip)
xorl%eax, %eax
movl$9, (%rdx)
xorl%edx, %edx
movq%rdx, e(%rip)
ret

Bisects to r14-338-g1dd154f6407

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #10 from Hao Liu  ---
> foo is just an example for not getting inlined, the point here is extra cost 
> paid.

My point is that the case is different from the original case in
tree-vect-loop.cc.  For example, change the case as following:

__attribute__((noipa)) int foo(int *a) { *a == 1 ? return 1 : return 0;}

That's similar to the original problem (the value of "a" is undefiend).

I don't mean that "a" must be initialized in test().  We can also initalize "a"
in foo, but should not use "a" before initialization. E.g.

__attribute__((noipa)) int foo(int *a) { 
  *a == 1;
  ...
  if (*a)
}

The above case has no problem.

[Bug tree-optimization/110538] New: [14 Regression] Dead Code Elimination Regression since r14-368-ge1366a7e4ce

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

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

Bug ID: 110538
   Summary: [14 Regression] Dead Code Elimination Regression since
 r14-368-ge1366a7e4ce
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/53Ys78do1

Given the following code:

void foo(void);
static int b, d, f;
static int *c, *e = 
static unsigned g;
void a();
int main() {
g = -19;
for (; g; ++g) {
int h = g;
int *i = 
int **j = 
if (d) {
int **k = 
j = 
*k = 
} else
*e = 0;
if (!(((h) >= -19) && ((h) <= -1))) {
__builtin_unreachable();
}
if (i)
;
else
a();
if (j ==  || j == )
;
else
foo();
;
}
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
subq$24, %rsp
movl$-19, g(%rip)
.p2align 4,,10
.p2align 3
.L4:
movld(%rip), %edx
movl$c, %eax
testl   %edx, %edx
jne .L2
leaq8(%rsp), %rax
.L2:
cmpq$c, %rax
je  .L5
leaq8(%rsp), %rdx
cmpq%rdx, %rax
je  .L5
callfoo
.L5:
addl$1, g(%rip)
jne .L4
xorl%eax, %eax
addq$24, %rsp
ret

gcc-13.1.0 -O2 eliminates the call to foo:

main:
movl$-19, g(%rip)
.p2align 4,,10
.p2align 3
.L2:
movlg(%rip), %eax
addl$1, %eax
movl%eax, g(%rip)
jne .L2
ret

Bisects to r14-368-ge1366a7e4ce

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Hao Liu :

https://gcc.gnu.org/g:2c12ccf800fc7890925402d30a02f0fa9e2627cc

commit r14-2290-g2c12ccf800fc7890925402d30a02f0fa9e2627cc
Author: Hao Liu 
Date:   Tue Jul 4 17:17:50 2023 +0800

PR tree-optimization/110531 - Vect: avoid using uninitialized variable

slp_done_for_suggested_uf is used directly in vect_analyze_loop_2
without initialization, which is undefined behavior.  Initialize it to
false
according to the discussion.

gcc/ChangeLog:
PR tree-optimization/110531
* tree-vect-loop.cc (vect_analyze_loop_1): initialize
slp_done_for_suggested_uf to false.

[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.2|14.0

[Bug tree-optimization/97108] [10/11/12/13/14 Regression] -Wmaybe-uninitialized false positive

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

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

Bug 101912 Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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

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

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

Bug 101912 Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||13.1.0
  Known to work|13.0|14.0

--- Comment #15 from Richard Biener  ---
r14-2289-gb083203f053f16 removed the XFAIL again.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #29 from Richard Biener  ---
I can't reproduce the original failure on trunk or with GCC 13.1, but the
testcase from comment#16 is now fixed.  I also cannot reproduce the testcase
from comment#21 before the fix.

Can people double-check this is now fixed, maybe also on the branch when this
fix is cherry-picked?

Thanks.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

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

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

commit r14-2289-gb083203f053f1666e9cc1ded2abdf4e1688d1ec0
Author: Richard Biener 
Date:   Tue Jul 4 10:29:26 2023 +0200

tree-optimization/110228 - avoid undefs in ifcombine more thoroughly

The following replaces the simplistic gimple_uses_undefined_value_p
with the conservative mark_ssa_maybe_undefs approach as already
used by LIM and IVOPTs.  This is to avoid exposing an unconditional
uninitialized read on a path from entry by if-combine.

PR tree-optimization/110228
* tree-ssa-ifcombine.cc (pass_tree_ifcombine::execute):
Mark SSA may-undefs.
(bb_no_side_effects_p): Check stmt uses for undefs.

* gcc.dg/torture/pr110228.c: New testcase.
* gcc.dg/uninit-pr101912.c: Un-XFAIL.

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

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

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

--- Comment #8 from Kewen Lin  ---
(In reply to Hao Liu from comment #7)
> > int foo() {
> >   bool a = true;
> >   bool b;
> >   if (a || b)
> > return 1;
> >   b = true;
> >   return 0;
> > }
> > 
> > still has the warning, it looks something can be improved (guess we prefer 
> > not to emit warning).
> 
> Your case is wrong, you should initialize "b" and there will be no warning.
> 

I don't follow why it is wrong, doesn't short-circuiting make b uninitialized
trivial?

> 
> > __attribute__((noipa)) int foo(int *a) { *a = 1; return 1;}
> > 
> > int test(){
> > #ifdef AINIT
> >   int a = 0;
> > #else
> >   int a;
> > #endif
> >   int b = foo();
> >   return b;
> > }
> 
> This case doesn't have problem. If "foo" uses "a" directly, the result is
> undefined behavior, which causes both correctness and performance issues.

foo is just an example for not getting inlined, the point here is extra cost
paid.

[Bug target/104914] [MIPS] wrong comparison with scrabbled int value

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
I had remembered fixing a similar issue before. I will look at this later
today. And yes ins should have been used instead of dins.

[Bug tree-optimization/110436] [14 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed (though the problem looks latent to me).

[Bug target/110533] [x86-64] naked with -O0 and register-passed struct/int128 clobbers parameters/callee-saved regs

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #1)
> >clobbering other parameters and callee-saved registers.
> 
> 
> (insn 2 8 3 2 (set (reg:DI 84)
> (reg:DI 5 di [ aD.2522 ])) "/app/example.cpp":3:25 -1
>  (nil))
> (insn 3 2 4 2 (set (reg:DI 85)
> (reg:DI 4 si [ aD.2522+8 ])) "/app/example.cpp":3:25 -1
>  (nil))
> (insn 4 3 5 2 (set (reg:TI 83)
> (subreg:TI (reg:DI 84) 0)) "/app/example.cpp":3:25 -1
>  (nil))
> (insn 5 4 6 2 (set (subreg:DI (reg:TI 83) 8)
> (reg:DI 85)) "/app/example.cpp":3:25 -1
>  (nil))
> (insn 6 5 7 2 (set (reg/v:TI 82 [ aD.2522 ])
> (reg:TI 83)) "/app/example.cpp":3:25 -1
>  (nil))

This is emitted by middle-end to reconstruct a function argument in cases when
argument is passed via multiple registers. Function argument is specified by
the same hook that is used for the caller and the callee, so it is not possible
to simple disable it for naked functions.

When -O2 is used, optimizers figure out that the reconstructed value is unused
and remove the whole reconstruction sequence. This is unfortunately not the
case with -O0.

So, middle-end should provide some sort of mechanism to suppress the generation
of reconstruction sequence. The above sequence is emitted in
function.cc/assign_parm_remove_parallels, but similar functionality can
probably be found elsewhere in the function handling code.

Or only pass simple arguments to naked function. Naked functions are
specialist's tool, not intended for "general public".

[Bug tree-optimization/110436] [14 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

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

https://gcc.gnu.org/g:729aa4fa48d627c4344764676edad3b65d40a003

commit r14-2288-g729aa4fa48d627c4344764676edad3b65d40a003
Author: Richard Biener 
Date:   Tue Jul 4 09:51:05 2023 +0200

tree-optimization/110436 - bogus live/relevant for unused pattern

When we compute liveness and relevantness we have to make sure to
handle live but not relevant stmts in a way we can later vectorize
them.  When the stmt uses only operands that do not need vectorization
we can just leave such stmts in place - but not in the case they
are recognized as patterns.  Since we don't have a way to cancel
pattern recognition we have to force mark such stmts as relevant.

PR tree-optimization/110436
* tree-vect-stmts.cc (vect_mark_relevant): Expand dumping,
force live but not relevant pattern stmts relevant.

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

[Bug target/104914] [MIPS] wrong comparison with scrabbled int value

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

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

--- Comment #3 from YunQiang Su  ---
Ohhh, I think that the real problem is that:

why DINS is used instead of INS when work with an INT?

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #7 from Hao Liu  ---
> int foo() {
>   bool a = true;
>   bool b;
>   if (a || b)
> return 1;
>   b = true;
>   return 0;
> }
> 
> still has the warning, it looks something can be improved (guess we prefer 
> not to emit warning).

Your case is wrong, you should initialize "b" and there will be no warning.


> __attribute__((noipa)) int foo(int *a) { *a = 1; return 1;}
> 
> int test(){
> #ifdef AINIT
>   int a = 0;
> #else
>   int a;
> #endif
>   int b = foo();
>   return b;
> }

This case doesn't have problem. If "foo" uses "a" directly, the result is
undefined behavior, which causes both correctness and performance issues.

[Bug tree-optimization/107004] [12 Regression] GCC12 warning in OOB access: array subscript is partly outside array bounds

[sbouchex at infovista dot com via Gcc-bugs]

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

--- Comment #7 from sbouchex  ---
(In reply to sbouchex from comment #6)
> The same testcase is failing on :
> 
> [...]
> g++ --version
> g++ (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)
> [...]
> 
> [...]
> [root@dev-sbo-eva-ol8 CorrCommon]# g++ -std=c++20 -Wall -Wextra -Werror
> -pedantic -Warray-bounds -O3 -o /tmp/toto /tmp/toto.cpp
> In file included from /usr/include/c++/13/bits/stl_iterator.h:85,
>  from /usr/include/c++/13/bits/stl_algobase.h:67,
>  from /usr/include/c++/13/vector:62,
>  from /tmp/toto.cpp:1:
> In function 'constexpr void std::_Construct(_Tp*, _Args&& ...) [with _Tp =
> int*; _Args = {}]',
> inlined from 'static constexpr _ForwardIterator
> std::__uninitialized_default_n_1::__uninit_default_n(_ForwardIterator,
> _Size) [with _ForwardIterator = int**; _Size = long unsigned int]' at
> /usr/include/c++/13/bits/stl_uninitialized.h:666:23,
> inlined from 'static constexpr _ForwardIterator
> std::__uninitialized_default_n_1::__uninit_default_n(_ForwardIterator,
> _Size) [with _ForwardIterator = int**; _Size = long unsigned int]' at
> /usr/include/c++/13/bits/stl_uninitialized.h:660:9,
> inlined from 'constexpr _ForwardIterator
> std::__uninitialized_default_n(_ForwardIterator, _Size) [with
> _ForwardIterator = int**; _Size = long unsigned int]' at
> /usr/include/c++/13/bits/stl_uninitialized.h:706:20,
> inlined from 'constexpr _ForwardIterator
> std::__uninitialized_default_n_a(_ForwardIterator, _Size, allocator<_Tp>&)
> [with _ForwardIterator = int**; _Size = long unsigned int; _Tp = int*]' at
> /usr/include/c++/13/bits/stl_uninitialized.h:773:44,
> inlined from 'constexpr void std::vector<_Tp,
> _Alloc>::_M_default_append(size_type) [with _Tp = int*; _Alloc =
> std::allocator]' at /usr/include/c++/13/bits/vector.tcc:668:41,
> inlined from 'constexpr void std::vector<_Tp, _Alloc>::resize(size_type)
> [with _Tp = int*; _Alloc = std::allocator]' at
> /usr/include/c++/13/bits/stl_vector.h:1013:21,
> inlined from 'void foo(std::vector&)' at /tmp/toto.cpp:7:13:
> /usr/include/c++/13/bits/stl_construct.h:119:7: error: array subscript
> 'int*[0]' is partly outside array bounds of 'unsigned char [8]'
> [-Werror=array-bounds=]
>   119 |   ::new((void*)__p) _Tp(std::forward<_Args>(__args)...);
>   |   ^
> In file included from
> /usr/include/c++/13/x86_64-redhat-linux/bits/c++allocator.h:33,
>  from /usr/include/c++/13/bits/allocator.h:46,
>  from /usr/include/c++/13/vector:63:
> In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type,
> const void*) [with _Tp = int*]',
> inlined from 'constexpr _Tp* std::allocator< 
> >::allocate(std::size_t) [with _Tp = int*]' at
> /usr/include/c++/13/bits/allocator.h:198:40,
> inlined from 'static constexpr _Tp*
> std::allocator_traits >::allocate(allocator_type&,
> size_type) [with _Tp = int*]' at
> /usr/include/c++/13/bits/alloc_traits.h:482:28,
> inlined from 'constexpr std::_Vector_base<_Tp, _Alloc>::pointer
> std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = int*;
> _Alloc = std::allocator]' at
> /usr/include/c++/13/bits/stl_vector.h:378:33,
> inlined from 'constexpr void std::vector<_Tp,
> _Alloc>::_M_default_append(size_type) [with _Tp = int*; _Alloc =
> std::allocator]' at /usr/include/c++/13/bits/vector.tcc:663:45,
> inlined from 'constexpr void std::vector<_Tp, _Alloc>::resize(size_type)
> [with _Tp = int*; _Alloc = std::allocator]' at
> /usr/include/c++/13/bits/stl_vector.h:1013:21,
> inlined from 'void foo(std::vector&)' at /tmp/toto.cpp:7:13:
> /usr/include/c++/13/bits/new_allocator.h:147:55: note: at offset [1, 8] into
> object of size 8 allocated by 'operator new'
>   147 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
> sizeof(_Tp)));
>   |   ^
> cc1plus: all warnings being treated as errors
> [...]


But no warning with -O2

[Bug tree-optimization/107004] [12 Regression] GCC12 warning in OOB access: array subscript is partly outside array bounds

[sbouchex at infovista dot com via Gcc-bugs]

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

sbouchex  changed:

   What|Removed |Added

 CC||sbouchex at infovista dot com

--- Comment #6 from sbouchex  ---
The same testcase is failing on :

[...]
g++ --version
g++ (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)
[...]

[...]
[root@dev-sbo-eva-ol8 CorrCommon]# g++ -std=c++20 -Wall -Wextra -Werror
-pedantic -Warray-bounds -O3 -o /tmp/toto /tmp/toto.cpp
In file included from /usr/include/c++/13/bits/stl_iterator.h:85,
 from /usr/include/c++/13/bits/stl_algobase.h:67,
 from /usr/include/c++/13/vector:62,
 from /tmp/toto.cpp:1:
In function 'constexpr void std::_Construct(_Tp*, _Args&& ...) [with _Tp =
int*; _Args = {}]',
inlined from 'static constexpr _ForwardIterator
std::__uninitialized_default_n_1::__uninit_default_n(_ForwardIterator,
_Size) [with _ForwardIterator = int**; _Size = long unsigned int]' at
/usr/include/c++/13/bits/stl_uninitialized.h:666:23,
inlined from 'static constexpr _ForwardIterator
std::__uninitialized_default_n_1::__uninit_default_n(_ForwardIterator,
_Size) [with _ForwardIterator = int**; _Size = long unsigned int]' at
/usr/include/c++/13/bits/stl_uninitialized.h:660:9,
inlined from 'constexpr _ForwardIterator
std::__uninitialized_default_n(_ForwardIterator, _Size) [with _ForwardIterator
= int**; _Size = long unsigned int]' at
/usr/include/c++/13/bits/stl_uninitialized.h:706:20,
inlined from 'constexpr _ForwardIterator
std::__uninitialized_default_n_a(_ForwardIterator, _Size, allocator<_Tp>&)
[with _ForwardIterator = int**; _Size = long unsigned int; _Tp = int*]' at
/usr/include/c++/13/bits/stl_uninitialized.h:773:44,
inlined from 'constexpr void std::vector<_Tp,
_Alloc>::_M_default_append(size_type) [with _Tp = int*; _Alloc =
std::allocator]' at /usr/include/c++/13/bits/vector.tcc:668:41,
inlined from 'constexpr void std::vector<_Tp, _Alloc>::resize(size_type)
[with _Tp = int*; _Alloc = std::allocator]' at
/usr/include/c++/13/bits/stl_vector.h:1013:21,
inlined from 'void foo(std::vector&)' at /tmp/toto.cpp:7:13:
/usr/include/c++/13/bits/stl_construct.h:119:7: error: array subscript
'int*[0]' is partly outside array bounds of 'unsigned char [8]'
[-Werror=array-bounds=]
  119 |   ::new((void*)__p) _Tp(std::forward<_Args>(__args)...);
  |   ^
In file included from
/usr/include/c++/13/x86_64-redhat-linux/bits/c++allocator.h:33,
 from /usr/include/c++/13/bits/allocator.h:46,
 from /usr/include/c++/13/vector:63:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = int*]',
inlined from 'constexpr _Tp* std::allocator< 
>::allocate(std::size_t) [with _Tp = int*]' at
/usr/include/c++/13/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = int*]' at
/usr/include/c++/13/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = int*;
_Alloc = std::allocator]' at
/usr/include/c++/13/bits/stl_vector.h:378:33,
inlined from 'constexpr void std::vector<_Tp,
_Alloc>::_M_default_append(size_type) [with _Tp = int*; _Alloc =
std::allocator]' at /usr/include/c++/13/bits/vector.tcc:663:45,
inlined from 'constexpr void std::vector<_Tp, _Alloc>::resize(size_type)
[with _Tp = int*; _Alloc = std::allocator]' at
/usr/include/c++/13/bits/stl_vector.h:1013:21,
inlined from 'void foo(std::vector&)' at /tmp/toto.cpp:7:13:
/usr/include/c++/13/bits/new_allocator.h:147:55: note: at offset [1, 8] into
object of size 8 allocated by 'operator new'
  147 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n *
sizeof(_Tp)));
  |   ^
cc1plus: all warnings being treated as errors
[...]

[Bug middle-end/110495] fre introduces signed wrap for vector

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 110310 Summary: vector epilogue handling is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310

   What|Removed |Added

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

[Bug tree-optimization/110310] vector epilogue handling is inefficient

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/110495] fre introduces signed wrap for vector

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

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

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

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

commit r14-2282-gf703d2fd3f03890a180e8cc04df087c208999e81
Author: Richard Biener 
Date:   Mon Jul 3 10:28:10 2023 +0200

middle-end/110495 - avoid associating constants with (VL) vectors

When trying to associate (v + INT_MAX) + INT_MAX we are using
the TREE_OVERFLOW bit to check for correctness.  That isn't
working for VECTOR_CSTs and it can't in general when one considers
VL vectors.  It looks like it should work for COMPLEX_CSTs but
I didn't try to single out _Complex int in this change.

The following makes sure that for vectors we use the fallback of
using unsigned arithmetic when associating the above to
v + (INT_MAX + INT_MAX).

PR middle-end/110495
* tree.h (TREE_OVERFLOW): Do not mention VECTOR_CSTs
since we do not set TREE_OVERFLOW on those since the
introduction of VL vectors.
* match.pd (x +- CST +- CST): For VECTOR_CST do not look
at TREE_OVERFLOW to determine validity of association.

* gcc.dg/tree-ssa/addadd-2.c: Amend.
* gcc.dg/tree-ssa/forwprop-27.c: Adjust.

[Bug tree-optimization/110310] vector epilogue handling is inefficient

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

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

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

https://gcc.gnu.org/g:0682a32c026f1e246eb07bb8066abca4636f01d8

commit r14-2281-g0682a32c026f1e246eb07bb8066abca4636f01d8
Author: Richard Biener 
Date:   Mon Jul 3 13:59:33 2023 +0200

tree-optimization/110310 - move vector epilogue disabling to analysis phase

The following removes late deciding to elide vectorized epilogues to
the analysis phase and also avoids altering the epilogues niter.
The costing part from vect_determine_partial_vectors_and_peeling is
moved to vect_analyze_loop_costing where we use the main loop
analysis to constrain the epilogue scalar iterations.

I have not tried to integrate this with vect_known_niters_smaller_than_vf.

It seems the for_epilogue_p parameter in
vect_determine_partial_vectors_and_peeling is largely useless and
we could compute that in the function itself.

PR tree-optimization/110310
* tree-vect-loop.cc (vect_determine_partial_vectors_and_peeling):
Move costing part ...
(vect_analyze_loop_costing): ... here.  Integrate better
estimate for epilogues from ...
(vect_analyze_loop_2): Call
vect_determine_partial_vectors_and_peeling
with actual epilogue status.
* tree-vect-loop-manip.cc (vect_do_peeling): ... here and
avoid cancelling epilogue vectorization.
(vect_update_epilogue_niters): Remove.  No longer update
epilogue LOOP_VINFO_NITERS.

* gcc.target/i386/pr110310.c: New testcase.
* gcc.dg/vect/slp-perm-12.c: Disable epilogue vectorization.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #27 from Richard Biener  ---
For the testcase in comment#16 we have ifcombine doing

[local count: 477815112]:
-  if (v_12 == 1)
-goto ; [34.00%]
-  else
-goto ; [66.00%]
-
-   [local count: 315357972]:
-  if (LookupFlags_5 != 0)
-goto ; [50.00%]
+  _19 = v_12 == 1;
+  _20 = LookupFlags_5 | _19;
+  if (_20 != 0)
+goto ; [67.00%]

that at least accesses 'LookupFlags_5' without checking v_12 is either zero
or one.  This exposes an uninitialized read of LookupFlags_5 on the path
from entry, even actually at runtime.  PHI-OPT then makes tt value
dependent on this uninitialized variable and I suspect things go downhill
from there.

Note it's not obvious at all that 'LookupFlags_5' may be uninitialized here,
so ifcombine might need to use mark_ssa_maybe_undefs to try to conservatively
catch those.

[Bug tree-optimization/110531] Vect: slp_done_for_suggested_uf is not initialized in tree-vect-loop.cc

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

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

--- Comment #6 from Kewen Lin  ---
It's an arguable topic, I can't find the thread that previously some reviewers
told me it's not always good to initialize the local variable. IIRC, the case
is that I initialized one variable at the top, but the one got assigned in
below all switch cases, I was told not to initialize it, once a new case arm
use that variable unexpectedly, some bug would show up (static analyzer or
runtime bug), a default (but not reasonable) value is easy to cover some issue,
though at that time I hold an argument that initializing local variable seems
best practice.

For this case, since vect_analyze_loop_2 isn't able to be inlined, the
initialization can't be optimized, the worse thing I meant is to have more
instructions than before, for example, a test case like:

__attribute__((noipa)) int foo(int *a) { *a = 1; return 1;}

int test(){
#ifdef AINIT
  int a = 0;
#else
  int a;
#endif
  int b = foo();
  return b;
}

on Power, I got one more li and stw for -DAINIT.

But I just posted my naive thoughts, if you still think it's better to
initialize it, you can just go ahead to post a patch. :)



btw, the test case

int foo() {
  bool a = true;
  bool b;
  if (a || b)
return 1;
  b = true;
  return 0;
}

still has the warning, it looks something can be improved (guess we prefer not
to emit warning).

[Bug target/104914] [MIPS] wrong comparison with scrabbled int value

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

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

YunQiang Su  changed:

   What|Removed |Added

 CC||syq at gcc dot gnu.org

--- Comment #2 from YunQiang Su  ---
In fact, gcc-11 works with `short', for which, seh is used to sign extending.

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

--- Comment #26 from Richard Biener  ---
(In reply to Sergei Trofimovich from comment #24)
> Trying to understand the failure mode here:
> 
> In bug.c.033t.early_objsz I still see the explicit stores to LocalFlags:
> 
>:
>   LookupFlags_15 = 0;
>   goto ; [INV]
> 
>:
>   if (v_13 == 1)
> goto ; [INV]
>   else
> goto ; [INV]
> 
>:
>   LookupFlags_14 = 1;
> 
>:
>   # LookupFlags_4 = PHI  LookupFlags_14(6)>
>   *p_16(D) = LookupFlags_4;
> 
> But in bug.c.034t.ccp1 I see no stores at all:
> 
>   if (v_13 == 0)
> goto ; [INV]
>   else
> goto ; [INV]
> 
>:
>   if (v_13 == 1)
> goto ; [INV]
>   else
> goto ; [INV]
> 
>:
> 
>:
>   # LookupFlags_4 = PHI <0(3), LookupFlags_5(4), 1(5)>
> 
> Specifically '# LookupFlags_4 = PHI <0(3), LookupFlags_5(4), 1(5)>' claims
> that somehow gets values '0' and '1' into a PHI node.
> 
> AFAIU PHI is an equivalent of a mutable variable in an otherwise immutable
> SSA form. It has to be a write it needed value is not there yet. Why the
> store of '1' was removed? Is it because variable 'v_13' already happens to
> have 0 or 1 value?
> 
> I wonder why PHI does not look like something below:
> 
> # LookupFlags_4 = PHI 

LookupFlags is in SSA form thus we are dealing with registers and no "stores".
What happens is just constant propagation, LookupFlags_1{4,5} can be
replaced with their assigned constant.

[Bug target/110537] ICE for OpenMP loop with SVE (aarch64) intrinsics

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug middle-end/101018] ICE when enabling OpenMP on a simple loop with SVE intrinsics (aarch64)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pgodbole at nvidia dot com

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

[Bug target/110537] New: ICE for OpenMP loop with SVE (aarch64) intrinsics

[pgodbole at nvidia dot com via Gcc-bugs]

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

Bug ID: 110537
   Summary: ICE for OpenMP loop with SVE (aarch64) intrinsics
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pgodbole at nvidia dot com
  Target Milestone: ---

Created attachment 55465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55465=edit
OpenMP code with SVE intrinsics

We are observing a crash with GCC 14 when compiling an OpenMP loop that uses
SVE intrinsics (see attached source code).

Command:
gcc -mcpu=neoverse-v2 -fopenmp crash_sve_bug.c -w

Results in:

crash_sve_bug.c: In function _HPL_dlaswp06T_:
crash_sve_bug.c:82:33: internal compiler error: Segmentation fault
   82 |  svfloat64_t __a0_sve = svld1_f64(pg, a0 +   0 * LDA);
  | ^
0xef64df crash_signal
/home/latest_trunk/git/gcc/gcc/toplev.cc:314
0xb7570c omp_add_variable
/home/latest_trunk/git/gcc/gcc/gimplify.cc:7411
0xb7570c omp_add_variable
/home/latest_trunk/git/gcc/gcc/gimplify.cc:7352
0xb765db omp_notice_variable
/home/latest_trunk/git/gcc/gcc/gimplify.cc:8026
0xb761ff omp_notice_variable
/home/latest_trunk/git/gcc/gcc/gimplify.cc:8095
0xb7a577 gimplify_var_or_parm_decl
/home/latest_trunk/git/gcc/gcc/gimplify.cc:3063
0xb826eb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:16902
0xb89fbb gimplify_expr
/home/latest_trunk/git/gcc/gcc/gimplify.cc:17505
0xb89fbb gimplify_arg(tree_node**, gimple**, unsigned int, bool)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:3523
0xb8f4e7 gimplify_call_expr
/home/latest_trunk/git/gcc/gcc/gimplify.cc:3808
0xb82c57 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:16413
0xb9 gimplify_modify_expr
/home/latest_trunk/git/gcc/gcc/gimplify.cc:6173
0xb82983 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:16441
0xb86c4b gimplify_stmt(tree_node**, gimple**)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:7246
0xb8b3e3 gimplify_and_add(tree_node*, gimple**)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:492
0xb8b3e3 gimplify_decl_expr
/home/latest_trunk/git/gcc/gcc/gimplify.cc:1936
0xb82fc3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:16638
0xb86c4b gimplify_stmt(tree_node**, gimple**)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:7246
0xb83a3f gimplify_statement_list
/home/latest_trunk/git/gcc/gcc/gimplify.cc:2019
0xb83a3f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/latest_trunk/git/gcc/gcc/gimplify.cc:16886
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

The same ICE is observed on GCC 12.3 and 13.1. It compiles successfully without
-fopenmp

Thanks,
Prachi