[Bug c++/94546] New: unimplemented: unexpected AST of kind nontype_argument_pack

[bisqwit at iki dot fi]

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

Bug ID: 94546
   Summary: unimplemented: unexpected AST of kind
nontype_argument_pack
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

Rejects valid code.

$ g++-10 --version
g++-10 (Debian 10-20200324-1) 10.0.1 20200324 (experimental) [master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]

$ g++-10 tmp.cc -std=c++20
tmp.cc: In instantiation of ‘void test(auto:1&&) [with auto:1 =
main()::&]’:
tmp.cc:18:14:   required from here
tmp.cc:8:5: sorry, unimplemented: unexpected AST of kind nontype_argument_pack
8 | [&](T&&... rest)
  | ^~~~
9 | {
  | ~
   10 | plot(std::forward(rest)...);
  | ~~~
   11 | };
  | ~
tmp.cc:8: confused by earlier errors, bailing out

#include 
void test(auto&& plot)
{
// Note: For brevity, this lambda function is only
// defined, not called nor assigned to a variable.
// Doing those things won’t fix the error.
[&](T&&... rest)
{
plot(std::forward(rest)...);
};
}
int main()
{
auto Plot = [](auto&&...)
{
};
test(Plot);
}

[Bug libstdc++/94545] std::to_integer(std::numeric_limits::max()) returns 0

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is because numeric_limits::max() is byte() because it isn't an
arithmetic type, so numeric_limits isn't meaningful.

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[sch...@linux-m68k.org]

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

--- Comment #9 from Andreas Schwab  ---
This breaks aarch64 -mabi=ilp32.

during RTL pass: vartrack
In file included from
../../../../../../libstdc++-v3/src/c++98/pool_allocator.cc:31:
/opt/gcc/gcc-20200410/Build/aarch64-suse-linux/ilp32/libstdc++-v3/include/ext/pool_allocator.h:
In member function '_Tp*
__gnu_cxx::__pool_alloc<_Tp>::allocate(__gnu_cxx::__pool_alloc<_Tp>::size_type,
const void*) [with _Tp = wchar_t]':
/opt/gcc/gcc-20200410/Build/aarch64-suse-linux/ilp32/libstdc++-v3/include/ext/pool_allocator.h:262:5:
internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8355

[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional

[bisqwit at iki dot fi]

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

--- Comment #4 from Joel Yliluoma  ---
Still confirmed on GCC 10 (Debian 10-20200324-1) 10.0.1 20200324 (experimental)
[master revision
596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]


Seems I lack the oomph to update the "confirmed" state of this report.

[Bug testsuite/94547] New: gcc.target/arm/acle/cde.c fails on armeb

[clyon at gcc dot gnu.org]

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

Bug ID: 94547
   Summary: gcc.target/arm/acle/cde.c fails on armeb
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed that gcc.target/arm/acle/cde.c fails on
armeb-none-linux-gnueabihf.

gcc.target/arm/acle/cde.c   -O1   check-function-bodies test_cde_cx1da
gcc.target/arm/acle/cde.c   -O1   check-function-bodies test_cde_cx2da
gcc.target/arm/acle/cde.c   -O1   check-function-bodies test_cde_cx3da
gcc.target/arm/acle/cde.c   -O2   check-function-bodies test_cde_cx1da
gcc.target/arm/acle/cde.c   -O2   check-function-bodies test_cde_cx2da
gcc.target/arm/acle/cde.c   -O2   check-function-bodies test_cde_cx3da
gcc.target/arm/acle/cde.c   -O3 -g   check-function-bodies test_cde_cx1da
gcc.target/arm/acle/cde.c   -O3 -g   check-function-bodies test_cde_cx2da
gcc.target/arm/acle/cde.c   -O3 -g   check-function-bodies test_cde_cx3da
gcc.target/arm/acle/cde.c   -Os   check-function-bodies test_cde_cx1da
gcc.target/arm/acle/cde.c   -Os   check-function-bodies test_cde_cx2da
gcc.target/arm/acle/cde.c   -Os   check-function-bodies test_cde_cx3da
gcc.target/arm/acle/cde.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none -ffat-lto-objects  check-function-bodies test_cde_cx1da
gcc.target/arm/acle/cde.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none -ffat-lto-objects  check-function-bodies test_cde_cx2da
gcc.target/arm/acle/cde.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none -ffat-lto-objects  check-function-bodies test_cde_cx3da
gcc.target/arm/acle/cde.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -ffat-lto-objects  check-function-bodies test_cde_cx1da
gcc.target/arm/acle/cde.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -ffat-lto-objects  check-function-bodies test_cde_cx2da
gcc.target/arm/acle/cde.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -ffat-lto-objects  check-function-bodies test_cde_cx3da


I don't know if that's supposed to work on big-endian, so maybe it's just a
matter of skipping the test in that config?

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Andreas Schwab from comment #9)
> This breaks aarch64 -mabi=ilp32.
> 
> during RTL pass: vartrack
> In file included from
> ../../../../../../libstdc++-v3/src/c++98/pool_allocator.cc:31:
> /opt/gcc/gcc-20200410/Build/aarch64-suse-linux/ilp32/libstdc++-v3/include/
> ext/pool_allocator.h: In member function '_Tp*
> __gnu_cxx::__pool_alloc<_Tp>::allocate(__gnu_cxx::__pool_alloc<_Tp>::
> size_type, const void*) [with _Tp = wchar_t]':
> /opt/gcc/gcc-20200410/Build/aarch64-suse-linux/ilp32/libstdc++-v3/include/
> ext/pool_allocator.h:262:5: internal compiler error: in
> vt_expand_var_loc_chain, at var-tracking.c:8355

Can you please provide a pre-processed source file?

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Andreas Schwab from comment #9)
> This breaks aarch64 -mabi=ilp32.

Does https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543702.html fix that?

[Bug target/56550] cortex-m3: incorrect write to member of volatile packed structure

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
 Target||arm

--- Comment #1 from Christophe Lyon  ---
With today's trunk, the generated code with -mcpu=cortex-m3 -mthumb is:
main:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
push{r7}
sub sp, sp, #12
add r7, sp, #0
mvn r3, #254
str r3, [r7, #4]
ldr r3, [r7, #4]
ldr r2, .L3
str r3, [r2, #7]@ unaligned
movsr3, #0
mov r0, r3
addsr7, r7, #12
mov sp, r7
@ sp needed
ldr r7, [sp], #4
bx  lr

Since cortex-m3 supports unaligned accesses, the use of
str r3, [r2, #7]@ unaligned
looks OK

[Bug rtl-optimization/70164] [8/9/10 Regression] Code/performance regression due to poor register allocation on Cortex-M0

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #24 from Christophe Lyon  ---
With today's trunk, I still see the same problem:

history_expand_line_internal:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r2, r4, r5, r6, r7, lr}
ldr r3, .L3
ldr r6, .L3+4
ldr r7, [r3]
ldr r3, [r6]   ; ; <--- load of 'hist_verify' onto r3
movsr5, r0
str r3, [sp, #4]; <--- Spill
movsr3, #0
str r3, [r6]
bl  pre_process_line
ldr r3, [sp, #4]; <--- reload
movsr4, r0
addsr7, r7, r3
str r7, [r6]
cmp r5, r0
bne .L1
bl  str_len
addsr0, r0, #1
bl  x_malloc
movsr1, r4
bl  str_cpy
movsr4, r0
.L1:
@ sp needed
movsr0, r4
pop {r1, r2, r3, r4, r5, r6, r7, pc}
.L4:
.align  2
.L3:
.word   a1
.word   hist_verify

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   See Also|https://bugzilla.kernel.org |https://sourceware.org/bugz
   |/show_bug.cgi?id=207187 |illa/show_bug.cgi?id=25810

--- Comment #15 from H.J. Lu  ---
I will fix it in glibc:

https://sourceware.org/bugzilla/show_bug.cgi?id=25810

[Bug target/82038] Very poor optimization of constant multiply on ARM Cortex-M7

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #3 from Christophe Lyon  ---
With todays' trunk, we get rid of the push/pop sequence:

_Z1fi:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
asrsr1, r0, #31
mov r3, r0
lslsr0, r0, #14
lslsr1, r1, #14
orr r1, r1, r3, lsr #18
bx  lr

_Z1gi:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r1, r0
lslsr0, r0, #14
asrsr1, r1, #18
bx  lr

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[sch...@linux-m68k.org]

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

--- Comment #12 from Andreas Schwab  ---
Yes, it does.

[Bug target/94541] [8/9/10 Regression] -mx32 gcc produces wrong code passing structs by value

[ibuclaw at gdcproject dot org]

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

--- Comment #16 from Iain Buclaw  ---
(In reply to H.J. Lu from comment #15)
> I will fix it in glibc:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=25810

Thanks, that certainly explains why I couldn't get it down any further.

[Bug c/94548] New: [AVR] Part of the code seems to have disappeared in the elf

[fabrice.salvaire at orange dot fr]

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

Bug ID: 94548
   Summary: [AVR] Part of the code seems to have disappeared in
the elf
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabrice.salvaire at orange dot fr
  Target Milestone: ---

For this code

### unsigned long int
### ml_per_h_to_timer_value(int desired_ml_per_h, int syringe_step_per_ml) {
###   unsigned long int timer = 0;
###   timer = ((31.2500 * 360UL) / ((unsigned long) desired_ml_per_h *
(unsigned long) syringe_step_per_ml));
### #ifdef DEBUG_PROCESS
###   Serial.println("* TIMER VALUE
*");
###   Serial.println(timer);
### #endif
###   return (timer);
### }

I got

### unsigned long int
### ml_per_h_to_timer_value(int desired_ml_per_h, int syringe_step_per_ml) {
###  9cc:   cf 92   pushr12
###  9ce:   df 92   pushr13
###  9d0:   ef 92   pushr14
###  9d2:   ff 92   pushr15
###   unsigned long int timer = 0;
###   timer = ((31.2500 * 360UL) / ((unsigned long) desired_ml_per_h *
(unsigned long) syringe_step_per_ml));
###  9d4:   9c 01   movwr18, r24
###  9d6:   db 01   movwr26, r22
###  9d8:   0e 94 7f 1d call0x3afe  ; 0x3afe <__mulhisi3>
###  9dc:   0e 94 bb 1c call0x3976  ; 0x3976 <__floatunsisf>
###  9e0:   9b 01   movwr18, r22
###  9e2:   ac 01   movwr20, r24
###  9e4:   64 ea   ldi r22, 0xA4   ; 164
###  9e6:   73 e9   ldi r23, 0x93   ; 147
###  9e8:   86 ed   ldi r24, 0xD6   ; 214
###  9ea:   9c e4   ldi r25, 0x4C   ; 76
###  9ec:   0e 94 1a 1c call0x3834  ; 0x3834 <__divsf3>
###  9f0:   0e 94 8c 1c call0x3918  ; 0x3918 <__fixunssfsi>
###  9f4:   6b 01   movwr12, r22
###  9f6:   7c 01   movwr14, r24
###   // timer = ((f0 * 360UL) / ((unsigned long) desired_ml_per_h *
(unsigned long) syringe_step_per_ml));
### #ifdef DEBUG_PROCESS
###   Serial.println("* TIMER VALUE
*");
###  9f8:   83 ef   ldi r24, 0xF3   ; 243
###  9fa:   91 e0   ldi r25, 0x01   ; 1
###  9fc:   0e 94 d3 04 call0x9a6   ; 0x9a6 
###   else return printNumber(n, base);
###  a00:   2a e0   ldi r18, 0x0A   ; 10
###  a02:   b7 01   movwr22, r14
###  a04:   a6 01   movwr20, r12
###  a06:   83 e6   ldi r24, 0x63   ; 99
###  a08:   96 e0   ldi r25, 0x06   ; 6
###  a0a:   0e 94 5a 04 call0x8b4   ; 0x8b4

###  a0e:   60 ef   ldi r22, 0xF0   ; 240
###  a10:   71 e0   ldi r23, 0x01   ; 1
###  a12:   83 e6   ldi r24, 0x63   ; 99
###  a14:   96 e0   ldi r25, 0x06   ; 6
###  a16:   0e 94 4b 04 call0x896   ; 0x896 
###   Serial.println(timer);
### #endif
###   return (timer);
### }
###  a1a:   c7 01   movwr24, r14
###  a1c:   b6 01   movwr22, r12
###  a1e:   ff 90   pop r15
###  a20:   ef 90   pop r14
###  a22:   df 90   pop r13
###  a24:   cf 90   pop r12
###  a26:   08 95   ret

But

### unsigned long int
### ml_per_h_to_timer_value(int desired_ml_per_h, int syringe_step_per_ml) {
###   unsigned long int timer = 0;
###   const unsigned long int f0 = (8UL*10^6) / (1000*256UL);
###   timer =  ((f0 * 360UL) / ((unsigned long) desired_ml_per_h *
(unsigned long) syringe_step_per_ml));
### #ifdef DEBUG_PROCESS
###   Serial.println("* TIMER VALUE
*");
###   Serial.println(timer);
### #endif
###   return (timer);
### }

