[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

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

--- Comment #32 from Andrew Pinski  ---
(In reply to Florian Weimer from comment #31)
> Will propose a backport to 13 in ~2 weeks.

Any news on the backport? There is aim to release GCC 13.2.0 at the end of
July.

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

[npiggin at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Nicholas Piggin  ---
(In reply to Segher Boessenkool from comment #12)
> > I guess that would be annoying if you couldn't have modifiers on constraints
> 
> There is no such thing as "operand modifiers".  There are *output* modifiers:
> they change how an operand is *printed*, they do not change the operand in
> any
> way, shape, or form.

No I mean like x, y, z for different register pairs, or Pn where n=0..4, eI,
eP, eQ for different immediates.

If they're practically just implemented as another constraint, what is really
the big deal with adding a even/odd GPR pair constraint anyway? You say it's
2^T^N additional constraints. As far as I can tell it turns out to be one extra
constrain, or maybe 2 if you need one that excludes r0. 

> 
> > or a bad algorithm for working them out. Fair enough.
> 
> No idea what you mean here?

If you can't deal well with more constraints.

> 
> > > > or why TI doesn't work but PTI apparently would,
> > > 
> > > Because this is exactly what PTImode is *for*!
> > 
> > Right I accept it is, I meant I just would not have been able to work it out
> > (assuming if PTI was documented it would be "Partial Tetra Integer" and be
> > no more useful than the other P?I type documentation.
> 
> For the rs6000 port, multi-register operands are not restricted to aligned
> register numbers ("even/odd pairs").  (Some other ports do have this).  We
> use
> the existing PTI mode for that (it also can be allocated in GPRs only, never
> in
> VSRs, unlike TImode).
> 
> "Partial" does not have much meaning here.  A minority of ports use partial
> integer words for what they were introduced for originally: modes that are
> smaller than a full register, say, a 24-bit mode when registers are 32 bits.
> 
> We use it as another integer mode that is the same size.  It is unfortunate
> that we still have to resort to such tricks.

Okay that explains it, thank you.

[Bug libstdc++/110602] std::format and friends are accessible without std::

[tchaikov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from kefu chai  ---
hi Andrew,

ahh, i missed that. thank you for pointing this out.

[Bug libstdc++/110602] std::format and friends are accessible without std::

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

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

--- Comment #2 from Andrew Pinski  ---
See https://en.cppreference.com/w/cpp/language/adl for a quick reference on the
subject.

[Bug libstdc++/110602] std::format and friends are accessible without std::

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is how agrument depedent namelookup works.

[Bug libstdc++/110602] New: std::format and friends are accessible without std::

[tchaikov at gmail dot com via Gcc-bugs]

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

Bug ID: 110602
   Summary: std::format and friends are accessible without std::
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tchaikov at gmail dot com
  Target Milestone: ---

following code should not compile as "format_to" should be placed in the "std"
namespace:

8<
#include 

std::string foo() {
std::string ss;
format_to(std::back_inserter(ss), "{}", 1);
return ss;
}

int main() {
return foo().size() != 1;
}
>8

but it compiles with gcc trunk (at the time of writing) and gcc 13.1. with
following command line options:

-std=c++23 -O2 -Wall -Wextra 

or 

-std=c++20 -O2 -Wall -Wextra 

i also tested clang + libstdc++ and clang + libc++. all of these combinations
compiles. see https://godbolt.org/z/GhrxPx7Gz for the reproducer.

i was trying to figure out by inspecting the preprocessed source file and
messing around with a sample code below to see if we somehow opened the std
namespace in format or some files included by it but failed:


std::string foo() {
std::string ss;
auto out = std::back_inserter(ss);
// auto args = make_format_args(1, 2, 3);
// basic_format_string fmt_str{"{} {}"};
auto std_args = std::make_format_args(1, 2, 3);
auto std_wargs = std::make_wformat_args(1, 2, 3);
// does not compile
// auto args = std::make_format_args(1, 2, 3);
// does not compile
// auto wargs = std::make_wformat_args(1, 2, 3);

vformat_to(out, "{} {} {}", std_args);
auto s = vformat("{}", std_args);
format_to(out, "{}", ss);
return ss;
}

it turns out make_format_args and make_wformat_args are still in "std"
namespace, while format, format_to and vformat_to can be accessed with and
without qualified with 'std'

[Bug tree-optimization/110600] [14 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:3a42c79c258f54f5837d2fd54874f8b291a518fc

commit r14-2398-g3a42c79c258f54f5837d2fd54874f8b291a518fc
Author: Jan Hubicka 
Date:   Sat Jul 8 23:47:38 2023 +0200

Add missing profile_dump check

gcc/ChangeLog:

PR tree-optimization/110600
* cfgloopmanip.cc (scale_loop_profile): Add mising profile_dump
check.

gcc/testsuite/ChangeLog:

PR tree-optimization/110600
* gcc.c-torture/compile/pr110600.c: New test.

[Bug target/110588] btl (on x86_64) not always generated

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
   Last reconfirmed||2023-07-08

--- Comment #1 from Roger Sayle  ---
Thanks Andrew.  I have a patch (a define_split in i386.md) that's currently
bootstrapping and regression testing.  But perhaps this should also be fixed at
the tree-level by match.pd canonicalizing ((T)(x & C)) ^ C to (T)((~x) & C)
when T is not wider than X and X is not wider than WORD_MODE.  It's tricky to
compare the costs of integer operations in different precisions, but WORD_MODE
(and int) operations are (typically) always cheap (and I believe unary
operations are preferred over binary operations (with immediate constants)).

[Bug c++/96425] ICE in maybe_process_partial_specialization() since r11-2735-g634046d1a81b48

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #9 from Sergei Trofimovich  ---
Let's close it as fixed as gcc-10 branch was closed and gcc-11+ should be fine.

[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #3 from Sergei Trofimovich  ---
git bisect landed on the r14-2087-g83269719640689 :

$ git bisect good
83269719640689415c0d5026ebfe05a0cf2bab72 is the first bad commit
commit 83269719640689415c0d5026ebfe05a0cf2bab72
Author: Roger Sayle 
Date:   Mon Jun 26 09:36:02 2023 +0100

i386: New *ashl_doubleword_highpart define_insn_and_split.

[Bug tree-optimization/110600] [14 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

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

[Bug middle-end/110601] [14 Regression] ICE on systemd-253.5: during GIMPLE pass: cunroll: internal compiler error: Segmentation fault in scale_loop_profile()

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/110601] [14 Regression] ICE on systemd-253.5: during GIMPLE pass: cunroll: internal compiler error: Segmentation fault in scale_loop_profile()

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

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 55505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55505&action=edit
bug.c.org

Attaching bug.c.org in case reduced example is too artificial.

[Bug middle-end/110601] New: [14 Regression] ICE on systemd-253.5: during GIMPLE pass: cunroll: internal compiler error: Segmentation fault in scale_loop_profile()

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

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

Bug ID: 110601
   Summary: [14 Regression] ICE on systemd-253.5: during GIMPLE
pass: cunroll: internal compiler error: Segmentation
fault in scale_loop_profile()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed ICE on gcc-master r14-2396-g15bbf1826a01f5 when building systemd-253.5

cvise came up with this test:

// $ cat bug.c
int high_key_blocks[] = {0, 0};
int high_key_blocks_0_0;
long test_key_bitmask_key;
void log_object_internal();
void test_key() {
  _Bool found = 0;
  for (long i;;)
for (long block = 0;
 block < sizeof(high_key_blocks) / sizeof(int) && !found; block++)
  for (i = high_key_blocks_0_0; i && !found; i++)
if (test_key_bitmask_key) {
  log_object_internal();
  found = 1;
}
}

Crashing:

$ gcc  -c bug.c -o bug.o -O2 -Werror -Wall
during GIMPLE pass: cunroll
bug.c: In function 'test_key':
bug.c:5:6: internal compiler error: Segmentation fault
5 | void test_key() {
  |  ^~~~
0xccc87f crash_signal
../../source/gcc/toplev.cc:314
0x85aafe fprintf
   
/nix/store/2bhnayqiskhnif3nhs26kkai342dz4dz-glibc-2.37-8-dev/include/bits/stdio2.h:79
0x85aafe scale_loop_profile(loop*, profile_probability, long)
../../source/gcc/cfgloopmanip.cc:585
0xdfa332 try_unroll_loop_completely
../../source/gcc/tree-ssa-loop-ivcanon.cc:911
0xdfa332 canonicalize_loop_induction_variables
../../source/gcc/tree-ssa-loop-ivcanon.cc:1286
0xdfb667 tree_unroll_loops_completely_1
../../source/gcc/tree-ssa-loop-ivcanon.cc:1429
0xdfb5be tree_unroll_loops_completely_1
../../source/gcc/tree-ssa-loop-ivcanon.cc:1382
0xdfb5be tree_unroll_loops_completely_1
../../source/gcc/tree-ssa-loop-ivcanon.cc:1382
0xdfb83b tree_unroll_loops_completely
../../source/gcc/tree-ssa-loop-ivcanon.cc:1478
0xdfbc3f execute
../../source/gcc/tree-ssa-loop-ivcanon.cc:1644
0xdfbc3f execute
../../source/gcc/tree-ssa-loop-ivcanon.cc:1634

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.2.1-dev/include
--with-gmp-lib=/<>/gmp-6.2.1/lib
--with-mpfr-include=/<>/mpfr-4.2.0-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.0/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.37-8-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug fortran/103506] [11 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE in   |[11 Regression] ICE in
   |gfc_free_namespace, at  |gfc_free_namespace, at
   |fortran/symbol.c:4039 since |fortran/symbol.c:4039 since
   |r10-2798-ge68a35ae4a65d2b3  |r10-2798-ge68a35ae4a65d2b3
 Status|NEW |ASSIGNED

[Bug fortran/103716] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15964 since r9-3803-ga5fbc2f36a291cbe

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/110585] ICE in gfc_compare_expr for findloc with complex literal array

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14, and on all open branches.  Closing.

Thanks for the report!

[Bug fortran/110585] ICE in gfc_compare_expr for findloc with complex literal array

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

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

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

https://gcc.gnu.org/g:8e365976ddc856a4c08aa52f90799330baed599a

commit r11-10900-g8e365976ddc856a4c08aa52f90799330baed599a
Author: Harald Anlauf 
Date:   Fri Jul 7 20:25:06 2023 +0200

Fortran: simplification of FINDLOC for constant complex arguments
[PR110585]

gcc/fortran/ChangeLog:

PR fortran/110585
* arith.c (gfc_compare_expr): Handle equality comparison of
constant
complex gfc_expr arguments.

gcc/testsuite/ChangeLog:

PR fortran/110585
* gfortran.dg/findloc_9.f90: New test.

(cherry picked from commit 7ac1581d066a6f3a0d4acf1042a74634258b4966)

[Bug tree-optimization/110600] [14 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-08
Summary|ICE on valid code at -O1|[14 Regregression] ICE on
   |and above on|valid code at -O1 and above
   |x86_64-linux-gnu:   |on x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
  if (exit_edge && exit_edge->src->loop_father != loop)
{
  fprintf (dump_file,
   ";; Loop exit is in inner loop;"
   " will leave exit probabilities inconsistent\n");
}


Confirmed, dump_file is not checked ...

[Bug tree-optimization/110600] New: ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault

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

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

Bug ID: 110600
   Summary: ICE on valid code at -O1 and above on
x86_64-linux-gnu: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

[546] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230708 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[547] % 
[547] % gcctk -O1 small.c
during GIMPLE pass: cunroll
small.c: In function ‘main’:
small.c:2:5: internal compiler error: Segmentation fault
2 | int main() {
  | ^~~~
0xfe4473 crash_signal
../../gcc-trunk/gcc/toplev.cc:314
0x7fa025ede51f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fa025f1bfc2 __GI__IO_fwrite
./libio/iofwrite.c:37
0xad5839 fprintf
/usr/include/x86_64-linux-gnu/bits/stdio2.h:105
0xad5839 scale_loop_profile(loop*, profile_probability, long)
../../gcc-trunk/gcc/cfgloopmanip.cc:585
0x11469b5 try_unroll_loop_completely
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:911
0x11469b5 canonicalize_loop_induction_variables
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1286
0x1147d82 tree_unroll_loops_completely_1
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1429
0x1147cea tree_unroll_loops_completely_1
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1382
0x1148134 tree_unroll_loops_completely
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1478
0x1148403 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1644
0x1148403 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1634
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[548] % 
[548] % cat small.c
int a(int b, int c) { return (b ^ c) < 0 ? b : b - c; }
int main() {
  for (int e = 0; e != -1; e = a(e, 1))
;
  return 0;
}

[Bug fortran/110585] ICE in gfc_compare_expr for findloc with complex literal array

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

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

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

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

commit r12-9762-g2d416f352be898c408fd3db402719d6625f26720
Author: Harald Anlauf 
Date:   Fri Jul 7 20:25:06 2023 +0200

Fortran: simplification of FINDLOC for constant complex arguments
[PR110585]

gcc/fortran/ChangeLog:

PR fortran/110585
* arith.cc (gfc_compare_expr): Handle equality comparison of
constant
complex gfc_expr arguments.

gcc/testsuite/ChangeLog:

PR fortran/110585
* gfortran.dg/findloc_9.f90: New test.

(cherry picked from commit 7ac1581d066a6f3a0d4acf1042a74634258b4966)

[Bug fortran/110585] ICE in gfc_compare_expr for findloc with complex literal array

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

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

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

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

commit r13-7550-gd00a7d22c68aae583fa37236d894a220028dd0c8
Author: Harald Anlauf 
Date:   Fri Jul 7 20:25:06 2023 +0200

Fortran: simplification of FINDLOC for constant complex arguments
[PR110585]

gcc/fortran/ChangeLog:

PR fortran/110585
* arith.cc (gfc_compare_expr): Handle equality comparison of
constant
complex gfc_expr arguments.

gcc/testsuite/ChangeLog:

PR fortran/110585
* gfortran.dg/findloc_9.f90: New test.

(cherry picked from commit 7ac1581d066a6f3a0d4acf1042a74634258b4966)

[Bug target/106484] Failure to optimize uint64_t/constant division on ARM32

[rsaxvc at gmail dot com via Gcc-bugs]

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

--- Comment #5 from rsaxvc at gmail dot com ---
Related ticket requested with Clang:
https://github.com/llvm/llvm-project/issues/63731

latest umulh() function is a little shorter:

static uint64_t umulh(uint64_t a, uint64_t b)
{
const uint32_t a_lo = a;
const uint32_t a_hi = a >> 32;
const uint32_t b_lo = b;
const uint32_t b_hi = b >> 32;

/* FOIL method of multiplication
See https://en.wikipedia.org/wiki/FOIL_method,
but instead of binomials with constants a,b,c,d variables x,y: (ax+b) * (cy +
d),
consider it with variables a,b,c,d, constants x,y = 1<<32
Results in one UMULL or UMLAL(when merged with accumulate below) per multiply*/
const uint64_t acc0 = (uint64_t)a_lo * b_lo;
const uint64_t acc1 = (uint64_t)a_hi * b_lo;
const uint64_t acc2 = (uint64_t)a_lo * b_hi;
const uint64_t acc3 = (uint64_t)a_hi * b_hi;

/* Accumulate the results, keeping only the top 64-bits of the 128-bit result*/
uint64_t acc = acc0;
acc >>= 32;
acc += acc1;
acc += acc2;
acc >>= 32;
acc += acc3;

return acc;
}

[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled

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

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

--- Comment #2 from Andrew Pinski  ---
Here is a C testcase:
```
#include 

typedef unsigned long long u64;

#define MAX_SUBTARGET_WORDS 4

//[[gnu::noipa]]
int notequal(const void *a, const void *b)
{
return __builtin_memcmp(a,b,MAX_SUBTARGET_WORDS*sizeof(u64)) != 0;
}
typedef struct FeatureBitset {
  u64 Bits[MAX_SUBTARGET_WORDS];
}FeatureBitset;

__attribute__((noipa))
bool is_eq_buggy (const FeatureBitset * lf, const FeatureBitset * rf) {
u64 Bits_l[MAX_SUBTARGET_WORDS];
Bits_l[0] = lf->Bits[0]&1;
Bits_l[1] = 0;
Bits_l[2] = 0;
Bits_l[3] = 0;
u64 Bits_r[MAX_SUBTARGET_WORDS];
Bits_r[0] = rf->Bits[0]&1;
Bits_r[1] = 0;
Bits_r[2] = 0;
Bits_r[3] = 0;
return !notequal(Bits_l, Bits_r);
}

__attribute__((noipa))
void bug(void) {
FeatureBitset lf, rf;
lf.Bits[0] = rf.Bits[0] = 1;
lf.Bits[1] = rf.Bits[1] = 1;
lf.Bits[2] = rf.Bits[2] = 1;
lf.Bits[3] = rf.Bits[3] = 1;

bool r = is_eq_buggy (&lf, &rf);
if (!r) __builtin_trap();
}

__attribute__((noipa))
int main(void) {
bug();
}
```

Again uncomment the attribute on notequal, if you want to see it works without
inlining of memcmp here ...

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #9)
> and simplify_replace_rtx simplifies the above to:
> 
> (gdb) p debug_rtx (src)
> (const_vector:V8HI [
> (const_int 204 [0xcc]) repeated x8
> ])

Patched compiler simplifies to:

(gdb) p debug_rtx (src)
(const_vector:V8HI [
(const_int 204 [0xcc]) repeated x4
(const_int 0 [0]) repeated x4
])

[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-08
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0
   Keywords||wrong-code
Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |on llvm-14.0.6  |on llvm-14.0.6 due to
   ||memcmp being miscompiled
 Ever confirmed|0   |1
  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
Confirmed looks like a target issue dealing with memcmp.
Take:
```

// $ cat bug.cpp
#include 

typedef unsigned long long u64;

const unsigned MAX_SUBTARGET_WORDS = 4;

[[gnu::noipa]]
int notequal(const void *a, const void *b)
{
return __builtin_memcmp(a,b,MAX_SUBTARGET_WORDS*sizeof(u64)) != 0;
}

struct FeatureBitset {
  u64 Bits[MAX_SUBTARGET_WORDS] = {0, 0, 0, 0};

  constexpr FeatureBitset() = default;
  constexpr FeatureBitset(std::initializer_list Init) {
for (auto I : Init) {
  Bits[I] = 1;
}
  }

  constexpr FeatureBitset operator&(const FeatureBitset &RHS) const {
FeatureBitset Result = *this;
for (unsigned I = 0, E = MAX_SUBTARGET_WORDS; I != E; ++I) {
  Result.Bits[I] &= RHS.Bits[I];
}
return Result;
  }

  bool operator!=(const FeatureBitset &RHS) const {
  return notequal(Bits, RHS.Bits);
  }
};

static constexpr const FeatureBitset TargetFeatures = { 0, 0, 0, 0, };

__attribute__((noipa))
bool is_eq_buggy (const FeatureBitset & lf, const FeatureBitset & rf) {
  if ((lf & TargetFeatures) != (rf & TargetFeatures))
return false;
  return true;
}

__attribute__((noipa))
void bug(void) {
FeatureBitset lf, rf;
lf.Bits[0] = rf.Bits[0] = 1;
lf.Bits[1] = rf.Bits[1] = 1;
lf.Bits[2] = rf.Bits[2] = 1;
lf.Bits[3] = rf.Bits[3] = 1;

bool r = is_eq_buggy (lf, rf);
if (!r) __builtin_trap();
}

__attribute__((noipa))
int main(void) {
bug();
}
```

The above is not miscompiled but once the gnu::noipa on the notequal is
removed, it is.

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

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

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

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

[Bug tree-optimization/110599] wrong code at -Os and above with "-fno-tree-forwprop -fno-tree-fre" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same problem as PR 110252 so dup.

phiopt match-simplify trying:
_2 != _5 ? 1 : _15
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:1991, gimple-match-5.cc:23
Matching expression match.pd:2480, gimple-match-4.cc:35
Matching expression match.pd:2483, gimple-match-3.cc:66
Applying pattern match.pd:4763, gimple-match-7.cc:16232
Folded into the sequence:
_14 = _2 != _5;
_8 = (int) _14;
_7 = _8 | _15;
statement un-sinked:
_15 = _2;
Removing basic block 3
;; basic block 3, loop depth 0
;;  pred:   2
;;  succ:   4


  # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
  _15 = _2;

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

[Bug fortran/99368] ICE in build_function_decl, at fortran/trans-decl.c:2381

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-2397-g9a2eab6172a8067e2f63e0fa2bcd5b2190656303
Author: Paul Thomas 
Date:   Sat Jul 8 18:13:23 2023 +0100

Fortran: Fix default type bugs in gfortran [PR99139, PR99368]

2023-07-08  Steve Kargl  

gcc/fortran
PR fortran/99139
PR fortran/99368
* match.cc (gfc_match_namelist): Check for host associated or
defined types before applying default type.
(gfc_match_select_rank): Apply default type to selector of
unknown type if possible.
* resolve.cc (resolve_fl_variable): Do not apply local default
initialization to assumed rank entities.

gcc/testsuite/
PR fortran/99139
* gfortran.dg/pr99139.f90 : New test

PR fortran/99368
* gfortran.dg/pr99368.f90 : New test

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-2397-g9a2eab6172a8067e2f63e0fa2bcd5b2190656303
Author: Paul Thomas 
Date:   Sat Jul 8 18:13:23 2023 +0100

Fortran: Fix default type bugs in gfortran [PR99139, PR99368]

2023-07-08  Steve Kargl  

gcc/fortran
PR fortran/99139
PR fortran/99368
* match.cc (gfc_match_namelist): Check for host associated or
defined types before applying default type.
(gfc_match_select_rank): Apply default type to selector of
unknown type if possible.
* resolve.cc (resolve_fl_variable): Do not apply local default
initialization to assumed rank entities.

gcc/testsuite/
PR fortran/99139
* gfortran.dg/pr99139.f90 : New test

PR fortran/99368
* gfortran.dg/pr99368.f90 : New test

[Bug tree-optimization/110599] New: wrong code at -Os and above with "-fno-tree-forwprop -fno-tree-fre" on x86_64-linux-gnu

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

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

Bug ID: 110599
   Summary: wrong code at -Os and above with "-fno-tree-forwprop
-fno-tree-fre" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

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

[501] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230708 (experimental) (GCC) 
[502] % 
[502] % gcctk -O2 small.c; ./a.out
1
[503] % gcctk -O2 -fno-tree-forwprop -fno-tree-fre small.c; ./a.out
-1
[504] % cat small.c
int printf(const char *, ...);
int a, b;
int main() {
  b = ~b;
  a = b ^ (a && 1) || b;
  printf("%d\n", a);
  return 0;
}

[Bug fortran/103796] form-team-spec-list is unsupported

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |
   Priority|P3  |P4
Summary|ICE in gfc_conv_expr_val,   |form-team-spec-list is
   |at  |unsupported
   |fortran/trans-expr.c:9446   |
   |since   |
   |r8-6395-gf8862a1b2afad9d1   |

--- Comment #10 from kargl at gcc dot gnu.org ---
Thanks Harald for re-opening the bug.  I've updated the Summary as you fixed
the ICE and this now documents the missing support for form-team-spec-list. 
I've also updated the Importance level.

[Bug c++/110598] New: [14 Regression] wrong code on llvm-14.0.6

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

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

Bug ID: 110598
   Summary: [14 Regression] wrong code on llvm-14.0.6
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially observed the failure as llvm-14.0.6 testsuite hangup on gcc
15bbf1826a01f5beb2d7c0f74d6270bbc94ece91.

Initially observed on
llvm-src-14.0.6/llvm/lib/Target/AMDGPU/AMDGPUPropagateAttributes.cpp code
around 
'AMDGPUPropagateAttributes::FnProperties:: bool operator == (const
FnProperties &Other) const' miscompilation.

Managed to extract the following example form it:

// $ cat bug.cpp
#include 

typedef unsigned long long u64;

const unsigned MAX_SUBTARGET_WORDS = 4;

struct FeatureBitset {
  u64 Bits[MAX_SUBTARGET_WORDS] = {0, 0, 0, 0};

  constexpr FeatureBitset() = default;
  constexpr FeatureBitset(std::initializer_list Init) {
for (auto I : Init) {
  Bits[I] = 1;
}
  }

  constexpr FeatureBitset operator&(const FeatureBitset &RHS) const {
FeatureBitset Result = *this;
for (unsigned I = 0, E = MAX_SUBTARGET_WORDS; I != E; ++I) {
  Result.Bits[I] &= RHS.Bits[I];
}
return Result;
  }

  bool operator!=(const FeatureBitset &RHS) const {
  return !std::equal(std::begin(Bits), std::end(Bits),
std::begin(RHS.Bits));
  }
};

static constexpr const FeatureBitset TargetFeatures = { 0, 0, 0, 0, };

__attribute__((noipa))
bool is_eq_buggy (const FeatureBitset & lf, const FeatureBitset & rf) {
  if ((lf & TargetFeatures) != (rf & TargetFeatures))
return false;
  return true;
}

__attribute__((noipa))
void bug(void) {
FeatureBitset lf, rf;
lf.Bits[0] = rf.Bits[0] = 1;
lf.Bits[1] = rf.Bits[1] = 1;
lf.Bits[2] = rf.Bits[2] = 1;
lf.Bits[3] = rf.Bits[3] = 1;

bool r = is_eq_buggy (lf, rf);
if (!r) __builtin_trap();
}

__attribute__((noipa))
int main(void) {
bug();
}

Triggering:

$ g++ -O1 bug.cpp -o bug "$@" && ./bug
# ok
$ g++ -O2 bug.cpp -o bug "$@" && ./bug
Illegal instruction (core dumped) ./bug

$ g++ -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.2.1-dev/include
--with-gmp-lib=/<>/gmp-6.2.1/lib
--with-mpfr-include=/<>/mpfr-4.2.0-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.0/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.37-8-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
Some more digging through the code:

In cprop.cc/try_replace_reg, we try to simplify the source of the set given our
substitution:

Breakpoint 1, try_replace_reg (from=0x7fffe9f0b7f8, to=0x7fffe9f099e0,
insn=0x7fffea01b6c0) at ../../git/gcc/gcc/cprop.cc:789
789   src = simplify_replace_rtx (SET_SRC (set), from, to);

(gdb) list
784   if (!success && set && reg_mentioned_p (from, SET_SRC (set)))
785 {
786   /* If above failed and this is a single set, try to simplify the
source
787  of the set given our substitution.  We could perhaps try this
for
788  multiple SETs, but it probably won't buy us anything.  */
789   src = simplify_replace_rtx (SET_SRC (set), from, to);

(gdb) p debug_rtx (set)
(set (reg:V8HI 100)
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
]

(gdb) p debug_rtx (from)
(reg:V4QI 98)

(gdb) p debug_rtx (to)
(const_vector:V4QI [
(const_int -52 [0xffcc]) repeated x4
])

and simplify_replace_rtx simplifies the above to:

(gdb) p debug_rtx (src)
(const_vector:V8HI [
(const_int 204 [0xcc]) repeated x8
])

which is obviously wrong, we have V4QImode input register holding V4QImode
constant.

Tracing through simplify-rtx.cc brings us to a recursive
simplify_replace_fn_rtx, which gets us to:

Breakpoint 1, simplify_replace_fn_rtx (x=0x7fffe9f0b888,
old_rtx=0x7fffe9f0b7f8, fn=0x0, data=0x7fffe9f099e0) at
../../git/gcc/gcc/simplify-rtx.cc:474
474   op0 = simplify_gen_subreg (GET_MODE (x), op0,

(gdb) list
469   if (code == SUBREG)
470 {
471   op0 = simplify_replace_fn_rtx (SUBREG_REG (x), old_rtx, fn,
data);
472   if (op0 == SUBREG_REG (x))
473 return x;
474   op0 = simplify_gen_subreg (GET_MODE (x), op0,
475  GET_MODE (SUBREG_REG (x)),
476  SUBREG_BYTE (x));
477   return op0 ? op0 : x;
478 }

(gdb) p debug_rtx (op0)
(const_vector:V4QI [
(const_int -52 [0xffcc]) repeated x4
])
(gdb) p debug_rtx (x)
(subreg:V16QI (reg:V4QI 98) 0)

and simplify_gen_subreg with the above arguments returns:

(gdb) p debug_rtx (op0)
(const_vector:V16QI [
(const_int -52 [0xffcc]) repeated x16
])

No way! It is not possible to get V16QImode vector from V4QImode vector, even
when all elements are duplicates.

Tracing even deeper to simplify_context::simplify_subreg, we found the
following:

Breakpoint 1, simplify_context::simplify_subreg (this=0x7fffd528,
outermode=E_V16QImode, op=0x7fffe9f099e0, innermode=E_V4QImode, byte=...)
at ../../git/gcc/gcc/simplify-rtx.cc:7561
7561return gen_vec_duplicate (outermode, elt);

(gdb) list
7556  rtx elt;
7557
7558  if (VECTOR_MODE_P (outermode)
7559  && GET_MODE_INNER (outermode) == GET_MODE_INNER (innermode)
7560  && vec_duplicate_p (op, &elt))
7561return gen_vec_duplicate (outermode, elt);
7562
7563  if (outermode == GET_MODE_INNER (innermode)
7564  && vec_duplicate_p (op, &elt))
7565return elt;

(gdb) p outermode
$1 = E_V16QImode
(gdb) p debug_rtx (elt)
(const_int -52 [0xffcc])

(gdb) fin
Run till exit from #0  simplify_context::simplify_subreg (this=0x7fffd528,
outermode=E_V16QImode, op=0x7fffe9f099e0, innermode=E_V4QImode, byte=...)
at ../../git/gcc/gcc/simplify-rtx.cc:7561
0x00eb24d3 in simplify_subreg (byte=..., innermode=E_V4QImode,
op=, outermode=) at ../../git/gcc/gcc/rtl.h:3513
3513  return simplify_context ().simplify_subreg (outermode, op, innermode,
byte);
Value returned is $4 = (rtx_def *) 0x7fffe9f09c10

(gdb) p debug_rtx ($4)
(const_vector:V16QI [
(const_int -52 [0xffcc]) repeated x16
])

Nope. This transformation is valid only for non-paradoxical registers.

Patch is then obvious:

diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index d7315d82aa3..87ca25086dc 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -7557,6 +7557,7 @@ simplify_context::simplify_subreg (machine_mode
outermode, rtx op,

   if (VECTOR_MODE_P (outermode)
  && GET_MODE_INNER (outermode) == GET_MODE_INNER (innermode)
+ && !paradoxical_subreg_p (outermode, innermode)
  && vec_duplicate_p (op, &elt))
return gen_vec_duplicate (outermode, elt);

[Bug middle-end/110590] Failing CFG consistency testcases

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:15bbf1826a01f5beb2d7c0f74d6270bbc94ece91

commit r14-2396-g15bbf1826a01f5beb2d7c0f74d6270bbc94ece91
Author: Jan Hubicka 
Date:   Sat Jul 8 17:38:09 2023 +0200

Fix tree-ssa/update-cunroll.c

In this testcase the profile is misupdated before loop has two exits.
The first exit is one eliminated by complete unrolling while second exit
remains.
We remove first exit but forget about fact that the source BB of other exit
will
then have higher frequency making other exit more likely.

This patch fixes that in duplicate_loop_body_to_header_edge.
While looking into resulting profiles I also noticed that in some cases
scale_loop_profile may drop probabilities to 0 incorrectly either when
trying to update exit from nested loop (which has similar problem) or when
the profile
was inconsistent as described in coment bellow.

gcc/ChangeLog:

PR middle-end/110590
* cfgloopmanip.cc (scale_loop_profile): Avoid scaling exits within
inner loops and be more careful about inconsistent profiles.
(duplicate_loop_body_to_header_edge): Fix profile update when
eliminated
exit is followed by other exit.

gcc/testsuite/ChangeLog:

PR middle-end/110590
* gcc.dg/tree-prof/update-cunroll-2.c: Remove xfail.
* gcc.dg/tree-ssa/update-cunroll.c: Likewise.

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

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Status|RESOLVED|REOPENED

--- Comment #9 from anlauf at gcc dot gnu.org ---
Steve correctly noted in pr105526#c5 that his patch provides parsing of
the form-team-spec-list, although it will only emit a sorry-type error
message for a not implemented feature, instead of a syntax error.

Reopening, so that his patch won't be lost.

This PR might be referenced in a suitable coarray meta-bug.

[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-2395-gb1079fc88f082d3c5b583c8822c08c5647810259
Author: Harald Anlauf 
Date:   Wed Jul 5 22:21:09 2023 +0200

Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments
[PR92178]

gcc/fortran/ChangeLog:

PR fortran/92178
* trans-expr.cc (gfc_conv_procedure_call): Check procedures for
allocatable dummy arguments with INTENT(OUT) and move deallocation
of actual arguments after evaluation of argument expressions before
the procedure is executed.

gcc/testsuite/ChangeLog:

PR fortran/92178
* gfortran.dg/intent_out_16.f90: New test.
* gfortran.dg/intent_out_17.f90: New test.
* gfortran.dg/intent_out_18.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/110585] ICE in gfc_compare_expr for findloc with complex literal array

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7ac1581d066a6f3a0d4acf1042a74634258b4966

commit r14-2394-g7ac1581d066a6f3a0d4acf1042a74634258b4966
Author: Harald Anlauf 
Date:   Fri Jul 7 20:25:06 2023 +0200

Fortran: simplification of FINDLOC for constant complex arguments
[PR110585]

gcc/fortran/ChangeLog:

PR fortran/110585
* arith.cc (gfc_compare_expr): Handle equality comparison of
constant
complex gfc_expr arguments.

gcc/testsuite/ChangeLog:

PR fortran/110585
* gfortran.dg/findloc_9.f90: New test.

[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Uroš Bizjak  ---
The testcase needs __attribute__((noinline)) to supress unwanted constant
propagation with recent gcc.

void
__attribute__((noinline))
foo (U u, u16 c, V *r)
...

[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

Summary|alpha cross build crashes   |[12/13/14 Regression] alpha
   |gcc-12 "internal compiler   |cross build crashes gcc-12
   |error: in emit_move_insn"   |"internal compiler error:
   ||in emit_move_insn"
   Target Milestone|--- |12.4
  Known to fail||12.3.1, 13.1.1, 14.0
  Known to work||11.4.1

[Bug target/106966] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Uroš Bizjak  ---
Created attachment 55504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55504&action=edit
Proposed patch.

Can someone please bootstrap and test the attached patch?

[Bug target/106966] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #7 from Uroš Bizjak  ---
*** Bug 110597 has been marked as a duplicate of this bug. ***

[Bug target/110597] [12/13/14 Regression] ICE in emit_move_insn, at expr.cc:4224 on alpha-linux-gnu

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Dup of PR106966.

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

[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32

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

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

--- Comment #2 from Eric Botcazou  ---
Note that the SPARC compiler can be configured --with-cpu or --with-cpu_32 or
--with-cpu_64 (as well as s/cpu/tune/) so you can locally tweak defaults.

[Bug fortran/110595] Documentation: typo in the docs for -Wmissing-include-dirs

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:45aab94325eb4b44547c38ac0090eeacc723c589

commit r12-9761-g45aab94325eb4b44547c38ac0090eeacc723c589
Author: Jonathan Wakely 
Date:   Sat Jul 8 10:22:29 2023 +0100

doc: Fix typo in Warning Options [PR110595]

gcc/ChangeLog:

PR c++/110595
* doc/invoke.texi (Warning Options): Fix typo.

(cherry picked from commit 238944752e20d7714352152cb26a08fb26aea831)

[Bug fortran/110595] Documentation: typo in the docs for -Wmissing-include-dirs

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

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

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

https://gcc.gnu.org/g:238944752e20d7714352152cb26a08fb26aea831

commit r13-7549-g238944752e20d7714352152cb26a08fb26aea831
Author: Jonathan Wakely 
Date:   Sat Jul 8 10:22:29 2023 +0100

doc: Fix typo in Warning Options [PR110595]

gcc/ChangeLog:

PR c++/110595
* doc/invoke.texi (Warning Options): Fix typo.

[Bug fortran/110595] Documentation: typo in the docs for -Wmissing-include-dirs

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

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

--- Comment #3 from Jonathan Wakely  ---
I think this would be better, but a fortran maintainer should confirm that:

For Fortran, it is partially enabled by default, only warning for @option{-I}
and @option{-J}."

[Bug fortran/110595] Documentation: typo in the docs for -Wmissing-include-dirs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |fortran
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Version|unknown |14.0
   Last reconfirmed||2023-07-08

--- Comment #2 from Jonathan Wakely  ---
I've fixed that, but the rest of the sentence has poor grammar, and the options
should be marked up with @option:

"For Fortran, it is partially enabled by default by warning for -I and -J,
only."

Reassigning to fortran.

[Bug c++/110596] Documentation: typo in the docs for -Wnrvo

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk, thanks.

[Bug c++/110595] Documentation: typo in the docs for -Wmissing-include-dirs

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:72cfa0f799f3a695cc7b6d0c10a27a27fa087c26

commit r14-2391-g72cfa0f799f3a695cc7b6d0c10a27a27fa087c26
Author: Jonathan Wakely 
Date:   Sat Jul 8 10:22:29 2023 +0100

doc: Fix typos in Warning Options [PR110596]

gcc/ChangeLog:

PR c++/110595
PR c++/110596
* doc/invoke.texi (Warning Options): Fix typos.

[Bug c++/110596] Documentation: typo in the docs for -Wnrvo

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:72cfa0f799f3a695cc7b6d0c10a27a27fa087c26

commit r14-2391-g72cfa0f799f3a695cc7b6d0c10a27a27fa087c26
Author: Jonathan Wakely 
Date:   Sat Jul 8 10:22:29 2023 +0100

doc: Fix typos in Warning Options [PR110596]

gcc/ChangeLog:

PR c++/110595
PR c++/110596
* doc/invoke.texi (Warning Options): Fix typos.

[Bug target/110597] New: [12/13/14 Regression] ICE in emit_move_insn, at expr.cc:4224 on alpha-linux-gnu

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

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

Bug ID: 110597
   Summary: [12/13/14 Regression] ICE in emit_move_insn, at
expr.cc:4224 on alpha-linux-gnu
   Product: gcc
   Version: 12.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

forwarded from https://bugs.debian.org/1019011

seen with current gcc-12 and gcc-13 branches and trunk on alpha-linux-gnu,
-mbuild-constants triggers the issue

$ cat tst.i
short *a;
void b() { a[0] = a[1] = a[2] = a[3] = 2; }

$ alpha-linux-gnu-gcc-13 -c -msmall-text -msmall-data -mno-fp-regs
-mbuild-constants -mcpu=ev67 -O2 tst.i
during RTL pass: expand
tst.i: In function ‘b’:
tst.i:2:17: internal compiler error: in emit_move_insn, at expr.cc:4224
2 | void b() { a[0] = a[1] = a[2] = a[3] = 2; }
  |~^~~~
0x596354 emit_move_insn(rtx_def*, rtx_def*)
../../src/gcc/expr.cc:4224
0xe01205 alpha_emit_set_long_const
../../src/gcc/config/alpha/alpha.cc:2094
0xe095aa alpha_split_const_mov(machine_mode, rtx_def**)
../../src/gcc/config/alpha/alpha.cc:2208
0xe09711 alpha_expand_mov(machine_mode, rtx_def**)
../../src/gcc/config/alpha/alpha.cc:2254
0x1168e59 gen_movv4hi(rtx_def*, rtx_def*)
../../src/gcc/config/alpha/alpha.md:4463
0x801697 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
../../src/gcc/recog.h:407
0x801697 emit_move_ccmode
../../src/gcc/expr.cc:4043
0x801697 emit_move_insn_1(rtx_def*, rtx_def*)
../../src/gcc/expr.cc:4188
0x801a7f emit_move_insn(rtx_def*, rtx_def*)
../../src/gcc/expr.cc:4339
0x7dfae7 force_reg(machine_mode, rtx_def*)
../../src/gcc/explow.cc:683
0xe0be16 alpha_expand_movmisalign(machine_mode, rtx_def**)
../../src/gcc/config/alpha/alpha.cc:2414
0x1169096 gen_movmisalignv4hi(rtx_def*, rtx_def*)
../../src/gcc/config/alpha/alpha.md:4485
0xa31258 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../src/gcc/optabs.cc:8153
0xa31258 expand_insn(insn_code, unsigned int, expand_operand*)
../../src/gcc/optabs.cc:8184
0x80ab17 expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.cc:5613
0x701ee2 expand_gimple_stmt_1
../../src/gcc/cfgexpand.cc:3946
0x701ee2 expand_gimple_stmt
../../src/gcc/cfgexpand.cc:4044
0x706cb7 expand_gimple_basic_block
../../src/gcc/cfgexpand.cc:6106
0x7088e6 execute
../../src/gcc/cfgexpand.cc:6841
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
We're not going to change that now; compile for V8 if you want to run on V8.

[Bug c++/110596] New: Documentation: typo in the docs for -Wnrvo

[gennaro.prota+gccbugzilla at gmail dot com via Gcc-bugs]

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

Bug ID: 110596
   Summary: Documentation: typo in the docs for -Wnrvo
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

>From the manual (currently,
, but I'm afraid this
is a moving target):

  -Wnrvo [...]
For instance, in the example below the compiler cannot elide copies from
both
v1 and b2, so it elides neither.

  std::vector f()
  {
std::vector v1, v2;
// ...
if (cond) return v1;
else return v2; // warning: not eliding copy
  }

Clearly, the text should say "v1 and v2", not "v1 and b2".

[Bug c++/110595] New: Documentation: typo in the docs for -Wmissing-include-dirs

[gennaro.prota+gccbugzilla at gmail dot com via Gcc-bugs]

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

Bug ID: 110595
   Summary: Documentation: typo in the docs for
-Wmissing-include-dirs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

>From the manual
():

  -Wmissing-include-dirs (C, C++, Objective-C, Objective-C++ and Fortran only)

  Warn if a user-supplied include directory does not exist. This opions is
  disabled by default for C, C++, Objective-C and Objective-C++.

Note the typo "opions" (missing 't' and extra 's').

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

Alexander Klepikov  changed:

   What|Removed |Added

  Attachment #55382|0   |1
is obsolete||

--- Comment #98 from Alexander Klepikov  
---
Created attachment 55503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55503&action=edit
Testcase for SH specific loop optimization pass

I modified testcase for hoisting tests. It contains two different dg-final
commands at once. First uses 'scan-assembler' command and second uses
'check-function-bodies'.

The difference is that 'scan-assembler' uses "plain" regexp and is more
powerfull but more complicated to understand. 'check-function-bodies' is
simpler but less powerfull and requires C++, if I'm not mistaken.

They both work, but only one is needed because they do the same. I hope this
will help.

[Bug libstdc++/110594] std::variant's converting constructor does not resolve alternative correctly

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
I think libstdc++ is correct here.

[Bug libstdc++/110594] std::variant's converting constructor does not resolve alternative correctly

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

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

--- Comment #1 from Jonathan Wakely  ---
converting a size_t to int64_t is a narrowing conversion, try it without a
constant value and you'll get an error: https://godbolt.org/z/rb6jrr4xq

That's what the SFINAE check for _Arr does, so your {size_t(1)} is not
equivalent and your assumptions based on that are incorrect.

[Bug libstdc++/110593] The std::ratio meta arithmetic can accept non-std::ratio

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/110594] New: std::variant's converting constructor does not resolve alternative correctly

[xgao at nvidia dot com via Gcc-bugs]

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

Bug ID: 110594
   Summary: std::variant's converting constructor does not resolve
alternative correctly
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xgao at nvidia dot com
  Target Milestone: ---

Created attachment 55502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55502&action=edit
minimum repro

According to https://en.cppreference.com/w/cpp/utility/variant/variant, I would
expect the attached program to output:

int64_t: 1
variant is int

However, I am getting:

int64_t: 1
variant is complex

gcc-9 seems to have the correct behavior for the attached program, however, the
implementation of std::variant in gcc-9 has another problem that the following
example in that cppreference.com page does not work:

std::variant z = 0; // OK, holds long
 // float and double are not candidates

Thanks to the help of jjsjann123 (https://github.com/jjsjann123), this is
potentially related to the SFINAE in the "variant" header:

  // Helper used to check for valid conversions that don't involve narrowing.
  template struct _Arr { _Ti _M_x[1]; };

seems that this will block int64_t from being selected as shown in
https://godbolt.org/z/Gcr4j53rd. However, the following code is totally valid:

int64_t x[] = {size_t(1)};

so probably that SFINAE might be wrong.