[Bug libfortran/101310] Bind(C): CFI_section seems confused by pointer arrays

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

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Patch posted here:

https://gcc.gnu.org/pipermail/fortran/2021-July/056251.html

[Bug preprocessor/101493] Error message for too deep include seems to be off by one

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90581
   Last reconfirmed||2021-07-18

--- Comment #1 from Andrew Pinski  ---
  if (pfile->line_table->depth >= CPP_OPTION (pfile, max_include_depth))
cpp_error (pfile,
   CPP_DL_ERROR,
   "#include nested depth %u exceeds maximum of %u"
   " (use -fmax-include-depth=DEPTH to increase the maximum)",
   pfile->line_table->depth,
   CPP_OPTION (pfile, max_include_depth));
in libcpp/directives.c

The option is new for GCC 10 (added with r10-1503) and the error message
changed then.  It used to just say:
"#include nested too deeply"
And not even say the limit.

Confirmed.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

[rin at NetBSD dot org via Gcc-bugs]

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

--- Comment #1 from Rin Okuyama  ---
I've confirmed that the problem also occurs for sh3-none-elf:


$ sh3-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/pkg/cross-sh3-none-elf/bin/sh3-none-elf-gcc
COLLECT_LTO_WRAPPER=/usr/pkg/cross-sh3-none-elf/libexec/gcc/sh3-none-elf/10.3.0/lto-wrapper
Target: sh3-none-elf
Configured with:
/build/pkgsrc/cross/sh3-none-elf-gcc/work.x86_64/gcc-10.3.0/configure
--target=sh3-none-elf --enable-languages=c,c++ --with-newlib --disable-nls
--disable-libstdcxx-pch --prefix=/usr/pkg/cross-sh3-none-elf
--build=x86_64--netbsd --host=x86_64--netbsd
--infodir=/usr/pkg/cross-sh3-none-elf/info
--mandir=/usr/pkg/cross-sh3-none-elf/man
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC)


So, this is not NetBSD-specific.

Also, for shle--netbsdelf, GCC 7.5 and 5.5 has the same problem; this is
not a recent regression.

Thanks,
rin

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to alig from comment #8)
> The problem still persists with GNU Fortran (GCC) 11.1.0.

The problem is likely to persist for the foreseeable future
as there is no one left to work on gfortran bugs.  Lacking 
a sudden influx of new volunteer contributors, it seems
the only way forward is to NOT use parameterized derived 
types with gfortran.

[Bug target/101495] New: Unnecessary vzeroupper

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

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

Bug ID: 101495
   Summary: Unnecessary vzeroupper
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-2 pr101456]$ cat y.c
#include 

extern __m256d x;

extern __m256d bar (void);

__m256d
foo (void)
{
  x = _mm256_setzero_pd ();
  return bar ();
}
[hjl@gnu-cfl-2 pr101456]$ gcc -S -O2 -mavx2 y.c
[hjl@gnu-cfl-2 pr101456]$ cat y.s
.file   "y.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB5667:
.cfi_startproc
vxorpd  %xmm0, %xmm0, %xmm0
vmovapd %ymm0, x(%rip)
vzeroupper
jmp bar
.cfi_endproc
.LFE5667:
.size   foo, .-foo
.ident  "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr101456]$ 

Since bar returns __m256d, it must be compiled with AVX and there is no
need for vzeroupper.

[Bug tree-optimization/101494] New: -Wmaybe-uninitialized false alarm with memrchr of size 0

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 101494
   Summary: -Wmaybe-uninitialized false alarm with memrchr of size
0
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

I ran into this problem when compiling Gnulib tests on gcc (GCC) 11.1.1
20210531 (Red Hat 11.1.1-3) on x86-64. Here is a stripped down program
illustrating the bug:

void *malloc (unsigned long)
  __attribute__((__malloc__)) __attribute__((__alloc_size__ (1)));

void *memrchr (const void *, int, unsigned long)
  __attribute__((__access__ (__read_only__, 1, 3)));

int
main (void)
{
  char *input = malloc (1);
  if (!input)
return 1;
  *input = 0;
  return !!memrchr (input, 'a', 0);
}


The following command:

gcc -Wmaybe-uninitialized -O2 -S w.i

outputs:
w.i: In function 'main':
w.i:14:12: warning: 'input' may be used uninitialized [-Wmaybe-uninitialized]
   14 |   return !!memrchr (input, 'a', 0);
  |^~~
w.i:4:7: note: in a call to 'memrchr' declared with attribute 'access
(read_onl\
y, 1, 3)' here
4 | void *memrchr (const void *, int, unsigned long)
  |   ^~~

This warning is bogus, as 'input' is initialized; and even if "input = 0;" were
removed the call to memrchr would still be valid as the size argument is 0.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

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

