[Bug target/77348] --with-arch=skylake still not working because config.gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84331
   Target Milestone|--- |8.0

--- Comment #2 from Andrew Pinski  ---
Fixed for GCC 8 by r8-7853-g176a3386885f99 (PR 84331).

[Bug target/77588] Internal error triggered by __builtin___chkp_bndret

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
   Target Milestone|--- |9.0
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
GCC 8 gives:
```
:4:9: error: invalid conversion from '#'pointer_bounds_type' not
supported by dump_type_prefix# (*)(const
void*)#'pointer_bounds_type' not supported by dump_type_suffix#' to 'void*'
[-fpermissive]
   test1(__builtin___chkp_bndret);
 ^~~
:1:18: note:   initializing argument 1 of 'void test1(void*)'

```

But these builtins were removed in GCC 9 by r9-1060-g31db0fe044cc9d .

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

--- Comment #5 from Andrew Pinski  ---
Reduced testcase which shows this never worked:
```
template  struct c1 {};

template 
inline constexpr auto b_v = t;

template 
using c1_t = c1>;

template 
constexpr auto g(_Data __data) {
return c1_t<_Data>{};
}

void f() {
  auto & = g(0);
}
```

I don't know understand how the original testcase worked in GCC 13 when the
above testcase never worked ...

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda

--- Comment #4 from Andrew Pinski  ---
This might come down to:
```
template 
inline constexpr auto __descriptor_fn_v = t;
```

being handled wrong.

