[Bug c++/110851] New: [contracts] Inheriting multiple base functions with clashing contracts is not diagnosed

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

Bug ID: 110851
   Summary: [contracts] Inheriting multiple base functions with
clashing contracts is not diagnosed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

See https://wandbox.org/permlink/SICxkVAe2gVql3Ae

tl;dr:

struct Base1  {
  virtual void g(int x) [[ pre : x > 0 ]] {}
};
struct Base2  {
  virtual void g(int x) [[ pre : x <= 0 ]] {}
};

struct Derived : public Base1, public Base2 {
  virtual void g(int x) override {}
};

int main()
{
Derived d1;
Base1& b1 = d1;
Base2& b2 = d1;
b1.g(42);
//b2.g(-42);
}

The various online compilers accept and run the code. On my machine, I get an
assembler diagnostic:
/tmp/ccYlVuY9.s: Assembler messages:
/tmp/ccYlVuY9.s:53: Error: symbol `_ZN7Derived1gEi' is already defined

which is saying that Derived::g(int)
is already defined.

The declaration of Derived::g() ought to be ill-formed, because the base
functions do not have the same list of contracts.

[Bug tree-optimization/110852] New: [14 Regression] ICE: in get_predictor_value, at predict.cc:2695 with -O -fno-tree-fre and __builtin_expect()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 110852
   Summary: [14 Regression] ICE: in get_predictor_value, at
predict.cc:2695 with -O -fno-tree-fre and
__builtin_expect()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-fre testcase.c
during GIMPLE pass: profile_estimate
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: in get_predictor_value, at
predict.cc:2695
8 | }
  | ^
0x7c5847 get_predictor_value
/repo/gcc-trunk/gcc/predict.cc:2695
0x7c5847 get_predictor_value
/repo/gcc-trunk/gcc/predict.cc:2686
0x13687d0 tree_predict_by_opcode
/repo/gcc-trunk/gcc/predict.cc:2750
0x13687d0 tree_estimate_probability_bb
/repo/gcc-trunk/gcc/predict.cc:3131
0x1374a19 tree_estimate_probability(bool)
/repo/gcc-trunk/gcc/predict.cc:3161
0x1374fb5 execute
/repo/gcc-trunk/gcc/predict.cc:4133
0x1374fb5 execute
/repo/gcc-trunk/gcc/predict.cc:4118
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ 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-2866-20230729170758-ge68a31549d9-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-2866-20230729170758-ge68a31549d9-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230729 (experimental) (GCC)

[Bug target/106222] x86 Better code squence for __builtin_shuffle

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||roger at nextmovesoftware dot 
com
   Target Milestone|--- |13.0

--- Comment #3 from Roger Sayle  ---
This was fixed by Hongtao's patch for GCC 13.

[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #8 from paul.richard.thomas at gmail dot com  ---
Hi Harald,

I have just returned from a trip to the General Atomics DIIID facility
in San Diego and feel like death warmed up :-(

I'll try to get to the backport this afternoon once I have unpacked
and had a nap.

Regards

Paul

On Sat, 29 Jul 2023 at 21:18, anlauf at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed |Added
> 
>  CC||anlauf at gcc dot gnu.org
>
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #6)
> > I will backport to 13-branch in a few weeks.
>
> Could you please ping me after the backport?
>
> I would like to backport the fix for pr110825 and avoid a merge conflict,
> as the changes are adjacent.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.

[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Sergey Fedorov  ---
Any update on this?

[Bug sanitizer/98608] missing sanitizer detection for arrays with invalid length defind using typeof

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #2 from Martin Uecker  ---

The problem is actually the missing sanitizer instrumentation of the parameter
type. This is easy to fix, but then I run into the problem that a lot of code
has n == 0 in parameters. Having an option to avoid the instrumentation
(PR98609) might help.

[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Sergey Fedorov  ---
(In reply to Eric Gallager from comment #8)

> I'd need to rebuild gcc with debug info to get a better backtrace.

Have you been able to?

[Bug sanitizer/98609] sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #9 from Martin Uecker  ---

I just ran into this problem again while trying to fix PR98608 where the
problem is that instrumentation of parameters is missing.  In parameters people
often use n == 0 null and some of the -Wnonnull warnings we have currently even
require setting it 0.

[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|*-*-darwin  |powerpc-*-darwin,
   ||i686-*-darwin

--- Comment #15 from Iain Sandoe  ---
(In reply to Sergey Fedorov from comment #14)
> (In reply to Eric Gallager from comment #8)

With current trunk on a cross to powerpc-apple-darwin9 this reproduces for the
runtime ABI 01 - which is used on 32b Darwin. (i.e the code compiles fine for
'-m64')

A guess would be that we have a conflict between C++ exception handling (DWARF
unwinding) and runtime-abi-01 exception handling (set jump / long jump). 
Probably, there needs to be some way to flag which kind of exception is
present.

For runtime ABI 02 (64bit) this should not happen - so the only really affected
targets are 32b powerpc and i686 Darwin.

= backtrace for curent trunk:

  * frame #0: 0x0001021b78a5 cc1objplus`internal_error(gmsgid="in %s, at
%s:%d") at diagnostic.cc:2166:25
frame #1: 0x0001021b7d8b
cc1objplus`fancy_abort(file="/src-local/gcc-master/gcc/objc/objc-next-runtime-abi-01.cc",
line=2795, function="objc_eh_runtime_type") at diagnostic.cc:2296:18
frame #2: 0x00010003dab7
cc1objplus`::objc_eh_runtime_type(type=0x00011401c5e8) at
objc-next-runtime-abi-01.cc:2795:3
frame #3: 0x0001011501ad
cc1objplus`add_type_for_runtime(type=0x00011401c5e8) at except.cc:683:40
frame #4: 0x00010114f8c4
cc1objplus`gen_eh_region_catch(t=0x000117c3b318,
type_or_list=0x00011401c5e8) at except.cc:424:23
frame #5: 0x000101a400bb
cc1objplus`::lower_catch(state=0x000309267190, tp=0x00014813f690) at
tree-eh.cc:1815:31
frame #6: 0x000101a40cfe
cc1objplus`::lower_eh_constructs_2(state=0x000309267190,
gsi=0x000309267140) at tree-eh.cc:2107:27
frame #7: 0x000101a40e17
cc1objplus`::lower_eh_constructs_1(state=0x000309267190,
pseq=0x000309267188) at tree-eh.cc:2153:27
frame #8: 0x000101a40f46
cc1objplus`pass_lower_eh::execute(this=0x6260c540,
fun=0x0001480e8678) const at tree-eh.cc:2198:25
frame #9: 0x0001017b5131
cc1objplus`execute_one_pass(pass=0x6260c540) at passes.cc:2641:30
frame #10: 0x0001017b5570
cc1objplus`::execute_pass_list_1(pass=0x6260c540) at passes.cc:2750:28
frame #11: 0x0001017b5607
cc1objplus`execute_pass_list(fn=0x0001480e8678, pass=0x6260c240) at
passes.cc:2761:23
frame #12: 0x000100fe00c4
cc1objplus`cgraph_node::analyze(this=0x000148128990) at
cgraphunit.cc:694:22
frame #13: 0x000100fe23d1
cc1objplus`::analyze_functions(first_time=true) at cgraphunit.cc:1247:18
frame #14: 0x000100fe5ed4
cc1objplus`symbol_table::finalize_compilation_unit(this=0x000114006000) at
cgraphunit.cc:2554:21
frame #15: 0x000101987ad5 cc1objplus`::compile_file() at
toplev.cc:471:41
frame #16: 0x00010198b4f0 cc1objplus`::do_compile(no_backend=false) at
toplev.cc:2126:24
frame #17: 0x00010198ba34
cc1objplus`toplev::main(this=0x00030926751a, argc=16,
argv=0x000309267668) at toplev.cc:2282:18
frame #18: 0x000102187a64 cc1objplus`main(argc=16,
argv=0x000309267668) at main.cc:39:23

[Bug rtl-optimization/110823] [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
It's a weakness in the REE pass. AFAICT normally it would handle this, but here
there are two elimination candidates in 'main', the first is eliminated
successfully, and then REE punts on the second because one if its reaching
definitions is the first redundant extension:

  /* If def_insn is already scheduled to be deleted, don't attempt
 to modify it.  */
  if (state->modified[INSN_UID (def_insn)].deleted)
return false;

While looking into this I noticed that the fix for PR 61094 introduced a
write-only bitfield 'do_not_reextend' (the Changelog wrongly claimed it was
used).

[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #15)

Would be nice to have it fixed, otherwise `jack` is broken:
https://github.com/jackaudio/jack2/issues/950
Which, in turn, leaves broken dependencies.

[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER

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

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

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

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

commit r13-7654-g1a322145aa60a65bed064fbb5514a193a27bd86f
Author: Paul Thomas 
Date:   Sun Jul 30 13:25:19 2023 +0100

Fortran: Seg fault passing string to type cptr dummy [PR108961].

2023-07-30  Paul Thomas  

gcc/fortran
PR fortran/108961
* trans-expr.cc (gfc_conv_procedure_call): The hidden string
length must not be passed to a formal arg of type(cptr).

gcc/testsuite/
PR fortran/108961
* gfortran.dg/pr108961.f90: New test.

[Bug tree-optimization/110280] [13 Regression] internal compiler error: in const_unop, at fold-const.cc:1884

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

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

--- Comment #16 from Sam James  ---
Prathamesh, could you cherry-pick this on to the releases/13 branch please?

[Bug c++/110853] New: [c++-concepts] Bad interaction between deduction guide with decay and constraints

[daniel.kruegler at googlemail dot com via Gcc-bugs]

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

Bug ID: 110853
   Summary: [c++-concepts] Bad interaction between deduction guide
with decay and constraints
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com
  Target Milestone: ---

The following simplified code snippet demonstrates a breakage our company code
when updating gcc from C++17 to C++20. I'm starting first with the original
example, because it provides a bit more context information:


#include 

void value_twice(int& result)
{
  result = 2 * result;
}

auto key_value_gen()
{
  return std::pair("key", value_twice);
}

int main()
{
}


Using gcc HEAD 14.0.0 20230728 and compiled with the previous settings
-Wall -Wextra -pedantic -std=c++17
the code is accepted, but switching to
-Wall -Wextra -pedantic -std=c++20
it becomes rejected with the following diagnostics:


In file included from /opt/wandbox/gcc-head/include/c++/14.0.0/utility:69,
 from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/14.0.0/bits/stl_pair.h: In instantiation of
'struct std::pair':
/opt/wandbox/gcc-head/include/c++/14.0.0/bits/stl_pair.h:307:57:   required by
substitution of 'template pair(const _T1&, const _T2&)->
std::pair<_T1, _T2> requires (std::pair<_T1, _T2>::_S_constructible)() [with _T1 = char [4]; _T2 = void(int&)]'
prog.cc:10:38:   required from here
/opt/wandbox/gcc-head/include/c++/14.0.0/bits/stl_pair.h:194:11: error: data
member 'std::pair::second' invalidly declared function
type
  194 |   _T2 second;///< The second member
  |   ^~

Note that std::pair has a "decaying" deduction guide

template
pair(T1, T2) -> pair;

but the error message reveals that attempts the produce a std::pair of the
undecayed types.

Additional information:
a) Current MSVC accepts the code but clang also rejects it but for different
reasons than gcc (see below).
b) I'm aware that a simple workaround exists by returning std::pair("key",
&value_twice) instead, and this is what we did to fix this. Nonetheless I think
that not everyone is able to fix such a problem in similar code when it was
provided by thirdparty libraries.

Basically the same error occurs when we use std::tuple(value_twice) instead.

The C++20 std::pair implementation uses noexcept, conditional explicit, and
trailing requires-clause based on static member functions as predicates, but
for gcc the problem can be reduced to the trailing requires-clause alone:

--
#define WITH_FUNC 1

template
constexpr bool is_copy_constructible_v = true;

template
struct p
{
  T1 first;

  static constexpr bool do_is_copy_constructible()
  {
return true;
  }

  p(const T1& t1) 
 requires (
#if WITH_FUNC
  do_is_copy_constructible()  // Line 19
#else
  is_copy_constructible_v
#endif
 )
  : first(t1) 
{}
};

template
p(T1) -> p;

void value_twice(int& result)
{
  result = 2 * result;
}

auto value_gen()
{
  return p(value_twice); // line 38
}

int main() {}
--

If we define WITH_FUNC to 0, the code is accepted, otherwise (as shown above),
the code is rejected with:

--
prog.cc: In instantiation of 'struct p':
prog.cc:19:31:   required by substitution of 'template p(const T1&)->
p requires (p::do_is_copy_constructible)() [with T1 = void(int&)]'
prog.cc:38:23:   required from here
prog.cc:9:6: error: data member 'p::first' invalidly declared
function type
9 |   T1 first;
  |  ^
--

Note that clang does accept the reduced case, even though it rejects the
original example as well due to slightly different reasons, which I will report
separately to them.

The reduced case uses the same implementation strategy as libstdc++ by means of
a static member function. What's special here is that the body of such a
function is a complete-class context of p, which I guess causes the error here
because the trailing requires-clause is not a complete-class context of p, so
one could say that this is actually a libstdc++ defect to use this
implementation strategy, it seems odd to me that the compiler attempts to
instantiate p with the undecayed function here and would like to open this
initially as compiler defect since the corresponding function does not actually
depend on p being complete. Feel free to correct me, but in case of a
correction of my understanding I would like to change this to a libstdc++ issue
instead of closing it because that would mean that libstdc++ cannot use there
static member function predicate approach (A f

[Bug middle-end/110115] Wrong code at -O1 on x86_64-linux-gnu

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

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

--- Comment #5 from Shaohua Li  ---
I tried to bisect this case and I bisected it to r0-2686-gd119f34c952

[Bug middle-end/110141] Wrong code at -O2 on x86_64-linux-gnu

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

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

--- Comment #2 from Shaohua Li  ---
I tried to bisect this case and I bisected it to r12-4790-g4b3a325f07a

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #8 from Shaohua Li  ---
I tried to bisect it and I bisected it to r12-4871-g502ffb1f389

[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #6 from Shaohua Li  ---
I tried to bisect it and it was bisected to r13-3875-g9e11ceef165

[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu

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

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

--- Comment #5 from Shaohua Li  ---
Bisect to r14-1179-g1cd5bc387c4

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #9 from Sam James  ---
(In reply to Shaohua Li from comment #8)
> I tried to bisect it and I bisected it to r12-4871-g502ffb1f389

Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
fine with that?

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #10 from Sam James  ---
(In reply to Sam James from comment #9)
> (In reply to Shaohua Li from comment #8)
> > I tried to bisect it and I bisected it to r12-4871-g502ffb1f389
> 
> Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
> fine with that?

sorry: =ranger

[Bug tree-optimization/110640] [13/14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13

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

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

--- Comment #5 from Shaohua Li  ---
Bisect to r12-1653-gcb448ade74d

[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023

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

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

--- Comment #2 from Shaohua Li  ---
Bisect to r14-2230-g7e904d6c7f2

[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

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

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

--- Comment #3 from Shaohua Li  ---
Bisect to r13-550-gebce0e9bd8d

[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023

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

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

--- Comment #3 from Shaohua Li  ---
I tried to bisect it and it was bisected to r14-2674-gd0de3bf9175, which is
different from the bisection point in bug110641

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #11 from Shaohua Li  ---
(In reply to Sam James from comment #10)
> (In reply to Sam James from comment #9)
> > (In reply to Shaohua Li from comment #8)
> > > I tried to bisect it and I bisected it to r12-4871-g502ffb1f389
> > 
> > Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
> > fine with that?
> 
> sorry: =ranger

Could you make it clear which parameters I should try? Thanks.

[Bug fortran/110825] TYPE(*) dummy argument to generate an unused hidden argument

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

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

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

https://gcc.gnu.org/g:63d18dffeb34e58a8ef79ca614f854e055355043

commit r13-7656-g63d18dffeb34e58a8ef79ca614f854e055355043
Author: Harald Anlauf 
Date:   Thu Jul 27 21:30:26 2023 +0200

Fortran: do not pass hidden character length for TYPE(*) dummy [PR110825]

gcc/fortran/ChangeLog:

PR fortran/110825
* gfortran.texi: Clarify argument passing convention.
* trans-expr.cc (gfc_conv_procedure_call): Do not pass the
character
length as hidden argument when the declared dummy argument is
assumed-type.

gcc/testsuite/ChangeLog:

PR fortran/110825
* gfortran.dg/assumed_type_18.f90: New test.

(cherry picked from commit 02f4ca0df2d69b922a622e7cc9b396cf686d5a0f)

[Bug target/110787] [14 regression] ICE building SYSTEM.def

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

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

--- Comment #7 from Gaius Mulley  ---
Many thanks for the fix!  modula-2 bootstraps successfully on x86_32.

gcc/m2/gm2-libs/SYSTEM.mod implements arbitrary sized rotates and shifts for
the runtime (as well as export system specific procedures/types).

gcc/m2/gm2-libs/SYSTEM.mod:{ShiftVal,ShiftLeft,ShiftRight} and
gcc/m2/gm2-libs/SYSTEM.mod:{RotateVal,RotateLeft,RotateRight} for example.

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

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

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

--- Comment #17 from Mikael Morin  ---
Created attachment 55660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55660&action=edit
Update function type patch

This patch changes the dummy argument declaration type.
It changes the dump as follows.

--- m32/pr110419_comment4.f90.005t.original 2023-07-05 13:05:58.743843174
+
+++ pr110419_comment4.f90.005t.original 2023-07-30 19:31:20.880043687 +
@@ -1,5 +1,5 @@
 __attribute__((fn spec (". r w ")))
-void val (character(kind=1)[1:1] & restrict x, character(kind=1)[1:1] c,
integer(kind=4) _x, integer(kind=4) _c)
+void val (character(kind=1)[1:1] & restrict x, character(kind=1) c,
integer(kind=4) _x, integer(kind=4) _c)
 {
   {
 struct __st_parameter_dt dt_parm.0;
@@ -25,7 +25,7 @@
 _gfortran_transfer_character_write (&dt_parm.1, &c, 1);
 _gfortran_st_write_done (&dt_parm.1);
   }
-  if (c[1]{lb: 1 sz: 1} != (*x)[1]{lb: 1 sz: 1})
+  if ((*x)[1]{lb: 1 sz: 1} != c)
 {
   _gfortran_stop_numeric (1, 0);
 }
@@ -36,7 +36,7 @@
 __attribute__((fn spec (". ")))
 void p ()
 {
-  static void val (character(kind=1)[1:1] & restrict, character(kind=1)[1:1],
integer(kind=4), integer(kind=4));
+  static void val (character(kind=1)[1:1] & restrict, character(kind=1),
integer(kind=4), integer(kind=4));
   static integer(kind=4) a = 65;

   {

It seems to fix comment #4 (both 32 and 64 bits).

[Bug tree-optimization/110852] [14 Regression] ICE: in get_predictor_value, at predict.cc:2695 with -O -fno-tree-fre and __builtin_expect()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug ipa/110753] [14 Regression] ICE in meet_with_1, at ipa-cp.cc:1057

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

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

--- Comment #2 from Shaohua Li  ---
Bisect to r14-2379-gc496d15954c, which was committed by @al...@redhat.com

[Bug modula2/110631] Bug in FIO.WriteCardinal

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Gaius Mulley
:

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

commit r13-7658-gd1611c51dd7ce054eceb19fda3be72c2164aaa71
Author: Gaius Mulley 
Date:   Sun Jul 30 21:44:49 2023 +0100

PR modula2/110631 Bugfix to FIO WriteCardinal

FIO.WriteCardinal fails to write binary data.  This patch fixes two
bugs in FIO.mod and provides a testcase which writes and reads binary
cardinals.  There was an off by one error when using HIGH (a) to
determine the number of bytes and the dest/src pointers were switched
when calling memcpy.

gcc/m2/ChangeLog:

PR modula2/110631
* gm2-libs/FIO.def (ReadAny): Correct comment as
HIGH (a) + 1 is number of bytes.
(WriteAny): Correct comment as HIGH (a) + 1 is number of
bytes.
* gm2-libs/FIO.mod (ReadAny): Correct comment as
HIGH (a) + 1 is number of bytes.  Also pass HIGH (a) + 1
to BufferedRead.
(WriteAny): Correct comment as HIGH (a) + 1 is number of
bytes.  Also pass HIGH (a) + 1 to BufferedWrite.
(BufferedWrite): Rename parameter a to src, rename variable
t to dest.  Correct parameter order to memcpy.

gcc/testsuite/ChangeLog:

PR modula2/110631
* gm2/pimlib/run/pass/testfiobinary.mod: New test.

(cherry picked from commit 73cc6ce1294ec35e9322b1bbc91009cfc76f732b)

Signed-off-by: Gaius Mulley 

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #37 from anlauf at gcc dot gnu.org ---
Created attachment 55661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55661&action=edit
Tentative patch for the bind(c) case

The attached lightly-tested patch tries to fix (at least at the technical
level) the issues exhibited in comment#33 for the calls to val_c.
On x86 (LE) it fixes the 3rd case by dereferencing the temporary.

For BE platforms it apparently used to work for the character literal only
because it was internally converted to an integer(kind=1), so the patch
now tries to achieve that for the other two cases.

I am not too happy about the actual patch, because I do not yet see how
to cleanly adapt it to the non-bind(c) case (val).  But understanding the
val_c case might be key to proceeding.

BTW: the patch fixes a minor memleak in conv_scalar_char_value.

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> What is interesting is I tested with the patches I have for PR 106164 which
> should fix this but does not. If I try it out manually forwprop does catch
> it so I need to figure out what is going wrong in phiopt4.

Oh I missed it was a pointer type. So I have a patch ...

[Bug modula2/110174] Using illegal constraints for builtin return_address gives ICE

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Gaius Mulley
:

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

commit r13-7659-gc8024088ccc263833d005afe7df835109db1965b
Author: Gaius Mulley 
Date:   Mon Jul 31 01:05:20 2023 +0100

PR modula2/110174 Bugfixes to M2GenGCC.mod:CodeInline preventing an ICE

This patch calls skip_const_decl before chaining parameter values and
ensures that all strings passed to build_stmt (..., ASM_EXPR, ...) are
nul terminated.  It also improves the accuracy of locations in
function calls and asm statements.

gcc/m2/

PR modula2/110174
* gm2-compiler/M2GCCDeclare.def (PromoteToCString): New procedure
function.
* gm2-compiler/M2GCCDeclare.mod (PromoteToCString): New procedure
function.
* gm2-compiler/M2GenGCC.mod (BuildTreeFromInterface): Call
skip_const_decl before chaining the parameter value.
Use PromoteToCString to ensure the string is nul terminated.
(CodeInline): Remove all parameters and replace with quad.
Use GetQuadOtok to get operand token numbers.
Remove call to DeclareConstant and replace it with
PromoteToCString.
* gm2-compiler/M2Quads.def (BuildInline): Rename into ...
(BuildAsm): ... this.
* gm2-compiler/M2Quads.mod: (BuildInline): Rename into ...
(BuildAsm): ... this.
(BuildAsmElement): Add debugging.
* gm2-compiler/P1Build.bnf: Remove import of BuildInline.
* gm2-compiler/P2Build.bnf: Remove import of BuildInline.
* gm2-compiler/P3Build.bnf: Remove import of BuildInline and
import BuildAsm.
* gm2-compiler/PHBuild.bnf: Remove import of BuildInline.
* gm2-libs-iso/SysClock.mod (foo): Remove.
* gm2-libs/FIO.mod (BufferedRead): Rename parameter a to dest.
Rename variable t to src.
* m2pp.cc (pf): Correct block comment.
(pe): Correct block comment.
(m2pp_asm_expr): New function.
(m2pp_statement): Call m2pp_asm_expr.

gcc/testsuite/

PR modula2/110174
* gm2/pim/pass/program2.mod: Remove import of BuildInline.
* gm2/extensions/asm/fail/extensions-asm-fail.exp: New test.
* gm2/extensions/asm/fail/stressreturn.mod: New test.
* gm2/extensions/asm/pass/extensions-asm-pass.exp: New test.
* gm2/extensions/asm/pass/fooasm.mod: New test.

(cherry picked from commit c4637cbed3f23095b98962b41063380c4ab9eda9)

Signed-off-by: Gaius Mulley 

[Bug modula2/110174] Using illegal constraints for builtin return_address gives ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #5 from Gaius Mulley  ---
Closing now that the patch has been applied to the gcc-13 branch.

[Bug libstdc++/110854] New: constructor of std::counting_semaphore is not constexpr

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 110854
   Summary: constructor of std::counting_semaphore is not
constexpr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

from [thread.sema#lib:counting_semaphore,constructor]:
constexpr explicit counting_semaphore(ptrdiff_t desired);

but this snippet of code won't compile for gcc >= 11.1 with -std=c++20

=
#include 

constinit std::binary_semaphore sem {0};

int main() {}
=
with the following error:
:3:33: error: 'constinit' variable 'sem' does not have a constant
initializer
3 | constinit std::binary_semaphore sem {0};
  | ^~~
:3:39: error: call to non-'constexpr' function
'std::counting_semaphore<__least_max_value>::counting_semaphore(std::ptrdiff_t)
[with long int __least_max_value = 1; std::ptrdiff_t = long int]'
3 | constinit std::binary_semaphore sem {0};
  |   ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20230730/include/c++/14.0.0/semaphore:55:16:
note:
'std::counting_semaphore<__least_max_value>::counting_semaphore(std::ptrdiff_t)
[with long int __least_max_value = 1; std::ptrdiff_t = long int]' declared here
   55 |   explicit counting_semaphore(ptrdiff_t __desired) noexcept
  |^~
Compiler returned: 1

[Bug libstdc++/110854] constructor of std::counting_semaphore is not constexpr

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. It looks like it was missed when it was added.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #11 from Hao Liu  ---
Hi Richard,

That's great! Glad to hear the status. Waiting for the patches to be ready and
upstreamed to trunk.

[Bug middle-end/110832] [14 Regression] 14% capacita -O2 regression between g:9fdbd7d6fa5e0a76 (2023-07-26 01:45) and g:ca912a39cccdd990 (2023-07-27 03:44) on zen3 and core

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #9 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to Richard Biener from comment #6)
> > Do we know whether we could in theory improve the sanitizing by optimization
> > without -funsafe-math-optimizations (I think -fno-trapping-math,
> > -ffinite-math-only -fno-signalling-nans should be a better guard?)?
> 
> Regarding the sanitizing, we can remove all sanitizing MOVQ instructions
> between trapping instructions (IOW, the result of ADDPS is guaranteed to
> have zeros in the high part outside V2SF, so MOVQ is unnecessary in front of
> a follow-up MULPS).
> 
> I think that some instruction back-walking pass on the RTL insn stream would
> be able to identify these unnecessary instructions and remove them.
> 

V2SFmode operand can be produced by direct patterns or SUBREG,
I'm thinking about only sanitizing those V2SFmode operations when there's a
subreg in source operand and make sure every other patterns which set V2SFmode
dest will clear upper bits.(inlucde
mov_internal,vec_concatv2sf_sse4_1,sse_storehps,sse_storehps,*vec_concatv2sf_sse)
for mov_internal, we can just set alternative (v,v) with mode DI, then it
will use vmovq, for other alternatives which set sse_regs, the instructions has
already cleared the upper bits.

For vec_concatv2sf_sse4_1/sse_storehps/sse_storehps/*vec_concatv2sf_sse, we can
change them into define_insn_and_split,  splitting into a V4SF instruction(like
we did for those V2SFmode patterns), and use SUBREG for the dest or explicitly
sanitizing the dest.


BTW looks like *vec_concatv2df_sse4_1 can be merged into *vec_concatv2sf_sse

[Bug target/81904] FMA and addsub instructions

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Richard Biener from comment #2)
> __m128d h(__m128d x, __m128d y, __m128d z){
> __m128d tem = _mm_mul_pd (x,y);
> __m128d tem2 = tem + z;
> __m128d tem3 = tem - z;
> return __builtin_shuffle (tem2, tem3, (__m128i) {0, 3});
> }
> 
> doesn't quite work (the combiner pattern for fmaddsub is missing).  Tried
> {0, 2} as well.
> 
> :
> .LFB5021:
> .cfi_startproc
> vmovapd %xmm0, %xmm3
> vfmsub132pd %xmm1, %xmm2, %xmm0
> vfmadd132pd %xmm1, %xmm2, %xmm3
> vshufpd $2, %xmm0, %xmm3, %xmm0

  tem2_6 = .FMA (x_2(D), y_3(D), z_5(D));
  # DEBUG tem2 => tem2_6
  # DEBUG BEGIN_STMT
  tem3_7 = .FMS (x_2(D), y_3(D), z_5(D));
  # DEBUG tem3 => NULL
  # DEBUG BEGIN_STMT
  _8 = VEC_PERM_EXPR ;

Can it be handled in match.pd? rewrite fmaddsub pattern into vec_merge fma fms
 looks too complex.

Similar for VEC_ADDSUB + MUL -> VEC_FMADDSUB.

[Bug target/81904] FMA and addsub instructions

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Richard Biener from comment #1)
> Hmm, I think the issue is we see
> 
> f (__m128d x, __m128d y, __m128d z)
> {
>   vector(2) double _4;
>   vector(2) double _6;
> 
>[100.00%]:
>   _4 = x_2(D) * y_3(D);
>   _6 = __builtin_ia32_addsubpd (_4, z_5(D)); [tail call]
We can fold the builtin into .VEC_ADDSUB, and optimize MUL + VEC_ADDSUB ->
VEC_FMADDSUB in match.pd?

[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1

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

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

--- Comment #10 from Andrew Pinski  ---
Patches submitted with testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625808.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625807.html