--- Comment #252 from The Written Word  
---
(In reply to Larkin Nickle from comment #249)
> Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I
> eventually run into other errors:
> 
> ../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c: In function
> 'gcov_clear':
> ../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c:143:1:
> internal compiler error: Illegal instruction
>   143 | }
>   | ^
> libbacktrace could not find executable to open 

I tried building 10.3.0 using the same patches as in 11.1.0 and ran into the
above for the 10.3.0 build.

[Bug c/101493] New: Error message for too deep include seems to be off by one

[wolf+gcc at wolfsden dot cz via Gcc-bugs]

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

Bug ID: 101493
   Summary: Error message for too deep include seems to be off by
one
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wolf+gcc at wolfsden dot cz
  Target Milestone: ---

When you by accident create infinite loop in includes, you get this error
message:

../foo.c:1:32: error: #include nested depth 200 exceeds maximum of 200 (use
-fmax-include-depth=DEPTH to increase the maximum)

That seems slightly off, since 200 does not exceed 200. I guess it should have
been 201 exceeds [..] 200?

[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations

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

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

--- Comment #2 from David Malcolm  ---
I wonder why this changed recently; as Dimitry notes, this has been done the
same since the initial merger of libgccjit into trunk.

I'm using $(includedir).  What should I be using?  Thanks

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

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

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

Andrew Stubbs  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-17

--- Comment #1 from Andrew Stubbs  ---
A new warning has been added that falsely identifies any access to a hardcoded
constant address as bogus. This has affected a few targets, including GCN
libgomp. See pr101374.

There's some discussion what to do about it. E.g.
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574880.html

[Bug target/101492] New: -msse4 -mgeneral-regs-only doesn't work

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

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

Bug ID: 101492
   Summary: -msse4 -mgeneral-regs-only doesn't work
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-2 i386]$ cat pr99744-9.c
/* { dg-do compile } */
/* { dg-options "-O2 -msse4.2 -mgeneral-regs-only" } */

#include 

unsigned int
foo1 (unsigned int x, unsigned int y)
{
  return __crc32d (x, y);
}
[hjl@gnu-cfl-2 i386]$ gcc -S -O2 pr99744-9.c -msse4 -mgeneral-regs-only -o
/tmp/x.s
In file included from
/usr/lib/gcc/x86_64-redhat-linux/11/include/x86gprintrin.h:27,
 from
/usr/lib/gcc/x86_64-redhat-linux/11/include/x86intrin.h:27,
 from pr99744-9.c:4:
pr99744-9.c: In function ‘foo1’:
/usr/lib/gcc/x86_64-redhat-linux/11/include/ia32intrin.h:77:1: error: inlining
failed in call to ‘always_inline’ ‘__crc32d’: target specific option mismatch
   77 | __crc32d (unsigned int __C, unsigned int __V)
  | ^~~~
pr99744-9.c:9:10: note: called from here
9 |   return __crc32d (x, y);
  |  ^~~
[hjl@gnu-cfl-2 i386]$