[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #2)
> Created attachment 57739 [details]
> Patch fixing the problem
> 
> This small patch fixes the problem.
> Unfortunately allowing more errors seems counter-productive here.
> As seen in the testsuite changes, the additional errors have little value,
> and add more noise than anything else.
> I'm tempted to close this as WONTFIX.

I like your approach to limit the run-on errors.

I am, however, of the mind that if gfortran gets to the
"Unclassifiable error" message, that perhaps, this should be
a fatal error.

[Bug libstdc++/114400] New: The resolution of LWG3950 seems incorrectly implemented

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 114400
   Summary: The resolution of LWG3950 seems incorrectly
implemented
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following example fails to compile with libstdc++ due to ambiguity in
overload resolution (https://godbolt.org/z/Ya5o4rrKj).


```
#include 
#include 
#include 

namespace test {
template
concept characterized_traits = requires { typename
Traits::is_characterized; };

template
struct test_traits : std::char_traits {
using is_characterized = void;
};

template
struct traits_comparison_category {
using type = std::weak_ordering;
};
template
requires requires { typename Traits::comparison_category; }
struct traits_comparison_category {
using type = Traits::comparison_category;
static_assert(std::disjunction_v<
std::is_same,
std::is_same,
std::is_same>);
};

// N.B. std::type_identity_t is exactly used.

template
constexpr bool operator==(
std::basic_string_view x,
std::type_identity_t> y) noexcept
{
return x.size() == y.size() && x.compare(y) == 0;
}

template
constexpr traits_comparison_category::type operator<=>(
std::basic_string_view x,
std::type_identity_t> y) noexcept
{
return
static_cast::type>(x.compare(y) <=> 0);
}

using test_string_view = std::basic_string_view>;
static_assert(test_string_view{} == test_string_view{});
static_assert(test_string_view{} == "");
static_assert("" == test_string_view{});

static_assert(test_string_view{} <=> test_string_view{} ==
std::strong_ordering::equal);
static_assert(test_string_view{} <=> "" == std::strong_ordering::equal);
static_assert("" <=> test_string_view{} == std::strong_ordering::equal);
}
```

The resolution of LWG3950 (https://cplusplus.github.io/LWG/issue3950) uses
`type_identity_t`, while libstdc++ currently uses `__type_identity_t`. The
difference between two alias templates can be observed by partial ordering
introduced by associated constraints.

Related PR in MSVC STL:
https://github.com/microsoft/STL/pull/4249

[Bug target/114399] [14] RISC-V rv32i miscompile

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Andrew Pinski  ---
.

[Bug c++/111918] #pragma GCC diagnostic pop does not restore error status of -Wnarrowing

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #8 from Lewis Hyatt  ---
Fixed for GCC 14.

[Bug c++/111918] #pragma GCC diagnostic pop does not restore error status of -Wnarrowing

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:44ba7bcb752a40ec7490dea53d3a472ce633371d

commit r14-9561-g44ba7bcb752a40ec7490dea53d3a472ce633371d
Author: Lewis Hyatt 
Date:   Wed Nov 8 16:13:14 2023 -0500

diagnostics: Fix behavior of permerror options after diagnostic pop
[PR111918]

When a diagnostic pragma changes the classification of a given diagnostic,
the global options flags (such as warn_narrowing, etc.) may get changed
too.
Specifically, if a warning was not enabled initially and was later enabled
by a pragma, then the corresponding global flag will change from false to
true when the pragma is processed. That change is permanent and is not
undone by a subsequent `#pragma GCC diagnostic pop'; the warning flag needs
to remain enabled since a diagnostic could be generated later on for a
source location prior to the pop.

So in order to support popping to the initial classification, given that
the
global options flags no longer reflect that state, the diagnostic_context
object itself remembers the way things were before it changed anything. The
current implementation works fine for diagnostics that are always errors or
always warnings, but it doesn't do the right thing for diagnostics that
could be either, such as -Wnarrowing. The classification of that diagnostic
(or any permerror diagnostic) depends on the state of -fpermissive; for the
particular case of -Wnarrowing it also matters whether a compile-time or
run-time narrowing is being diagnosed.

The problem is that the current implementation insists on recording whether
an enabled diagnostic should be a DK_WARNING or a DK_ERROR, and then, after
popping to the initial state, it overrides it always to that type only. Fix
that up by adding a new internal diagnostic type DK_ANY. This just
indicates
that the diagnostic is enabled without mandating exactly what type of
diagnostic it should be. Then the diagnostic can be emitted with whatever
type the frontend asks for.

Incidentally, while making this change, I noticed that
classify_diagnostic()
spends some time computing a return value (the old classification kind)
that
is not used anywhere. The computed value seems to have some problems,
mainly
that it does not take into account `#pragma GCC diagnostic pop' at all, and
so the returned value doesn't seem like it could make sense in many
contexts. Given it would also not be desirable to leak the new
internal-only
DK_ANY type to outside callers, I think it would make sense in a subsequent
cleanup patch to remove the return value altogether.

gcc/ChangeLog:

PR c++/111918
* diagnostic-core.h (enum diagnostic_t): Add DK_ANY special flag.
* diagnostic.cc
(diagnostic_option_classifier::classify_diagnostic):
Make use of DK_ANY to indicate a diagnostic was initially enabled.
(diagnostic_context::diagnostic_enabled): Do not change the type of
a diagnostic if the saved classification is type DK_ANY.

gcc/testsuite/ChangeLog:

PR c++/111918
* g++.dg/cpp0x/Wnarrowing21a.C: New test.
* g++.dg/cpp0x/Wnarrowing21b.C: New test.
* g++.dg/cpp0x/Wnarrowing21c.C: New test.
* g++.dg/cpp0x/Wnarrowing21d.C: New test.

[Bug target/114399] [14] RISC-V rv32i miscompile

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from Patrick O'Neill  ---
Ah thank you - that makes sense.
IIUC -malign-double is the option I'm looking for to set the padding to be the
same between x86/risc-v.

[Bug target/114399] [14] RISC-V rv32i miscompile

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

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

--- Comment #2 from Andrew Pinski  ---
That is doing:
  long long f __attribute__((packed,aligned(4)));


Will produce the same result between the 2 targets.

Likewise:
  long long f __attribute__((packed,aligned(8)));


With  -Wpadded you can see the padding between e and f is added.

:7:13: warning: padding struct to align 'd::f' [-Wpadded]


Just the padding is different between the 2 targets due to the alignment of
long long being 4 bytes (it is an old ABI where 4 bytes was the only alignment
at the time when long long was added, double have a similar thing too).

[Bug target/114399] [14] RISC-V rv32i miscompile

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
32bit i686 long long has an alignment of 4 while most other targets have an
alignment of 8. 

Which you could see via sizeof.

```
int tt = sizeof(struct b);
int tt1 = sizeof(struct d);
```

i?86:
```
tt:
.long   8
...
tt1:
.long   12
```

RISCV32:
```
tt:
.word   8
...
tt1:
.word   16
```

Basically in the i?86 case, i.h.f++ will modify byte 4 of the union while on
most other targets, it will modify byte 8.

[Bug target/114399] New: [14] RISC-V rv32i miscompile

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114399
   Summary: [14] RISC-V rv32i miscompile
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a;
struct b {
  long long c;
};
struct d {
  short e;
  long long f;
};
union {
  struct b g;
  struct d h;
} i;
int main() {
  i.h.f++;
  a = i.g.c >> 1;
  __builtin_printf("%X\n", a);
}

Commands:
> gcc red.c -o red.out -m32 -fno-strict-aliasing -static
> ./red.out
8000

> riscv64-unknown-linux-gnu-gcc -mabi=ilp32 -march=rv32i red.c -o red.out 
> -fno-strict-aliasing -static
> /scratch/tc-testing/tc-mar-19/build-rv32-64-gcv/bin/qemu-riscv32 red.out
0

Discovered/tested with r14-9544-gc7a774edbf8 (not bisected)

Found via fuzzer.

I don't think this has any undefined behavior but the combo of union/struct has
me a bit wary.

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

--- Comment #3 from Andrew Pinski  ---
Reducing ...

[Bug tree-optimization/114390] Missed SLP of permuted mask load

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/114390] Missed SLP of permuted mask load

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #9 from Jakub Jelinek  ---
BTW, just curious, r14-162 had:
   /* Ensure that the header will have just the latch as a predecessor
 inside the loop.  */
-  if (!single_pred_p (exit->dest))
+  if (!single_pred_p (nonexit->dest))
{
- header = split_edge (exit);
+ header = split_edge (nonexit);
  exit = single_pred_edge (header);
}
chunk, shouldn't that be nonexit = single_pred_edge (header); or is that line
correct?

[Bug c++/114392] Address of overloaded function with requires

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=29143

--- Comment #2 from Andrew Pinski  ---
Related to the much older bug 29143; which was fixed in GCC 4.9.0 but I suspect
the issue is in the same area even ...

[Bug c++/38658] trivial try/catch statement not eliminated

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

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

[Bug c++/64786] Eliminate exceptions thrown/caught inside a function

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/114391] catch() and immediate throw; could be optimized to noop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 CC||pinskia at gcc dot gnu.org

[Bug ipa/114254] [11/12/13/14 regression] Indirect inlining through C++ member pointers fails if the underlying class has a virtual function

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-9559-gbf838884fac573b4902a21bb82d9b6f777e32cb9
Author: Martin Jambor 
Date:   Tue Mar 19 22:33:27 2024 +0100

ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.

Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.

The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code.  The pattern
matcher had a small bug which did not matter before
r10-917-g3b47da42de621c but did afterwards.

This patch changes the pattern matcher to match both of these cases.

gcc/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case
looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads
from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a
pointer
parameter, also recognize the case when pfn pointer is loaded in
its
own BB.

gcc/testsuite/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* g++.dg/ipa/iinline-4.C: New test.
* g++.dg/ipa/pr108802.C: Likewise.

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-9559-gbf838884fac573b4902a21bb82d9b6f777e32cb9
Author: Martin Jambor 
Date:   Tue Mar 19 22:33:27 2024 +0100

ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.

Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.

The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code.  The pattern
matcher had a small bug which did not matter before
r10-917-g3b47da42de621c but did afterwards.

This patch changes the pattern matcher to match both of these cases.

gcc/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case
looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads
from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a
pointer
parameter, also recognize the case when pfn pointer is loaded in
its
own BB.

gcc/testsuite/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* g++.dg/ipa/iinline-4.C: New test.
* g++.dg/ipa/pr108802.C: Likewise.

[Bug target/99829] MVE: ICE in lra_assign at -O3

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:9c91f8a88b2db50c8faf70786d3cef27b39ac9fc

commit r14-9557-g9c91f8a88b2db50c8faf70786d3cef27b39ac9fc
Author: Vladimir N. Makarov 
Date:   Tue Mar 19 16:57:11 2024 -0400

[PR99829][LRA]: Fixing LRA ICE on arm

  LRA removed insn setting equivalence to memory whose output was
reloaded. This resulted in writing an uninitiated value to the memory
which triggered assert in LRA code checking the final generated code.
This patch fixes the problem.  Comment in the patch contains more
details about the problem and its solution.

gcc/ChangeLog:

PR target/99829
* lra-constraints.cc (lra_constraints): Prevent removing insn
with reverse equivalence to memory if the memory was reloaded.

[Bug tree-optimization/114396] [14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv

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

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

--- Comment #7 from Robin Dapp  ---
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 4375ebdcb49..f8f7ba0ccc1 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9454,7 +9454,7 @@ vect_peel_nonlinear_iv_init (gimple_seq* stmts, tree
init_expr,
wi::to_mpz (skipn, exp, UNSIGNED);
mpz_ui_pow_ui (mod, 2, TYPE_PRECISION (type));
mpz_powm (res, base, exp, mod);
-   begin = wi::from_mpz (type, res, TYPE_SIGN (type));
+   begin = wi::from_mpz (type, res, TYPE_SIGN (utype));
tree mult_expr = wide_int_to_tree (utype, begin);
init_expr = gimple_build (stmts, MULT_EXPR, utype,
  init_expr, mult_expr);

This helps for the test case.

[Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer since r14-6239

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Patch looked good to me and it passed bootstrap, regrtesting, and integration
testing (all on x86_64-pc-linux-gnu), so I went ahead and pushed it to trunk.

Marking as resolved.

Thanks again for the patch

[Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer since r14-6239

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-9555-gc87f1f3d660f4103c91c72a4d3e1d19ff2858671
Author: Jakub Jelinek 
Date:   Tue Mar 19 16:06:13 2024 -0400

analyzer: fix ICE due to corrupt MEM_REFs [PR113505]

gcc/analyzer/ChangeLog
PR analyzer/113505
* region-model.cc (get_tree_for_byte_offset,
region_model::get_representative_path_var_1,
test_mem_ref, test_POINTER_PLUS_EXPR_then_MEM_REF): Use
char __attribute__((may_alias)) * as type of MEM_REF second
argument.

gcc/testsuite/ChangeLog
PR analyzer/113505
* gcc.dg/analyzer/pr113505.c: New test.

Signed-off-by: David Malcolm 

[Bug tree-optimization/71258] Missed optimizations: dynamic allocation, virtual calls, empty destructors

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Phosit from comment #5)
> struct Base{
> virtual ~Base() = default;
> };
> 
> int main(){
> delete new Base;
> return 0;
> }
> 
> In this partial test case the destructor is not inlined.
> Curiously when changing the function name the destructor is inlined.
> I compiled with -O3

Yes main is known to be only called once so heuristics decide inlining is not
profitable. Gcc does this because things called directly from main (without a
loop) is usually not on the hot path of applications.

[Bug tree-optimization/71258] Missed optimizations: dynamic allocation, virtual calls, empty destructors

[phosit at autistici dot org via Gcc-bugs]

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

Phosit  changed:

   What|Removed |Added

 CC||phosit at autistici dot org

--- Comment #5 from Phosit  ---
struct Base{
virtual ~Base() = default;
};

int main(){
delete new Base;
return 0;
}

In this partial test case the destructor is not inlined.
Curiously when changing the function name the destructor is inlined.
I compiled with -O3

[Bug fortran/114001] is_contiguous considers unlimited polymorphic dummy always as contiguous

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug fortran/114001] is_contiguous considers unlimited polymorphic dummy always as contiguous

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

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

commit r13-8468-g5b928badac560ad48e0e9fc480096ff396d9d9c6
Author: Harald Anlauf 
Date:   Tue Mar 12 22:58:39 2024 +0100

Fortran: fix IS_CONTIGUOUS for polymorphic dummy arguments [PR114001]

gcc/fortran/ChangeLog:

PR fortran/114001
* expr.cc (gfc_is_simply_contiguous): Adjust logic so that CLASS
symbols are also handled.

gcc/testsuite/ChangeLog:

PR fortran/114001
* gfortran.dg/is_contiguous_4.f90: New test.

(cherry picked from commit 11caf47b599568c6c6f5a12cf8e21f50778176d3)

[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:9623e5dd70b0d8334ebe093459721d0d447ce4f2

commit r13-8467-g9623e5dd70b0d8334ebe093459721d0d447ce4f2
Author: Harald Anlauf 
Date:   Mon Mar 18 19:36:59 2024 +0100

Fortran: error recovery in frontend optimization [PR103715]

gcc/fortran/ChangeLog:

PR fortran/103715
* frontend-passes.cc (check_externals_expr): Prevent invalid read
in case of mismatch of external subroutine with function.

gcc/testsuite/ChangeLog:

PR fortran/103715
* gfortran.dg/pr103715.f90: New test.

(cherry picked from commit 3be2b8f475f22c531d6cef1b041c0573b3ea5133)

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #9 from Andrew Pinski  ---
https://eel.is/c++draft/dcl.init.general#16.2 applies here I think. Which comes
before the `Parenthesized aggregates initialization` clause. But I could be
wrong.

https://github.com/cplusplus/papers/issues/1494 is kinda of related.

[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #64 from Jan Hubicka  ---
> Are you going to apply this patch, even if it just helps partially with some
> tests and not others?
I think we should fix this completely, since it is source of very
suprising bugs.  I discussed it with Martin (since he is maintaining the
jump functions) and he will add comparator for them, so we can plug this
bug completely.  If we have operator= on functions, we can use it at the
spot I am comparing value ranges. 

There is also a need to compare loop structures.   Seems I have testcase
now too (triggering peeling on miscomputed upper bound on iteration
count). Will attach it after cleaning up.

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #7)
> All of Clang, MSVC and EDG disagree with GCC though, so maybe there's a DR
> that we're missing.

Maybe https://cplusplus.github.io/CWG/issues/1467.html (again).
See clang bug https://github.com/llvm/llvm-project/pull/77768 .

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #12)
> Further simplified without any headers, -O1 works, -O2 fails.

For this testcase (at -O3), GCC 4.7.4 works but 4.8.1 fails.

[Bug middle-end/59863] const array in function is placed on stack

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114206

--- Comment #10 from Xi Ruoyao  ---
Note that if we take a pointer to such an array this optimization will be
invalid.  And unfortunately the mis-optimization is already happening (even for
non-const arrays) with some strange command line switch combinations.  See
PR114206.

[Bug middle-end/114348] Corrupt SARIF output on stderr

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

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

--- Comment #5 from David Malcolm  ---
Should be fixed on trunk for GCC 14 by the above patch.  Keeping open to
backport.

(In reply to Tobias Specht from comment #2)
[...snip...]
> A workaround could be, to only parse the first line as json, but this also
> seems racy.

Note that although in earlier releases the JSON was all on one line, for GCC 14
I've added newlines and formatting to the output:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639625.html  (which
I've found *very* useful in my own usage of SARIF output).

[Bug middle-end/114348] Corrupt SARIF output on stderr

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-9554-g0bf99b1b7eda2f4c34b9f56b895980ea1c261765
Author: David Malcolm 
Date:   Tue Mar 19 13:57:35 2024 -0400

diagnostics: fix corrupt json/SARIF on stderr [PR114348]

Various values of -fdiagnostics-format= request machine-readable output
on stderr, using JSON, but in various places we use fnotice to write
free-form text to stderr, such as "compilation terminated", leading to
corrupt JSON.

Fix by having fnotice skip the output for such cases.

gcc/ChangeLog:
PR middle-end/114348
* diagnostic-format-json.cc
(json_stderr_output_format::machine_readable_stderr_p): New.
(json_file_output_format::machine_readable_stderr_p): New.
* diagnostic-format-sarif.cc
(sarif_stream_output_format::machine_readable_stderr_p): New.
(sarif_file_output_format::machine_readable_stderr_p): New.
* diagnostic.cc (diagnostic_context::action_after_output): Move
"fnotice" to before "finish" call, so that we still have the
diagnostic_context.
(fnotice): Bail out if the user requested one of the
machine-readable diagnostic output formats on stderr.
* diagnostic.h
(diagnostic_output_format::machine_readable_stderr_p): New pure
virtual function.
(diagnostic_text_output_format::machine_readable_stderr_p): New.
(diagnostic_context::get_output_format): New accessor.

Signed-off-by: David Malcolm 

[Bug ada/114398] New: Unexpected storage error when "executing" return statement.

[d.van.raaij at gmail dot com via Gcc-bugs]

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

Bug ID: 114398
   Summary: Unexpected storage error when "executing" return
statement.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.van.raaij at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

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

The program included in this report generates an unexpected storage error
(SIGSEGV) when the return statement on line 37 is being "executed". The issue
seems to be a regression in GCC 14.0.1 (20240228). 

A quick analysis using rr hints at an invalid value of "_init" in the expanded
code:

(rr) list
244   procedure reproducer__pkg__intIP (_init : out
245 reproducer__pkg__int; P60b : natural := 0; _init_level :
246 natural := 0) is
247   begin
248  if P60b = 0 then
249 _init._tag := pkg__intP; < Error occurs here.
250  end if;
251  if P60b /= 3 then
252 $ada__finalization__limited_controlledIP (_init._parent,
253   1);
(rr) p/x _init
$1 = 

The invalid memory address seems to come from a hidden argument of the "+"
operator function named "OaddBIPaccess":

(rr) frame
#0  reproducer.pkg."+" (left=..., right=..., =0,
=0x0, =0x7fffc9c35df0,
=-909943160, =0x7f1d6258d340
,
=0x17fff) at
/home/dvraaij/gnat14_bip_issue/reproducer.adb.dg:385
385   function reproducer__pkg__Oadd (left : reproducer__pkg__int;


*** Compilation ***

$ gnatmake -f reproducer.adb -cargs -O0 -g -gnatDGL -bargs -Es
gcc -c -O0 -g -gnatDGL reproducer.adb
gnatbind -Es -x reproducer.ali
gnatlink reproducer.ali

*** Program output ***

$ ./reproducer

raised STORAGE_ERROR : stack overflow or erroneous memory access
[/lib64/libgnat-14.so]
0x7f441f1d805f
[/lib64/libc.so.6]
0x7f441ecaf70e
[./reproducer]
0x404b95 reproducer__pkg__intIP.12 at reproducer.adb.dg:249
0x4047eb reproducer__pkg__Oadd.5 at reproducer.adb.dg:579
0x404df9 reproducer__test.15 at reproducer.adb.dg:733
0x404478 _ada_reproducer at reproducer.adb.dg:855
0x403bf7 Main at b~reproducer.adb:254
[/lib64/libc.so.6]
0x7f441ec99086
0x7f441ec99149
[./reproducer]
0x403633 _start at ???
0xfffe

raised PROGRAM_ERROR : reproducer.adb.dg:571 finalize/adjust raised exception
[./reproducer]
0x404af0 reproducer__pkg__Oadd__R80b___finalizer.8 at reproducer.adb.dg:571
0x404894 reproducer__pkg__Oadd.5 at reproducer.adb.dg:600
0x404df9 reproducer__test.15 at reproducer.adb.dg:733
0x404478 _ada_reproducer at reproducer.adb.dg:855
0x403bf7 Main at b~reproducer.adb:254
[/lib64/libc.so.6]
0x7f441ec99086
0x7f441ec99149
[./reproducer]
0x403633 _start at ???
0xfffe

*** Compiler version ***

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.0.1-20240228/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240228 (Red Hat 14.0.1-0) (GCC)

[Bug tree-optimization/114396] [14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
   Target Milestone|--- |14.0
   Last reconfirmed||2024-03-19
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Confirmed.
Fails on x86_64 with the simple: "-O3  -fno-vect-cost-model -fwrapv" .


Note aarch64 vectorizes this loop in GCC 13 (with "-O3  -fno-vect-cost-model
-fwrapv") and gets it right.

The only difference is:

trunk:
  _34 = _36 * 32767;

GCC 13:
  _32 = _34 * 62945;

[Bug libgcc/114397] New: wrong code with _BitInt() division at -O0

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114397
   Summary: wrong code with _BitInt() division at -O0
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc testcase.c
$ ./a.out 
Aborted

The result is 0 instead of -1.

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

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

--- Comment #12 from Jakub Jelinek  ---
Further simplified without any headers, -O1 works, -O2 fails.
double a[2] = { 0.8147, 0.9058 };
double b[6] = { 0.1576, 0.9706, 1, 1, 1, 1 };
double c[16];
typedef double U __attribute__ ((vector_size(16), may_alias, aligned(1)));
typedef double V __attribute__ ((vector_size(16), may_alias));

int
main ()
{
  for (int f = 0; f < 6; f++)
{
  *(U *) [f] = *(U *) [f] + (V) { b[f], b[f] } * *(U *) a;
  *(U *) [f + 2] = *(U *) [f + 2] + (V) { b[f], b[f] } * *(U *) a;
}
  if (c[1] <= 0.93 || c[1] >= 0.94)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/107263] Memcpy not elided when initializing struct

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #3 from AK  ---
Seems like a duplicate of #59863 ?

[Bug middle-end/59863] const array in function is placed on stack

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #9 from AK  ---
*** Bug 114342 has been marked as a duplicate of this bug. ***

[Bug middle-end/114342] suboptimal codegen of vector::vector(range)

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
Version|unknown |14.0
 Status|NEW |RESOLVED

--- Comment #3 from AK  ---
I see. marking as duplicate. Thanks for clarifying!

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

[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE

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

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

--- Comment #12 from avieira at gcc dot gnu.org ---
Sorry, missed that comment, thanks! I'll test backporting both.

[Bug libfortran/106295] INQUIRE statement bus error at runtime

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

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

--- Comment #7 from Jerry DeLisle  ---
I don't think that is a bad idea. I realize that this comes up often enough to
consider some solution.

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #7 from Jonathan Wakely  ---
All of Clang, MSVC and EDG disagree with GCC though, so maybe there's a DR that
we're missing.

[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to avieira from comment #10)
> First of all, apologies for this! I don't know why I didn't test this on
> x86_64 too, I usually do for such backports.
> 
> Anyway I checked locally and backporting: 
> r14-2821-gd1c072a1c3411a6fe29900750b38210af8451eeb seems to be enough for
> gcc-12, I'm testing it on gcc-13 and running full regression tests on both
> x86_64 and aarch64 and will get back to you.
> 
> @Andrew what made you think we also needed r14-2985-g04aa0edcace22a ? Not to
> say we may not want to backport it, but just trying to figure out why it's
> needed for this particular case.

Because r14-2821 introduced PR 110838 (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838#c1) which was fixed by
r14-2985 .

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #6 from Marek Polacek  ---
Right, another design principle is that () should work where {} works, and
const B {a}; works.  A(b) previously didn't work so it's not really changing
meaning.  So not a bug IMHO.

[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE

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

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

--- Comment #10 from avieira at gcc dot gnu.org ---
First of all, apologies for this! I don't know why I didn't test this on x86_64
too, I usually do for such backports.

Anyway I checked locally and backporting: 
r14-2821-gd1c072a1c3411a6fe29900750b38210af8451eeb seems to be enough for
gcc-12, I'm testing it on gcc-13 and running full regression tests on both
x86_64 and aarch64 and will get back to you.

@Andrew what made you think we also needed r14-2985-g04aa0edcace22a ? Not to
say we may not want to backport it, but just trying to figure out why it's
needed for this particular case.

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #5 from Jonathan Wakely  ---
I disagree, A(b) definitely changed meaning. It now initializes A by copying
the base part of b

This is a combination of aggregates being allowed to have base classes and
paren-init doing aggregate-init.

[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41

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

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

--- Comment #63 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #58)
> Created attachment 57702 [details]
> Compare value ranges in jump functions

s/functoins/functions/

Are you going to apply this patch, even if it just helps partially with some
tests and not others?

[Bug target/114396] [14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 Target|x86_64-*-* riscv*-*-*   |riscv*-*-* aarch64-*-*
   ||x86_64-*-*
Summary|[14] RISC-V rv64gcv vector: |[14 Regression] Vector:
   |Runtime mismatch at -O3 |Runtime mismatch at -O2
   |with -fwrapv|with -fwrapv
  Known to work||13.2.0

--- Comment #5 from Patrick O'Neill  ---
Looks like an regression from 13.

x86 godbolt: https://godbolt.org/z/fzd4cj6rz

[Bug target/114396] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3 with -fwrapv

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

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

--- Comment #4 from Jonathan Wakely  ---
$ ~/gcc/14/bin/aarch64-unknown-linux-gnu-gcc -O3 -fwrapv  -fno-vect-cost-model
-fwrapv red.c -o red.out
$ ./red.out
decimal: 32693
hex: 7FB5
$ ~/gcc/14/bin/aarch64-unknown-linux-gnu-gcc  red.c -o red.out
$ ./red.out
decimal: 2283
hex: 8EB

[Bug target/114396] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3 with -fwrapv

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

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

--- Comment #3 from Robin Dapp  ---
-O3 -mavx2 -fno-vect-cost-model -fwrapv seems to be sufficient.

[Bug target/114396] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3 with -fwrapv

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

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

Robin Dapp  changed:

   What|Removed |Added

 Target|riscv*-*-*  |x86_64-*-* riscv*-*-*

--- Comment #2 from Robin Dapp  ---
At first glance it doesn't really look like a target issue.

Tried it on x86 and it fails as well with
-O3 -march=native pr114396.c -fno-vect-cost-model -fwrapv

short a = 0xF;
short b[16];

int main() {
for (int e = 0; e < 9; e += 1)
b[e] = a *= 0x5;

if (a != 2283)
__builtin_abort ();
}

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

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

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

--- Comment #39 from GCC Commits  ---
The master branch has been updated by Edwin Lu :

https://gcc.gnu.org/g:60586710b0646efdbbd77a7f53b93fb5edb87a61

commit r14-9552-g60586710b0646efdbbd77a7f53b93fb5edb87a61
Author: Edwin Lu 
Date:   Mon Mar 18 11:43:41 2024 -0700

RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]

We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments
and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail

Fix the issue by checking if arg.type is NULL as r14-9503-g218d1749612
explains

Tested on linux rv64gcv.

gcc/ChangeLog:

PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions
if arg.type is NULL

[Bug middle-end/112499] [11/12/13/14 Regression] ICE in output_operand: invalid expression as operand with addition of 2 differences of address of labels

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

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

--- Comment #4 from Jakub Jelinek  ---
Or consider
typedef unsigned __INTPTR_TYPE__ uintptr_t;
volatile int v;

int
foo (int x)
{
  static uintptr_t a = ((char *)& - (char *)&) + ((char *)& - (char
*)&) + ((char *)& - (char *)&);
  void *b[] = { &, &, &, &, &, & };
l1:
  ++v;
l2:
  ++v;
l3:
  ++v;
l4:
  ++v;
l5:
  ++v;
l6:
  ++v;
  if (x >= 0 && x <= 5)
{
  x += 42;
  goto *b[x - 42];
}
  return a;
}
That is even older.
r0-79351-g7771bb621aad43c7d0e21ccec4922dd3beac9cb6
still used to reject that:
error: initializer element is not computable at load time
r0-79390-g7ffb5e78794b6d8f8094d7c928e6f0e94b62cad6
already accepts but assembler doesn't handle that:
pr112499-2.s:58: Error: invalid operands (*ABS* and .text sections) for `-'
pr112499-2.s:58: Error: invalid operands (*ABS* and .text sections) for `-'
pr112499-2.s:58: Error: invalid operands (.text and .text sections) for `+'
.quad   .L3-.L6-.L4-.L2+.L7+.L5
Guess we can only accept a subtraction of 2 labels, not addition of 2 labels or
something more complex.

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #3)
> Changed with r10-5137-g43aae289866f5e:
> 
> commit 43aae289866f5ea55d187444520412554aa2e171
> Author: Marek Polacek 
> Date:   Tue Dec 3 15:59:40 2019 +
> 
> PR c++/91363 - P0960R3: Parenthesized initialization of aggregates.

Hmm, reading the paper, I am not 100% sure if GCC implemented this correctly
due to the wording of the design principles:
```
Any existing meaning of A(b) should not change.
```

[Bug c++/91363] Implement P0960R3: Parenthesized initialization of aggregates

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Changed with r10-5137-g43aae289866f5e:

commit 43aae289866f5ea55d187444520412554aa2e171
Author: Marek Polacek 
Date:   Tue Dec 3 15:59:40 2019 +

PR c++/91363 - P0960R3: Parenthesized initialization of aggregates.

[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.

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

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

--- Comment #2 from Mikael Morin  ---
Created attachment 57739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739=edit
Patch fixing the problem

This small patch fixes the problem.
Unfortunately allowing more errors seems counter-productive here.
As seen in the testsuite changes, the additional errors have little value, and
add more noise than anything else.
I'm tempted to close this as WONTFIX.

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

--- Comment #2 from Andrew Pinski  ---
Except this works with C++20+ for GCC:
```
struct A {
int a;
};
struct B : public A {};

void f(const A )
{
typedef const B & Btype;
Btype b(a);
}

```

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #8 from Jakub Jelinek  ---
Great,
--- gcc/tree-ssa-loop-ch.cc.jj  2024-03-19 16:27:35.969474787 +0100
+++ gcc/tree-ssa-loop-ch.cc 2024-03-19 17:12:57.904712489 +0100
@@ -957,7 +957,7 @@ ch_base::copy_headers (function *fun)

   edge entry = loop_preheader_edge (loop);

-  propagate_threaded_block_debug_into (exit->dest, entry->dest);
+  propagate_threaded_block_debug_into (nonexit->dest, entry->dest);
   if (!gimple_duplicate_seme_region (entry, exit, bbs, n_bbs, copied_bbs,
 true))
{
looks very much promising:
-XFAIL: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
+XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
-FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 34 c ==
[0]
+PASS: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 34 c ==
[0]
-FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 39 c ==
[0]
+PASS: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 39 c ==
[0]
-PASS: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 34 c ==
[0]
+FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 34 c ==
[0]
-PASS: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 39 c ==
[0]
+FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 39 c ==
[0]
-FAIL: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21 i == v
+ 1
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21
x == 10 - i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21
y == 20 - 2 * i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21
z == 30 - 3 * i
+PASS: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21 i == v
+ 1
+PASS: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21 x ==
10 - i
+PASS: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21 y ==
20 - 2 * i
+PASS: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21 z ==
30 - 3 * i
-FAIL: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21 i == v
+ 1
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21
x == 10 - i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21
y == 20 - 2 * i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21
z == 30 - 3 * i
+PASS: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21 i == v
+ 1
+PASS: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21 x ==
10 - i
+PASS: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21 y ==
20 - 2 * i
+PASS: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21 z ==
30 - 3 * i
-FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 i == v + 1
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i
+PASS: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 i == v + 1
+PASS: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
+PASS: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
+PASS: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
-UNSUPPORTED: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i
+FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
+FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

--- Comment #5 from Martin Jambor  ---
I'd like to ping this, are there plans to implement this in the near-ish term?

[Bug target/113832] [14 Regression] 6% exec time regression of 464.h264ref on aarch64

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

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

--- Comment #3 from Filip Kastl  ---
It seems that the benchmark runtime returned to normal for a while but then
went back to 6% slowdown.

Somewhere between these two commits the benchmark sped up
g:eb7a8f213d59e0cf
g:15d1dae0d4d1be88

And between these two commits the benchmark regressed once again
g:c7a9883663a88861
g:84fc8f4f3263d665

[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|std::is_constructible_v |[c++20+]
   |result of const reference   |std::is_constructible_v
   |incorrect   |result of const reference
   ||incorrect

--- Comment #1 from Andrew Pinski  ---
Hmm, this fails only for C++20+.

[Bug libfortran/106295] INQUIRE statement bus error at runtime

[ghlixo at gmail dot com via Gcc-bugs]

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

--- Comment #6 from ghlixo at gmail dot com ---
One last comment about this issue.

I maintain and distribute a Fortran subroutine package to users.  In my
experience, most of them are unaware that Fortran compilers evolve over time,
and that the compiler used to build the subroutine package might not be the
same version that they have installed.

It seems that simple form of link-time version control might alert them to the
problem, and avoid spurious problem reports.  Would not a reference to a symbol
in the run-time library dropped into compiled code when a library routine is
used solve the problem?  If the symbol definition changes when the library
changes, then it would be impossible to link old code with an incompatible
run-time library.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|14.0|11.5

--- Comment #10 from Iain Sandoe  ---
fixed on trunk, but this will need back porting to avoid fails when building
the release branches with latest toolchains / on newest OS versions.

[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #22 from Uroš Bizjak  ---
Fixed also for TImode STV.

[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:07e03761a7fc1626a6a74ed957e117f56981558c

commit r14-9551-g07e03761a7fc1626a6a74ed957e117f56981558c
Author: Jonathan Wakely 
Date:   Mon Mar 18 13:22:17 2024 +

libstdc++: Fix infinite loop in std::binomial_distribution [PR114359]

The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiplying
integers.

libstdc++-v3/ChangeLog:

PR libstdc++/114359
* include/bits/random.tcc (binomial_distribution::param_type):
Ensure arithmetic is done as type double.
* testsuite/26_numerics/random/binomial_distribution/114359.cc: New
test.

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-9550-gc608b57f77a47179899666940c3b8b6a2e5435b2
Author: Jonathan Wakely 
Date:   Thu Feb 29 17:13:49 2024 +

libstdc++: Suppress deprecation messages from  [PR101228]

libstdc++-v3/ChangeLog:

PR libstdc++/101228
* include/pstl/parallel_backend_tbb.h
(TBB_SUPPRESS_DEPRECATED_MESSAGES):
Define before including  then undef afterwards.

[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038

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

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

--- Comment #21 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

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

commit r12-10284-gf6ed0466d40de496b14225fae44acf618dac1fd2
Author: Uros Bizjak 
Date:   Tue Mar 19 16:57:50 2024 +0100

testsuite/i386: Correct pr111822.C dg-do options [PR111822]

PR target/111822

gcc/testsuite/ChangeLog:

* g++.target/i386/pr111822.C (dg-do): Compile only for ia32
targets.
(dg-options): Add -march=x86-64.

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #7 from Jan Hubicka  ---
Found it, probably. I renamed exit to nonexit (since name was misleading) and
then forgot to update
 propagate_threaded_block_debug_into (exit->dest, entry->dest);

I will check this after teaching (which I have in 10 mins)

[Bug target/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g04520645038

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

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

--- Comment #20 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Uros Bizjak :

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

commit r13-8466-g1a6d04fce7d78b9e5201333be0c0877390f81bc3
Author: Uros Bizjak 
Date:   Tue Mar 19 16:56:11 2024 +0100

i386: Unify {general,timode}_scalar_chain::convert_op [PR111822]

Recent PR111822 fix implemented REG_EH_REGION note copying to a STV
converted
preload instruction in general_scalar_chain::convert_op.  However, the same
issue remains in timode_scalar_chain::convert_op.  Instead of copying the
newly introduced code to timode_scalar_chain::convert_op, the patch unifies
both functions to a common function.

PR target/111822

gcc/ChangeLog:

* config/i386/i386-features.cc (smode_convert_cst): New function
to handle SImode, DImode and TImode immediates.
(scalar_chain::convert_op): Unify from
general_scalar_chain::convert_op and
timode_scalar_chain::convert_op.
(general_scalar_chain::convert_op): Remove.
(timode_scalar_chain::convert_op): Remove.
* config/i386/i386-features.h (class scalar_chain):
Redeclare convert_op as protected class member.
(class general_calar_chain): Remove convert_op.
(class timode_scalar_chain): Ditto.

gcc/testsuite/ChangeLog:

* g++.target/i386/pr111822.C (dg-do): Compile only for ia32
targets.
(dg-options): Add -march=x86-64.

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #6 from Jan Hubicka  ---
On this testcase trunk does get same dump as gcc13 for pass just before ch2

with ch2 we get:
@@ -192,9 +236,8 @@
   # DEBUG BEGIN_STMT
   goto ; [100.00%]

-   [local count: 954449105]:
+   [local count: 954449104]:
   # j_15 = PHI 
-  # DEBUG j => j_15
   # DEBUG BEGIN_STMT
   a[b_14][j_15] = 0;
   # DEBUG BEGIN_STMT
@@ -203,29 +246,30 @@
   # DEBUG j => j_9
   # DEBUG BEGIN_STMT
   if (j_9 <= 7)
-goto ; [88.89%]
+goto ; [87.50%]
   else
-goto ; [11.11%]
+goto ; [12.50%]

[local count: 119292720]:
+  # DEBUG j => 0
   # DEBUG BEGIN_STMT
   b_7 = b_14 + 1;
   # DEBUG b => b_7
   # DEBUG b => b_7
   # DEBUG BEGIN_STMT
   if (b_7 <= 6)
-goto ; [87.50%]
+goto ; [85.71%]
   else
-goto ; [12.50%]
+goto ; [14.29%]

[local count: 119292720]:
   # b_14 = PHI 
-  # DEBUG b => b_14
   # DEBUG j => 0
   # DEBUG BEGIN_STMT
   goto ; [100.00%]

[local count: 17041817]:
+  # DEBUG b => 0
   # DEBUG BEGIN_STMT
   optimize_me_not ();
   # DEBUG BEGIN_STMT


So in addition to updating BB profile, we indeed end up moving debug statements
around.

The change of dump is:
+  Analyzing: if (b_1 <= 6)
+Will eliminate peeled conditional in bb 6.
+May duplicate bb 6
+  Not duplicating bb 8: it is single succ.
+  Analyzing: if (j_2 <= 7)
+Will eliminate peeled conditional in bb 4.
+May duplicate bb 4
+  Not duplicating bb 3: it is single succ.
 Loop 2 is not do-while loop: latch is not empty.
+Duplicating header BB to obtain do-while loop
 Copying headers of loop 1
 Will duplicate bb 6
-  Not duplicating bb 8: it is single succ.
-Duplicating header of the loop 1 up to edge 6->8, 2 insns.
+Duplicating header of the loop 1 up to edge 6->7
 Loop 1 is do-while loop
 Loop 1 is now do-while loop.
+Exit count: 17041817 (estimated locally)
+Entry count: 17041817 (estimated locally)
+Peeled all exits: decreased number of iterations of loop 1 by 1.
 Copying headers of loop 2
 Will duplicate bb 4
-  Not duplicating bb 3: it is single succ.
-Duplicating header of the loop 2 up to edge 4->3, 2 insns.
+Duplicating header of the loop 2 up to edge 4->5
 Loop 2 is do-while loop
 Loop 2 is now do-while loop.
+Exit count: 119292720 (estimated locally)
+Entry count: 119292720 (estimated locally)
+Peeled all exits: decreased number of iterations of loop 2 by 1.

Dumps moved around, but we do same duplicaitons as before (BB6 and BB4 to
eliminate the conditionals).

   [local count: 1073741824]:
  # j_2 = PHI <0(8), j_9(3)>
  # DEBUG j => j_2
  # DEBUG BEGIN_STMT
  if (j_2 <= 7)
goto ; [88.89%]
  else
goto ; [11.11%]

   [local count: 136334537]:
  # b_1 = PHI <0(2), b_7(5)>
  # DEBUG b => b_1
  # DEBUG BEGIN_STMT
  if (b_1 <= 6)
goto ; [87.50%]
  else
goto ; [12.50%]

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #4)
> The change makes loop iteration estimates more realistics, but does not
> introduce any new code that actually changes the IL, so it seems this makes
> existing problem more visible.  I will try to debug what happens.

Yeah, I didn't see any debug info handling in that commit, so wouldn't surprise
me if it was something latent before, or something where ch now needs to do a
better job.
All I can see from the dumps is that before ch2 the debug stmt placements were
reasonable both for b and j, b 0 at the very start and after SSA_NAME def stmts
which update it to a new value for the var (e.g. after PHI at the start of loop
body,
or after increasing the IV).
Before r14-162 ch2 used to do weird stuff with them - duplicating
  # DEBUG b => 0
  # DEBUG b => 0
at the start, after ++j:
  # DEBUG j => j_9
  # DEBUG j => j_9
after ++b:
  # DEBUG b => b_7
  # DEBUG b => b_7
and (the perhaps only reasonable change adding
  # DEBUG j => 0
after the b PHI, though not really necessary as it has unconditional goto to
the header with PHI after which it is set to something else).
But, newly ch2 in addition to the useless duplicate of b => 0, j => j_9 and b
=> b_7
removes the most important debug stmts (
  # DEBUG j => j_2
and
  # DEBUG b => b_1
after the PHIs) and adds wrong-debug debug stmts elsewhere - the
  # DEBUG j => 0
and
  # DEBUG b => 0
in random incorrect places.

[Bug target/114396] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3 with -fwrapv

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Here's the result when running with -fwrapv on rv64gcv at O2:

> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O2 red.c -o red.out -fwrapv
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/qemu-riscv64 red.out
decimal: 2283
hex: 8EB

[Bug target/114396] New: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3 with -fwrapv

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114396
   Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
with -fwrapv
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
short a = 0xF;
short b[16];
int main() {
  for (int e = 0; e < 9; e += 1)
b[e] = a *= 0x5;
  __builtin_printf("decimal: %d\n", a);
  __builtin_printf("hex: %X\n", a);
}

Commands:
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O3 red.c -o red.out -fwrapv
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/qemu-riscv64 red.out
decimal: 32693
hex: 7FB5
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> red.c -o red.out
> /scratch/tc-testing/tc-mar-18/build-rv64gcv/bin/qemu-riscv64 red.out
decimal: 2283
hex: 8EB

Discovered/tested using r14-9519-g3e3ad8eeb41 (not bisected)

Found using fuzzer.

[Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer since r14-6239

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

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

--- Comment #5 from David Malcolm  ---
Thanks, am testing your patch now.

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #4 from Jan Hubicka  ---
The change makes loop iteration estimates more realistics, but does not
introduce any new code that actually changes the IL, so it seems this makes
existing problem more visible.  I will try to debug what happens.

[Bug middle-end/112653] PTA should handle correctly escape information of values returned by a function

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #16 from Thomas Schwinge  ---
By means of facilitating an additional '-Wuninitialized' diagnostic, this
commit r14-5879-gf7884f7673444b8a2c10ea0981d480f2e82dd16a
"tree-optimization/112653 - PTA and return" found a bug in GCC/Rust front end
C++ constructor code: see 
"`Block.Rust::AST::ExprWithoutBlock::Rust::AST::Expr.Rust::AST::Expr::node_id’
is used uninitialized [-Werror=uninitialized]`".  :-)

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #3 from Jakub Jelinek  ---
Loooking at pr90716.c, that case seems like a clear wrong-debug.
Before r14-162 j was  everywhere, "j\0" DW_TAG_variable didn't
have any DW_AT_location/DW_AT_const_value, optimized dump doesn't show any
DEBUG stmts for j nor any references to it, etc.
With r14-162 and later the DW_TAG_variable has DW_AT_const_value 0, which is
wrong,
if anything it should have DW_AT_const_value 8.
Optimized dump difference is
--- pr90716.c.254t.optimized_   2024-03-19 10:23:03.688427714 -0400
+++ pr90716.c.254t.optimized2024-03-19 10:23:39.351797960 -0400
@@ -18,19 +18,20 @@ void optimize_me_not ()
 int main ()
 {
[local count: 17041817]:
   # DEBUG BEGIN_STMT
   # DEBUG BEGIN_STMT
   # DEBUG b => 0
   # DEBUG BEGIN_STMT
   # DEBUG b => 0
   # DEBUG BEGIN_STMT
   __builtin_memset (, 0, 224);
-  # DEBUG b => NULL
+  # DEBUG j => 0
+  # DEBUG b => 0
   # DEBUG BEGIN_STMT
   optimize_me_not ();
   # DEBUG BEGIN_STMT
   return 0;

 }
Clearly even the b value is wrong, that again should be either 8 or NULL after
the loops.
Before ch2 pass, the IL is the same with r14-161 and r14-162:
   [local count: 17041817]:
  # DEBUG b => 0
  goto ; [100.00%]

   [local count: 954449105]:
  a[b_1][j_2] = 0;
  j_9 = j_2 + 1;
  # DEBUG j => j_9

   [local count: 1073741824]:
  # j_2 = PHI <0(8), j_9(3)>
  # DEBUG j => j_2
  if (j_2 != 8)
goto ; [88.89%]
  else
goto ; [11.11%]

   [local count: 119292720]:
  b_7 = b_1 + 1;
  # DEBUG b => b_7

   [local count: 136334537]:
  # b_1 = PHI <0(2), b_7(5)>
  # DEBUG b => b_1
  if (b_1 != 7)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 119292720]:
  goto ; [100.00%]

   [local count: 17041817]:
  optimize_me_not ();
  return 0;
but ch2 changes the IL (r14-161 vs. r14-162): 
--- pr90716.c.126t.ch2_ 2024-03-19 11:20:14.311013575 -0400
+++ pr90716.c.126t.ch2  2024-03-19 11:20:18.879061929 -0400
@@ -72,44 +72,44 @@ Removing basic block 12
 int main ()
 {
   int j;
   int b;

[local count: 17041817]:
   # DEBUG b => 0
   # DEBUG b => 0
   goto ; [100.00%]

[local count: 954449105]:
   # j_15 = PHI 
-  # DEBUG j => j_15
   a[b_14][j_15] = 0;
   j_9 = j_15 + 1;
   # DEBUG j => j_9
   # DEBUG j => j_9
   if (j_9 != 8)
 goto ; [88.89%]
   else
 goto ; [11.11%]

[local count: 119292720]:
+  # DEBUG j => 0
   b_7 = b_14 + 1;
   # DEBUG b => b_7
   # DEBUG b => b_7
   if (b_7 != 7)
 goto ; [87.50%]
   else
 goto ; [12.50%]

[local count: 119292720]:
   # b_14 = PHI 
-  # DEBUG b => b_14
   # DEBUG j => 0
   goto ; [100.00%]

[local count: 17041817]:
+  # DEBUG b => 0
   optimize_me_not ();
   return 0;

 }
The changes in r14-162 feel highly undesirable for debug info.

[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:16afbd9c9c4282d56062cef95e6eccfdcf3efe03

commit r14-9545-g16afbd9c9c4282d56062cef95e6eccfdcf3efe03
Author: Jonathan Wakely 
Date:   Mon Mar 18 13:00:17 2024 +

libstdc++: Begin lifetime of storage in std::vector [PR114367]

This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.

This change uses the allocator's construct function instead of using
std::construct_at directly, in order to support fancy pointers.

libstdc++-v3/ChangeLog:

PR libstdc++/114367
* include/bits/stl_bvector.h (_M_allocate): Use allocator's
construct function to begin lifetime of words.

[Bug c++/114395] New: std::is_constructible_v result of const reference incorrect

[yronglin777 at gmail dot com via Gcc-bugs]

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

Bug ID: 114395
   Summary: std::is_constructible_v result of const reference
incorrect
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yronglin777 at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/h5af6f5x9
```
#include 

struct A {
int a;
};
struct B : public A {};

static_assert(!std::is_constructible_v);
static_assert(!std::is_constructible_v);

```
Clang and MSVC accepted this code, but gcc rejected.

```
:8:15: error: static assertion failed
8 | static_assert(!std::is_constructible_v);
  |   ^~
Compiler returned: 1
```

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3 since r13-1268-g8c99e307b20c50

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

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

--- Comment #31 from Richard Biener  ---
diff --git a/gcc/tree-dfa.cc b/gcc/tree-dfa.cc
index cbd3774b21f..1dbd9bd7a00 100644
--- a/gcc/tree-dfa.cc
+++ b/gcc/tree-dfa.cc
@@ -549,7 +549,8 @@ get_ref_base_and_extent (tree exp, poly_int64 *poffset,
/* Try to constrain maxsize with range information.  */
offset_int omax
  = offset_int::from (max, TYPE_SIGN (TREE_TYPE (index)));
-   if (known_lt (lbound, omax))
+   if (wi::get_precision (max) < ADDR_MAX_PRECISION
+   && known_lt (lbound, omax))
  {
poly_offset_int rmaxsize;
rmaxsize = (omax - lbound + 1)
@@ -567,7 +568,8 @@ get_ref_base_and_extent (tree exp, poly_int64 *poffset,
/* Try to adjust bit_offset with range information.  */
offset_int omin
  = offset_int::from (min, TYPE_SIGN (TREE_TYPE (index)));
-   if (known_le (lbound, omin))
+   if (wi::get_precision (min) < ADDR_MAX_PRECISION
+   && known_le (lbound, omin))
  {
poly_offset_int woffset
  = wi::sext (omin - lbound,


fixes the testcase but I'm not 100% sure the condition is correct.  We
possibly need to cover for the << LOG2_BITS_PER_UNIT done, so maybe
using ADDR_MAX_BITSIZE is better.  I'm going to test a variant with
using <= ADDR_MAX_BITSIZE.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3 since r13-1268-g8c99e307b20c50

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #30 from Richard Biener  ---
It's LIM2 which applies store-motion to m[0] but keeps m[p] in the loop.
Then with range-info for the int128 of [0, +INF] we get into
get_ref_base_and_extent:

query = get_range_query (cfun);

if (TREE_CODE (index) == SSA_NAME
&& (low_bound = array_ref_low_bound (exp),
poly_int_tree_p (low_bound))
&& (unit_size = array_ref_element_size (exp),
TREE_CODE (unit_size) == INTEGER_CST)
&& query->range_of_expr (vr, index)
&& !vr.varying_p ()
&& !vr.undefined_p ())
  {
wide_int min = vr.lower_bound ();
wide_int max = vr.upper_bound ();
poly_offset_int lbound = wi::to_poly_offset (low_bound);
/* Try to constrain maxsize with range information.  */
offset_int omax
  = offset_int::from (max, TYPE_SIGN (TREE_TYPE (index)));
if (known_lt (lbound, omax))
  {
poly_offset_int rmaxsize;
rmaxsize = (omax - lbound + 1)
* wi::to_offset (unit_size) << LOG2_BITS_PER_UNIT;
if (!known_size_p (maxsize)
|| known_lt (rmaxsize, maxsize))

and compute rmaxsize == 0.

What's definitely questionable here is the offset_int::from, though it
fits.  But omax - lbound + 1 overflows to zero here.  It's probably
better to use widest-int here, even if that's possibly slower than
offset_int.  Or ensure offset_int has one more bit than required for
the index type (offset_int has 64bit + 3bits, so 128bits).

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
ipa-sra-1.c has been adjusted since in r14-8997
Comparing current trunk vs. current 13 branch, I see in guality:
-XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
-XPASS: gcc.dg/guality/ipa-sra-1.c   -O0  line 15 k == 3
-XPASS: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 15 k ==
3
-XPASS: gcc.dg/guality/ipa-sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 15 k == 3
-FAIL: gcc.dg/guality/pr41616-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
-FAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
-FAIL: gcc.dg/guality/pr41616-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution
test
-FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 34 c ==
[0]
-FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 39 c ==
[0]
+FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 34 c ==
[0]
+FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 39 c ==
[0]
-FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
-FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
-FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i
+FAIL: gcc.dg/guality/pr54693-2.c   -O1  -DPREVENT_OPTIMIZATION  line 21 i == v
+ 1
+FAIL: gcc.dg/guality/pr54693-2.c   -O2  -DPREVENT_OPTIMIZATION  line 21 i == v
+ 1
+FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 21 i == v + 1
+FAIL: gcc.dg/guality/pr54693-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 21 i
== v + 1
+FAIL: gcc.dg/guality/pr54693.c   -O1  -DPREVENT_OPTIMIZATION  line 22 i == c -
48
+FAIL: gcc.dg/guality/pr54693.c   -O2  -DPREVENT_OPTIMIZATION  line 22 i == c -
48
+FAIL: gcc.dg/guality/pr54693.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 22 i == c - 48
+FAIL: gcc.dg/guality/pr54693.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 22 i == c - 48
+FAIL: gcc.dg/guality/pr54693.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 22 i ==
c - 48
+FAIL: gcc.dg/guality/pr54693.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 22 i ==
c - 48
+FAIL: gcc.dg/guality/pr54693.c   -Os  -DPREVENT_OPTIMIZATION  line 22 i == c -
48
+FAIL: gcc.dg/guality/pr89463.c   -O1  -DPREVENT_OPTIMIZATION  line 23 i + 1 ==
7
+FAIL: gcc.dg/guality/pr90074.c   -O1  -DPREVENT_OPTIMIZATION  line 28 c + 1 ==
2
+FAIL: gcc.dg/guality/pr90074.c   -O1  -DPREVENT_OPTIMIZATION  line 28 i + 1 ==
8
+FAIL: gcc.dg/guality/pr90716.c   -O1  -DPREVENT_OPTIMIZATION  line 23 j + 1 ==
9
+FAIL: gcc.dg/guality/pr90716.c   -O2  -DPREVENT_OPTIMIZATION  line 23 j + 1 ==
9
+FAIL: gcc.dg/guality/pr90716.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  -DPREVENT_OPTIMIZATION line 23 j + 1 == 9
+FAIL: gcc.dg/guality/pr90716.c   -Os  -DPREVENT_OPTIMIZATION  line 23 j + 1 ==
9
+FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 17 sizeof (a) == 6
where ipa-sra-1.c changes are because r14-8997 intentionally tweaked the
expectations for -O0/-O1/-Og.

[Bug libstdc++/114394] std::bind uses std::result_of which is deprecated

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2024-03-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Jonathan Wakely  ---
Oh I see it's just a suggested change not a complete patch anyway. I'll take
care of this then. Thanks for the suggested patch at least :)

[Bug libstdc++/114394] std::bind uses std::result_of which is deprecated

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

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

--- Comment #1 from Jonathan Wakely  ---
Patches need to be sent to the mailing list not attached in bugzilla.

The patch is wrong though, it needs to use _Fn& as an lvalue, not an rvalue.

[Bug libstdc++/114394] New: std::bind uses std::result_of which is deprecated

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Bug ID: 114394
   Summary: std::bind uses std::result_of which is deprecated
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Created attachment 57738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57738=edit
Tentative patch

Hi,

Clang >= 18 now prints a valid deprecation warning with this snippet:

#include 

void f();

void g()
{
std::function a = std::bind();
}


Warning:
In file included from :1:
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/functional:552:2:
warning: 'result_of' is deprecated: use 'std::invoke_result'
instead [-Wdeprecated-declarations]
  552 | using _Res_type_impl
  | ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/functional:556:2:
note: in instantiation of template type alias '_Res_type_impl' requested here
  556 | using _Res_type = _Res_type_impl<_Functor, _CallArgs,
_Bound_args...>;
  | ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/functional:586:28:
note: in instantiation of template type alias '_Res_type' requested here
  586 |typename _Result = _Res_type>>
  |   ^
:7:31: note: in instantiation of template class 'std::_Bind' requested here
7 | std::function a = std::bind();
  |   ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/type_traits:2590:9:
note: 'result_of' has been explicitly marked deprecated here
 2590 | { } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result");
  | ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-linux-gnu/bits/c++config.h:122:45:
note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST'
  122 | # define _GLIBCXX17_DEPRECATED_SUGGEST(ALT)
_GLIBCXX_DEPRECATED_SUGGEST(ALT)
  | ^
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-linux-gnu/bits/c++config.h:98:19:
note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
   98 |   __attribute__ ((__deprecated__ ("use '" ALT "' instead")))
  |   ^
1 warning generated.
Compiler returned: 0


(see on Compiler Explorer: https://godbolt.org/z/3jxGr77Ye).

I tried very quickly the attached patch, which seems to fix the warning for me
(however I didn't really test it, so maybe it's not correct).

Note: I guess the fix will qualify for a backport in releases branches, in my
case I have hit this with gcc 13.

[Bug tree-optimization/113727] [14 Regression] csmith: differences from nothing to -O1 since r14-4612-g6decda1a35be57

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

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

--- Comment #23 from Richard Biener  ---
Note with the 2nd patch it's still broken when the BIT_FIELD_REFs in the IL are
not byte aligned.

Both patches passed bootstrap & regtest, there is unknown effect on
optimization of __imag / __real.

Looking at such an example we see

  _1 = x.f;
  s$f = _1;
  REALPART_EXPR  = 1.0e+0;
  _7 = s$f;
  s.f = _7;
  bar (s);

so while we don't "handle" REALPART_EXPR we assume its base is fully
replaced.  For the BIT_FIELD_REF case we cannot know any such thing.

Ah, and the fix is a bit wrong I guess.  It should be

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8e71ec48b9..f8176de817f 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -2358,6 +2358,12 @@ sort_and_splice_var_accesses (tree var)
  j++;
}

+  /* When there is a partial LHS involved we have no way to see what it
+accesses, so if it's not the only access to the subregion
+we have to fail.  */
+  if (grp_partial_lhs && j != i + 1)
+   return NULL;
+
   i = j;

   access->group_representative = access;

and that indeed does disable SRA for

struct S { _Complex float f; } x;

void bar (struct S);

float foo ()
{
  struct S s;
  s.f = x.f;
  __real s.f = 1.f;
  bar (s);
  float x = __real s.f;
  return x;
}

so maybe grp_partial_lhs isn't supposed to handle the BIT_FIELD_REF case
in question but only handles the case where there's a sub-access in its
base?

I suppose it simply wasn't designed to handle mixed accesses.

Maybe the problem is that SRA fails to see that for a ->grp_partial_lhs
access we _have_ to do a replacement.  For the testcase in this PR the
access is 'as' itself and we create a replacement for as.au and as.f3
but then we have overlapping replacements (with the covering 'as').

The following fixes that, but maybe not in the correct place:

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8e71ec48b9..dbfae5e7fdd 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -2735,7 +2735,8 @@ analyze_access_subtree (struct access *root, struct
access *parent,
 {
   hole |= covered_to < child->offset;
   sth_created |= analyze_access_subtree (child, root,
-allow_replacements && !scalar,
+allow_replacements && !scalar
+&& !root->grp_partial_lhs,
 totally);

   root->grp_unscalarized_data |= child->grp_unscalarized_data;

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #9 from Xi Ruoyao  ---
(In reply to Antoni from comment #8)
> Created attachment 57726 [details]
> Reproducer using union
> 
> I tried switching to a union and I still get the same error.
> 
> A union is used by std::optional, so I would assume that this should work.
> Or is copying uninitialized memory via a union also UB?

Yes.

std::optional copy constructor is not a default copy constructor.  It does not
copy if the input is nullopt.

[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/114286] ICE: in deref_rvalue, at analyzer/region-model.cc:2762 with _Atomic _BitInt() and -fanalyzer

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-9544-gc7a774edbf802d79b95871ede5b80f6e9adf8e88
Author: David Malcolm 
Date:   Tue Mar 19 09:06:45 2024 -0400

analyzer: fixes to __atomic_{exchange,load,store} [PR114286]

In r14-1497-gef768035ae8090 I added some support to the analyzer for
__atomic_ builtins (enough to fix false positives I was seeing in
my integration tests).

Unfortunately I messed up the implementation of
__atomic_{exchange,load,store}, leading to ICEs seen in
PR analyzer/114286.

Fixed thusly, fixing the ICEs.  Given that we're in stage 4, the patch
doesn't add support for any of the various __atomic_compare_exchange
builtins, so that these continue to fall back to the analyzer's
"anything could happen" handling of unknown functions.

Signed-off-by: David Malcolm 

gcc/analyzer/ChangeLog:
PR analyzer/114286
* kf.cc (class kf_atomic_exchange): Reimplement based on signature
seen in gimple, rather than user-facing signature.
(class kf_atomic_load): Likewise.
(class kf_atomic_store): New.
(register_atomic_builtins): Register kf_atomic_store.

gcc/testsuite/ChangeLog:
PR analyzer/114286
* c-c++-common/analyzer/atomic-builtins-pr114286.c: New test.

Signed-off-by: David Malcolm 

[Bug middle-end/114391] catch() and immediate throw; could be optimized to noop

[antoshkka at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Antony Polukhin  ---
> Is there something to optimize when foo() cannot be tail-called?

Yes. Just `catch (...) { throw; }`, no more restrictions. I do not even think,
that it should be the outer most EH region:


void foo();
void bar();

void test() {
try {
foo();
} catch (...) {
throw;
}
bar();
}


is fine to optimize to just


void test() {
foo();
bar();
}

[Bug rtl-optimization/113390] [14 Regression] ICE: in model_update_limit_points_in_group, at haifa-sched.cc:1986 with -O2 --param=max-sched-region-insns=200 --param=max-sched-extend-regions-iters=2

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

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

--- Comment #4 from Jeffrey A. Law  ---
Made it a P1 simply because it was likely not RISC-V specific ICE.  I don't
think we're at a point where it makes sense for RISC-V to be a primary
platform, though hopefully that'll change in the relatively near future.