I got

### 09cc :
###   unsigned long int timer = 0;
###   const unsigned long int f0 = (8UL*10^6) / (1000*256UL);
###   // timer = ((31.2500 * 360UL) / ((unsigned long) desired_ml_per_h *
(unsigned long) syringe_step_per_ml));
###   timer = ((f0 * 360UL) / ((unsigned long) desired_ml_per_h * (unsigned
long) syringe_step_per_ml));
### #ifdef DEBUG_PROCESS
###   Serial.println("* TIMER VALUE
*");
###  9cc:   83 ef   ldi r24, 0xF3   ; 243
###  9ce:   91 e0   ldi r25, 0x01   ; 1
###  9d0:   0e 94 d3 04 call0x9a6   ; 0x9a6 
###   else return printNumber(n, base);
###  9d4:   2a e0   ldi r18, 0x0A   ; 10
###  9d6:   40 e0   ldi r20, 0x00   ; 0
###  9d8:   50 e0   ldi r21, 0x00   ; 0
###  9da:   ba 01   movwr22, r20
###   

[Bug c++/94546] unimplemented: unexpected AST of kind nontype_argument_pack

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-04-10

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/94546] [10 Regression] unimplemented: unexpected AST of kind nontype_argument_pack

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|rejects-valid   |ice-on-valid-code
   Target Milestone|--- |10.0
Summary|unimplemented: unexpected   |[10 Regression]
   |AST of kind |unimplemented: unexpected
   |nontype_argument_pack   |AST of kind
   ||nontype_argument_pack
   Priority|P3  |P1

--- Comment #2 from Marek Polacek  ---
Started with r277900.

[Bug libgomp/92843] [OpenACC] Wrong/missing dynamic reference counting for structured 'REFCOUNT_INFINITY'

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r10-7678-gbe9862dd96945772ae0692bc95b37ec6dbcabda0
Author: Julian Brown 
Date:   Fri Jan 17 13:18:18 2020 -0800

Test cases for mixed structured/dynamic data lifetimes with OpenACC
[PR92843]

libgomp/
PR libgomp/92843
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c:
New file.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c:
Likewise.

[Bug c/89433] Repeated use of the OpenACC 'routine' directive

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7676-gff3f862b451496dd4afbe2dbfae82afab59a42c6
Author: Thomas Schwinge 
Date:   Wed Mar 4 17:58:33 2020 +0100

Handle 'omp declare target' attribute set for both OpenACC and OpenMP
'target' [PR89433, PR93465]

... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406
causes
an ICE.  Not sure if this is actually supposed to be valid or invalid code.
Until the interactions between OpenACC and OpenMP 'target' get defined
properly, make this a compile-time error.

gcc/
PR middle-end/89433
PR middle-end/93465
* omp-general.c (oacc_verify_routine_clauses): Diagnose if
"#pragma omp declare target" has also been applied.
gcc/testsuite/
PR middle-end/89433
PR middle-end/93465
* c-c++-common/goacc-gomp/pr93465-1.c: New file.