[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations

[dimitry at andric dot com via Gcc-bugs]

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

Dimitry Andric  changed:

   What|Removed |Added

 CC||dimitry at andric dot com,
   ||dmalcolm at gcc dot gnu.org

--- Comment #1 from Dimitry Andric  ---
It appears libgccjit.h and libgccjit++.h are installed into $(includedir), via
gcc/jit/Make-lang.in:

jit.install-headers: installdirs
$(INSTALL_DATA) $(srcdir)/jit/libgccjit.h \
  $(DESTDIR)$(includedir)/libgccjit.h
$(INSTALL_DATA) $(srcdir)/jit/libgccjit++.h \
  $(DESTDIR)$(includedir)/libgccjit++.h

This has been the case since David committed r217374. I'm unsure why these
headers seem to be installed only recently?

[Bug middle-end/71741] The program works 3 times slower compiled with g++ 5.3.1 than the same program compiled with g++ 4.8.4 with the same command (i7-5820 Haswell)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |MOVED
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=20495

--- Comment #5 from Andrew Pinski  ---
This was an issue in glibc as
https://sourceware.org/bugzilla/show_bug.cgi?id=20495 shows.

Closing as moved.

[Bug c++/79741] errors about struct members being of type size_t when it's not, other strange errors. cached source too.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
Invalid as the problem is in the user code rather than in GCC.

[Bug other/89702] 03 issue with SIGALRM causes program to SEGV on Solaris

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.3
 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #5 from Andrew Pinski  ---
(In reply to Karl Burgess from comment #4)
> 
> The problem does not occur with GCC 8.3.0

So closing as fixed.

[Bug other/83150] GCC's internal use of `abort`is unsafe in several ways

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Andrew Pinski  ---
(In reply to Ben Longbons from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > The signal handler will always be sync unless someone decides to do a kill
> > from the command line.
> 
> You're assuming that no library ever calls abort(). Glibc certainly does,
> notably in its malloc() implementation.

Huh? Anyways there is a fall back if the signal handler is called twice.

Anyways there is no reason to fix this.  Calling abort is an exceptional case
really.  It should NEVER EVER BE CALLED inside GCC unless there is a bug.
Fixing this is just working around the other bug.

[Bug libfortran/101310] Bind(C): CFI_section seems confused by pointer arrays

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Looks like 3 bugs for the price of 1!

First off the loop to fill in the result dimensions in CFI_section seemed to be
applying the base adjustment twice in different ways, or something like that. 
I've rewritten and simplified that code.

The section-3 and section-3p test cases were themselves buggy.  I swear I fixed
one of bugs before but I must have discarded that change along with some failed
experiments/debugging code for the bug above.

Finally, fc-out-descriptor-7 was failing because it uses the same pointer array
as both source and result, and CFI_section was messing with the dimensions in
result before computing the base address adjustment from source.  This ended up
not having anything to do with the result array being intent(out).

I'm going to add some more test cases and regression-test before posting the
patch, but I do have fixes for all 3 bugs now.

[Bug jit/101491] New: [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations

[gerald at pfeifer dot com via Gcc-bugs]

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

Bug ID: 101491
   Summary: [11 regression] /usr/local/include/libgccjit++.h
conflicts between different GCC installations
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---

In the FreeBSD Ports Collection (and presumably similarly other distros)
we install different versions of GCC into the same prefix with

  --program-suffix=
  --libdir=
  --with-gxx-include-dir=

which has been working very well for years.

Recently users reported that /usr/local/include/libgccjit++.h is
installed by both GCC 11 and GCC 12 at least, cf. 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060

Looks like this should go into a version-specific directory (such
as --with-gxx-include-dir= maybe?

[Bug target/83610] Come up with __builtin_expect_with_probabilty

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||acahalan at gmail dot com

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

[Bug c/26367] multiple levels of __builtin_expect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Andrew Pinski  ---
Fixed when __builtin_expect_with_probability was added which was recorded as PR
83610.

https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect_005fwith_005fprobability


So closing as a dup.

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

[Bug target/41910] Very basic example failing

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #2 from Andrew Pinski  ---
No feedback in over 4 years so closing.

[Bug target/53485] gcc -O -mavx generates illegal instruction on win64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
No feedback in over 4 years so closing as invalid.

[Bug target/63789] g++ -m32 on solaris has trouble finding abs with int64_t

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
   Target Milestone|--- |6.0

--- Comment #8 from Andrew Pinski  ---
Fixed so closing.

[Bug target/77953] [MIPS] ice: insn does not satisfy its constraints - __bswapsi2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
Fixed, GCC 6 (and even GCC 7) is no longer supported and no longer getting
updates.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #251 from dave.anglin at bell dot net ---
On 2021-07-15 2:48 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #243 from The Written Word  com> ---
> (In reply to John Buddery from comment #238)
>> It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and
>> later require a 64 bit build for 64 bit objects to work reliably.
> I can build up to and including 2.32 with the HP C compiler. Starting with
> 2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry
> with 2.32.
Adding -std=gnu99 unilaterally seems like a bug.

[Bug target/101205] csinv does not have an zero_extend version

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-July/57
   ||5514.html

--- Comment #6 from Andrew Pinski  ---
Finally went through.

[Bug d/101490] New: ICE at convert_expr(tree_node*, Type*, Type*)

[SztfG at yandex dot ru via Gcc-bugs]

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

Bug ID: 101490
   Summary: ICE at convert_expr(tree_node*, Type*, Type*)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

testcase:

import std.stdio;

struct test
{
  int[0] foo;
};

void main()
{
  test* t;
  auto a = cast(typeof((*t).foo)[0])t.foo;
  writeln(a);
}


/opt/wandbox/gdc-head/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/d/std/format.d:
In function 'formatValue':
/opt/wandbox/gdc-head/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/d/std/format.d:2605:23:
internal compiler error: Floating point exception
 2605 | formatValue(w, obj[], f);
  |   ^
0xc2df5f crash_signal
../../source/gcc/toplev.c:328
0x7b78c4 convert_expr(tree_node*, Type*, Type*)
../../source/gcc/d/d-convert.cc:476
0x7c9a5e ExprVisitor::visit(SliceExp*)
../../source/gcc/d/expr.cc:1382
0x7c74c0 build_expr(Expression*, bool, bool)
../../source/gcc/d/expr.cc:3129
0x7b60d1 d_build_call(TypeFunction*, tree_node*, tree_node*,
Array*)
../../source/gcc/d/d-codegen.cc:2042
0x7c8f34 ExprVisitor::visit(CallExp*)
../../source/gcc/d/expr.cc:1886
0x7c74c0 build_expr(Expression*, bool, bool)
../../source/gcc/d/expr.cc:3129
0x7c755b build_expr_dtor(Expression*)
../../source/gcc/d/expr.cc:3152
0x7d3cf1 IRVisitor::visit(ExpStatement*)
../../source/gcc/d/toir.cc:1120
0x7d37bf IRVisitor::build_stmt(Statement*)
../../source/gcc/d/toir.cc:274
0x7d37bf IRVisitor::visit(CompoundStatement*)
../../source/gcc/d/toir.cc:1137
0x7d37bf IRVisitor::visit(CompoundStatement*)
../../source/gcc/d/toir.cc:1127
0x7d2e12 IRVisitor::build_stmt(Statement*)
../../source/gcc/d/toir.cc:274
0x7d2e12 build_function_body(FuncDeclaration*)
../../source/gcc/d/toir.cc:1549
0x7c6623 DeclVisitor::visit(FuncDeclaration*)
../../source/gcc/d/decl.cc:945
0x7c5b2f DeclVisitor::build_dsymbol(Dsymbol*)
../../source/gcc/d/decl.cc:146
0x7c5b2f DeclVisitor::visit(TemplateInstance*)
../../source/gcc/d/decl.cc:341
0x7c5b2f DeclVisitor::visit(TemplateInstance*)
../../source/gcc/d/decl.cc:332
0x7c31d6 DeclVisitor::build_dsymbol(Dsymbol*)
../../source/gcc/d/decl.cc:146
0x7c31d6 build_decl_tree(Dsymbol*)
../../source/gcc/d/decl.cc:986
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/101479] vectorized impossible conditional floating point operations still cause traps (-ffast-math, -O3)

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Simon Thornington from comment #4)
> I'll add that changing close_to_zero from 
> 
> fabs(x) < 0.5
> 
> to
> 
> x == 0.0 || fabs(x) < 0.5
> 
> everything starts to work as I'd expect again...

Yes because it is not vectorized.
Again if you want keep traps/exceptions use -ftrapping-math if you use -Ofast
or -ffast-math.

[Bug target/101205] csinv does not have an zero_extend version

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 51169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51169=edit
full patch

Patch which I sent but the company mail relay server looks broken.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

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

--- Comment #250 from Larkin Nickle  ---
I should probably note that my PATH is set to the standard path, appended with
the PATH to whichever GCC's bin folder as well as a folder I have with some
utilities:

awk   gawk  make  mksh  sed   tar

I use mksh as my CONFIG_SHELL as the system shells don't play nicely with some
configure scripts, e.g. binutils' in my experience.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[me at larbob dot org via Gcc-bugs]

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

--- Comment #249 from Larkin Nickle  ---
I am still unable to replicate a proper 11.1 build against 2.36 gas. Here's my
process:

HP GCC 4.7.1 -> GCC 4.7.4:

../../sources/gcc-4.7.4/configure --prefix=/usr/util/toolchain/gcc-4.7.4 --w
ith-as=/opt/hp-gcc/bin/as --enable-languages=c,c++ --disable-nls

-> 4.9.2:

../../sources/gcc-4.9.2/configure --disable-libgomp --with-as=/opt/hp-gcc/bi
n/as --enable-languages=c,c++ --prefix=/usr/util/toolchain/gcc-4.9.2
--disable-n
ls

Then, I compiled binutils 2.36 (w/ -mlp64), gmp 6.2.1, mpfr 4.1.0, and mpc
1.2.1 with HP GCC 4.7.1. All GMP tests passed except for `t-printf`, all mpfr
tests passed except `tasprintf`, and all mpc tests passed. These results are
the same as John's except his `t-printf` passes with GMP.

Then, I compile GCC 11.1.0 with GCC 4.9.2:

../../sources/gcc-11.1.0/configure --prefix=/usr/util/toolchain/gcc-11.1.0 -
-enable-comdat --disable-libgomp --disable-nls
--with-as=/usr/util/toolchain/bin
utils-2.36/bin/as --with-gmp=/usr/util/toolchain/gmp-6.2.1
--with-mpfr=/usr/util
/toolchain/mpfr-4.1.0 --with-mpc=/usr/util/toolchain/mpc-1.2.1
--enable-language
s=c,c++ --with-dwarf2

First it errors out when compiling charset.c:

../../../sources/gcc-11.1.0-new/libcpp/charset.c: In function 'cset_converter
init_iconv_desc(cpp_reader*, const char*, const char*)':
../../../sources/gcc-11.1.0-new/libcpp/charset.c:695:1: internal compiler
error: in plus_constant, at explow.c:101
  695 | }
  | ^
libbacktrace could not find executable to open 

Then, if libcpp's Makefile is patched so that charset.c is built with -O1, I
eventually run into other errors:

../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c: In function
'gcov_clear':
../../../../sources/gcc-11.1.0-new/libgcc/libgcov-interface.c:143:1: internal
compiler error: Illegal instruction
  143 | }
  | ^
libbacktrace could not find executable to open 

After making that compile with -O1:

../../../sources/gcc-11.1.0/zlib/inftrees.c: In function 'inflate_table':
../../../sources/gcc-11.1.0/zlib/inftrees.c:32:19: internal compiler error:
Illegal instruction
   32 | int ZLIB_INTERNAL inflate_table(type, lens, codes, table, bits, work)
  |   ^
libbacktrace could not find executable to open

I am only able to get a build of 11.1 with BOOT_CFLAGS="-g -O1"
BOOT_CXXFLAGS="-g -O1".

It's worth noting that I have rebuilt gmp with the -O1'd 11.1 build and it
fixed the `t-printf` test not passing. I then rebuilt mpfr and mpc against it
with 4.7.1 (4.9.2 and 11.1 can't seem to properly compile mpfr) and then tried
to build 11.1 against the new builds and still ran into the same issues.

[Bug libgcc/101489] New: Documentation gives wrong signatures for libgcc float128 routines

[harald at gigawatt dot nl via Gcc-bugs]

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

Bug ID: 101489
   Summary: Documentation gives wrong signatures for libgcc
float128 routines
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harald at gigawatt dot nl
  Target Milestone: ---

At ,
all functions that take __float128 / _Float128 are declared as taking long
double instead. It is possible this was written back when 128-bit float types
were only available as long double, only on some platforms, so it would have
been correct at that time, but it is no longer correct now that __float128 is
more widely available.

[Bug testsuite/101206] [12 Regression] gcc.target/aarch64/vect-vmaxv.c and gcc.target/aarch64/vect-vaddv.c fail

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

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

--- Comment #1 from Andrew Pinski  ---
It worked here:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/700977.html
but failed here:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/701197.html


Most likely canidate of introducing this regression:
r12-1551

[Bug c++/101488] Implement p1042r1 __VA_OPT__ placemarker changes

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

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

--- Comment #1 from Jakub Jelinek  ---
I've tried a WIP (with just 0 && or commenting out parts of current code
instead of removing/cleaning up) that attempts to treat __VA_OPT__ ( ... ) with
## before __VA_OPT__ and/or after ) more similarly to the case where the
__VA_OPT__, ( and ) tokens are missing:
--- libcpp/macro.c.jj   2021-07-16 11:10:08.512925510 +0200
+++ libcpp/macro.c  2021-07-17 15:55:03.178568895 +0200
@@ -2059,7 +2059,7 @@ replace_args (cpp_reader *pfile, cpp_has

  /* Remove any tail padding from inside the __VA_OPT__.  */
  paste_flag = tokens_buff_last_token_ptr (buff);
- while (paste_flag && paste_flag != start
+ while (0 && paste_flag && paste_flag != start
 && (*paste_flag)->type == CPP_PADDING)
{
  tokens_buff_remove_last_token (buff);
@@ -2184,7 +2184,7 @@ replace_args (cpp_reader *pfile, cpp_has
 previous emitted token is at the beginning of __VA_OPT__;
 placemarkers within __VA_OPT__ are ignored in that case.  */
  else if (arg_tokens_count == 0
-  && tmp_token_ptr != vaopt_start)
+/*&& tmp_token_ptr != vaopt_start */)
paste_flag = tmp_token_ptr;
}
}
@@ -2197,7 +2197,7 @@ replace_args (cpp_reader *pfile, cpp_has
 MACRO_ARG_TOKEN_EXPANDED,
 arg, arg->expanded);

- if (last_token_is (buff, vaopt_start))
+ if (0 && last_token_is (buff, vaopt_start))
{
  /* We're expanding an arg at the beginning of __VA_OPT__.
 Skip padding. */
@@ -2215,7 +2215,7 @@ replace_args (cpp_reader *pfile, cpp_has
   /* Padding on the left of an argument (unless RHS of ##).  */
   if ((!pfile->state.in_directive || pfile->state.directive_wants_padding)
  && src != macro->exp.tokens && !(src[-1].flags & PASTE_LEFT)
- && !last_token_is (buff, vaopt_start))
+ /* && !last_token_is (buff, vaopt_start) */)
{
  const cpp_token *t = padding_token (pfile, src);
  unsigned index = expanded_token_index (pfile, macro, src, i);
@@ -2301,7 +2301,7 @@ replace_args (cpp_reader *pfile, cpp_has

   /* Avoid paste on RHS (even case count == 0).  */
   if (!pfile->state.in_directive && !(src->flags & PASTE_LEFT)
- && !last_token_is (buff, vaopt_start))
+ /*&& !last_token_is (buff, vaopt_start)*/)
{
  const cpp_token *t = >avoid_paste;
  tokens_buff_add_token (buff, virt_locs,
@@ -3544,6 +3544,8 @@ create_iso_definition (cpp_reader *pfile
   bool varadic = false;
   bool ok = false;
   cpp_macro *macro = NULL;
+  bool vaopt_after_paste = false;
+  unsigned int vaopt_end_idx = 0;

   /* Look at the first token, to see if this is a function-like
  macro.   */
@@ -3700,14 +3702,33 @@ create_iso_definition (cpp_reader *pfile
token[-1].flags |= SP_DIGRAPH;
  if (token->flags & PREV_WHITE)
token[-1].flags |= SP_PREV_WHITE;
+ if (macro->count == vaopt_end_idx)
+   token[-2].flags |= PASTE_LEFT;
}
  following_paste_op = true;
}
   else
following_paste_op = false;

-  if (vaopt_tracker.update (token) == vaopt_state::ERROR)
+  vaopt_state::update_type vostate = vaopt_tracker.update (token);
+  if (vostate == vaopt_state::INCLUDE)
+   continue;
+  if (vostate == vaopt_state::ERROR)
goto out;
+  if (vostate == vaopt_state::BEGIN
+ && macro->count > 1
+ && (token[-1].flags & PASTE_LEFT))
+   vaopt_after_paste = true;
+  if (vostate == vaopt_state::DROP && vaopt_after_paste)
+   {
+ vaopt_after_paste = false;
+ /* Duplicate the PASTE_LEFT flag on ( after __VA_OPT__
+if ## is before __VA_OPT__.  */
+ if (!vaopt_tracker.stringify ())
+   token->flags |= PASTE_LEFT;
+   }
+  if (vostate == vaopt_state::END)
+   vaopt_end_idx = macro->count;
 }

   /* We're committed to winning now.  */

and that results into identical output on the #c0 testcase above as clang++,
and ditto macro_vaopt_p1042r1.cpp testcase, but macro_vaopt_expand.cpp differs
slightly:
-9: HT_A() C ( ) B ( ) "A()"
+9: TONG C ( ) B ( ) "A()"
-27_1: BA0 11
+27_1: BexpandedA0 11
(- is gcc with #__VA_OPT__ and the above patch, + is clang++).  That actually
matches how the F0 case in
#define LPAREN ( 
#define A0 expandedA0
#define A1  expandedA1 A0
#define A2  expandedA2 A1
#define A3  expandedA3 A2
#define A() B LPAREN )
#define B() C LPAREN )
#define C() D LPAREN )
#define HT_B() TONG
#define F0(x, ...) HT_ ## x x A()  #x
#define F(x, ...) HT_ ## __VA_OPT__(x x A()  #x)
8: F0(A(),1)
9: F(A(),1)
is handled, so I'm getting lost on what is supposed to be 

[Bug c++/101488] New: Implement p1042r1 __VA_OPT__ placemarker changes

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

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

Bug ID: 101488
   Summary: Implement p1042r1 __VA_OPT__ placemarker changes
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

With the https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575355.html
there are still some pending placemarker changes that need to be done for full
C++20 __VA_OPT__ support.

Testcases include besides c-c++-common/cpp/va-opt* also e.g.
#define A(x,...) a ## __VA_OPT__ (a) ## a
#define B(x,...) a ## __VA_OPT__ () ## a
#define C(x,...) a ## __VA_OPT__ (x) ## a
#define D(x,...) a ## __VA_OPT__ (x##x) ## a
#define E(x,...) a ## __VA_OPT__ (x##x 1) ## a
#define F(x,...) a ## __VA_OPT__ (1 x##x) ## a
v1: A(,)
v2: A(,1)
v3: A(2,1)
v4: B(,)
v5: B(,1)
v6: B(2,1)
v7: C(,)
v8: C(,1)
v9: C(2,1)
v10: D(,)
v11: D(,1)
v12: D(2,1)
v13: E(,)
v14: E(,1)
v15: E(2,1)
v16: F(,)
v17: F(,1)
v18: F(2,1)
or clang/test/Preprocessor/macro_vaopt_expand.cpp and
clang/test/Preprocessor/macro_vaopt_p1042r1.cpp
On the above testcase, trunk with the #__VA_OPT__ patch to clang difference is:
-v14: a1a
+v14: a 1a
-v17: a1a
+v17: a1 a
On the macro_vaopt_expand.cpp testcase, the difference between patched trunk
and clang is
-26: B1
-26_1: B1
+26: B 1
+26_1: B 1
-27: B11
+27: B 11
-28: B11
+28: B 11
and on the macro_vaopt_p1042r1.cpp testcase the difference is:
-4: ab
+4: a b
-4B: ab
+4B: a b

[Bug gcov-profile/101487] New: [GCOV] Wrong coverage of "switch" inside "while" loop

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 101487
   Summary: [GCOV] Wrong coverage of "switch" inside "while" loop
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

$ cat test.c
void foo(int x, int y) {
  while (x > 0)
switch (({
  if (y)
break;
  y;
})) {
case 2:
  x = 0;
}
}

int main() {
  foo(1, 1);
  return 0;
}

$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:66.67% of 12
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
1:1:void foo(int x, int y) {
1:2:  while (x > 0)
#:3:switch (({
1:4:  if (y)
1:5:break;
#:6:  y;
-:7:})) {
#:8:case 2:
#:9:  x = 0;
-:   10:}
1:   11:}
-:   12:
1:   13:int main() {
1:   14:  foo(1, 1);
1:   15:  return 0;
-:   16:}


Line 3 was wrongly marked as unexecuted

[Bug c++/101486] New: Rejects valid qualification conversion involving array of unknown bound in function template argument [P0388]

[leni536 at gmail dot com via Gcc-bugs]

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

Bug ID: 101486
   Summary: Rejects valid qualification conversion involving array
of unknown bound in function template argument [P0388]
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leni536 at gmail dot com
  Target Milestone: ---

Version:

g++
(Compiler-Explorer-Build-gcc-48e8a7a677b8356df946cd12fbb215538828e747-binutils-2.36.1)
12.0.0 20210707 (experimental)

Flags: -std=c++20 -pedantic-errors

Observed behavior:

Rejects the following code:

```
template 
void f1(const T(*)[10]);

template 
void f2(T(*)[]);

void bar(int (*ptr)[10]) {
f1(ptr); // accepts
f2(ptr); // rejects
}
```

Expected behavior:

Accept both function calls. Qualification conversions are allowed when deducing
template arguments in a pointer function parameter
(https://timsong-cpp.github.io/cppwp/n4868/temp.deduct#call-4.2). As of C++20
(P0388) converting `int (*)[10]` to `int (*)[]` is a valid qualification
conversion.

Exhibits:

https://godbolt.org/z/rcbMhEf45

[Bug gcov-profile/101147] [GCOV] Wrong coverage with label inside "for" loop

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #1 from Yang Wang  ---
sorry,its(In reply to Yang Wang from comment #0)
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-
> wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../configure -enable-checking=release
> -enable-languages=c,c++ -disable-multilib
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.2.0 (GCC) 
> 
> $ cat test.c
> #include 
> #include
> 
> int x;
> int main() {
>   int i = 0;
>   x = 0;
>   if (x) {
> for (; i < 10; ++i) {
> doit:
>   x = i;
> }
>   }
>   if (!x)
> goto doit;
>   if (x != 9)
> __builtin_abort();
>   return 0;
> }
> 
> $ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
> libgcov profiling error:/home/wangyang/coverage/test/test.gcda:overwriting
> an existing profile data with a different timestamp
> File 'test.c'
> Lines executed:91.67% of 12
> Creating 'test.c.gcov'
> 
> -:0:Source:test.c
> -:0:Graph:test.gcno
> -:0:Data:test.gcda
> -:0:Runs:1
> -:1:#include 
> -:2:#include
> -:3:
> -:4:int x;
> 1:5:int main() {
> 1:6:  int i = 0;
> 1:7:  x = 0;
> 1:8:  if (x) {
>   10*:9:for (; i < 10; ++i) {
> 9:   10:doit:
>10:   11:  x = i;
> -:   12:}
> -:   13:  }
> 2:   14:  if (!x)
> 1:   15:goto doit;
> 1:   16:  if (x != 9)
> #:   17:__builtin_abort();
> 1:   18:  return 0;
> -:   19:}
> 
> Coverage of line 9 should be same as line 10

sorry,it's line 10 should be same as line 11

[Bug c++/101485] New: Calling std::equal with std::byte* does not use memcmp

[dennis-hezel at gmx dot de via Gcc-bugs]

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

Bug ID: 101485
   Summary: Calling std::equal with std::byte* does not use memcmp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dennis-hezel at gmx dot de
  Target Milestone: ---

See https://godbolt.org/z/fKbhqe1sz

```
#include 

auto equal_with_bytes(std::byte* b1, std::byte* e1, std::byte* b2) {
  return std::equal(b1, e1, b2);
}

auto equal_with_chars(unsigned char* b1, unsigned char* e1, unsigned char* b2)
{
  return std::equal(b1, e1, b2);
}
```

In the above code `equal_with_chars` invokes `memcmp` while `equal_with_bytes`
does not, although it would be eligble.

The problematic code seems to be in `stl_algobase.h`

```
  template
_GLIBCXX20_CONSTEXPR
inline bool
__equal_aux1(_II1 __first1, _II1 __last1, _II2 __first2)
{
  typedef typename iterator_traits<_II1>::value_type _ValueType1;
  const bool __simple = ((__is_integer<_ValueType1>::__value
  || __is_pointer<_ValueType1>::__value)
 && __memcmpable<_II1, _II2>::__value);
  return std::__equal<__simple>::equal(__first1, __last1, __first2);
} 
```

since `std::byte` is neither an integer nor a pointer.

Suggested fix: Extend the condition with a check for `std::byte`

```
__is_integer<_ValueType1>::__value || __is_pointer<_ValueType1>::__value ||
__is_byte<_ValueType1>::__value
```

[Bug target/101484] New: [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 101484
   Summary: [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa
(gcn offload)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

trunk 20210717 ftbfs the gcn offload compiler (using a just built 20210717
trunk build):

configuration complains about:

checking assembler for working .subsection -1...
/packages/gcc/snap/gcc-snapshot-20210717/bin-gcn/nm: error: conftest.o The fil
e was not recognized as a valid object file

/packages/gcc/snap/gcc-snapshot-20210717/bin-gcn/nm: error: conftest.o The file
was not recognized as a valid object file

no


The linker tools point to the ones provided by LLVM 9.

Later then:

libtool: compile: 
/packages/gcc/snap/gcc-snapshot-20210717/build-gcn/./gcc/gfortran
-B/packages/gcc/snap/gcc-snapshot-20210717
/build-gcn/./gcc/ -nostdinc
-B/packages/gcc/snap/gcc-snapshot-20210717/build-gcn/amdgcn-amdhsa/newlib/
-isystem /packages/gcc/s
nap/gcc-snapshot-20210717/build-gcn/amdgcn-amdhsa/newlib/targ-include -isystem
/packages/gcc/snap/gcc-snapshot-20210717/src-gcn
/newlib/libc/include -B/usr/lib/gcc-snapshot/amdgcn-amdhsa/bin/
-B/usr/lib/gcc-snapshot/amdgcn-amdhsa/lib/ -isystem /usr/lib/gc
c-snapshot/amdgcn-amdhsa/include -isystem
/usr/lib/gcc-snapshot/amdgcn-amdhsa/sys-include -L. -Wall -L../libgfortran -c
../../.
./src-gcn/libgomp/config/accel/openacc.f90 -o openacc.o
In file included from ../../../src-gcn/libgomp/barrier.c:28:
In function 'gcn_thrs',
inlined from 'gomp_thread' at ../../../src-gcn/libgomp/libgomp.h:803:10,
inlined from 'GOMP_barrier' at ../../../src-gcn/libgomp/barrier.c:34:29:
../../../src-gcn/libgomp/libgomp.h:792:10: error: array subscript 0 is outside
array bounds of '__lds struct gomp_thread * __lds[0]' [-Werror=array-bounds]
  792 |   return *thrs;
  |  ^

[Bug target/101205] csinv does not have an zero_extend version

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The fix actually might be simplier than I had expected because csneg is
> already implement, just need to extend it to csinv also like so:

Yep that works. time to test it.

[Bug target/101205] csinv does not have an zero_extend version

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

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

--- Comment #3 from Andrew Pinski  ---
The fix actually might be simplier than I had expected because csneg is already
implement, just need to extend it to csinv also like so:
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index f12a0bebd3d..8cd259fca9c 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4203,15 +4203,15 @@ (define_insn "*csinv3_insn"
   [(set_attr "type" "csel")]
 )

-(define_insn "csneg3_uxtw_insn"
+(define_insn "*cs3_uxtw_insn4"
   [(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
  (if_then_else:SI
(match_operand 1 "aarch64_comparison_operation" "")
-   (neg:SI (match_operand:SI 2 "register_operand" "r"))
+   (NEG_NOT:SI (match_operand:SI 2 "register_operand" "r"))
(match_operand:SI 3 "aarch64_reg_or_zero" "rZ"]
   ""
-  "csneg\\t%w0, %w3, %w2, %M1"
+  "cs\\t%w0, %w3, %w2, %M1"
   [(set_attr "type" "csel")]
 )

[Bug target/101205] csinv does not have an zero_extend version

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

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

--- Comment #2 from Andrew Pinski  ---
The problem is csinv3si_insn, csinv3_uxtw_insn2, nor csinv3_uxtw_insn3 would
match as those have the zero_extend inside the if/then/else rather on the
outside which is being matched here:
Trying 36 -> 19:
   36: r94:SI={(cc:CC==0)?~r100:SI:r101:SI}
  REG_DEAD r100:SI
  REG_DEAD cc:CC
  REG_DEAD r101:SI
   19: x0:DI=zero_extend(r94:SI)
  REG_DEAD r94:SI
Failed to match this instruction:
(set (reg/i:DI 0 x0)
(zero_extend:DI (if_then_else:SI (eq (reg:CC 66 cc)
(const_int 0 [0]))
(not:SI (reg:SI 100))
(reg:SI 101

[Bug libstdc++/101483] New: join_view::iterator's constructor missing std::move

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 101483
   Summary: join_view::iterator's constructor missing std::move
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This is specified in [range.join.iterator#7]: "Effects: Initializes outer_­
with std​::​move(i.outer_­), inner_­ with std​::​move(i.inner_­), and parent_­
with i.parent_­."

https://godbolt.org/z/8Mox7qGss

[Bug c++/96227] Comma operation sequencing issue

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think so, the evaluation order when invoking operator, not through the x, y
syntax is like for any other function call, the arguments evaluation is
indeterminately sequenced.
See https://en.cppreference.com/w/cpp/language/eval_order