[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

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

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

--- Comment #8 from Siddhesh Poyarekar  ---
(In reply to Martin Sebor from comment #7)
> The dollar sign in the internal attr_access string implies a VLA bound and
> the attr_access::vla_bounds() function queries the VLA bounds.  That should
> make it possible to distinguish the two cases.

I noticed a attr_access.internal_p which has the following comment in
attribs.c:

/* Forms containing the square bracket are internal-only
   (not specified by an attribute declaration), and used
   for various forms of array and VLA parameters.  */   

That should be a good differentiator right?  It fixes the motivating case here.
 This is what I'm testing a bit more extensively.

diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index b0b50774936..1e87739eda6 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -1477,7 +1477,7 @@ parm_object_size (struct object_size_info *osi, tree var)
   tree typesize = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (parm)));
   tree sz = NULL_TREE;

-  if (access && access->sizarg != UINT_MAX)
+  if (access && access->sizarg != UINT_MAX && !access->internal_p)
 {
   tree fnargs = DECL_ARGUMENTS (fndecl);
   tree arg = NULL_TREE;

[Bug target/105033] New: Suboptimal for vec_concat lower halves of two vectors.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 105033
   Summary: Suboptimal for vec_concat lower halves of two vectors.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

typedef _Float16 v8hf __attribute__((vector_size (16)));
 typedef _Float16 v4hf __attribute__((vector_size (8)));

 v8hf foov (v4hf a, v4hf b)
 {
   return __builtin_shufflevector (a, b, 0, 1, 2, 3, 4, 5, 6, 7);
}

 typedef short v8hi __attribute__((vector_size (16)));
 typedef short v4hi __attribute__((vector_size (8)));

 v8hi foov (v4hi a, v4hi b)
 {
   return __builtin_shufflevector (a, b, 0, 1, 2, 3, 4, 5, 6, 7);
}

with -march=skylake-avx512 -O2

_Z4foovDv4_DF16_S_:
vmovq   xmm2, xmm0
vmovdqa xmm0, XMMWORD PTR .LC0[rip]
vmovq   xmm1, xmm1
vpermi2wxmm0, xmm2, xmm1
ret
foov(short __vector(4), short __vector(4)):
vmovq   xmm2, xmm0
vmovdqa xmm0, XMMWORD PTR .LC0[rip]
vmovq   xmm1, xmm1
vpermi2wxmm0, xmm2, xmm1
ret
.LC0:
.value  0
.value  1
.value  2
.value  3
.value  8
.value  9
.value  10
.value  11

But with -march=skylake -O2

It can be optimized to

_Z4foovDv4_DF16_S_:
vmovq   xmm1, xmm1
vmovq   xmm0, xmm0
vpunpcklqdq xmm0, xmm0, xmm1
ret
foov(short __vector(4), short __vector(4)):
vmovq   xmm1, xmm1
vmovq   xmm0, xmm0
vpunpcklqdq xmm0, xmm0, xmm1
ret

[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Hongtao.liu  ---
stuck in this loop

1731  for (prev_insn = PREV_INSN (start_insn),
1732 next_insn = NEXT_INSN (start_insn);
1733   insns_num != 1 && (prev_insn != NULL || next_insn != NULL);
)
1734{
1735  if (prev_insn != NULL)
1736{
1737  if (bitmap_bit_p (_reg_info[regno].insn_bitmap,
(gdb)
1738INSN_UID (prev_insn)))
1739{
1740  first_insn = prev_insn;
1741  insns_num--;
1742}
1743prev_insn = PREV_INSN (prev_insn);
1744}
1745  if (next_insn != NULL && second_insn == NULL)
1746{
1747  if (! bitmap_bit_p (_reg_info[regno].insn_bitmap,
(gdb)
1748INSN_UID (next_insn)))
1749next_insn = NEXT_INSN (next_insn);
1750  else
1751{
1752  second_insn = next_insn;
1753  insns_num--;
1754}
1755}
1756}

(gdb) p second_insn
$5 = (rtx_insn *) 0x7fffea2f9980
(gdb) p prev_insn
$6 = (rtx_insn *) 0x0
(gdb) p next_insn
$7 = (rtx_insn *) 0x7fffea2f9980
(gdb) p second_insn
$8 = (rtx_insn *) 0x7fffea2f9980
(gdb) p insns_num
$9 = 2
(gdb) f
#0  find_reload_regno_insns (regno=91, start=@0x7fffd308: 0xcc2968
::release()+68>, finish=@0x7fffd300:
0x7fffd320) at gcc/lra-assigns.cc:1733

[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage

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

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

--- Comment #1 from Andrew Pinski  ---
GCC 6.4 used to ICE:
: In function 'void* __sys_mmap(void*, size_t, int, int, int, off_t)':
:39:1: error: unable to find a register to spill
 }
 ^
:39:1: error: this is the insn:
(insn 21 20 37 2 (set (reg:SI 102 [orig:96 offset.10_18 ] [96])
(mem/c:SI (plus:SI (reg/f:SI 16 argp)
(const_int 28 [0x1c])) [1 offset+0 S4 A32])) :37 86
{*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 16 argp)
(nil)))
:39: confused by earlier errors, bailing out

[Bug c/105032] New: Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage

[ammarfaizi2 at gmail dot com via Gcc-bugs]

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

Bug ID: 105032
   Summary: Compiling inline ASM x86 causing GCC stuck in an
endless loop with 100% CPU usage
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ammarfaizi2 at gmail dot com
  Target Milestone: ---

Full story:
https://lore.kernel.org/lkml/9cfcb296-9dfe-aef1-4209-20a3a95c5...@gnuweeb.org/

Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU
usage.

-
ammarfaizi2@integral2:/tmp$ gcc --version
gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ammarfaizi2@integral2:/tmp$ gcc -m32 -o test test.c # stuck here...
^C
ammarfaizi2@integral2:/tmp$ 
-



Reproducer:
-
#include 
#include 
#include 

#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6)\
({  \
long _ret;  \
register long _num  asm("eax") = (num); \
register long _arg1 asm("ebx") = (long)(arg1);  \
register long _arg2 asm("ecx") = (long)(arg2);  \
register long _arg3 asm("edx") = (long)(arg3);  \
register long _arg4 asm("esi") = (long)(arg4);  \
register long _arg5 asm("edi") = (long)(arg5);  \
long _arg6 = (long)(arg6); /* Always be in memory */\
\
asm volatile (  \
"pushl  %[_arg6]\n\t"   \
"pushl  %%ebp\n\t"  \
"movl   4(%%esp), %%ebp\n\t"\
"int$0x80\n\t"  \
"popl   %%ebp\n\t"  \
"addl   $4,%%esp\n\t"   \
: "=a"(_ret)\
: "r"(_num), "r"(_arg1), "r"(_arg2), "r"(_arg3),\
  "r"(_arg4),"r"(_arg5), [_arg6]"m"(_arg6)  \
: "memory", "cc"\
);  \
_ret;   \
})


static void *__sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
off_t offset)
{
offset >>= 12;
return (void *)my_syscall6(__NR_mmap2, addr, length, prot, flags, fd,
   offset);
}