[Bug middle-end/93465] [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802 since r10-471-gb48f44bf77a39fef

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r10-7676-gff3f862b451496dd4afbe2dbfae82afab59a42c6
Author: Thomas Schwinge 
Date:   Wed Mar 4 17:58:33 2020 +0100

Handle 'omp declare target' attribute set for both OpenACC and OpenMP
'target' [PR89433, PR93465]

... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406
causes
an ICE.  Not sure if this is actually supposed to be valid or invalid code.
Until the interactions between OpenACC and OpenMP 'target' get defined
properly, make this a compile-time error.

gcc/
PR middle-end/89433
PR middle-end/93465
* omp-general.c (oacc_verify_routine_clauses): Diagnose if
"#pragma omp declare target" has also been applied.
gcc/testsuite/
PR middle-end/89433
PR middle-end/93465
* c-c++-common/goacc-gomp/pr93465-1.c: New file.

[Bug libgomp/92843] [OpenACC] Wrong/missing dynamic reference counting for structured 'REFCOUNT_INFINITY'

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8489-g3c7a476c5ad3761cb5373f8c59a92e04525c5638
Author: Julian Brown 
Date:   Fri Jan 17 13:18:18 2020 -0800

Test cases for mixed structured/dynamic data lifetimes with OpenACC
[PR92843]

libgomp/
PR libgomp/92843
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c:
New file.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c:
Likewise.
*
testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c:
Likewise.

(cherry picked from commit be9862dd96945772ae0692bc95b37ec6dbcabda0)

[Bug middle-end/93465] [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802 since r10-471-gb48f44bf77a39fef

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

  Known to fail|10.0|
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||10.0

--- Comment #8 from Thomas Schwinge  ---
ICE fixed for GCC 10.  Not planning to backport to release branches; mixed
OpenACC/OpenMP code continues to invoke undefined behavior (without ICE).

[Bug c++/92856] incorrectly accepts invalid C++11 braced initialisation of double from long double

[dangelog at gmail dot com]

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

Giuseppe D'Angelo  changed:

   What|Removed |Added

 CC||dangelog at gmail dot com

--- Comment #5 from Giuseppe D'Angelo  ---
Hi,

This specific bug needs to be reopened: GCC incorrectly accepts long double to
double in list initializations, and generates no warnings, on architectures
where long double is the same as double.

Testcases:

On ARM: https://godbolt.org/z/SRg3fr
On X86-64 also passing -mlong-double-64: https://godbolt.org/z/GnRkHC

SFINAE contexts are affected as well: https://godbolt.org/z/icMA3k

Clang, MSVC reject the code.

[Bug c++/94549] New: [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 94549
   Summary: [10 Regression] Inherited and constrained constructors
are "ambiguous" even if they aren't
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

The following code worked until gcc 10:

```c++
struct base {
  template 
requires false
  base(type);

  template 
requires true
  base(type);
};

struct derived : base {
  using base::base;
};

int main() { derived{'G'}; }
```

All other major compilers supporting concepts accept this example, see
https://godbolt.org/z/cabrpc

but gcc10 produces 

```
> g++-git -std=c++2a ice.cpp   

ice.cpp: In function ‘int main()’:
ice.cpp:15:25: error: call of overloaded ‘derived()’ is ambiguous
   15 | int main() { derived{'G'}; }
  | ^
ice.cpp:4:3: note: candidate: ‘base::base(type)’
4 |   base(type);
  |   ^~~~
ice.cpp:12:15: note:   inherited here
   12 |   using base::base;
  |   ^~~~
ice.cpp:8:3: note: candidate: ‘base::base(type)’
8 |   base(type);
  |   ^~~~
ice.cpp:12:15: note:   inherited here
   12 |   using base::base;
  |   ^~~~
ice.cpp:11:8: note: candidate: ‘constexpr derived::derived(const derived&)’
   11 | struct derived : base {
  |^~~
ice.cpp:11:8: note: candidate: ‘constexpr derived::derived(derived&&)’
```

My gcc version is

```
> g++-git -v   

Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200326 (experimental) (GCC)
```

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/17314] Error message wrongly shows declared rather than inherited access

[ich.freak at gmx dot net]

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

Igel  changed:

   What|Removed |Added

 CC||ich.freak at gmx dot net

--- Comment #21 from Igel  ---
Seconded! This bug still exists in 9.2.0. Here's another example:

class Base {  protected: int i; };
class Derived:  public Base{ using Base::i; };
class Derived2: public Derived { using Derived::i; };
int main(){}

> g++ test.cpp -o test
test.cpp:3:7: error: 'int Base::i' is protected within this context
3 | class Derived2: public Derived { using Derived::i; };
  |   ^~~~
test.cpp:1:30: note: declared protected here
1 | class Base {  protected: int i; };
  |  ^

no mention of line 2 where the actual problem is (namely that i is declared
private (not protected)).

cheers

[Bug c++/94550] New: False positive with -Wparentheses

[icegood1980 at gmail dot com]

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

Bug ID: 94550
   Summary: False positive with -Wparentheses
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: icegood1980 at gmail dot com
  Target Milestone: ---

Compiler warns with 
-Werror=parentheses


for valid boost code in mpl:

template< typename Pred >
failed  (Pred:: 
  assert_arg( void (*)(Pred), typename assert_arg_pred::type )
);

template< typename Pred >
failed  (boost::mpl::not_:: 
  assert_not_arg( void (*)(Pred), typename assert_arg_pred_not::type
)
);

[Bug libstdc++/94545] std::to_integer(std::numeric_limits::max()) returns 0

[thomas.mercier.jr at gmail dot com]

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

--- Comment #2 from Thomas Mercier  ---
I thought that might be the response. Then why does it compile? The fact that
it does, and produces a result is surprising. I don't know what the standard
says, but just looking at cppreference it says that specializations are
provided for arithmetic types. We could have a more sane default than value
initialization
(https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/limits#L321)
that produces a compilation error if it's unspecified (something like below).

template
struct mylimits
{
  static constexpr _Tp max() noexcept {
static_assert(sizeof(_Tp) == 0, "There is no specialization of mylimits for
this type."); 
  }
};

template<>
struct mylimits
{
  static constexpr bool max() noexcept { return true; }
};

// and so on...

Gives you:
$ g++ -std=c++17 test.cc
test.cc: In instantiation of ‘static constexpr _Tp mylimits<_Tp>::max() [with
_Tp = int]’:
test.cc:21:34:   required from here
test.cc:5:5: error: static assertion failed: There is no specialization of
mylimits for this type.
 static_assert(sizeof(_Tp) == 0, "There is no specialization of mylimits
for this type.");

[Bug fortran/93579] [9/10 Regression] ICE in gfc_conv_substring_expr, at fortran/trans-expr.c:8587

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||tkoenig at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #4 from Thomas Koenig  ---
Fixed, then.

[Bug target/94551] New: [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu

[tkoenig at gcc dot gnu.org]

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

Bug ID: 94551
   Summary: [10 Regression] Bootstrap failure on
powerpc64le-unknown-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

This is with commit e26bd694c790b7c8f68c6736b2683c60a8fcbcfe, as
of just now.l The machine is gcc135.fsffrance.org, in case anybody
wants to reproduce.

/home/tkoenig/trunk-bin/./prev-gcc/xg++ -B/home/tkoenig/trunk-bin/./prev-gcc/
-B/home/tkoenig/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++
-B/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/tkoenig/trunk/libstdc++-v3/libsupc++
-L/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include  -I../../trunk/gcc/../libdecnumber
-I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../trunk/gcc/../libbacktrace   -o tree-streamer.o -MT tree-streamer.o -MMD
-MP -MF ./.deps/tree-streamer.TPo ../../trunk/gcc/tree-streamer.c
during RTL pass: vartrack
../../trunk/gcc/tree-streamer.c: In function 'void
streamer_check_handled_ts_structures()':
../../trunk/gcc/tree-streamer.c:99:1: internal compiler error: in
vt_expand_var_loc_chain, at var-tracking.c:8355
   99 | }
  | ^

[Bug fortran/93762] Truncation of deferred-length string when passing as optional

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-10
 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
Unfortunately, the test case fails with different ways on
current trunk:

$ gfortran -g  a.f90
$ ./a.out
 at bot of deepest_call, str is "12345"

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f0a66c3059f in ???
at
/usr/src/debug/glibc-2.26-lp151.19.11.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x400c65 in __interface_call_m_MOD_interface_call
at /tmp/a.f90:20
#2  0x400d99 in MAIN__
at /tmp/a.f90:32
#3  0x400f0b in main
at /tmp/a.f90:25
Speicherzugriffsfehler (Speicherabzug geschrieben)

(gdb) r a.f90 
Starting program: /tmp/a.out a.f90
 at bot of deepest_call, str is "12345"

Program received signal SIGSEGV, Segmentation fault.
_gfortran_string_len_trim (s=0x6068d0 "12345", len=) at
../../../gcc/libgfortran/intrinsics/string_intrinsics_inc.c:231
231   if (*((unsigned long*) (s + i + 1)) != blank_longword)
(gdb) p s
$1 = 0x6068d0 "12345"
(gdb) p i
$2 = 564082115390472183

Seems like uninitialzed memory for i.

Valgrind confirms this:

$ valgrind ./a.out
==5621== Memcheck, a memory error detector
==5621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5621== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==5621== Command: ./a.out
==5621== 
 at bot of deepest_call, str is "12345"
==5621== Conditional jump or move depends on uninitialised value(s)
==5621==at 0x50A29A5: _gfortran_string_len_trim
(string_intrinsics_inc.c:188)
==5621==by 0x50A2A87: _gfortran_string_trim (string_intrinsics_inc.c:168)
==5621==by 0x400C65: __interface_call_m_MOD_interface_call (a.f90:20)
==5621==by 0x400D99: MAIN__ (a.f90:32)
==5621==by 0x400F0B: main (a.f90:25)

Not sure if this ever worked in a released version.

[Bug target/94551] [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495#c11

[Bug inline-asm/94552] New: issue with branch offset calculation by m68k-linux-gnu-as

[i...@abp-labs.com]

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

Bug ID: 94552
   Summary: issue with branch offset calculation by
m68k-linux-gnu-as
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i...@abp-labs.com
  Target Milestone: ---

Created attachment 48254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48254&action=edit
asm source to reproduce the assembler error.

command :
m68k-linux-gnu-as -o bug-as.o -m68000 bug-as.s

when using bra, code is generated correctly :

 :
   0:   2648moveal %a0,%a3
   2:   6000 0002   braw 6 

0006 :
   6:   224bmoveal %a3,%a1
   8:   60fcbras 6 

When using bra.s instead of bra (or bra.w), wrong error message:

bug-as.s: Messages de l'assembleur:
bug-as.s:16: Erreur: décalage d'octets de branchement invalide

as version :

Version de l'assembleur GNU 2.30 (m68k-linux-gnu) utilisant la version BFD (GNU
Binutils for Ubuntu) 2.30

Used with GNU/Linux Mint 19.3

[Bug testsuite/92550] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|target  |testsuite
Summary|[10 Regression] FAIL:   |FAIL:
   |gcc.dg/ipa/ipa-sra-8.c  |gcc.dg/ipa/ipa-sra-8.c
   |execution test  |execution test

--- Comment #9 from John David Anglin  ---
With -fno-ipa-sra, the test always fails since it was first introduced.

The test passes if I change the argument of get_a from SS to SSS.  Then,
it handles the misaligned argument:

get_a:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
.stabn  68,0,14,L$M0001-L$FBB0001
L$M0001:
ldb 0(%r26),%r19
zdep %r19,7,8,%r19
ldb 1(%r26),%r20
zdep %r20,15,16,%r20
ldb 2(%r26),%r28
or %r20,%r19,%r20
zdep %r28,23,24,%r28
ldb 3(%r26),%r19
or %r28,%r20,%r28
.stabn  68,0,17,L$M0002-L$FBB0001
L$M0002:
bv %r0(%r2)
or %r19,%r28,%r28
.EXIT
.PROCEND

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:62c25d7adb1a5664982449dda0e7f9ca63cf4735

commit r10-7681-g62c25d7adb1a5664982449dda0e7f9ca63cf4735
Author: Marek Polacek 
Date:   Thu Apr 9 16:31:59 2020 -0400

c++: make __is_constructible work with paren-init of aggrs [PR94149]

In C++20 this is well-formed:

  using T = int[2];
  T t(1, 2);

which means that std::is_constructible_v should be true.
But constructible_expr immediately returned the error_mark_node when it
saw a list with more than one element.  To give accurate results in
C++20, we have to try initializing the aggregate from a parenthesized list
of
values.

To not repeat the same mistake as in c++/93790, if there's only one
element, I'm trying {} only when () didn't succeed.  is_constructible5.C
verifies this.

In paren-init24.C std::is_nothrow_constructible_v doesn't work due to
 error: invalid 'static_cast' from type 'int' to type 'int [1]'
and
 error: functional cast to array type 'int [2]'

This needs to be fixed in libstdc++.

PR c++/94149
* method.c (constructible_expr): In C++20, try using parenthesized
initialization of aggregates to determine the result of
__is_constructible.

* g++.dg/cpp2a/paren-init24.C: New test.
* g++.dg/cpp2a/paren-init25.C: New test.
* g++.dg/ext/is_constructible5.C: New test.

[Bug c++/94149] __is_constructible doesn't know about C++20 parenthesized init for arrays

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/94553] New: Revisit [basic.scope.declarative]/4.2

[mpolacek at gcc dot gnu.org]

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

Bug ID: 94553
   Summary: Revisit [basic.scope.declarative]/4.2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

 has a note:
A structured binding ([dcl.struct.bind]), namespace name ([basic.namespace]),
or class template name ([temp.pre]) must be unique in its declarative region.
but we don't fully implement that.  Consequently, the following is
accepts-valid.  (The structured binding part was added in CWG 2289.)

void
f ()
{
  int arr[1] = { 1 };
  struct A { };
  auto [A] = arr; // error
  auto [B] = arr;
  struct B { }; // error
}

struct C { };
template int C; // error
template int D;
struct D { }; // error

[Bug c++/94553] Revisit [basic.scope.declarative]/4.2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Marek Polacek  ---
(In reply to Marek Polacek from comment #0)
> Consequently, the following is accepts-valid.

s/valid/invalid/, of course.

[Bug inline-asm/94552] issue with branch offset calculation by m68k-linux-gnu-as

[i...@abp-labs.com]

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

Jean-Michel  changed:

   What|Removed |Added

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

--- Comment #1 from Jean-Michel  ---
Wrong bug report!

Code is OK with bra.w (6000 0002)
Code can not be generated with bra.s (6000) since is causes an address trap
error.

[Bug c++/94554] New: spurious -Waddress warning within "if constexpr" function-null compares

[myriachan at gmail dot com]

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

Bug ID: 94554
   Summary: spurious -Waddress warning within "if constexpr"
function-null compares
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

The following with -std=c++17 -Waddress:

int meow() { return 1; }
void kitty(int);
template 
void test() {
if constexpr (F) {
kitty(F());
} else {
kitty(2);
}
}
template void test();
template void test();

gives a spurious/pointless warning:

: In instantiation of 'void test() [with int (* F)() = meow]':
:12:26:   required from here
:5:5: warning: the address of 'int meow()' will never be NULL
[-Waddress]
5 | if constexpr (F) {
  | ^~

The warning should be suppressed in "if constexpr" contexts, because of course
it's going to be always true or always false.

Clang errors on this case, so it's possible that my code is invalid: Is it
legal to compare a function pointer against null in a constant-expression?

[Bug target/94494] gcc-10 unrecognizable insn

[abrahm.scully at gmail dot com]

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

--- Comment #2 from Abrahm Scully  ---
Created attachment 48255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48255&action=edit
preprocessed source file

With gcc-10-20200329, "g++ -Wall -ftree-vectorize -march=pentium3 -O2 -m32 -c
illegal-insn.cpp.ii -o illegal-insn.cpp.o" prints the following:

illegal-insn.cpp: In function 'void illegal_insn(float*, float*, float*, int,
int, int, int, int)':
illegal-insn.cpp:16:1: error: unrecognizable insn:
   16 | }
  | ^
(insn 80 79 81 13 (set (reg:V1TI 144)
(lshiftrt:V1TI (subreg:V1TI (reg:V4SI 113 [ vect_found_18.20 ]) 0)
(const_int 64 [0x40]))) -1
 (nil))
during RTL pass: vregs
illegal-insn.cpp:16:1: internal compiler error: in extract_insn, at
recog.c:2294
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/94494] gcc-10 unrecognizable insn

[abrahm.scully at gmail dot com]

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

--- Comment #3 from Abrahm Scully  ---
Not sure if this is helpful, but "gcc -v" outputs:
Reading specs from /opt/tools-20200401/lib/gcc/i686-pc-linux-gnu/10/specs
COLLECT_GCC=/opt/tools-20200401/bin/gcc
COLLECT_LTO_WRAPPER=/opt/tools-20200401/libexec/gcc/i686-pc-linux-gnu/10/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/opt/tools-20200401 --with-system-zlib
--enable-languages=c,c++,fortran,lto --enable-bootstrap --enable-libgomp
--enable-checking=release --enable-shared --enable-threads=posix
--with-arch=pentium3 --with-tune=pentium3 --disable-multilib
--enable-initfini-array --enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --with-zstd --disable-libssp --enable-__cxa_atexit
--disable-libunwind-exceptions --with-gcc-major-version-only --with-isl
-disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200329 (experimental) (GCC)

[Bug target/94551] [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Does https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543702.html fix that?

[Bug libstdc++/94545] std::to_integer(std::numeric_limits::max()) returns 0

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Thomas Mercier from comment #2)
> I thought that might be the response. Then why does it compile?

Because the standard requires it to.

> The fact that it does, and produces a result is surprising.
> I don't know what the standard says,

You should look. It's very explicit:

"The default numeric_limits template shall have all members, but with 0 or
false values."

The standard is clear about what the primary template does, and is clear that
there is no specialization for std::byte.

std::byte is not a numeric type, why do you expect std::numeric_limits to be
meaningful for it?

If you want the value with all bits set, use ~std::byte().

[Bug libstdc++/94545] std::to_integer(std::numeric_limits::max()) returns 0

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
cppreference does document this, see the second row of the "Return value" table
at https://en.cppreference.com/w/cpp/types/numeric_limits/max

[Bug other/94555] New: [10 regression] ICE compiling gfortran.dg/substr_6.f90 after r10-7665

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 94555
   Summary: [10 regression] ICE compiling gfortran.dg/substr_6.f90
after r10-7665
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:33c45e51b4914008064d9b77f2c1fc0eea1ad060, r10-7665

FAIL: gfortran.dg/substr_6.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/substr_6.f90   -O3 -g  (test for excess errors)

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/substr_6.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -g -std=legacy
-B/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./substr_6.exe
during RTL pass: vartrack
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/substr_6.f90:23:0:
internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8355
0x10ff46cf vt_expand_var_loc_chain
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8355
0x10ff46cf vt_expand_loc_callback
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8551
0x10590027 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1880
0x105931c7 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1727
0x10ff3a1f vt_expand_loc_callback
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8485
0x10590253 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1845
0x105931c7 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1727
0x10ff409b vt_expand_var_loc_chain
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8388
0x10ff409b vt_expand_loc_callback
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8551
0x10590027 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1880
0x105931c7 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1727
0x10ff409b vt_expand_var_loc_chain
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8388
0x10ff409b vt_expand_loc_callback
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8551
0x10590027 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1880
0x1058fe77 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1919
0x1058fe77 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1919
0x1058fe77 cselib_expand_value_rtx_1
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1919
0x105931c7 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/home/seurer/gcc/git/gcc-test2/gcc/cselib.c:1727
0x10ff409b vt_expand_var_loc_chain
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8388
0x10ff409b vt_expand_loc_callback
/home/seurer/gcc/git/gcc-test2/gcc/var-tracking.c:8551

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I don't think this warning should be suppressed in "if constexpr" contexts. 
What's the point of such code?

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

[myriachan at gmail dot com]

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

--- Comment #2 from Melissa  ---
Templates that take an optional function pointer as a template parameter.  It
lets you have templates that change behavior if a null function pointer is
passed.

[Bug target/94551] [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #3 from Andreas Schwab  ---
*** Bug 94555 has been marked as a duplicate of this bug. ***

[Bug other/94555] [10 regression] ICE compiling gfortran.dg/substr_6.f90 after r10-7665

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
dup

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

[Bug target/94551] [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I'm bootstrapping/regtesting that patch overnight on
{x86_64,i686,powerpc64{,le}}-linux and will commit tomorrow if it passes to
unbreak everybody.

[Bug target/94556] New: [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

Bug ID: 94556
   Summary: [10 Regression] FAIL: nptl/tst-thread-exit-clobber
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

On Linux/x32, GCC 10.0.1 20200324 caused

FAIL: nptl/tst-thread-exit-clobber

[hjl@gnu-cfl-2 build-x86_64-linux]$ nptl/tst-thread-exit-clobber --direct
info: unsigned int, direct pthread_exit call
info: double, direct pthread_exit call
error: tst-thread-exit-clobber.cc:119: not true: value ==
magic_values_double.v2
info: unsigned int, indirect pthread_exit call
info: double, indirect pthread_exit call
error: 1 test failures
[hjl@gnu-cfl-2 build-x86_64-linux]$ 

in tests on glibc master branch.  GCC 9.3 is OK.

[Bug libstdc++/94545] std::to_integer(std::numeric_limits::max()) returns 0

[thomas.mercier.jr at gmail dot com]

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

--- Comment #5 from Thomas Mercier  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Thomas Mercier from comment #2)
> > I thought that might be the response. Then why does it compile?
> 
> Because the standard requires it to.
> 
> > The fact that it does, and produces a result is surprising.
> > I don't know what the standard says,
> 
> You should look. It's very explicit:
> 
> "The default numeric_limits template shall have all members, but with 0
> or false values."
> 
> The standard is clear about what the primary template does, and is clear
> that there is no specialization for std::byte.
> 
> std::byte is not a numeric type, why do you expect std::numeric_limits to be
> meaningful for it?
> 
> If you want the value with all bits set, use ~std::byte().

Yeah paywalled unfortunately. :\ I since found the section you quote in a draft
document.

I don't have a problem with std::byte being a non-arithmetic type, but that
didn't occur to me as I was first writing the code. The behavior of the primary
template is what is surprising... and entirely compliant as you point out.

[Bug bootstrap/87252] gcc-4.4 cross-builds broken, apparently in self-tests

[abrahm.scully at gmail dot com]

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

--- Comment #9 from Abrahm Scully  ---
I'm no longer convinced that I didn't see the problem previously because I just
wasn't running the tests. Stage 1 has checking enabled... so I don't know why
this problem showed up for others in gcc 9 but not for me until gcc 10.

Either way, building gcc-4.7.4 first and then building gcc-10 with that
produces a compiler without the problem.

Again, sorry for the noise.

[Bug c++/94523] [10 Regression] error: 'constexpr' evaluation depth exceeds maximum of 512 (use '-fconstexpr-depth=' to increase the maximum) since r10-7490-g76f09260b7eccd6c

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/94546] [10 Regression] unimplemented: unexpected AST of kind nontype_argument_pack

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ubizjak at gmail dot com
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-10

--- Comment #1 from H.J. Lu  ---
It is caused by r10-2846:

commit bc4aa158c9490e76573bee3eec90f893b7d0b1ae
Author: Uros Bizjak 
Date:   Wed Aug 28 17:09:51 2019 +0200

* config/i386/i386-features.c
(general_scalar_chain::compute_convert_gain):
Correct cost for double-word shifts.
(general_scalar_to_vector_candidate_p): Reject count operands
greater or equal to mode bitsize.

From-SVN: r274994

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> It is caused by r10-2846:
> 
> commit bc4aa158c9490e76573bee3eec90f893b7d0b1ae
> Author: Uros Bizjak 
> Date:   Wed Aug 28 17:09:51 2019 +0200
> 
> * config/i386/i386-features.c
> (general_scalar_chain::compute_convert_gain):
> Correct cost for double-word shifts.
> (general_scalar_to_vector_candidate_p): Reject count operands
> greater or equal to mode bitsize.
> 
> From-SVN: r274994

This isn't the real cause.  The bug is somewhere else.

[Bug target/94557] New: [9 regression] r9-8486 causes several builtin instruction test case execution failures on power 9

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 94557
   Summary: [9 regression] r9-8486 causes several builtin
instruction test case execution failures on power 9
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:892c755eae2e2e45547395013695fdd819c297fa, r9-8486

FAIL: gcc.target/powerpc/vsx-builtin-10b.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11b.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16b.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-17b.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18b.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9b.c execution test

[Bug middle-end/94548] [AVR] Part of the code seems to have disappeared in the elf

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-10
 Status|UNCONFIRMED |WAITING
  Component|target  |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
###   const unsigned long int f0 = (8UL*10^6) / (1000*256UL);
###   // timer = ((31.2500 * 360UL) / ((unsigned long) desired_ml_per_h *
(unsigned long) syringe_step_per_ml));
###   timer = ((f0 * 360UL)

Are you sure this does not overflow unsigned long to get 0?

[Bug target/94494] gcc-10 unrecognizable insn

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Target Milestone|--- |9.4
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #4 from Uroš Bizjak  ---
Confirmed, fails with -O2 -ftree-vectorize -m32 -msse -mno-sse2.

The compiler generates SSE2 instruction with -msse.

Backtrace:

(gdb) bt
#0  0x01644c80 in gen_sse2_lshrv1ti3(rtx_def*, rtx_def*, rtx_def*) ()
at ./genrtl.h:39
#1  0x013a493f in emit_reduc_half (i=128, src=0x7fffea97e870,
dest=0x7fffea985f18)
at /home/uros/git/gcc/gcc/config/i386/i386-expand.c:14870
#2  ix86_expand_reduc (fn=fn@entry=0x160ac80 , dest=dest@entry=0x7fffea985f00, 
in=in@entry=0x7fffea97e870) at
/home/uros/git/gcc/gcc/config/i386/i386-expand.c:14977
#3  0x016cec5d in gen_reduc_smax_scal_v4si (operand0=0x7fffea97e600,
operand1=0x7fffea97e870)
at /home/uros/git/gcc/gcc/config/i386/sse.md:2746
#4  0x00eeb3e9 in maybe_expand_insn (ops=ops@entry=0x7fffd860,
nops=nops@entry=2, 
icode=icode@entry=CODE_FOR_reduc_smax_scal_v4si) at
/home/uros/git/gcc/gcc/optabs.c:7508
#5  expand_insn (icode=icode@entry=CODE_FOR_reduc_smax_scal_v4si,
nops=nops@entry=2, ops=ops@entry=0x7fffd860)
at /home/uros/git/gcc/gcc/optabs.c:7508