int main(void)
{
__sys_mmap(NULL, 0x1000, PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
return 0;
}

[Bug libstdc++/105031] New: wrong constexpr if statement in basic_stacktrace::operator=(basic_stacktrace&&)

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105031
   Summary: wrong constexpr if statement in
basic_stacktrace::operator=(basic_stacktrace&&)
   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: ---

include/std/stacktrace#L386:

  if constexpr (_AllocTraits::is_always_equal::value)
std::swap(_M_impl, __other._M_impl);
  else if (_M_alloc == __other._M_alloc)
std::swap(_M_impl, __other._M_impl);
  else
{
  const auto __s = __other.size();

  if constexpr (__pocma || _M_impl._M_capacity < __s)
{
  // Need to allocate new storage.
  _M_clear();

_M_impl._M_capacity cannot be used as a constant expression.

https://godbolt.org/z/zfxd6n5Eb

[Bug target/104967] ICE: Segmentation fault (in find_instance)

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-23
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Kewen Lin  ---
Confirmed, it's not a dup of PR104482.

[Bug tree-optimization/105030] New: store motion if-change flag causes if-conversion optimization can't be taken.

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

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

Bug ID: 105030
   Summary: store motion if-change flag causes if-conversion
optimization can't be taken.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guihaoc at gcc dot gnu.org
  Target Milestone: ---

// source code
extern void bar (double *, int);

void foo (double a[], int n)
{
  double atemp = 0.5;
  for (int i = 0; i < n; i++)
if (a[i] < atemp)
  atemp = a[i];
  bar (, n);
}

// -O3 -fdump-tree-lim2
  if (_4 < atemp.0_5)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  atemp_lsm.4_24 = _4;
  atemp_lsm_flag.5_25 = 1;

It creates the lsm flag in lim2 pass. So the "then" block has two sets which
blocks the if-conversion optimization.

//assemble -O3 -ffast-math -fno-unroll-loops on ppc64le
.L5:
lfd 0,0(3)
addi 3,3,8
fcmpu 0,12,0
ble 0,.L3
fmr 12,0
li 9,1
.L3:
bdnz .L5
andi. 9,9,0x1
beq 0,.L2
stfd 12,32(1)

Inefficient fcmpu is used. If the source code is tweaked as below, the
efficient xvmindp is generated.

// tweaked source code
extern void bar (double *, int);

void foo (double a[], int n)
{
  double atemp = 0.5;
  for (int i = 0; i < n; i++)
if (a[i] < atemp)
  atemp = a[i];
  double btemp = atemp;
  bar (, n);
}

//assembly
.L4:
lxv 0,0(9)
addi 9,9,16
xvmindp 12,12,0
bdnz .L4

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Alan Modra  ---
Do check that the result is not a direct call.  I think I was wrong to say the
assert could be removed (or modified as you have done).

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||andre.schackier at gmail dot 
com

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

[Bug c++/105020] #pragma GCC diagnostic ignored "-Wmultichar" doesn't work

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 53431 (well it is a dup of bug 100891 which was marked as a dup of
that other bug).

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

[Bug bootstrap/95934] bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||eyalroz1 at gmx dot com

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

[Bug sanitizer/105029] sanitizer_internal_defs.h:254:72: error: size of array ‘assertion_failed__1135’ is negative

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Keywords||build

--- Comment #2 from Andrew Pinski  ---
This was fixed in GCC 9.3.0 (and the GCC 10+). There is not much can be done
for older GCC as they are not maintained any more. You could backport the fix
if you want.

The commit was r9-8063-g75003cdd23c310 (for the backport to GCC 9) and
r10-4986-g4abc46b51af575 for GCC 10+ releases.

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

[Bug sanitizer/105029] sanitizer_internal_defs.h:254:72: error: size of array ‘assertion_failed__1135’ is negative

[eyalroz1 at gmx dot com via Gcc-bugs]

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

Eyal Rozenberg  changed:

   What|Removed |Added

   Host||x86_64-pc-linux-gnu
 Target||x86_64-pc-linux-gnu

--- Comment #1 from Eyal Rozenberg  ---
I'm running on an x86_64 machine, with an Intel i5-7600K CPU.

[Bug sanitizer/105029] New: sanitizer_internal_defs.h:254:72: error: size of array ‘assertion_failed__1135’ is negative

[eyalroz1 at gmx dot com via Gcc-bugs]

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

Bug ID: 105029
   Summary: sanitizer_internal_defs.h:254:72: error: size of array
‘assertion_failed__1135’ is negative
   Product: gcc
   Version: 6.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz1 at gmx dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I'm build GCC 6.5.0 on Devuan GNU/Linux Chimaera. The configuration line was:

 ./configure --prefix=/opt/gcc-6.5.0 --enable-languages="c++,c"

and then I ran make. I get the following error:

In file included from
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:186:0:
../../.././libsanitizer/sanitizer_common/sanitizer_internal_defs.h:254:72:
error: size of array ‘assertion_failed__1135’ is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../.././libsanitizer/sanitizer_common/sanitizer_internal_defs.h:248:30:
note: in expansion of macro ‘IMPL_COMPILER_ASSERT’
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^~~~
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1424:3:
note: in expansion of macro ‘COMPILER_CHECK’
   COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
   ^~
../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1135:1:
note: in expansion of macro ‘CHECK_SIZE_AND_OFFSET’
 CHECK_SIZE_AND_OFFSET(ipc_perm, mode);
 ^

CC and CXX are unset, and the default compiler is gcc (Debian 10.2.1-6) 10.2.1
20210110 ; I can provide more information about my system as necessary.

[Bug c++/105024] VLAs with C++ causes the gimplifier to produce __builtin_stack_save with the line# of the closing }

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |c++
 Ever confirmed|0   |1
   Last reconfirmed||2022-03-22

--- Comment #2 from Andrew Pinski  ---
Note the C front-end produces:
  [/app/example.cpp:1:34] saved_stack.10 = __builtin_stack_save ();

This is all VLA related which means this is using an extension to C++.

[Bug middle-end/105024] VLAs with C++ causes the gimplifier to produce __builtin_stack_save with the line# of the closing }

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-debug
Summary|g++ generates wrong line|VLAs with C++ causes the
   |debug information   |gimplifier to produce
   ||__builtin_stack_save with
   ||the line# of the closing }
  Component|debug   |middle-end

--- Comment #1 from Andrew Pinski  ---
  [/app/example.cpp:17:1] saved_stack.15 = __builtin_stack_save ();

[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[pkubaj at anongoth dot pl via Gcc-bugs]

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

--- Comment #5 from Piotr Kubaj  ---
The command line output I pasted in the OP is actually from 12-20220320 (but
12-20220306 fails the same way). So I guess that fix did nothing for
powerpc64-freebsd.

Regarding .machine, I will check it tomorrow.

[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

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

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

--- Comment #4 from Segher Boessenkool  ---
Have you tried with something with

commit 80fcc4b6afee72443bef551064826b3b4b6785e6
Author: Segher Boessenkool 
Date:   Fri Mar 11 21:15:18 2022 +

rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)

Fixes: 77eccbf39ed5


?  And, what .machine do you get now?

[Bug middle-end/105028] [11/12 Regression] gcc.dg/long_branch.c compilation time increases by 10x on BE system after r11-5648

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
   Keywords||ra
Summary|gcc.dg/long_branch.c|[11/12 Regression]
   |compilation time increases  |gcc.dg/long_branch.c
   |by 10x on BE system after   |compilation time increases
   |r11-5648|by 10x on BE system after
   ||r11-5648

[Bug other/105028] New: gcc.dg/long_branch.c compilation time increases by 10x on BE system after r11-5648

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

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

Bug ID: 105028
   Summary: gcc.dg/long_branch.c compilation time increases by 10x
on BE system after r11-5648
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Starting back in gcc 11 there were a couple of test case compilations that
started to time out on our older BE systems.  The most common one was
gcc.dg/long_branch.c.  It happened so rarely I never got back to investigating
if it was always this way or there was some recent change.

I finally tracked it down to r11-5648.  Note it also happens in trunk.  Before
the change on a power 7 long_branch.c takes about 4s to compile with -m32 and
5.5s with -m64 (varies a bit between runs).  With r11-5648 that changes to 50+s
and 9s respectively.  On a busy system that 50s can stretch out long enough to
hit the 300 second ulimit set for test case compilations and thus they time
out. The time change increases are similar on a power 8 BE machine, too, but as
they are faster they never hit the timeout.

I see no difference in compilation time on an LE system.

I looked using -ftime-report at what was taking more time and saw these:

g:337d6362458ab033d3bfe287dda37f9da5577406, r11-5647:
 phase opt and generate :   3.89 ( 97%)   0.04 ( 44%)   3.92 ( 95%)
   43M ( 91%)
 callgraph functions expansion  :   3.23 ( 80%)   0.02 ( 22%)   3.25 ( 79%)
   32M ( 68%)
 integrated RA  :   0.23 (  6%)   0.00 (  0%)   0.23 (  6%)
   12M ( 26%)

g:037fe26ee1ac18581bf0ad646d48591c97d10bd3, r11-5648:
 phase opt and generate :  32.86 (100%)   0.16 ( 73%)  33.02 ( 99%)
  205M ( 98%)
 callgraph functions expansion  :  32.28 ( 98%)   0.14 ( 64%)  32.42 ( 98%)
  194M ( 93%)
 integrated RA  :  20.70 ( 63%)   0.08 ( 36%)  20.79 ( 63%)
   50M ( 24%)

The latter run had a few more phases that ran, too.

So, is this a real problem or a "just live with it" thing?


commit 037fe26ee1ac18581bf0ad646d48591c97d10bd3
Author: Jakub Jelinek 
Date:   Wed Dec 2 11:32:19 2020 +0100

expansion: Further improve double-word modulo, division and divmod
[PR97459]

[Bug rtl-optimization/105023] new test case g++.dg/other/pr104989.C ICEs

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

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

--- Comment #2 from Segher Boessenkool  ---
@findex BLKmode
@item BLKmode
``Block'' mode represents values that are aggregates to which none of
the other modes apply.  In RTL, only memory references can have this mode,
and only if they appear in string-move or vector instructions.  On machines
which have no such instructions, @code{BLKmode} will not appear in RTL@.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

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

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

--- Comment #22 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #21)
> It did so even before my or Roger's patch.

It was my first successful bootstrap in a few days, and I replied to this old
PR
without looking everywhere else first.

> As I wrote in PR105023, the problem is that the rs6000 backend decides to
> pass that huge (2 Exabytes long) argument partially in registers (reg:BLK 3
> 3) and partially on the stack,

It isn't the backend that decides to do that.  The backend correctly does what
the ABI requires here: pass up to eight things in GPRs, and the rest in the
parameter save area (on the stack) (this is ignoring FPRs and the like, for
simplicity).

> while on most other backends it is passed
> just on the stack and we sorry at that point instead of trying to overwrite
> compiler's memory.  (reg:BLK 3 3) looks just way too suspect to me, do we
> pass say 256 byte long homogenous structures that way too?

reg:BLK is invalid always, :BLK is valid on memory only.

[Bug libstdc++/105027] New: Missing constraints on std::bit_cast

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 105027
   Summary: Missing constraints on std::bit_cast
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

[bit.cast] Constraints (nb. prior to P1719R2 these were specified as SFINAE,
but they have been there since the start):
(1.1) sizeof(To) == sizeof(From) is true;
(1.2) is_­trivially_­copyable_­v is true; and
(1.3) is_­trivially_­copyable_­v is true.

#include 
template
concept BitCastable = requires(U u) { std::bit_cast(u); };
static_assert(BitCastable); // OK
static_assert(BitCastable); // #1: different size
struct A { A(A const&); int i; };
static_assert(BitCastable); // #2: not trivially copyable

#1 and #2 are erroneously accepted although the corresponding call to
std::bit_cast would fail internally; MSVC and clang (with libc++) correctly
reject.

static_assert(BitCastable); // #3: see below
int f();
long l = std::bit_cast(f); // #4

By my reading of [temp.deduct] #3 should be a hard error, since sizeof(int())
is not only invalid; it is not SFINAE. However, compilers that allow it (gcc
everywhere, MSVC and clang as SFINAE) should then reject either by SFINAE, or
as having the incorrect size, or since function types are not trivially
copyable; gcc/libstdc++ does not and also accepts #4, decaying the function
reference to a function pointer; clang/libstdc++ rejects within its own
__builtin_bit_cast.

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org

--- Comment #3 from Peter Bergner  ---
(In reply to Alan Modra from comment #1)
> Likely "gcc_assert (INTVAL (cookie) == 0);" in
> rs6000_sibcall_aix can just be deleted.

I think it's still useful to ensure we have a valid sibcall.  The problem is
that with pcrel, we have more opportunities to do a sibcall than we did before,
meaning it doesn't matter if the callee has the same TOC value as us, since we
don't use it.  I think we just need to relax the assert when the caller is
pcrel.  The following fixes the ICE and I'm putting it through a bootstrap &
regtest cycle.

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index a7645820b1e..fc5cfeac4fa 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -25659,7 +25659,7 @@ rs6000_sibcall_aix (rtx value, rtx func_desc, rtx
tlsarg, rtx cookie)
   rtx r12 = NULL_RTX;
   rtx func_addr = func_desc;

-  gcc_assert (INTVAL (cookie) == 0);
+  gcc_assert (rs6000_pcrel_p () || INTVAL (cookie) == 0);

   if (global_tlsarg)
 tlsarg = global_tlsarg;

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

--- Comment #19 from Jonathan Wakely  ---
(In reply to Patrick Palka from comment #17)
> Sounds related to PR92067, which requests that
> __is_constructible(Incomplete) be a hard error.

That request is far too simplistic and needs to be considered carefully.
Consider the example in PR 104242, where overload resolution for the
constructor has to consider the is_constructible constraints on std::any's
constructor while the type is incomplete.

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

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

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

--- Comment #2 from Jonathan Wakely  ---
We need to be careful about this in SFINAE contexts. It can't be a hard error,
because it's extremely common for constructors to be constrained with
std::is_constructible, and for overload resolution to consider constructors for
incomplete types.

[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
would be nice if GCC could detect this itself (see bug 72789)

[Bug libstdc++/105021] [11/12 Regression] Missing freestanding headers: bits/atomic_base.h:41:10: fatal error: bits/atomic_wait.h: No such file or directory

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||10.3.1
  Known to fail||11.2.1, 12.0
   Last reconfirmed||2022-03-22
 Ever confirmed|0   |1
   Target Milestone|--- |11.3
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[pkubaj at anongoth dot pl via Gcc-bugs]

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

Piotr Kubaj  changed:

   What|Removed |Added

 CC||segher at kernel dot 
crashing.org

--- Comment #3 from Piotr Kubaj  ---
Current git bisect visualize --oneline:
93557e6dc39 (refs/bisect/bad) Update gcc de.po
77eccbf39ed rs6000: Improve .machine
0e5d9ae8e41 Update .po files
591d2130348 c++: Standard mangling abbreviations & modules
14dfbb53594 (HEAD) Fix 'libgomp.oacc-c-c++-common/kernels-decompose-1.c'
expected diagnostics
458ad38ce2b analyzer: reduce svalue depth limit from 13 to 12 [PR103521]
c3402486afa mkruntimeinc: skip _FILE

14dfbb53594 is still building but it looks like it will succeed. This would
mean that 77eccbf39ed is the culprit.

@segher
Could you look into it?

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

[eyalroz1 at gmx dot com via Gcc-bugs]

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

--- Comment #18 from Eyal Rozenberg  ---
(In reply to Jason Merrill from comment #14)
> > Alternatively, when not following the standard strictly, why should it not
> > be option (4.): Ignore the official restriction on determining (nothrow)
> > constructibility, make a best-effort attempt to determine it anyway ( which
> > in this example should succeed), and report failure otherwise.
> > 
> > ?
> 
> If we can define such a best-effort attempt, it could be a candidate for
> standardization.

Try to resolve is_nothrow_constructible as long as this resolution does not
involve DataWithMember or any of its constituents (e.g. as though we had seen
the initializer expression before the definition of DataWithVariant even
began). If that  succeeds - we're good; if it fails - that's an error all on
its own and we (sort of) don't care about the DataWithVariant error; and if it
trips the wire and tries to refer to DataWithMember or a constituent thereof -
give up on the parse attempt.

Now, this is not _best_ effort, it's actually _minimal_ effort, since we're not
willing to even accept use of A and its constituents, but it's still something.
Not a candidate for standardization though.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

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

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

--- Comment #15 from Marek Polacek  ---
Patch seems safe to backport to 11.

[Bug c/84685] Designated initializers warning

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

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

--- Comment #7 from Marek Polacek  ---
Patch seems safe to backport to 11.

[Bug c/84685] Designated initializers warning

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:4b7d9f8f51bd96d290aac230c71e501fcb6b21a6

commit r12-7772-g4b7d9f8f51bd96d290aac230c71e501fcb6b21a6
Author: Marek Polacek 
Date:   Tue Mar 22 14:37:02 2022 -0400

c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings.  Our docs say that this warning "does not warn about designated
initializers", but we give a warning for

1) the array case:

  struct S {
struct N {
  int a;
  int b;
} c[1];
  } d = {
.c[0].a = 1,
.c[0].b = 1, // missing initializer for field 'b' of 'struct N'
  };

we warn because push_init_level, when constructing an array, clears
constructor_designated (which the warning relies on), and we forget
that we were in a designated initializer context.  Fixed by the
push_init_level hunk; and

2) the compound literal case:

  struct T {
int a;
int *b;
int c;
  };

  struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of
'struct T'

where set_designator properly sets constructor_designated to 1, but the
compound literal causes us to create a whole new initializer_stack in
start_init, which clears constructor_designated.  Then, after we've parsed
the compound literal, finish_init flushes the initializer_stack entry,
but doesn't restore constructor_designated, so we forget we were in
a designated initializer context, which causes the bogus warning.  (The
designated flag is also tracked in constructor_stack, but in this case,
we didn't perform push_init_level between set_designator and start_init
so it wasn't saved anywhere.)

PR c/82283
PR c/84685

gcc/c/ChangeLog:

* c-typeck.cc (struct initializer_stack): Add 'designated' member.
(start_init): Set it.
(finish_init): Restore constructor_designated.
(push_init_level): Set constructor_designated to the value of
constructor_designated in the upper constructor_stack.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmissing-field-initializers-1.c: New test.
* gcc.dg/Wmissing-field-initializers-2.c: New test.
* gcc.dg/Wmissing-field-initializers-3.c: New test.
* gcc.dg/Wmissing-field-initializers-4.c: New test.
* gcc.dg/Wmissing-field-initializers-5.c: New test.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

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

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

--- Comment #14 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:4b7d9f8f51bd96d290aac230c71e501fcb6b21a6

commit r12-7772-g4b7d9f8f51bd96d290aac230c71e501fcb6b21a6
Author: Marek Polacek 
Date:   Tue Mar 22 14:37:02 2022 -0400

c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings.  Our docs say that this warning "does not warn about designated
initializers", but we give a warning for

1) the array case:

  struct S {
struct N {
  int a;
  int b;
} c[1];
  } d = {
.c[0].a = 1,
.c[0].b = 1, // missing initializer for field 'b' of 'struct N'
  };

we warn because push_init_level, when constructing an array, clears
constructor_designated (which the warning relies on), and we forget
that we were in a designated initializer context.  Fixed by the
push_init_level hunk; and

2) the compound literal case:

  struct T {
int a;
int *b;
int c;
  };

  struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of
'struct T'

where set_designator properly sets constructor_designated to 1, but the
compound literal causes us to create a whole new initializer_stack in
start_init, which clears constructor_designated.  Then, after we've parsed
the compound literal, finish_init flushes the initializer_stack entry,
but doesn't restore constructor_designated, so we forget we were in
a designated initializer context, which causes the bogus warning.  (The
designated flag is also tracked in constructor_stack, but in this case,
we didn't perform push_init_level between set_designator and start_init
so it wasn't saved anywhere.)

PR c/82283
PR c/84685

gcc/c/ChangeLog:

* c-typeck.cc (struct initializer_stack): Add 'designated' member.
(start_init): Set it.
(finish_init): Restore constructor_designated.
(push_init_level): Set constructor_designated to the value of
constructor_designated in the upper constructor_stack.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmissing-field-initializers-1.c: New test.
* gcc.dg/Wmissing-field-initializers-2.c: New test.
* gcc.dg/Wmissing-field-initializers-3.c: New test.
* gcc.dg/Wmissing-field-initializers-4.c: New test.
* gcc.dg/Wmissing-field-initializers-5.c: New test.

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #5 from Ed Catmur  ---
Posted https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592154.html

[Bug c/105026] New: ICE: SIGSEGV in tree_class_check with __int128 and _Fract comparison

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105026
   Summary: ICE: SIGSEGV in tree_class_check with __int128 and
_Fract comparison
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: error-recovery
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: mips64el-unknown-linux-gnuabi64

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

Compiler output:
$ mips64el-unknown-linux-gnuabi64-gcc testcase.c -wrapper
valgrind,-q,--track-origins=yes
testcase.c:1:1: sorry, unimplemented: GCC cannot support operators with integer
types and fixed-point types that have too many integral and fractional bits
together
1 | int i = (__int128) 0 == (_Fract) 0;
  | ^~~
==15373== Invalid read of size 2
==15373==at 0x969319: tree_class_check (tree.h:3573)
==15373==by 0x969319: shorten_compare(unsigned int, tree_node**,
tree_node**, tree_node**, tree_code*) (c-common.cc:3197)
==15373==by 0x8DE4F9: build_binary_op(unsigned int, tree_code, tree_node*,
tree_node*, bool) (c-typeck.cc:12746)
==15373==by 0x8E2BB1: parser_build_binary_op(unsigned int, tree_code,
c_expr, c_expr) (c-typeck.cc:3821)
==15373==by 0x9093C9: c_parser_binary_expression(c_parser*, c_expr*,
tree_node*) (c-parser.cc:8036)
==15373==by 0x90A50B: c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) (c-parser.cc:7606)
==15373==by 0x90AD30: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.cc:7521)
==15373==by 0x90DF0C: c_parser_initializer (c-parser.cc:5218)
==15373==by 0x90DF0C: c_parser_initializer(c_parser*) (c-parser.cc:5210)
==15373==by 0x92354E: c_parser_declaration_or_fndef(c_parser*, bool, bool,
bool, bool, bool, tree_node**, vec*, bool,
tree_node*, oacc_routine_data*, bool*) (c-parser.cc:2281)
==15373==by 0x92C7E3: c_parser_external_declaration(c_parser*)
(c-parser.cc:1779)
==15373==by 0x92D22B: c_parser_translation_unit (c-parser.cc:1652)
==15373==by 0x92D22B: c_parse_file() (c-parser.cc:23357)
==15373==by 0x98F2DD: c_common_parse_file() (c-opts.cc:1240)
==15373==by 0xF383AD: compile_file() (toplev.cc:452)
==15373==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==15373== 
testcase.c:1:1: internal compiler error: Segmentation fault
0xf382cf crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x969319 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/repo/gcc-trunk/gcc/tree.h:3573
0x969319 shorten_compare(unsigned int, tree_node**, tree_node**, tree_node**,
tree_code*)
/repo/gcc-trunk/gcc/c-family/c-common.cc:3197
0x8de4f9 build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/c/c-typeck.cc:12746
0x8e2bb1 parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
/repo/gcc-trunk/gcc/c/c-typeck.cc:3821
0x9093c9 c_parser_binary_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8036
0x90a50b c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:7606
0x90ad30 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.cc:7521
0x90df0c c_parser_initializer
/repo/gcc-trunk/gcc/c/c-parser.cc:5218
0x90df0c c_parser_initializer
/repo/gcc-trunk/gcc/c/c-parser.cc:5210
0x92354e c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2281
0x92c7e3 c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:1779
0x92d22b c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1652
0x92d22b c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:23357
0x98f2dd c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1240
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ mips64el-unknown-linux-gnuabi64-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-mips64el/bin/mips64el-unknown-linux-gnuabi64-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7721-20220319135312-gb60bc913cca-checking-yes-rtl-df-extra-mips64el/bin/../libexec/gcc/mips64el-unknown-linux-gnuabi64/12.0.1/lto-wrapper
Target: mips64el-unknown-linux-gnuabi64
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/mips64el-unknown-linux-gnuabi64 --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=mips64el-unknown-linux-gnuabi64
--with-ld=/usr/bin/mips64el-unknown-linux-gnuabi64-ld
--with-as=/usr/bin/mips64el-unknown-linux-gnuabi64-as 

[Bug middle-end/105025] New: ICE: in gimplify_expr, at gimplify.cc:15863 with _Fract

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105025
   Summary: ICE: in gimplify_expr, at gimplify.cc:15863 with
_Fract
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: mips64el-unknown-linux-gnuabi64

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

Compiler output:
$ mips64el-unknown-linux-gnuabi64-gcc testcase.c 
testcase.c: In function 'foo':
testcase.c:6:11: internal compiler error: in gimplify_expr, at
gimplify.cc:15863
6 |   r >= (0 && r);
  |   ^~
0x651f4e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15863
0xc1cda6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15833
0xc2bfc6 gimplify_cond_expr
/repo/gcc-trunk/gcc/gimplify.cc:4404
0xc1d909 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15013
0xc20b46 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7109
0xc1e87b gimplify_statement_list
/repo/gcc-trunk/gcc/gimplify.cc:2019
0xc1e87b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15501
0xc20b46 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7109
0xc2c5f5 gimplify_cond_expr
/repo/gcc-trunk/gcc/gimplify.cc:4393
0xc1d909 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15013
0xc20b46 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7109
0xc2c4a6 gimplify_cond_expr
/repo/gcc-trunk/gcc/gimplify.cc:4364
0xc1d909 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15013
0xc1f5cc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15824
0xc1cddf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15835
0xc20b46 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7109
0xc2129d gimplify_bind_expr
/repo/gcc-trunk/gcc/gimplify.cc:1428
0xc1d670 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15257
0xc2ee4f gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7109
0xc2ee4f gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:16313
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ mips64el-unknown-linux-gnuabi64-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-mips64el/bin/mips64el-unknown-linux-gnuabi64-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7721-20220319135312-gb60bc913cca-checking-yes-rtl-df-extra-mips64el/bin/../libexec/gcc/mips64el-unknown-linux-gnuabi64/12.0.1/lto-wrapper
Target: mips64el-unknown-linux-gnuabi64
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/mips64el-unknown-linux-gnuabi64 --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=mips64el-unknown-linux-gnuabi64
--with-ld=/usr/bin/mips64el-unknown-linux-gnuabi64-ld
--with-as=/usr/bin/mips64el-unknown-linux-gnuabi64-as --disable-multilib
--with-abi=64 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7721-20220319135312-gb60bc913cca-checking-yes-rtl-df-extra-mips64el
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220319 (experimental) (GCC)

[Bug fortran/104999] [12 Regression] runtime error: pointer index expression with base 0x00000cf67720 overflowed to 0xffffffffea627728

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

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

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

https://gcc.gnu.org/g:774ab2edcb5f3a24ed3a5cffd1143bd49a69f1ee

commit r12-7771-g774ab2edcb5f3a24ed3a5cffd1143bd49a69f1ee
Author: Harald Anlauf 
Date:   Tue Mar 22 20:54:18 2022 +0100

Fortran: ensure intialization of stride array

gcc/fortran/ChangeLog:

PR fortran/104999
* simplify.cc (gfc_simplify_cshift): Ensure temporary holding
source array stride is initialized.

[Bug target/104984] Use hard-fp for libgcc single-floating-point routines

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #2 from joseph at codesourcery dot com  ---
See libgcc/config/rs6000/t-e500v1-fp (which should have been removed along 
with associated configure logic when the powerpcspe port was removed, the 
cases using that file should no longer be reachable), for an example of a 
configuration using hardware floating point for single precision only.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #21 from Jakub Jelinek  ---
It did so even before my or Roger's patch.
As I wrote in PR105023, the problem is that the rs6000 backend decides to pass
that huge (2 Exabytes long) argument partially in registers (reg:BLK 3 3) and
partially on the stack, while on most other backends it is passed just on the
stack and we sorry at that point instead of trying to overwrite compiler's
memory.  (reg:BLK 3 3) looks just way too suspect to me, do we pass say 256
byte long homogenous structures that way too?

[Bug rtl-optimization/105023] new test case g++.dg/other/pr104989.C ICEs

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

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

--- Comment #1 from Jakub Jelinek  ---
There is already
FAIL: g++.dg/other/pr84964.C  -std=c++98 (internal compiler error: Aborted
signal terminated program cc1plus)
FAIL: g++.dg/other/pr84964.C  -std=c++98  1 blank line(s) in output
FAIL: g++.dg/other/pr84964.C  -std=c++14 (internal compiler error: Aborted
signal terminated program cc1plus)
FAIL: g++.dg/other/pr84964.C  -std=c++14  1 blank line(s) in output
FAIL: g++.dg/other/pr84964.C  -std=c++17 (internal compiler error: Aborted
signal terminated program cc1plus)
FAIL: g++.dg/other/pr84964.C  -std=c++17  1 blank line(s) in output
FAIL: g++.dg/other/pr84964.C  -std=c++20 (internal compiler error: Aborted
signal terminated program cc1plus)
FAIL: g++.dg/other/pr84964.C  -std=c++20  1 blank line(s) in output
and this is just a dup of it, we ICE before the sorry is called.

The reason it works on x86 etc. is that in that case if (args[i].reg == 0 ||
args[i].pass_on_stack) is true, while on ppc64le it is false - it wants to pass
that huge argument partially in (reg:BLK 3 3) (isn't that a bug?  BLKmode REGs
are just weird) and partially on the stack.
Either this should be fixed in the backend, or the generic code should just
sorry no matter if huge arguments are passed partially in registers or not.

[Bug c++/105024] New: g++ generates wrong line debug information

[blarsen at redhat dot com via Gcc-bugs]

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

Bug ID: 105024
   Summary: g++ generates wrong line debug information
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blarsen at redhat dot com
  Target Milestone: ---

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

When compiling the attached test case with the options -g -O0, there is a bug
in the line table generation.

The first instruction of merge_sort is assigned to line 17 instead of line 2,
then backtracks to line 5. It generates some confusion when trying to debug the
code, as GDB prints the wrong line when that instruction is being evaluated.

My guess is that g++ sees the early exit and assumes that part of the "if" is
related to that exit, and mislabels that instruction. I tried removing the
"return" statement and putting the rest of the code inside an else block, and
the line table was closer to what I expected.

This seems to be a long standing bug, as I can reproduce it with g++ 8.5.0 and
g++ 11.2.1, though 8.5.0 sets the line as 16 instead.

[Bug analyzer/105017] [12 Regression] gcc/analyzer/sm-taint.cc:631:21: warning: private field 'm_mem_space' is not used [-Wunused-private-field]

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug c/105013] Valgrind reports accessing uninitialized memory when -O2 option is used

[jamesallwright at yahoo dot co.uk via Gcc-bugs]

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

--- Comment #2 from James Allwright  ---
Here is the valgrind output

valgrind ./bug
==2490== Memcheck, a memory error detector
==2490== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2490== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==2490== Command: ./bug
==2490== 
out = 
command = 
==2490== Conditional jump or move depends on uninitialised value(s)
==2490==at 0x1092DB: example_func (bug.c:37)
==2490==by 0x1090D3: main (bug.c:44)
==2490== 
==2490== 
==2490== HEAP SUMMARY:
==2490== in use at exit: 0 bytes in 0 blocks
==2490==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==2490== 
==2490== All heap blocks were freed -- no leaks are possible
==2490== 
==2490== Use --track-origins=yes to see where uninitialised values come from
==2490== For lists of detected and suppressed errors, rerun with: -s
==2490== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint

[rootkea at gmail dot com via Gcc-bugs]

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

Avinash Sonawane  changed:

   What|Removed |Added

 CC||rootkea at gmail dot com

--- Comment #5 from Avinash Sonawane  ---
Since we are not quite there yet we should remove (comment out) the tainted-*
checkers listed under -fanalyzer in docs which says "Enabling this option
effectively enables the following warnings:".

Also, the wording in docs suggest that `-fanalyzer -fanalyzer-checker=taint`
enables the taint checkers *in addition* to the default checkers but currently,
enabling -fanalyzer-checker=taint stops other checkers. I came to know about
this after finding none of other checkers working. We should document this.

I just submitted a patch which documents the above fact and comments out the
tainted-* checkers under -fanalyzer.

When this issue gets fixed we can simply remove the .texi comment commands and
drop the line saying other checkers not working with taint checker.

https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592144.html

[Bug c/84685] Designated initializers warning

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
I have a patch.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
I have a patch which fixes all the testcases here.

[Bug rtl-optimization/105023] New: new test case g++.dg/other/pr104989.C ICEs

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

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

Bug ID: 105023
   Summary: new test case g++.dg/other/pr104989.C ICEs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6adbb51eaa85f5bfed1ee06327daca306d48986d, r12-7749-g6adbb51eaa85f5
make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/other/pr104989.C"
FAIL: g++.dg/other/pr104989.C  -std=gnu++98 (internal compiler error:
Segmentation fault signal terminated program cc1plus)
FAIL: g++.dg/other/pr104989.C  -std=gnu++14 (internal compiler error:
Segmentation fault signal terminated program cc1plus)
FAIL: g++.dg/other/pr104989.C  -std=gnu++17 (internal compiler error:
Segmentation fault signal terminated program cc1plus)
FAIL: g++.dg/other/pr104989.C  -std=gnu++20 (internal compiler error: Aborted
signal terminated program cc1plus)
FAIL: g++.dg/other/pr104989.C  -std=gnu++20  1 blank line(s) in output

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/other/pr104989.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++20 -fnon-call-exceptions -S -o pr104989.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/other/pr104989.C:6:9:
warning: width of 'a::b' exceeds its type
during RTL pass: expand
*** Error in
`/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../cc1plus': free():
corrupted unsorted chunks: 0x12f22e30 ***
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/other/pr104989.C: In
function 'void c(...)':

*** Error in
`/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../cc1plus': double
free or corruption (!prev): 0x12f22e30 ***
xg++: internal compiler error: Aborted signal terminated program cc1plus



commit 6adbb51eaa85f5bfed1ee06327daca306d48986d (HEAD, refs/bisect/bad)
Author: Jakub Jelinek 
Date:   Tue Mar 22 08:39:40 2022 +0100

calls: Fix error recovery after sorry differently [PR104989]

[Bug analyzer/105022] New: -Wanalyzer-tainted-allocation-size doesn't warn for custom allocators marked with "malloc" attribute

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

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

Bug ID: 105022
   Summary: -Wanalyzer-tainted-allocation-size doesn't warn for
custom allocators marked with "malloc" attribute
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Given:

typedef __SIZE_TYPE__ size_t;

void *custom_alloc (size_t sz) __attribute__((malloc (__builtin_free)));

void * __attribute__ ((tainted_args))
test_ (size_t sz)
{
  return custom_alloc (sz);
}

and compiling with:
  -fanalyzer -fanalyzer-checker=taint

there is no output.  Ideally the analyzer should complain with
-Wanalyzer-tainted-allocation-size that "sz" is attacker-controlled.


https://godbolt.org/z/oohh39Gjj

[Bug libstdc++/105021] New: [11/12 Regression] Missing freestanding headers: bits/atomic_base.h:41:10: fatal error: bits/atomic_wait.h: No such file or directory

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

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

Bug ID: 105021
   Summary: [11/12 Regression] Missing freestanding headers:
bits/atomic_base.h:41:10: fatal error:
bits/atomic_wait.h: No such file or directory
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

With -std=c++20 a simple #include  fails for a freestanding library:


In file included from /tmp/freestanding/include/c++/12.0.1/atomic:41,
 from /tmp/freestanding/include/c++/12.0.1/bits/stdc++.h:4,
 from :1:
/tmp/freestanding/include/c++/12.0.1/bits/atomic_base.h:41:10: fatal error:
bits/atomic_wait.h: No such file or directory
   41 | #include 
  |  ^~~~
compilation terminated.


That header also needs  and  which are not
freestanding either.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #17 from Patrick Palka  ---
(In reply to Jason Merrill from comment #16)
> A more targeted possiblity would be for __is_constructible to error if the
> class has unparsed DMI.

Sounds related to PR92067, which requests that __is_constructible(Incomplete)
be a hard error.

[Bug c++/105020] #pragma GCC diagnostic ignored "-Wmultichar" doesn't work

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

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

--- Comment #1 from Andrew Pinski  ---
There might be a dup of this bug but basically the issue is the c++ does lexing
up front and the pragma is handled in frontend after lexing.

[Bug c++/105020] New: #pragma GCC diagnostic ignored "-Wmultichar" doesn't work

[andre.schackier at gmail dot com via Gcc-bugs]

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

Bug ID: 105020
   Summary: #pragma GCC diagnostic ignored "-Wmultichar" doesn't
work
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andre.schackier at gmail dot com
  Target Milestone: ---

Created attachment 52664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52664=edit
The used source code

Give the following source code:

```cpp
#pragma GCC diagnostic ignored "-Wmultichar"
#pragma GCC diagnostic ignored "-Woverflow"

void EnterCharacter(unsigned short);

int main() { EnterCharacter('\0xFF'); }
```

Produces the following output:
```
source>:6:29: warning: multi-character character constant [-Wmultichar]
6 | int main() { EnterCharacter('\0xFF'); }
  | ^~~
```

It seems all version from gcc-4.6.4 to gcc-11.2 are affected including trunk.

[godbolt link](https://godbolt.org/z/PTWPModPT)

[Bug middle-end/105009] [12 Regression] Fails to build with --target=xtensa-esp32-elf

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That message is clearly from clang++, when I try:
extern inline __attribute__ ((__gnu_inline__)) int
tree_to_poly_int64 (int i)
{
  return i + 1;
}

int
tree_to_poly_int64 (int i)
{
  return i + 2;
}
clang++ complains:
error: redefinition of a 'extern inline' function 'tree_to_poly_int64' is not
supported in C++
Those inlines in tree.h are guarded with
#if !defined ENABLE_TREE_CHECKING && (GCC_VERSION >= 4003)
and
#define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)

If you are using the ill-designed -fgnuc-version= option for clang, don't.
While I've added a hack for it for libstdc++ headers, there is no way we are
going to do this everywhere in GCC sources itself.
__GNUC__ macro doesn't mean support for GNU extensions, it means using the GCC
compiler or at least something compatible with it up to the version, which
perhaps ICC more/less is, but clang certainly is not.

[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
Seems like it may expose a problem in gcc.target/i386/sse2-v1ti-shift-3.c as
well:

 for (i=0; i<128; i++) {
<...>
if ((ti)rotr_v1ti(ut,i) != (ti)rotr_ti(x,i))
  __builtin_abort();
if ((ti)rotl_v1ti(ut,i) != (ti)rotl_ti(x,i))

And those are defined:

uv1ti rotr_v1ti(uv1ti x, unsigned int i) { return (x >> i) | (x << (128-i)); }
uv1ti rotl_v1ti(uv1ti x, unsigned int i) { return (x << i) | (x >> (128-i)); }

so when i is 0, they can perform a shift of 128 on a 128 bit object.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

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

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #16)
> Same here:
> 
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> [...]
>   TLS0x00c3d0 0x0806c3d0 0x 0x0 0x00024 RW  0x10

If both linkers reproduce the problem and the PT_TLS is 16-byte aligned
and thr.1 in it is at offset 0 (or multiple of 16), then I'd think that points
to the dynamic linker.
The TLS transitions are performed by the linker.

> > But the question is if in
> > struct __attribute__((aligned (32))) S { long long buf[4]; };
> > __thread struct S s;
> > S *foo (void) { return  }
> > it won't return not properly 32-byte aligned pointer too (and is that in all
> > threads or just some (initial vs. other threads)?
> 
> I've wrapped that in a small test programming, calling foo both from the
> initial thread and a new one: in all cases, the return value from foo
> was 32-byte aligned as expected.

Perhaps the problem only shows when the PT_TLS size is not a multiple of the
alignment?  Or depends on other PT_TLS segments in shared libraries in the same
process.  The pointer2.f90 testcase will link against libgomp which uses TLS as
well.
So perhaps try:
struct __attribute__((aligned (16))) S { char buf[0x24]; };
__thread struct S s;
__attribute__((noipa)) S *foo (void) { return  }
int
main ()
{
  #pragma omp parallel
  __builtin_printf ("%p\n", foo ());
  return 0;
}
?

[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap

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

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

Bug 104890 Summary: [11 Regression]  doesn't work with 
__attribute__((target ("general-regs-only"))) and -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890

   What|Removed |Added

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

[Bug target/104890] [11 Regression] doesn't work with __attribute__((target ("general-regs-only"))) and -march=i686

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|12.0|11.3
 Status|NEW |RESOLVED

--- Comment #18 from H.J. Lu  ---
Fixed for GCC 12 and GCC 11.3.

[Bug target/105000] __attribute__((target("general-regs-only"))) doesn't disable AVX/SSE ISAs in ix86_isa_flags2

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.3

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 12 and GCC 11.3.

[Bug target/105000] __attribute__((target("general-regs-only"))) doesn't disable AVX/SSE ISAs in ix86_isa_flags2

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by H.J. Lu :

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

commit r11-9686-gf45603f39ba167dd0ea1b002c96ddccbfe2b4b2f
Author: H.J. Lu 
Date:   Mon Mar 21 11:45:59 2022 -0700

x86: Disable SSE in ISA2 for -mgeneral-regs-only

Replace OPTION_MASK_ISA2_AVX512F_UNSET with OPTION_MASK_ISA2_SSE_UNSET
in OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET to disable SSE, AVX and
AVX512 ISAs.

gcc/

PR target/105000
* common/config/i386/i386-common.c
(OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET): Replace
OPTION_MASK_ISA2_AVX512F_UNSET with OPTION_MASK_ISA2_SSE_UNSET.

gcc/testsuite/

PR target/105000
* gcc.target/i386/pr105000-1.c: New test.
* gcc.target/i386/pr105000-2.c: Likewise.
* gcc.target/i386/pr105000-3.c: Likewise.

(cherry picked from commit e8b6afa98f0a390c955a089a3d61fdd24f4e1d3a)

[Bug target/104890] [11 Regression] doesn't work with __attribute__((target ("general-regs-only"))) and -march=i686

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-11 branch has been updated by H.J. Lu :

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

commit r11-9685-gf407033b7ca27a75cccef8310360e275cdb94d26
Author: H.J. Lu 
Date:   Sun Mar 13 08:57:51 2022 -0700

x86: Also check _SOFT_FLOAT in 

Push target("general-regs-only") in  if x87 is enabled.

gcc/

PR target/104890
* config/i386/x86gprintrin.h: Also check _SOFT_FLOAT before
pushing target("general-regs-only").

gcc/testsuite/

PR target/104890
* gcc.target/i386/pr104890.c: New test.

(cherry picked from commit 3117ffce4c1598a35e724138735b099262353358)

[Bug target/105019] New: [nvptx] malias in libgomp results in "Internal error: reference to deleted section"

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

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

Bug ID: 105019
   Summary: [nvptx] malias in libgomp results in "Internal error:
reference to deleted section"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

As mentioned in the commit message for malias:
...
When enabling malias by default, libgomp detects alias support and
consequently libgomp.a will contains a few uses of .alias.  This however
results in aforementioned "Internal error: reference to deleted section" in
many test-cases.  Either there's some error with how .alias is used, or
there's a driver bug.  While this issue is not resolved, we keep malias
off-by-default.
...

This needs to be investigated, and if it's a driver bug, reported to nvidia, or
otherwise fixed or worked around.

Note: the same error showed up in a test-case where the call to an alias was
inlined, and consequently the alias referenced a defined but unused function. 
To observe this, disable this bit:
...
  if (!cgraph_node::get (name)->referred_to_p ())
/* Prevent "Internal error: reference to deleted section".  */
return;
...
in nvptx_asm_output_def_from_decls and run nvptx.exp=alias-2.c:
...
PASS: gcc.target/nvptx/alias-2.c (test for excess errors)
spawn nvptx-none-run ./alias-2.exe^M
fatal   : Internal error: reference to deleted section^M
nvptx-run: cuLinkComplete failed: unknown error (CUDA_ERROR_UNKNOWN, 999)^M
FAIL: gcc.target/nvptx/alias-2.c execution test
...

So it's possible that the error somehow related to this scenario.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

--- Comment #16 from Jason Merrill  ---
A more targeted possiblity would be for __is_constructible to error if the
class has unparsed DMI.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

--- Comment #15 from Jason Merrill  ---
Created attachment 52663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52663=edit
patch to make dependency on unparsed DMI a hard error

This doesn't seem to break anything in the library, only the two front-end
tests that were specifically for the SFINAE behavior.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

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

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

--- Comment #20 from Segher Boessenkool  ---
FAIL: g++.dg/other/pr84964.C  -std=c++14 (internal compiler error: Aborted
signal terminated program cc1plus)

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #19 from Segher Boessenkool  ---
This now ICEs with a segfault on powerpc64-linux.

[Bug c++/96917] decltype(auto) variable initialized with lambda by-reference capture has incorrect type

[gufideg at gmail dot com via Gcc-bugs]

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

Guillaume Racicot  changed:

   What|Removed |Added

 CC||gufideg at gmail dot com

--- Comment #2 from Guillaume Racicot  ---
Seems this bug also apply to deduced return type:

template 
void foo();

void bar() {
int i;
auto l = []() -> decltype(auto) {
foo();
return i;
};
l();
foo();
}


Yield the assembly:

bar():
sub rsp, 8
callvoid foo()
add rsp, 8
jmp void foo()


Strangely, replacing the return expression to `return
static_cast(i);` seems to fix the behaviour.

[Bug target/105014] [nvptx] FAIL: gcc.dg/pr97459-1.c execution test

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

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #0)
> > On a quadro k2000 with driver 470.103.01, I run into:
> 
> So, sm_30.
> 
> > ...
> > FAIL: gcc.dg/pr97459-1.c execution test
> 
> Reproduced on geforce gt710 (sm_35), with same driver.

But not on quadro k620 (sm_50).

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from Jakub Jelinek  ---
> If the movaps that it fails on are:
> movaps  %xmm1, thr.1@ntpoff(%ebx)
> movdqu  16(%eax), %xmm2
> movaps  %xmm2, thr.1@ntpoff+16(%ebx)
> then I'd say it must be some Solaris bug, because:
> .section.tbss,"awT",@nobits
> .align 16
> .type   thr.1, @object
> .size   thr.1, 36
> thr.1:
> .zero   36
> so thr.1 symbol should be 16-byte aligned and so movaps to that address should
> work.
> On pointer2.o, is the .tbss section properly 16-byte aligned?
> On i686-linux I see in readelf -Wa:
>   [ 8] .tbss NOBITS   000360 24 00 WAT  0   0
> 16

Same on Solaris:

  [ 8] .tbss NOBITS   000330 24 00 WAT  0   0
16

> What about the executable (in that case the PT_TLS segment is more important
> (whether it has 16-byte p_align).

Same here:

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  TLS0x00c3d0 0x0806c3d0 0x 0x0 0x00024 RW  0x10

> If Solaris dynamic linker doesn't ensure proper alignment of TLS vars (or
> assembler or linker screw it up in the middle), it would be nice to find out 
> if
> it does for all alignments or just say higher than 8-byte, and perhaps add 
> some
> workaround on the GCC side somewhere.
> On the pointer2.f90 testcase it is symtab_node::can_increase_alignment_p that
> decides if the alignment of the var can be done, so perhaps we'd need a target
> hook that for Solaris would say that one can't increase alignment of TLS vars.

We could try that once we know for certain that's the case (and get it
fixed at the same time).

However, when gld is in use, the test fails in exactly the same way.

> But the question is if in
> struct __attribute__((aligned (32))) S { long long buf[4]; };
> __thread struct S s;
> S *foo (void) { return  }
> it won't return not properly 32-byte aligned pointer too (and is that in all
> threads or just some (initial vs. other threads)?

I've wrapped that in a small test programming, calling foo both from the
initial thread and a new one: in all cases, the return value from foo
was 32-byte aligned as expected.

One thing I wondered about: Solaris ld used to be very picky about
exactly following the use of registers in TLS sequences: the Linker and
Libraries guide documents %eax for TLS LE:

https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html#scrolltoc

Maybe the use of %ebx in this code is the program?  At least the test
program above does use %eax, as expected.

We had issues like this both for amd64 and sparc in the past.

[Bug c++/105006] [12 Regression] ice: tree check: expected function_decl, have using_decl in maybe_push_used_methods, at cp/class.cc:1325

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/105014] [nvptx] FAIL: gcc.dg/pr97459-1.c execution test

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> On a quadro k2000 with driver 470.103.01, I run into:

So, sm_30.

> ...
> FAIL: gcc.dg/pr97459-1.c execution test

Reproduced on geforce gt710 (sm_35), with same driver.

[Bug ipa/104303] [12 regression] gnatmake is miscompiled by IPA/modref

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Honza, any progress on this?

[Bug target/104984] Use hard-fp for libgcc single-floating-point routines

[archicharmer at mail dot ru via Gcc-bugs]

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

--- Comment #1 from Den  ---
No one?.. Then, let's discourse.
These are inside the file t-hardfp-sfdf :

hardfp_float_modes := sf df
hardfp_int_modes := si
hardfp_extensions := sfdf
hardfp_truncations := dfsf

and these are inside the file t-softfp-sfdf :

softfp_float_modes := sf df
softfp_int_modes := si di
softfp_extensions := sfdf
softfp_truncations := dfsf

I assume it might be reasonable to create a new file. Let's call it
t-hardsf-soft-df . I believe these lines will be correct:

hardfp_float_modes := sf
softfp_float_modes := df
hardfp_int_modes := si

But what to set for extensions and truncations? And to which one in this case?

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #22 from Avi Kivity  ---
Maintainers, please review the patch posted in [1].


[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591907.html

[Bug c++/102489] [12 Regression] coroutines: ICE in is_this_parameter, at cp/semantics.c:11273 since r12-3529-g70ee703c479081ac

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
I think the testcase won't hurt.

[Bug c++/102489] [12 Regression] coroutines: ICE in is_this_parameter, at cp/semantics.c:11273 since r12-3529-g70ee703c479081ac

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-7770-gb6e33907ebe89361f8ddfb7481534cbf4a97f213
Author: Jakub Jelinek 
Date:   Tue Mar 22 15:37:20 2022 +0100

testsuite: Add testcase for already fixed PR [PR102489]

This got broken with r12-3529 and fixed with r12-5255.

2022-03-22  Jakub Jelinek  

PR c++/102489
* g++.dg/coroutines/pr102489.C: New test.

[Bug target/104882] [12 Regression] MVE: Wrong code at -O2 since r12-1434-g046a3beb1673bf4a61c131373b6a5e84158e92bf

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

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

--- Comment #3 from Christophe Lyon  ---
Revert patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592136.html

[Bug target/105018] [nvptx] Need better alias support

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

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

--- Comment #2 from Tom de Vries  ---
As mentioned before by amonakov, a possibility is to add alias support to the
nvptx-tools linker, and use that.

[Bug target/105018] [nvptx] Need better alias support

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

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

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> Aliases to aliases are not supported (see libgomp.c-c++-common/pr96390.c).
> This is currently not prohibited by the compiler, but with the driver link we
> run into:  "Internal error: alias to unknown symbol" .

And that is the reason that libgomp.c-c++-common/pr96390.c and friends doesn't
pass when I do:
...
/* { dg-additional-options "-foffload=-mptx=6.3 -foffload=-malias" { target
offload_target_nvptx } } */
...

[Bug tree-optimization/104969] Likely a false positive of -D_FORTIFY_SOURCE=3

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=28989
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #4 from Siddhesh Poyarekar  ---
Moving this to glibc, since gcc is working as expected.

[Bug target/105018] New: [nvptx] Need better alias support

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

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

Bug ID: 105018
   Summary: [nvptx] Need better alias support
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

We currently have alias support enabled by malias, which relies on the ptx
.alias directive.

There is a number of limitations, listed in the commit adding malias:
...
Only function aliases are supported.

Weak aliases are not supported.  That is, if I disable the check in
nvptx_asm_output_def_from_decls that disallows this, a weak alias is emitted
and parsed by the driver.  But the test gcc.dg/globalalias.c starts failing,
with the behaviour matching the comment about "weird behavior of AIX's .set
pseudo-op": a weak alias may resolve to different functions in different
files.

Aliases to weak symbols are not supported (see gcc.dg/localalias.c).  This is
currently not prohibited by the compiler, but with the driver link we run
into: "error: Function test with .weak scope cannot be aliased".

Aliases to aliases are not supported (see libgomp.c-c++-common/pr96390.c).
This is currently not prohibited by the compiler, but with the driver link we
run into:  "Internal error: alias to unknown symbol" .

Unreferenced aliases are not emitted (these can occur f.i. when inlining a
call to an alias).  This avoids driver link error "Internal error: reference
to deleted section".
...

We'd like an implementation that doesn't have (all of) these limitations.

[Bug target/105000] __attribute__((target("general-regs-only"))) doesn't disable AVX/SSE ISAs in ix86_isa_flags2

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Ever confirmed|0   |1
   Last reconfirmed||2022-03-22
 Resolution|FIXED   |---

--- Comment #6 from H.J. Lu  ---
GCC 11 isn't fixed yet.

[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #8 from Andrew Macleod  ---
Is this always true?

I implemented this for GCC13 in the new side-effect code, and its causing
problems in fortran.

In particular  gfortran.dg/check_bits_1.f90 goes into an infinite loop. I am
seeing things like

nb = bit_size (i)
do shift = 0, nb
 k = shiftl (i, shift) ! Fortran 2008
 i = shiftr (k, shift)

So it appears to do shifts on [0, 32] rather than [0, 31], and when I go look
for fortran 2008 info, i find:

"Its value must be non-negative, and less than or equal to BIT_SIZE(I)"

so it seem [0, N] for fortran rather than [0, N)?   Are there other language
issues as well?

[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #5 from Tom de Vries  ---
Using the test-case from comment 0 and:
...
/* { dg-additional-options "-foffload=-malias -foffload=-mptx=6.3 -O0" } */
...
I get:
...
$ strings test.exe | grep -i alias.alias
_ZN1VILi1EEC1ImvEET_,_ZN1VILi1EEC2ImvEET_;
...
so I see a normal alias, not a weak alias.

The test-case still fails in the abort.

Note that I get the same result with:
...
/* { dg-additional-options "-foffload=-mno-alias -foffload=-mptx=6.3 -O2" } */
...

There may be a problem with the test-case, there may be a problem with nvptx
c++ support, but the alias issue seems to have been addresses, so I'm closing
this one.

[Bug fortran/102314] [12 Regression] ICE in verify_ssa, at tree-ssa.c:1076 since r12-1319-gd4d38135b3137f1d

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

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

--- Comment #4 from Jakub Jelinek  ---
Though, if we make those arrays incomplete, gfc_omp_finish_clause will need to
figure out what size to use.  This is in:
  if (OMP_CLAUSE_SIZE (c) == NULL_TREE)
OMP_CLAUSE_SIZE (c)
  = DECL_P (decl) ? DECL_SIZE_UNIT (decl)
  : TYPE_SIZE_UNIT (TREE_TYPE (decl));
  if (gimplify_expr (_CLAUSE_SIZE (c), pre_p,
 NULL, is_gimple_val, fb_rvalue) == GS_ERROR)
OMP_CLAUSE_SIZE (c) = size_int (0);
and the gimplify_expr part is what my change added.  We'll need to check some
Fortran specific type flags etc. to see it is a deferred-length character and
find the corresponding . variable, though TYPE_LANG_SPECIFIC is NULL on the
ARRAY_TYPE created by gfc_get_character_type_len_for_eltype -> build_array_type
it seems.

[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression]
   |std::variant default|[CWG2335] std::variant
   |constructor |default constructor and
   ||unparsed DMI

--- Comment #14 from Jason Merrill  ---
(In reply to Eyal Rozenberg from comment #12)
> (In reply to Jason Merrill from comment #8)
> > We cannot correctly resolve is_nothrow_constructible until we've parsed
> > the DMI.  Given that, we have three options:
> > 
> > 1) Conservatively say no.
> > 2) Optimistically guess yes.
> > 3) Non-SFINAE error.
> >
> > ("We" in this sentence is the C++ standard.)
> 
> But in this page, "we" is the compiler. IIUC, the standard does not allow
> for determing is_nothrow_constructible. Am I correct? If that really is
> the case, shouldn't the compiler emit an error saying that?

Indeed, that's the question.

> Alternatively, when not following the standard strictly, why should it not
> be option (4.): Ignore the official restriction on determining (nothrow)
> constructibility, make a best-effort attempt to determine it anyway ( which
> in this example should succeed), and report failure otherwise.
> 
> ?

If we can define such a best-effort attempt, it could be a candidate for
standardization.

> > PR81359 changed our behavior from 3 to 1.
> 
> I searched that bug page for the rationale, and couldn't quite get it.

The patch made the error about depending on an unparsed initializer subject to
SFINAE, so that the implicit default ctor just isn't a viable candidate in this
context.  So for the testcase in comment #1, A is not default-constructible
until we reach the end of DataWithStruct.

The problem comes when we cache this answer in the is_default_constructible
class; now the rest of the compilation thinks A isn't default-constructible
because we happened to check it within DataWithStruct.

This seems analogous to type completeness; if A were forward-declared, and the
definition moved after the is_default_constructible test, we'd have the same
situation.  But that the standard library traits require that their argument be
complete, which avoids the caching problem at the top level, though we might
still end up caching based on the completeness of some intermediary.

The traits completeness requirement seems to suggest that making the unparsed
initializer a hard error again is the right way to go.  But I'm uneasy about
making this change at this point in GCC 12 stage 4; I'm definitely not going to
backport it.

[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++

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

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

Bug 97102 Summary: [nvptx] PTX JIT compilation failed when using aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102

   What|Removed |Added

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

[Bug target/97102] [nvptx] PTX JIT compilation failed when using aliases

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #8 from Tom de Vries  ---
The test-case from comment 0 now works in combination with:
/* { dg-additional-options "-foffload=-malias -foffload=-mptx=6.3" } */

[Bug fortran/102314] [12 Regression] ICE in verify_ssa, at tree-ssa.c:1076 since r12-1319-gd4d38135b3137f1d

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think those types:
  character(kind=1)[1:.y] * y;
don't really make sense for the character(:) allocatables, I think much better
would be to leave the TYPE_MAX_VALUE from TYPE_DOMAIN out, making it [1:].
[1:.y] nicely expresses the intent, in most places y (if it is not NULL) should
point to [1:.y] array.  But if we emit a DECL_EXPR for it, it will be just
wrong,
the middle-end expects the C/C++ VLA behavior, the size is computed once (when
encountering the DECL_EXPR), then the VLA is allocated with it and that is the
size it has from that point on.
The deferred-length (is that the right term) arrays work differently from this
though, the length can be changed at any time.  So the VLA length is always
determined from the current value of the .y variable (except in the short spots
where that is updated and the var not yet reallocated).

[Bug libgomp/98215] Coalescing memory in target region creates slower code

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

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

Tom de Vries  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
 CC||vries at gcc dot gnu.org

[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt

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

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

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #5 from Tom de Vries  ---
Fixed.

[Bug target/104783] [nvptx, openmp] Hang/abort with atomic update in simd construct

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #8 from Tom de Vries  ---
Fixed.

[Bug target/104957] [nvptx] Use .alias directive (available starting ptx isa version 6.3)

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #5 from Tom de Vries  ---
Committed.

[Bug target/104925] [nvptx] Use "%" as register prefix

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #2 from Tom de Vries  ---
Fixed.

[Bug target/104925] [nvptx] Use "%" as register prefix

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:24ee43194a542768b987be5d8021ae4ba7bad7b5

commit r12-7769-g24ee43194a542768b987be5d8021ae4ba7bad7b5
Author: Tom de Vries 
Date:   Sun Mar 20 12:10:45 2022 +0100

[nvptx] Use '%' as register prefix

The percentage sign as first character of a ptx identifier can be used to
avoid name conflicts, e.g., between user-defined variable names and
compiler-generated names.

The insn nvptx_uniform_warp_check contains register names without '%'
prefix,
which potentially could lead to name conflicts with user-defined variable
names.

Fix this by adding a '%' prefix, more specifically a '%r_' prefix to avoid
a
name conflict with ptx special registers.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-03-20  Tom de Vries  

PR target/104925
* config/nvptx/nvptx.md (define_insn "nvptx_uniform_warp_check"):
Use % as register prefix.

[Bug target/104957] [nvptx] Use .alias directive (available starting ptx isa version 6.3)

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r12-7766-gf8b15e177155960017ac0c5daef8780d1127f91c
Author: Tom de Vries 
Date:   Fri Mar 11 13:41:01 2022 +0100

[nvptx] Use .alias directive for mptx >= 6.3

Starting with ptx isa version 6.3, a ptx directive .alias is available.
Use this directive to support symbol aliases, as far as possible.

The alias support is off by default.  It can be turned on using a switch
-malias.

Furthermore, for pre-sm_75, it's not effective unless the ptx version is
bumped to 6.3 or higher using -mptx (given that the default for pre-sm_75
is
6.0).

The alias support has the following limitations.

Only function aliases are supported.

Weak aliases are not supported.  That is, if I disable the check in
nvptx_asm_output_def_from_decls that disallows this, a weak alias is
emitted
and parsed by the driver.  But the test gcc.dg/globalalias.c starts
failing,
with the behaviour matching the comment about "weird behavior of AIX's .set
pseudo-op": a weak alias may resolve to different functions in different
files.

Aliases to weak symbols are not supported (see gcc.dg/localalias.c).  This
is
currently not prohibited by the compiler, but with the driver link we run
into: "error: Function test with .weak scope cannot be aliased".

Aliases to aliases are not supported (see libgomp.c-c++-common/pr96390.c).
This is currently not prohibited by the compiler, but with the driver link
we
run into:  "Internal error: alias to unknown symbol" .

Unreferenced aliases are not emitted (these can occur f.i. when inlining a
call to an alias).  This avoids driver link error "Internal error:
reference
to deleted section".

When enabling malias by default, libgomp detects alias support and
consequently libgomp.a will contains a few uses of .alias.  This however
results in aforementioned "Internal error: reference to deleted section" in
many test-cases.  Either there's some error with how .alias is used, or
there's a driver bug.  While this issue is not resolved, we keep malias
off-by-default.

At some point we may add support in the nvptx-tools linker for symbol
aliases, and define f.i. malias=ptx and malias=ld to choose between the two
in
the compiler.

An example of where this support is useful, is the OvO (OpenMP vs Offload)
testsuite.  The testsuite passes already at -O2.  But at -O0, there are
errors
in some c++ test-cases due to missing symbol alias support.  By compiling
with
-malias, the whole testsuite passes also at -O0.

This patch causes a regression:
...
-PASS: gcc.dg/pr60797.c  (test for errors, line 4)
+FAIL: gcc.dg/pr60797.c  (test for errors, line 4)
...
The test-case is skipped for effective target alias, and both without and
with
this patch the nvptx target is considered to not support it, so the
test-case is
executed.  The test-case expects an error message along the lines of "alias
definitions not supported in this configuration", but instead we run into:
...
gcc.dg/pr60797.c:4:12: error: foo aliased to undefined symbol
...
This is probably due to the fact that the nvptx backend now defines macros
ASM_OUTPUT_DEF and ASM_OUTPUT_DEF_FROM_DECLS, so from the point of view of
the
common part of the compiler, aliases are supported.

gcc/ChangeLog:

2022-03-18  Tom de Vries  

PR target/104957
* config/nvptx/nvptx-protos.h (nvptx_asm_output_def_from_decls):
Declare.
* config/nvptx/nvptx.cc (write_fn_proto_1): Don't add function
marker
for alias.
(SET_ASM_OP, NVPTX_ASM_OUTPUT_DEF): New macro def.
(nvptx_asm_output_def_from_decls): New function.
* config/nvptx/nvptx.h (ASM_OUTPUT_DEF): New macro def, define to
gcc_unreachable ().
(ASM_OUTPUT_DEF_FROM_DECLS): New macro def, define to
nvptx_asm_output_def_from_decls.
* config/nvptx/nvptx.opt (malias): New opt.

gcc/testsuite/ChangeLog:

2022-03-18  Tom de Vries  

PR target/104957
* gcc.target/nvptx/alias-1.c: New test.
* gcc.target/nvptx/alias-2.c: New test.
* gcc.target/nvptx/alias-3.c: New test.
* gcc.target/nvptx/alias-4.c: New test.
* gcc.target/nvptx/nvptx.exp
(check_effective_target_runtime_ptx_isa_version_6_3): New proc.

[Bug target/104783] [nvptx, openmp] Hang/abort with atomic update in simd construct

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r12-7765-ga624388b9546b066250be8baa118b7d50c403c25
Author: Tom de Vries 
Date:   Wed Mar 9 10:35:14 2022 +0100

[nvptx] Add warp sync at simt exit

Consider this code (with N defined to 1024):
...
  float v = 0.0;
  #pragma omp target map(tofrom: v)
  #pragma omp parallel for simd
  for (int i = 0 ; i < N; i++)
{
  #pragma omp atomic update
  v = v + 1.0;
}
...

It hangs when executing on target board unix/-foffload=-misa=sm_75, using
drivers 470.103.01 and 510.54 on a T400 board (sm_75).

I'm tentatively identifying the problem as a bug in -muniform-simt for
architectures that support Independent Thread Scheduling (sm_70 and later).

The problem -muniform-simt is trying to address is to make sure that a
register produced outside an openmp simd region is available when used in
any
lane inside an simd region.

The solution is to, outside an simd region, execute in all warp lanes, thus
producing consistent values in result registers in each warp thread.

This approach doesn't work when executing in all warp lanes multiplies the
side effects from 1 to 32 separate side effects, which is the case for
atomic
insns.  So atomic insns are rewritten to execute only in lane 0, and if
there are any results, those are propagated to the other threads in the
warp.
[ And likewise for system calls malloc, free, vprintf. ]

Now, consider a non-atomic update: ld, add, store.  The store has side
effects, are those multiplied or not?

Pre-sm_70 we can assume that at the end of an SIMT region, any divergent
control flow has reconverged, and we have a uniform warp, executing in lock
step.  So:
- the load will load the same value into the result register across the
warp,
- the add will write the same value into the result register across the
warp,
- the store will write the same value to the same memory location, 32
times,
  at once, having the result of a single store.
So, no side-effect multiplication (well, at least that's the observation).

Starting sm_70, the threads in a warp are no longer guaranteed to
reconverge
after divergence.  There's a "Convergence Optimizer" that can can identify
that it is safe for a warp to reconverge, but that works only as long as
the
code does not contain "synchronizing operations".

Consequently, the ld, add, store sequence can be executed by a non-uniform
warp, which means the side effects can have multiplied, and the registers
are
no longer guarantueed to be in sync.

The atomic update in the example above is translated using an atom.cas
loop,
which means that we have divergence (because only one thread is allowed to
succeed at a time) and the "Convergence Optimizer" doesn't reconverge
probably
because the atom.cas counts as a "synchronizing operation".  So, it seems
plausible that the root cause for the mentioned hang is the problem
described
above.

Fix this by adding an explicit warp sync at simt exit.

Note that we're assuming here that the warp will stay uniform until the
next
SIMT region entry.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-03-09  Tom de Vries  

PR target/104916
PR target/104783
* config/nvptx/nvptx.md (define_expand "omp_simt_exit"): Emit warp
sync (or uniform warp check for mptx < 6.0).

libgomp/ChangeLog:

2022-03-15  Tom de Vries  

PR target/104916
PR target/104783
* testsuite/libgomp.c/pr104783-2.c: New test.

[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r12-7765-ga624388b9546b066250be8baa118b7d50c403c25
Author: Tom de Vries 
Date:   Wed Mar 9 10:35:14 2022 +0100

[nvptx] Add warp sync at simt exit

Consider this code (with N defined to 1024):
...
  float v = 0.0;
  #pragma omp target map(tofrom: v)
  #pragma omp parallel for simd
  for (int i = 0 ; i < N; i++)
{
  #pragma omp atomic update
  v = v + 1.0;
}
...

It hangs when executing on target board unix/-foffload=-misa=sm_75, using
drivers 470.103.01 and 510.54 on a T400 board (sm_75).

I'm tentatively identifying the problem as a bug in -muniform-simt for
architectures that support Independent Thread Scheduling (sm_70 and later).

The problem -muniform-simt is trying to address is to make sure that a
register produced outside an openmp simd region is available when used in
any
lane inside an simd region.

The solution is to, outside an simd region, execute in all warp lanes, thus
producing consistent values in result registers in each warp thread.

This approach doesn't work when executing in all warp lanes multiplies the
side effects from 1 to 32 separate side effects, which is the case for
atomic
insns.  So atomic insns are rewritten to execute only in lane 0, and if
there are any results, those are propagated to the other threads in the
warp.
[ And likewise for system calls malloc, free, vprintf. ]

Now, consider a non-atomic update: ld, add, store.  The store has side
effects, are those multiplied or not?

Pre-sm_70 we can assume that at the end of an SIMT region, any divergent
control flow has reconverged, and we have a uniform warp, executing in lock
step.  So:
- the load will load the same value into the result register across the
warp,
- the add will write the same value into the result register across the
warp,
- the store will write the same value to the same memory location, 32
times,
  at once, having the result of a single store.
So, no side-effect multiplication (well, at least that's the observation).

Starting sm_70, the threads in a warp are no longer guaranteed to
reconverge
after divergence.  There's a "Convergence Optimizer" that can can identify
that it is safe for a warp to reconverge, but that works only as long as
the
code does not contain "synchronizing operations".

Consequently, the ld, add, store sequence can be executed by a non-uniform
warp, which means the side effects can have multiplied, and the registers
are
no longer guarantueed to be in sync.

The atomic update in the example above is translated using an atom.cas
loop,
which means that we have divergence (because only one thread is allowed to
succeed at a time) and the "Convergence Optimizer" doesn't reconverge
probably
because the atom.cas counts as a "synchronizing operation".  So, it seems
plausible that the root cause for the mentioned hang is the problem
described
above.

Fix this by adding an explicit warp sync at simt exit.

Note that we're assuming here that the warp will stay uniform until the
next
SIMT region entry.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-03-09  Tom de Vries  

PR target/104916
PR target/104783
* config/nvptx/nvptx.md (define_expand "omp_simt_exit"): Emit warp
sync (or uniform warp check for mptx < 6.0).

libgomp/ChangeLog:

2022-03-15  Tom de Vries  

PR target/104916
PR target/104783
* testsuite/libgomp.c/pr104783-2.c: New test.