REDUC_SSE_SMINMAX_MODE mode iterator allows V4SI, V8HI and V16QI modes for SSE,
but we have:

case E_V16QImode:
case E_V8HImode:
case E_V4SImode:
case E_V2DImode:
  d = gen_reg_rtx (V1TImode);
  tem = gen_sse2_lshrv1ti3 (d, gen_lowpart (V1TImode, src),
GEN_INT (i / 2));
  break;

in i386-expand.c/emit_reduc_half.

Patch in testing:

--cut here--
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 8f5902292c6..d978e2aa256 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2733,8 +2733,8 @@
 ;; Modes handled by reduc_sm{in,ax}* patterns.
 (define_mode_iterator REDUC_SSE_SMINMAX_MODE
   [(V4SF "TARGET_SSE") (V2DF "TARGET_SSE")
-   (V2DI "TARGET_SSE4_2") (V4SI "TARGET_SSE") (V8HI "TARGET_SSE")
-   (V16QI "TARGET_SSE")])
+   (V4SI "TARGET_SSE2") (V8HI "TARGET_SSE2") (V16QI "TARGET_SSE2")
+   (V2DI "TARGET_SSE4_2")])

 (define_expand "reduc__scal_"
   [(smaxmin:REDUC_SSE_SMINMAX_MODE
--cut here--

[Bug fortran/93762] Truncation of deferred-length string when passing as optional

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #1)
> Unfortunately, the test case fails with different ways on
> current trunk:
> 
> $ gfortran -g  a.f90
> $ ./a.out
>  at bot of deepest_call, str is "12345"
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Backtrace for this error:
> #0  0x7f0a66c3059f in ???
> at
> /usr/src/debug/glibc-2.26-lp151.19.11.1.x86_64/signal/../sysdeps/unix/sysv/
> linux/x86_64/sigaction.c:0
> #1  0x400c65 in __interface_call_m_MOD_interface_call
> at /tmp/a.f90:20
> #2  0x400d99 in MAIN__
> at /tmp/a.f90:32
> #3  0x400f0b in main
> at /tmp/a.f90:25
> Speicherzugriffsfehler (Speicherabzug geschrieben)
> 
> (gdb) r a.f90 
> Starting program: /tmp/a.out a.f90
>  at bot of deepest_call, str is "12345"
> 
> Program received signal SIGSEGV, Segmentation fault.
> _gfortran_string_len_trim (s=0x6068d0 "12345", len=) at
> ../../../gcc/libgfortran/intrinsics/string_intrinsics_inc.c:231
> 231   if (*((unsigned long*) (s + i + 1)) != blank_longword)
> (gdb) p s
> $1 = 0x6068d0 "12345"
> (gdb) p i
> $2 = 564082115390472183
> 
> Seems like uninitialzed memory for i.
> 
> Valgrind confirms this:
> 
> $ valgrind ./a.out
> ==5621== Memcheck, a memory error detector
> ==5621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==5621== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
> ==5621== Command: ./a.out
> ==5621== 
>  at bot of deepest_call, str is "12345"
> ==5621== Conditional jump or move depends on uninitialised value(s)
> ==5621==at 0x50A29A5: _gfortran_string_len_trim
> (string_intrinsics_inc.c:188)
> ==5621==by 0x50A2A87: _gfortran_string_trim (string_intrinsics_inc.c:168)
> ==5621==by 0x400C65: __interface_call_m_MOD_interface_call (a.f90:20)
> ==5621==by 0x400D99: MAIN__ (a.f90:32)
> ==5621==by 0x400F0B: main (a.f90:25)
> 
> Not sure if this ever worked in a released version.

I doubt it ever worked.  It seems that the length is not getting
set properly for the returning string.  Should this be propagated
up the call change in the hidden string length argument.  Here's a
modified testcase where I print out lengths of str.

module deepest_call_m
   implicit none
   contains
  subroutine deepest_call(str)
 character(len=:), allocatable, optional :: str
 character(len=5) t
 t = '12345'
 if (present(str)) then
str = t
write(*,*) 'at bot of deepest_call, str is "'//trim(str)//'"'
 end if
 print *, 'len = ', len(str)
 print '(A)', 'Returning from deepest_call'
  end subroutine deepest_call
end module deepest_call_m

module interface_call_m
   implicit none
   contains
  subroutine interface_call(str)
 use deepest_call_m, only : deepest_call
 character(len=:), allocatable, optional :: str
 if (present(str)) then
call deepest_call(str)
print *, 'len = ', len(str)
write(*,*) 'at bot of interface_call, str is "'//trim(str)//'"'
 end if
  end subroutine interface_call
end module interface_call_m

program main
   use interface_call_m, only : interface_call
   implicit none
   character(len=:), allocatable :: str
   call interface_call(str)
   write(*,*) 'at bot of main, str is "'//trim(str)//'"'
end program main

I get

% gfcx -o z -g a.f90 && ./z
 at bot of deepest_call, str is "12345"
 len =5
Returning from deepest_call
 len =134516966
Segmentation fault (core dumped)

len = 5 is in deepest_call and the correct value.
len = 134516966 seems to be a bit too large.

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 48256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48256&action=edit
A tescase

[hjl@gnu-cfl-2 tmp]$ /usr/gcc-9.3.1-x32/bin/g++ -mx32 -O2 foo.cc -lpthread
[hjl@gnu-cfl-2 tmp]$ ./a.out 
info: double, direct pthread_exit call
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-10.0.1-x32/bin/g++ -mx32 -O2 foo.cc -lpthread
[hjl@gnu-cfl-2 tmp]$ ./a.out 
info: double, direct pthread_exit call
Aborted (core dumped)
[hjl@gnu-cfl-2 tmp]$ 

CFI may be incorrect.

[Bug target/94556] [10 Regression] FAIL: nptl/tst-thread-exit-clobber

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Depends on||83641

--- Comment #4 from H.J. Lu  ---
This is related to PR 83641.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83641
[Bug 83641] -fstack-clash-protection generates incorrect CFI on i386

[Bug fortran/93762] Truncation of deferred-length string when passing as optional

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
Here's a better testcasei, which removes IO statement, which
makes it easier to read -fdump-tree-original.

module deepest_call_m
   implicit none
   contains
  subroutine deepest_call(str)
 character(len=:), allocatable, intent(out), optional :: str
 if (present(str)) then
str = '12345'
if (len(str) /= 5) stop 1
 end if
  end subroutine deepest_call
end module deepest_call_m

module interface_call_m
   implicit none
   contains
  subroutine interface_call(str)
 use deepest_call_m, only : deepest_call
 character(len=:), allocatable, intent(out), optional :: str
 if (present(str)) then
call deepest_call(str)
if (len(str) /= 5) stop 2
 end if
  end subroutine interface_call
end module interface_call_m

program main
   use interface_call_m, only : interface_call
   implicit none
   character(len=:), allocatable :: str
   call interface_call(str)
   if (len(str) /= 5) stop 3
end program main

Here's the -fdump-tree-original where I have removed
inconsequential code and re-ordered to help with thinking.
Comments are in-lined.

MAIN__ ()
{
  integer(kind=4) .str;
  character(kind=1)[1:.str] * str;

  str = 0B;
  interface_call (&str, &.str);  /* .str is not set to some value. */ 
}

interface_call (character(kind=1)[1:*_str] * * str, integer(kind=4) * _str)
{
  if (str != 0B)
{
  {

/* This is not good.  *_str has the value of .str from MAIN,
   which wasn't set. */

character(kind=1)[1:*_str] * *D.3819;
integer(kind=4) D.3820;

/* Remove freeing from intent(out) attribute. */

D.3819 = str != 0B ? str : 0B;
D.3820 = str != 0B ? *_str : 0;

/* Here D.3820 is 0. */
deepest_call (D.3819, &D.3820);

/* *_str should be set to D.3820, but isn't. */
  }
}
}

deepest_call (character(kind=1)[1:*_str] * * str, integer(kind=4) * _str)
{
  if (str != 0B)
{
  {
integer(kind=4) D.3808;
integer(kind=4) D.3809;

/* Handle intent(out) and/or re-allocation on assign. */

/* Set *_str to 5, which is the desired length. */
*_str = 5;
D.3808 = *_str;
if (D.3808 > 0)
  {
 /* Copy '12345' into str. */
  }
  }
}
}

So, yep!  The string length is not propagated up the call chain.

[Bug middle-end/94548] [AVR] Part of the code seems to have disappeared in the elf

[fabrice.salvaire at orange dot fr]

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

--- Comment #2 from fabrice salvaire  ---
Yes I missed this important point on 8-bit architecture ...

This line doesn't also work for some reasons

const unsigned long int f0 = (8*(10ULL)^(6ULL)) / (1000*256ULL);

but this one works

const unsigned long int f0 = (8*100ULL) / (1000*256ULL);

It means the compiler computation of constants is a bit error prone on such
architectures versus x64.  There is no way in C to say compute the right value
in infinite-bit then store the result in 16-bit.

I am surprised by the fact the compiler doesn't warn for overflow ?  Since I
found the warning option "-Wno-overflow — Do not warn about compile-time
overflow in constant expressions" I should get a warning ???

[Bug c++/94553] Revisit [basic.scope.declarative]/4.2

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
To fix CWG 2289, we need this:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -1705,6 +1705,9 @@ duplicate_decls (tree newdecl, tree olddecl, bool
newdecl_is_friend)
  inform (olddecl_loc, "previous declaration %q#D", olddecl);
  return error_mark_node;
}
+  else if ((VAR_P (olddecl) && DECL_DECOMPOSITION_P (olddecl))
+  || (VAR_P (newdecl) && DECL_DECOMPOSITION_P (newdecl)))
+   /* A structured binding must be unique in its declarative region.  */;
   else if (DECL_IMPLICIT_TYPEDEF_P (olddecl)
   || DECL_IMPLICIT_TYPEDEF_P (newdecl))
/* One is an implicit typedef, that's ok.  */


but that's not enough to detect the 'A' case:
cp_parser_decomposition_declaration
uses

13968   tree decl2 = start_decl (declarator, &decl_specs, SD_INITIALIZED,
13969NULL_TREE, NULL_TREE, &elt_pushed_scope);

to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we don't do
fit_decomposition_lang_decl because the declarator kind is not cdk_decomp, so
then when start_decl calls maybe_push_decl, the decl 'A' isn't
DECL_DECOMPOSITION_P and we don't detect this case.  So we need a way to signal
to start_decl that it should fit_decomposition_lang_decl.

[Bug middle-end/94548] [AVR] Part of the code seems to have disappeared in the elf

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(10ULL)^(6ULL)

THIS IS NOT power but rather it is bitwise exclusive or (xor).

[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:0666767eb4cc864f00ba34d97b9d58f8dc650bba

commit r10-7682-g0666767eb4cc864f00ba34d97b9d58f8dc650bba
Author: Iain Sandoe 
Date:   Fri Apr 10 20:55:10 2020 +0100

coroutines: Revise await expansions [PR94528]

The expansions for await expressions were specific to particular
cases, this revises it to be more generic.

a: Revise co_await statement walkers.

We want to process the co_awaits one statement at a time.
We also want to be able to determine the insertion points for
new bind scopes needed to cater for temporaries that are
captured by reference and have lifetimes that need extension
to the end of the full expression.  Likewise, the handling of
captured references in the evaluation of conditions might
result in the need to make a frame copy.

This reorganises the statement walking code to make it easier to
extend for these purposes.

b: Factor reference-captured temp code.

We want to be able to use the code that writes a new bind expr
with vars (and their initializers) from several places, so split
that out of the maybe_promote_captured_temps() function into a
new replace_statement_captures ().  Update some comments.

c: Generalize await statement expansion.

This revises the expansion to avoid the need to expand conditionally
on the tree type.  It resolves PR 94528.

gcc/cp/ChangeLog:

2020-04-10  Iain Sandoe  

PR c++/94538
* coroutines.cc (co_await_expander): Remove.
(expand_one_await_expression): New.
(process_one_statement): New.
(await_statement_expander): New.
(build_actor_fn): Revise to use per-statement expander.
(struct susp_frame_data): Reorder and comment.
(register_awaits): Factor code.
(replace_statement_captures): New, factored from...
(maybe_promote_captured_temps):.. here.
(await_statement_walker): Revise to process per statement.
(morph_fn_to_coro): Use revised susp_frame_data layout.

gcc/testsuite/ChangeLog:

2020-04-10  Iain Sandoe  

PR c++/94538
* g++.dg/coroutines/pr94528.C: New test.

[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:0666767eb4cc864f00ba34d97b9d58f8dc650bba

commit r10-7682-g0666767eb4cc864f00ba34d97b9d58f8dc650bba
Author: Iain Sandoe 
Date:   Fri Apr 10 20:55:10 2020 +0100

coroutines: Revise await expansions [PR94528]

The expansions for await expressions were specific to particular
cases, this revises it to be more generic.

a: Revise co_await statement walkers.

We want to process the co_awaits one statement at a time.
We also want to be able to determine the insertion points for
new bind scopes needed to cater for temporaries that are
captured by reference and have lifetimes that need extension
to the end of the full expression.  Likewise, the handling of
captured references in the evaluation of conditions might
result in the need to make a frame copy.

This reorganises the statement walking code to make it easier to
extend for these purposes.

b: Factor reference-captured temp code.

We want to be able to use the code that writes a new bind expr
with vars (and their initializers) from several places, so split
that out of the maybe_promote_captured_temps() function into a
new replace_statement_captures ().  Update some comments.

c: Generalize await statement expansion.

This revises the expansion to avoid the need to expand conditionally
on the tree type.  It resolves PR 94528.

gcc/cp/ChangeLog:

2020-04-10  Iain Sandoe  

PR c++/94538
* coroutines.cc (co_await_expander): Remove.
(expand_one_await_expression): New.
(process_one_statement): New.
(await_statement_expander): New.
(build_actor_fn): Revise to use per-statement expander.
(struct susp_frame_data): Reorder and comment.
(register_awaits): Factor code.
(replace_statement_captures): New, factored from...
(maybe_promote_captured_temps):.. here.
(await_statement_walker): Revise to process per statement.
(morph_fn_to_coro): Use revised susp_frame_data layout.

gcc/testsuite/ChangeLog:

2020-04-10  Iain Sandoe  

PR c++/94538
* g++.dg/coroutines/pr94528.C: New test.

[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #6 from Iain Sandoe  ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Iain D Sandoe :

sorry about the bad PR number, this commit is unrelated to the PR.

[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
so fixed

[Bug target/94494] gcc-10 unrecognizable insn

[abrahm.scully at gmail dot com]

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

--- Comment #5 from Abrahm Scully  ---
I can't comment on the patch's correctness, but applied to gcc-10-20200405 it
does prevent the "unrecognizable insn" error.

[Bug bootstrap/87252] gcc-4.4 cross-builds broken, apparently in self-tests

[hp at gcc dot gnu.org]

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

--- Comment #10 from Hans-Peter Nilsson  ---
(In reply to Abrahm Scully from comment #9)
> Either way, building gcc-4.7.4 first and then building gcc-10 with that
> produces a compiler without the problem.
> 
> Again, sorry for the noise.

Please, do *not* apologize.  Even if you'd just repeat other observations, your
observations would serve as a confirmation.  But they're also new AFAICT.

So, your recent observation is that gcc-4.7.4 apparently works here.  Looking
deeper into what construct is used in the self-tests, that started working with
that version would likely help, if someone is so inclined.

Or, maybe it'd be ok to just disable the self-testing code before that version.
 Alternatively, plain raising the base version of the gcc being supported for
gcc *development* to 4.7.4 would probably be acceptable too.  To newcomers:
remember, this is just the cross-gcc case.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #12 from Piotr Kubaj  ---
This issue can be fixed with the following patches:
--- gcc/dumpfile.c.orig 2020-04-07 14:09:14 UTC
+++ gcc/dumpfile.c
@@ -2055,7 +2055,7 @@ temp_dump_context::temp_dump_context (bool forcibly_en
  bool forcibly_enable_dumping,
  dump_flags_t test_pp_flags)
 : m_context (),
-  m_saved (&dump_context ().get ())
+  m_saved(&dump_context::get())
 {
   dump_context::s_current = &m_context;
   if (forcibly_enable_optinfo)
--- libgcc/config/rs6000/t-crtstuff.orig2020-04-07 15:17:50 UTC
+++ libgcc/config/rs6000/t-crtstuff
@@ -3,4 +3,4 @@
 # Do not build crtend.o with -Os as that can result in references to
 # out-of-line register save/restore functions, which may be unresolved
 # as crtend.o is linked after libgcc.a.  See PR45053.
-CRTSTUFF_T_CFLAGS = -msdata=none -O2 -fno-asynchronous-unwind-tables
+CRTSTUFF_T_CFLAGS = -msdata=none -O0 -fno-asynchronous-unwind-tables
--- Makefile.in.orig2020-04-08 13:04:40 UTC
+++ Makefile.in
@@ -372,7 +372,7 @@ BUILD_PREFIX_1 = @BUILD_PREFIX_1@

 # Flags to pass to stage2 and later makes.  They are defined
 # here so that they can be overridden by Makefile fragments.
-BOOT_CFLAGS= -g -O2
+BOOT_CFLAGS?= -g -O2
 BOOT_LDFLAGS=
 BOOT_ADAFLAGS= -gnatpg


And then you need to pass to configure and make the following env variables
CFLAGS_FOR_TARGET="-O0" CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0".
The first patch is already sent by Gustavo Romero from IBM to GCC patches list.

GCC10 needs further fixing, unfortunately.

[Bug c++/93639] [c++2a] Segfault on non type template parameter and consteval (master)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Dup.

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

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||raphael.grimm at kit dot edu

--- Comment #4 from Marek Polacek  ---
*** Bug 93639 has been marked as a duplicate of this bug. ***

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Test from bug 93639:

template struct A;

template struct B;

template 
struct C
{
using type = B;
};

int main() {}

[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7685-ga615ea71bc8fbf31b9bc71cb373a7ca5b9cca44a
Author: Jakub Jelinek 
Date:   Sat Apr 11 07:32:12 2020 +0200

cselib: Mark the cselib_record_sp_cfa_base_equiv VALUE as preserved
[PR94551]

Sometimes the cselib_record_sp_cfa_base_equiv makes it into the
var-tracking
used VALUEs and needs to be preserved.

2020-04-11  Jakub Jelinek  

PR debug/94495
PR target/94551
* cselib.c (cselib_record_sp_cfa_base_equiv): Set PRESERVED_VALUE_P
on
val->val_rtx.

[Bug target/94551] [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7685-ga615ea71bc8fbf31b9bc71cb373a7ca5b9cca44a
Author: Jakub Jelinek 
Date:   Sat Apr 11 07:32:12 2020 +0200

cselib: Mark the cselib_record_sp_cfa_base_equiv VALUE as preserved
[PR94551]

Sometimes the cselib_record_sp_cfa_base_equiv makes it into the
var-tracking
used VALUEs and needs to be preserved.

2020-04-11  Jakub Jelinek  

PR debug/94495
PR target/94551
* cselib.c (cselib_record_sp_cfa_base_equiv): Set PRESERVED_VALUE_P
on
val->val_rtx.

[Bug tree-optimization/94482] [8/9 Regression] Inserting into vector with optimization enabled on x86 generates incorrect result

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7686-gbb87d5cc77db1f28083990f44e20b6c0728d925e
Author: Jakub Jelinek 
Date:   Sat Apr 11 07:50:50 2020 +0200

testsuite: Fix up pr94482.c testcase [PR94482]

The test FAILs on powerpc64-linux with -m32 due to psabi warnings.
Furthermore, the test needs really -msse2 to reproduce on x86 -m32 at -O2.

2020-04-11  Jakub Jelinek  

PR tree-optimization/94482
* gcc.dg/torture/pr94482.c: Add -Wno-psabi -w.  Don't add -msse
and sse_runtime effective target on x86, instead only add -msse2
if target is sse2_runtime.

[Bug c++/33661] template methods forget explicit local register asm vars

[mp8191mp at gmail dot com]

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

Martin Papik  changed:

   What|Removed |Added

 CC||mp8191mp at gmail dot com

--- Comment #17 from Martin Papik  ---

Hello, I found a bug, which I think is a duplicate of this one, but am not 100%
sure.

Below is a minimal piece of code which triggers the bug. All versions of gcc
seem to be affected, as seen on compiler explorer,
https://godbolt.org/z/jFMj8b, which also shows a difference in gimple, the
templated version is missing the explicit naming attributes.

Is this the same bug? If so, is there some technical reason why a clear
miscompilation persists for as long as it seems to? What I mean is this, if a
bug like this persists for this long, it could be taken to mean that the bug is
too big for a casual volunteer. Would that be the case? Can someone familiar
with the code base tell me what I'd need to know to fix this, e.g. what's wrong
with the patch, is it better to fix the patch or start from scratch.


$ cat bug.cpp
#define DEMONSTRABLY_IDENTICAL  \
long ret;   \
register long r10 __asm__("r10") = (long)a4;\
__asm__ __volatile__ ("syscall" \
: "=a"(ret) \
: "a"(n), "D"(a1), "S"(a2), "d"(a3), "r"(r10)   \
: "rcx", "r11", "memory"\
);
enum class sysnr : long {
// accept4 has enough parameters to require extra registers and trigger
the bug
accept4 = 0x120
};
static __inline long sys_01(long n, long a1, long a2, long a3, long a4)
{
DEMONSTRABLY_IDENTICAL
return ret;
}
template 
RET sys_02(T1 a1, T2 a2, T3 a3, T4 a4) {
constexpr long n = (long) SYS_NR;
DEMONSTRABLY_IDENTICAL
return (RET)ret;
}
void test_01 () {
sys_01( (long)sysnr::accept4, 0xfeed01, 0xfeed02, 0xfeed03, 0xfeed04 );
}
void test_02() {
sys_02( 0xfeed01, 0xfeed02, 0xfeed03, 0xfeed04 );
}
void test_03() {
sys_02( 0xfeed01,
0xfeed02, 0xfeed03, 0xfeed04 );
}

$ g++ -std=c++11 -O1 bug.cpp -c -o bug.c
$ objdump -Cd bug.o 

bug.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   41 ba 04 ed fe 00   mov$0xfeed04,%r10d
   6:   b8 20 01 00 00  mov$0x120,%eax
   b:   bf 01 ed fe 00  mov$0xfeed01,%edi
  10:   be 02 ed fe 00  mov$0xfeed02,%esi
  15:   ba 03 ed fe 00  mov$0xfeed03,%edx
  1a:   0f 05   syscall 
  1c:   c3  retq   

001d :
  1d:   b8 20 01 00 00  mov$0x120,%eax
  22:   bf 01 ed fe 00  mov$0xfeed01,%edi
  27:   be 02 ed fe 00  mov$0xfeed02,%esi
  2c:   ba 03 ed fe 00  mov$0xfeed03,%edx
  31:   41 b8 04 ed fe 00   mov$0xfeed04,%r8d
  37:   0f 05   syscall 
  39:   c3  retq   

003a :
  3a:   b8 20 01 00 00  mov$0x120,%eax
  3f:   bf 01 ed fe 00  mov$0xfeed01,%edi
  44:   be 02 ed fe 00  mov$0xfeed02,%esi
  49:   ba 03 ed fe 00  mov$0xfeed03,%edx
  4e:   41 b8 04 ed fe 00   mov$0xfeed04,%r8d
  54:   0f 05   syscall 
  56:   c3  retq