[Bug c++/102490] Erroneous optimization of default constexpr operator== of struct with bitfields

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:09d886e671f2230acca082e6579a69b8df8fb202

commit r12-4202-g09d886e671f2230acca082e6579a69b8df8fb202
Author: Jakub Jelinek 
Date:   Fri Oct 1 17:07:17 2021 +0200

c++: defaulted <=> with bitfields [PR102490]

The testcases in the patch are either miscompiled or ICE with checking,
because the defaulted operator== is synthesized too early (but only if
constexpr), when the corresponding class type is still incomplete type. 
The
problem is that at that point the bitfield FIELD_DECLs still have as
TREE_TYPE their underlying type rather than integral type with their
precision and when layout_class_type is called for the class soon after
that, it changes those types but the COMPONENT_REFs type stay the way that
they were during the operator== synthesize_method type and the middle-end
is
then upset by the mismatch of types.  As what exact type will be given
isn't
just a one liner but quite long code especially for over-sized bitfields, I
think it is best to just not synthesize the comparison operators so early
and call defaulted_late_check for them once again as soon as the class is
complete.

This is also a problem for virtual operator<=>, where we need to compare
the
noexcept-specifier to validate the override before the class is complete.
Rather than try to defer that comparison, maybe_instantiate_noexcept now
calls maybe_synthesize_method, which calls build_comparison_op in
non-defining mode if the class isn't complete yet.  In that situation we
also might not have base fields yet, so we look in the binfo for the bases.

Co-authored-by: Jason Merrill 

2021-10-01  Jakub Jelinek  

PR c++/98712
PR c++/102490
* cp-tree.h (maybe_synthesize_method): Declare.
* method.c (genericize_spaceship): Use
LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
LOOKUP_NORMAL for flags.
(comp_info): Remove defining member.  Add complain, code, retcat.
(comp_info::comp_info): Adjust.
(do_one_comp): Split out from build_comparison_op.   Use
LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
LOOKUP_NORMAL for flags.
(build_comparison_op): Add defining argument. Adjust comp_info
construction.  Use defining instead of info.defining.  Assert that
if defining, ctype is a complete type.  Walk base binfos.
(synthesize_method, maybe_explain_implicit_delete,
explain_implicit_non_constexpr): Adjust build_comparison_op
callers.
(maybe_synthesize_method): New function.
* class.c (check_bases_and_members): Don't call
defaulted_late_check
for sfk_comparison.
(finish_struct_1): Call it here instead after class has been
completed.
* pt.c (maybe_instantiate_noexcept): Call maybe_synthesize_method
instead of synthesize_method.

* g++.dg/cpp2a/spaceship-synth8.C (std::strong_ordering): Provide
more complete definition.
(std::strong_ordering::less, std::strong_ordering::equal,
std::strong_ordering::greater): Define.
* g++.dg/cpp2a/spaceship-synth12.C: New test.
* g++.dg/cpp2a/spaceship-synth13.C: New test.
* g++.dg/cpp2a/spaceship-synth14.C: New test.
* g++.dg/cpp2a/spaceship-eq11.C: New test.
* g++.dg/cpp2a/spaceship-eq12.C: New test.
* g++.dg/cpp2a/spaceship-eq13.C: New test.

[Bug c++/98712] Incorrect defaulted operator== at compile time and runtime when declared constexpr and inheriting (c++20)

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:09d886e671f2230acca082e6579a69b8df8fb202

commit r12-4202-g09d886e671f2230acca082e6579a69b8df8fb202
Author: Jakub Jelinek 
Date:   Fri Oct 1 17:07:17 2021 +0200

c++: defaulted <=> with bitfields [PR102490]

The testcases in the patch are either miscompiled or ICE with checking,
because the defaulted operator== is synthesized too early (but only if
constexpr), when the corresponding class type is still incomplete type. 
The
problem is that at that point the bitfield FIELD_DECLs still have as
TREE_TYPE their underlying type rather than integral type with their
precision and when layout_class_type is called for the class soon after
that, it changes those types but the COMPONENT_REFs type stay the way that
they were during the operator== synthesize_method type and the middle-end
is
then upset by the mismatch of types.  As what exact type will be given
isn't
just a one liner but quite long code especially for over-sized bitfields, I
think it is best to just not synthesize the comparison operators so early
and call defaulted_late_check for them once again as soon as the class is
complete.

This is also a problem for virtual operator<=>, where we need to compare
the
noexcept-specifier to validate the override before the class is complete.
Rather than try to defer that comparison, maybe_instantiate_noexcept now
calls maybe_synthesize_method, which calls build_comparison_op in
non-defining mode if the class isn't complete yet.  In that situation we
also might not have base fields yet, so we look in the binfo for the bases.

Co-authored-by: Jason Merrill 

2021-10-01  Jakub Jelinek  

PR c++/98712
PR c++/102490
* cp-tree.h (maybe_synthesize_method): Declare.
* method.c (genericize_spaceship): Use
LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
LOOKUP_NORMAL for flags.
(comp_info): Remove defining member.  Add complain, code, retcat.
(comp_info::comp_info): Adjust.
(do_one_comp): Split out from build_comparison_op.   Use
LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
LOOKUP_NORMAL for flags.
(build_comparison_op): Add defining argument. Adjust comp_info
construction.  Use defining instead of info.defining.  Assert that
if defining, ctype is a complete type.  Walk base binfos.
(synthesize_method, maybe_explain_implicit_delete,
explain_implicit_non_constexpr): Adjust build_comparison_op
callers.
(maybe_synthesize_method): New function.
* class.c (check_bases_and_members): Don't call
defaulted_late_check
for sfk_comparison.
(finish_struct_1): Call it here instead after class has been
completed.
* pt.c (maybe_instantiate_noexcept): Call maybe_synthesize_method
instead of synthesize_method.

* g++.dg/cpp2a/spaceship-synth8.C (std::strong_ordering): Provide
more complete definition.
(std::strong_ordering::less, std::strong_ordering::equal,
std::strong_ordering::greater): Define.
* g++.dg/cpp2a/spaceship-synth12.C: New test.
* g++.dg/cpp2a/spaceship-synth13.C: New test.
* g++.dg/cpp2a/spaceship-synth14.C: New test.
* g++.dg/cpp2a/spaceship-eq11.C: New test.
* g++.dg/cpp2a/spaceship-eq12.C: New test.
* g++.dg/cpp2a/spaceship-eq13.C: New test.

[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'

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

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

--- Comment #25 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #24)
> I wanted to look at #c20, but at least my i9-7960X for e.g. lock; btsl $65,
> var
> acts the same as lock; btsl $1, var rather than lock; btsl $1, var+8,
> so maybe #c20 is not possible.

The maximum bit position is 63 for the immediate operand.

[Bug middle-end/93644] [10/11/12 Regression] spurious -Wreturn-local-addr with PHI of PHI

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

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

--- Comment #18 from Eric Gallager  ---
This affects musl's getcwd implementation, btw:
https://git.musl-libc.org/cgit/musl/tree/src/unistd/getcwd.c?id=v1.2.2

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

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

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

--- Comment #13 from Eric Gallager  ---
For the purposes of clarifying the "lacks support" wording, where exactly does
the failure occur if one tries to enable it? That is, in which step?

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[ilya.konstantinov at gmail dot com via Gcc-bugs]

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

Ilya Konstantinov  changed:

   What|Removed |Added

 CC||ilya.konstantinov at gmail dot 
com

--- Comment #11 from Ilya Konstantinov  ---
Another manifestation of 'crtfastmath.o considered harmful':
https://github.com/gevent/gevent/pull/1820

[Bug target/102625] New: [meta-bug] -mcmodel=large can't link

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

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

Bug ID: 102625
   Summary: [meta-bug] -mcmodel=large can't link
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Depends on: 95620, 98693
  Target Milestone: ---
Target: x86-64

[hjl@gnu-cfl-2 tmp]$ cat l.c
#include 

char foo[0x1] = { 1 };

int
main ()
{
  printf ("%p\n", foo);
  return 0;
}
[hjl@gnu-cfl-2 tmp]$ gcc l.c -mcmodel=large
/usr/lib/gcc/x86_64-redhat-linux/11/crtbegin.o: in function
`deregister_tm_clones':
crtstuff.c:(.text+0x1): relocation truncated to fit: R_X86_64_32 against symbol
`__TMC_END__' defined in .data section in a.out
crtstuff.c:(.text+0x7): relocation truncated to fit: R_X86_64_32S against
`.tm_clone_table'
crtstuff.c:(.text+0x18): relocation truncated to fit: R_X86_64_32 against
`.tm_clone_table'
/usr/lib/gcc/x86_64-redhat-linux/11/crtbegin.o: in function
`register_tm_clones':
crtstuff.c:(.text+0x31): relocation truncated to fit: R_X86_64_32 against
symbol `__TMC_END__' defined in .data section in a.out
crtstuff.c:(.text+0x38): relocation truncated to fit: R_X86_64_32S against
`.tm_clone_table'
crtstuff.c:(.text+0x5a): relocation truncated to fit: R_X86_64_32 against
`.tm_clone_table'
/usr/lib/gcc/x86_64-redhat-linux/11/crtbegin.o: in function
`__do_global_dtors_aux':
crtstuff.c:(.text+0x76): relocation truncated to fit: R_X86_64_PC32 against
`.bss'
crtstuff.c:(.text+0x88): relocation truncated to fit: R_X86_64_PC32 against
`.bss'
collect2: error: ld returned 1 exit status
[hjl@gnu-cfl-2 tmp]$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620
[Bug 95620] [10 Regression] relocation truncated to fit: R_X86_64_PC32 against
`.bss'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98693
[Bug 98693] Compiling with -mcmodel=large emits .eh_frame with R_X86_64_PC32

[Bug target/102485] -Wa,-many no longer has any effect

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

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #4)
> (In reply to Segher Boessenkool from comment #3)
> > (In reply to Paul Clarke from comment #2)
> > > "-many" is supposed to make those black boxes just work.  This worked 
> > > before
> > > recent changes to binutils/GCC.  Is there any valid use of "-Wa,-many" 
> > > now?
> > 
> > It will still work if you are "compiling" a .s or .S, no?
> 
> Correct, since GCC doesn't actually compile anything, the asm is just passed
> directly to the assembler as is (modulo preprocessing, but that won't emit a
> .machine directive).

Yes.  I just didn't verify it actually still works after the changes :-)

[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.2.0

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Here is a slightly more reduced testcase (without the reasonable values):

Looks like the store to var_22 was fully removed, I think this is not a
vectorizer bug really, but rather some issue with jump threading 

[Bug tree-optimization/102359] ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
fixed

[Bug tree-optimization/102359] ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

https://gcc.gnu.org/g:433516e1c6b1f8eeceeceb83cec5ea02a14065dc

commit r12-4200-g433516e1c6b1f8eeceeceb83cec5ea02a14065dc
Author: qing zhao 
Date:   Tue Oct 5 16:14:00 2021 -0700

Not add initialization for variables been initialized by FEs [PR102359]

C++ FE creates proxy variables, which have associated DECL_VALUE_EXPR
and have been initialized by FE. For such auto variable, we should not
add initialization when -ftrivial-auto-var-init presents.

PR middle-end/102359

gcc/ChangeLog:

2021-10-05  qing zhao  

* gimplify.c (gimplify_decl_expr): Not add initialization for an
auto variable when it has been initialized by frontend.

gcc/testsuite/ChangeLog:

2021-10-05  qing zhao  

* g++.dg/pr102359_1.C: New test.
* g++.dg/pr102359_2.C: New test.

[Bug target/102485] -Wa,-many no longer has any effect

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

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

--- Comment #4 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Paul Clarke from comment #2)
> > "-many" is supposed to make those black boxes just work.  This worked before
> > recent changes to binutils/GCC.  Is there any valid use of "-Wa,-many" now?
> 
> It will still work if you are "compiling" a .s or .S, no?

Correct, since GCC doesn't actually compile anything, the asm is just passed
directly to the assembler as is (modulo preprocessing, but that won't emit a
.machine directive).

[Bug testsuite/94853] [10/11/12 regression] excess errors in gfortran.dg/analyzer/pr93993.f90 since r10-8012

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #7 from Peter Bergner  ---
(In reply to Martin Liška from comment #4)
> Nay progress on this please?

This still seems to be broken on GCC10 over a year after Martin's ping.

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #11 from Peter Bergner  ---
Bill confirmed these are now fixed.  Thanks for the fix Patrick!

[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

--- Comment #5 from Peter Bergner  ---
So I took dgebal.f and ran delta on it to try and reduce it to something
manageable (I wish creduce worked on fortran files!) and got the following
which still shows us accessing above the stack.

  SUBROUTINE DGEBAL( JOB, N, A, LDA, ILO, IHI, SCALE, INFO )
  CHARACTER  JOB
  DOUBLE PRECISION   A( LDA, * ), SCALE( * )
  LOGICALNOCONV
  140 CONTINUE
  DO 200 I = K, L
 C = DNRM2( L-K+1, A( K, I ), 1 )
 R = DNRM2( L-K+1, A( I, K ), LDA )
 ICA = IDAMAX( L, A( 1, I ), 1 )
 CA = ABS( A( ICA, I ) )
 IF( C.EQ.ZERO .OR. R.EQ.ZERO )
 $  GO TO 200
 IF( G.LT.R .OR. MAX( R, RA ).GE.SFMAX2 .OR.
 $   MIN( F, C, G, CA ).LE.SFMIN2 )GO TO 190
 F = F / SCLFAC
 G = G / SCLFAC
  190CONTINUE
 IF( ( C+R ).GE.FACTOR*S )
 $  GO TO 200
 IF( F.LT.ONE .AND. SCALE( I ).LT.ONE ) THEN
 END IF
 CALL DSCAL( N-K+1, G, A( I, K ), LDA )
  200 CONTINUE
  IF( NOCONV )
 $   GO TO 140
  END

This isn't related to some strange fortran parameter passing rules (ie, all
params are passed by reference), is it?


dgebal_:
.LFB0:
.cfi_startproc
.LCF0:
0:  addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry dgebal_,.-dgebal_
std 24,-88(1)
.cfi_offset 24, -88
lwa 24,0(6)
mflr 0
mfcr 11,8
std 20,-120(1)
std 15,-160(1)
std 16,-152(1)
std 17,-144(1)
std 19,-128(1)
std 21,-112(1)
std 22,-104(1)
std 23,-96(1)
std 25,-80(1)
std 27,-64(1)
std 28,-56(1)
stw 11,8(1)
li 9,0
.cfi_register 65, 0
.cfi_offset 20, -120
.cfi_offset 15, -160
.cfi_offset 16, -152
.cfi_offset 17, -144
.cfi_offset 19, -128
.cfi_offset 21, -112
.cfi_offset 22, -104
.cfi_offset 23, -96
.cfi_offset 25, -80
.cfi_offset 27, -64
.cfi_offset 28, -56
.cfi_offset 72, 8
addis 27,2,.LANCHOR0@toc@ha
stfd 29,-24(1)
stfd 30,-16(1)
stfd 31,-8(1)
std 14,-168(1)
std 18,-136(1)
std 26,-72(1)
std 29,-48(1)
cmpdi 0,24,0
std 0,16(1)
std 30,-40(1)
std 31,-32(1)
stdu 1,-224(1)
.cfi_def_cfa_offset 224
.cfi_offset 61, -24
.cfi_offset 62, -16
.cfi_offset 63, -8
.cfi_offset 14, -168
.cfi_offset 18, -136
.cfi_offset 26, -72
.cfi_offset 29, -48
.cfi_offset 65, 16
.cfi_offset 30, -40
.cfi_offset 31, -32
addi 27,27,.LANCHOR0@toc@l
li 21,-8
mr 25,6
isel 24,0,24,0
mr 16,4
cmpwi 4,9,0
addi 28,1,32
addi 22,1,36
addi 15,1,40
std 5,272(1)   # 272 is bigger than 224!
...

[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server

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

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

--- Comment #2 from Andrew Pinski  ---
Here is a slightly more reduced testcase (without the reasonable values):
static inline const unsigned (const unsigned , const unsigned )
{
return t > t1 ? t : t1;
}
extern int  var_20, var_22;
extern short arr_32[];
extern char arr_45[];

void test(int a, unsigned b, const long long ) __attribute__((noipa));
void test(int a, unsigned b, const long long ) {
  for (short d = 0; d < 13; d++) {
for (int e = 0; e < a; e += 3)
  var_20 = 0;
if (max1(b, unsigned((short)b))) {
  arr_32[d] = 0;
  var_22 = c;
}
for (unsigned f = 0; f < 69; f += 4)
  arr_45[f] = 0;
  }
}


int var_20 = 0;
int var_22 = 0;
short arr_32 [13];
char arr_45 [69];

int main() {
test(-1, 1, 42);
if (var_22 != 42)
  __builtin_abort();
return 0;
}

[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Wrong code with -O3 for |[12 Regression] Wrong code
   |skylake-avx512 and  |with -O3 for skylake-avx512
   |icelake-server  |and icelake-server
   Last reconfirmed||2021-10-05
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
reduced to one file:
static inline const unsigned (const unsigned , const unsigned )
{
return t > t1 ? t : t1;
}
long long int c = 42;
int var_20 = 0;
int var_22 = 0;
short arr_32 [13];
char arr_45 [69];

void test(int a, unsigned b, long long *c) __attribute__((noipa));
void test(int a, unsigned b, long long *c) {
  for (short d = 0; d < 13; d++) {
for (int e = 0; e < a; e += 3)
  var_20 = 0;
if (max1(b, unsigned((short)b))) {
  arr_32[d] = 0;
  var_22 = *c;
}
for (unsigned f = 0; f < 69; f += 4)
  arr_45[f] = 0;
  }
}
int main() {
test(-545750584, 1144022456U, );
if (var_22 != 42)
  __builtin_abort();
return 0;
}

Confirmed.

[Bug c++/102548] [9/10 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41

[ulatekh at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Steven Boswell II  ---
Great work! Thanks!

The patch seems to apply to gcc 10 also, but I haven't built the result yet.

[Bug target/102485] -Wa,-many no longer has any effect

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

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Paul Clarke from comment #2)
> GCC putting the base ".machine" directive at the beginning of the file makes
> any command-line use of "-many" (-Wa,-many) be ignored.  Is that OK? 

If people do not use -Wa,-many unnecessarily, it probably would be
good if the assembler somehow retained that option.  But I get the
impression that that option is used a lot for no good reason at all,
and that causes weird problems.

> "-many" is supposed to make those black boxes just work.  This worked before
> recent changes to binutils/GCC.  Is there any valid use of "-Wa,-many" now?

It will still work if you are "compiling" a .s or .S, no?

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from qingzhe huang  ---

> Ah yeah, I can reproduce the crash when invoking cc1plus directly and also
> when
> passing -Q to the driver.  Might be better to open a separate PR for this as
> it
> seems to be a latent bug.

just opened a new bug: pr102624

[Bug c++/102624] New: testcase lambda-uneval11.C causes cc1plus segment fault

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102624
   Summary: testcase lambda-uneval11.C causes cc1plus  segment
fault
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

The testcase g++.dg/cpp2a/lambda-uneval11.C causes cc1plus segment fault.
Running g++ driver won't expose this crash. Only running cc1plus directly can
expose the crash.




./install/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/cc1plus -std=c++20
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C
  void spam(decltype () (*)[sizeof (T)]) void foo()
 static constexpr void::_FUN()
constexpr::operator void (*)()() const  static constexpr
void::_FUN() constexpr::operator void (*)()() const
 static constexpr void::_FUN()
constexpr::operator void (*)()() const  static constexpr
void::_FUN() constexpr::operator void (*)()() const
constexpr::operator void (*)()() const  static constexpr
void::_FUN() constexpr::operator void (*)()() const
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C: In instantiation of
‘constexpr::operator void (*)()() const’:
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:9:12:   required from
here
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:4:25: internal compiler
error: Segmentation fault
4 | template  void spam(decltype([]{}) (*s)[sizeof(T)] = nullptr)
  | ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from qingzhe huang  ---
>>Might be better to open a separate PR for this as it
seems to be a latent bug.
thanks, I will file a new bug.









From: ppalka at gcc dot gnu.org 
Sent: October 5, 2021 5:05 PM
To: nickhuan...@hotmail.com 
Subject: [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on
warning write-strings 

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

--- Comment #14 from Patrick Palka  ---
(In reply to qingzhe huang from comment #13)
> (In reply to Patrick Palka from comment #12)
> > (In reply to qingzhe huang from comment #11)
> > > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault 
> > > if
> > > run by compiler cc1plus with latest code.
> > 
> > Hmm, I can't reproduce that on latest trunk.  Is your working tree clean?
> 
> I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull.
> It won't show anything when compiling with driver, i.e. g++, but if you run
> "cc1plus", it will crash. For example,
> ${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus
> -std=c++20 ./lambda-uneval11.C
> 
> Thank you

Ah yeah, I can reproduce the crash when invoking cc1plus directly and also when
passing -Q to the driver.  Might be better to open a separate PR for this as it
seems to be a latent bug.

[Bug c++/102548] [9/10 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10 Regression] ICE with
   |with cdecl attribute on a   |cdecl attribute on a
   |builtin function since  |builtin function since
   |r7-4737-g48330c9355e32a41   |r7-4737-g48330c9355e32a41

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.3+ and 12.1+ for now.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

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

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

--- Comment #14 from Patrick Palka  ---
(In reply to qingzhe huang from comment #13)
> (In reply to Patrick Palka from comment #12)
> > (In reply to qingzhe huang from comment #11)
> > > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault 
> > > if
> > > run by compiler cc1plus with latest code.
> > 
> > Hmm, I can't reproduce that on latest trunk.  Is your working tree clean?
> 
> I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull.
> It won't show anything when compiling with driver, i.e. g++, but if you run
> "cc1plus", it will crash. For example,
> ${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus
> -std=c++20 ./lambda-uneval11.C
> 
> Thank you

Ah yeah, I can reproduce the crash when invoking cc1plus directly and also when
passing -Q to the driver.  Might be better to open a separate PR for this as it
seems to be a latent bug.

[Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-9075-ge1edbce89a93dde8653666eaf402d58dda43e3b0
Author: Jakub Jelinek 
Date:   Tue Oct 5 22:28:38 2021 +0200

c++: Fix apply_identity_attributes [PR102548]

The following testcase ICEs on x86_64-linux with -m32 due to a bug in
apply_identity_attributes.  The function is being smart and attempts not
to duplicate the chain unnecessarily, if either there are no attributes
that affect type identity or there is possibly empty set of attributes
that do not affect type identity in the chain followed by attributes
that do affect type identity, it reuses that attribute chain.

The function mishandles the cases where in the chain an attribute affects
type identity and is followed by one or more attributes that don't
affect type identity (and then perhaps some further ones that do).

There are two bugs.  One is that when we notice first attribute that
doesn't affect type identity after first attribute that does affect type
identity (with perhaps some further such attributes in the chain after it),
we want to put into the new chain just attributes starting from
(inclusive) first_ident and up to (exclusive) the current attribute a,
but the code puts into the chain all attributes starting with first_ident,
including the ones that do not affect type identity and if e.g. we have
doesn't0 affects1 doesn't2 affects3 affects4 sequence of attributes, the
resulting sequence would have
affects1 doesn't2 affects3 affects4 affects3 affects4
attributes, i.e. one attribute that shouldn't be there and two attributes
duplicated.  That is fixed by the a2 -> a2 != a change.

The second one is that we ICE once we see second attribute that doesn't
affect type identity after an attribute that affects it.  That is because
first_ident is set to error_mark_node after handling the first attribute
that doesn't affect type identity (i.e. after we've copied the
[first_ident, a) set of attributes to the new chain) to denote that from
that time on, each attribute that affects type identity should be copied
whenever it is seen (the if (as && as->affects_type_identity) code does
that correctly).  But that condition is false and first_ident is
error_mark_node, we enter else if (first_ident) and use TREE_PURPOSE
/TREE_VALUE/TREE_CHAIN on error_mark_node, which ICEs.  When
first_ident is error_mark_node and a doesn't affect type identity,
we want to do nothing.  So that is the && first_ident != error_mark_node
chunk.

2021-10-05  Jakub Jelinek  

PR c++/102548
* tree.c (apply_identity_attributes): Fix handling of the
case where an attribute in the list doesn't affect type
identity but some attribute before it does.

* g++.target/i386/pr102548.C: New test.

(cherry picked from commit 737f95bab557584d876f02779ab79fe3cfaacacf)

[Bug sanitizer/102515] UBSAN misses signed division instrumentation

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-9074-gdcf70cb0d85d04ff680a361e32d79c326ae8b3fc
Author: Jakub Jelinek 
Date:   Fri Oct 1 14:27:32 2021 +0200

ubsan: Use -fno{,-}sanitize=float-divide-by-zero for float division by zero
recovery [PR102515]

We've been using
-f{,no-}sanitize-recover=integer-divide-by-zero to decide on the float
-fsanitize=float-divide-by-zero instrumentation _abort suffix.
This patch fixes it to use -f{,no-}sanitize-recover=float-divide-by-zero
for it instead.

2021-10-01  Jakub Jelinek  
Richard Biener  

PR sanitizer/102515
gcc/c-family/
* c-ubsan.c (ubsan_instrument_division): Check the right
flag_sanitize_recover bit, depending on which sanitization
is done.
gcc/testsuite/
* c-c++-common/ubsan/float-div-by-zero-2.c: New test.

(cherry picked from commit 9c1a633d96926357155d4702b66f8a0ec856a81f)

[Bug c++/102496] [11 regression] extern __thread and thread_local declaration in function scope produces a non-TLS reference

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:5fec46a0b4a94190209c81f4091a0369a056727d

commit r11-9073-g5fec46a0b4a94190209c81f4091a0369a056727d
Author: Jakub Jelinek 
Date:   Fri Oct 1 10:30:16 2021 +0200

c++: Fix handling of __thread/thread_local extern vars declared at function
scope [PR102496]

The introduction of push_local_extern_decl_alias in
r11-3699-g4e62aca0e0520e4ed2532f2d8153581190621c1a
broke tls vars, while the decl they are created for has the tls model
set properly, nothing sets it for the alias that is actually used,
so accesses to it are done as if they were normal variables.
This is then diagnosed at link time if the definition of the extern
vars is __thread/thread_local.

2021-10-01  Jakub Jelinek  

PR c++/102496
* name-lookup.c (push_local_extern_decl_alias): Return early even
for
tls vars with non-dependent type when processing_template_decl. 
For
CP_DECL_THREAD_LOCAL_P vars call set_decl_tls_model on alias.

* g++.dg/tls/pr102496-1.C: New test.
* g++.dg/tls/pr102496-2.C: New test.

(cherry picked from commit 701075864ac4d1c6cec936d10f9cfc2aeb8c1699)

[Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41

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

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

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

https://gcc.gnu.org/g:737f95bab557584d876f02779ab79fe3cfaacacf

commit r12-4198-g737f95bab557584d876f02779ab79fe3cfaacacf
Author: Jakub Jelinek 
Date:   Tue Oct 5 22:28:38 2021 +0200

c++: Fix apply_identity_attributes [PR102548]

The following testcase ICEs on x86_64-linux with -m32 due to a bug in
apply_identity_attributes.  The function is being smart and attempts not
to duplicate the chain unnecessarily, if either there are no attributes
that affect type identity or there is possibly empty set of attributes
that do not affect type identity in the chain followed by attributes
that do affect type identity, it reuses that attribute chain.

The function mishandles the cases where in the chain an attribute affects
type identity and is followed by one or more attributes that don't
affect type identity (and then perhaps some further ones that do).

There are two bugs.  One is that when we notice first attribute that
doesn't affect type identity after first attribute that does affect type
identity (with perhaps some further such attributes in the chain after it),
we want to put into the new chain just attributes starting from
(inclusive) first_ident and up to (exclusive) the current attribute a,
but the code puts into the chain all attributes starting with first_ident,
including the ones that do not affect type identity and if e.g. we have
doesn't0 affects1 doesn't2 affects3 affects4 sequence of attributes, the
resulting sequence would have
affects1 doesn't2 affects3 affects4 affects3 affects4
attributes, i.e. one attribute that shouldn't be there and two attributes
duplicated.  That is fixed by the a2 -> a2 != a change.

The second one is that we ICE once we see second attribute that doesn't
affect type identity after an attribute that affects it.  That is because
first_ident is set to error_mark_node after handling the first attribute
that doesn't affect type identity (i.e. after we've copied the
[first_ident, a) set of attributes to the new chain) to denote that from
that time on, each attribute that affects type identity should be copied
whenever it is seen (the if (as && as->affects_type_identity) code does
that correctly).  But that condition is false and first_ident is
error_mark_node, we enter else if (first_ident) and use TREE_PURPOSE
/TREE_VALUE/TREE_CHAIN on error_mark_node, which ICEs.  When
first_ident is error_mark_node and a doesn't affect type identity,
we want to do nothing.  So that is the && first_ident != error_mark_node
chunk.

2021-10-05  Jakub Jelinek  

PR c++/102548
* tree.c (apply_identity_attributes): Fix handling of the
case where an attribute in the list doesn't affect type
identity but some attribute before it does.

* g++.target/i386/pr102548.C: New test.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-05
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

May be related to pr102599 in some way or other.

[Bug fortran/102582] allocate treats all variables as type CHARACTER after use of CHARACTER(LEN=NNN)::

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Thanks for confirming that other compilers may have bugs!  Closing as per
request.

[Bug c++/102623] Failure to detect destructed scalar objects in consteval function

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I suspect this is basically PR 71093.

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from anlauf at gcc dot gnu.org ---
Fixed on mainline and backported to 11- and 10-branch.
Probably too risky for 9-branch.  Closing.

Thanks for the report!

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

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

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

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

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

commit r10-10170-gdea2e6c7b5af2ec620fd94d824f006440907a34d
Author: Harald Anlauf 
Date:   Thu Sep 30 20:29:31 2021 +0200

Fortran: resolve expressions during SIZE simplification

gcc/fortran/ChangeLog:

PR fortran/102458
* simplify.c (simplify_size): Resolve expressions used in array
specifications so that SIZE can be simplified.

gcc/testsuite/ChangeLog:

PR fortran/102458
* gfortran.dg/pr102458b.f90: New test.

(cherry picked from commit b19bbfb1482505367dd19ae4ab1ea19e36802b6a)

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

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

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

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

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

commit r10-10169-g4aabb9ac284fea307aa70bb8ae4bdce298461bc7
Author: Harald Anlauf 
Date:   Fri Sep 24 19:10:15 2021 +0200

Fortran - improve checking for intrinsics allowed in constant expressions

gcc/fortran/ChangeLog:

PR fortran/102458
* expr.c (is_non_constant_intrinsic): Check for intrinsics
excluded in constant expressions (F2018:10.1.12).
(gfc_is_constant_expr): Use that check.

gcc/testsuite/ChangeLog:

PR fortran/102458
* gfortran.dg/pr102458.f90: New test.

(cherry picked from commit 082b3588ee01399b93fe73acd2ac181ec2ee3536)

[Bug c++/102547] [11 Regression] g++ 11. ICE with NTTPs and partial specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12 Regression] g++ 11.  |[11 Regression] g++ 11. ICE
   |ICE with NTTPs and partial  |with NTTPs and partial
   |specialization  |specialization

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization

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

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

--- Comment #6 from Patrick Palka  ---
(In reply to Bob Steagall from comment #4)
> I have applied this tentative change to line 23436 of gcc/cp/pt.c from the
> gcc-11.2.0 source tarball, and can confirm that the test case compiles for
> me.
> 
> The code I was working on also compiles, links, and appears to run correctly.
> 
> I don't know if this is the final fix, but it is progress.

Excellent, thanks for testing.  The final fix is different but should have the
same effect.

[Bug c++/102623] New: Failure to detect destructed scalar objects in consteval function

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102623
   Summary: Failure to detect destructed scalar objects in
consteval function
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

using T = int;
consteval bool f()
{
  T t = 42;
  t.~T();
  return (t == 42);
}

bool x = f();

This code should not compile, as `f` invokes undefined behavior during constant
evaluation, as Clang diagnoses:

:9:10: error: call to consteval function 'f' is not a constant
expression
bool x = f();
 ^
:6:11: note: read of object outside its lifetime is not allowed in a
constant expression
  return (t == 42);
  ^

The specific usage with `int` here was not UB until C++20 (although
pseudo-destructors weren't allowed in constant expressions until C++20 anyway),
but as of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html#pseudo-destructor-calls
pseudo-destructors end the lifetime of the operand.

[Bug tree-optimization/102622] New: Wrong code with -O3 for skylake-avx512 and icelake-server

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 102622
   Summary: Wrong code with -O3 for skylake-avx512 and
icelake-server
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Reproducer:
// func.cpp
#include 

extern int var_20, var_22;
extern short arr_32[];
extern char arr_45[];

void test(int a, unsigned b, long long *c) {
  for (short d = 0; d < 13; d++) {
for (int e = 0; e < a; e += 3)
  var_20 = 0;
if (std::max(b, unsigned((short)b))) {
  arr_32[d] = 0;
  var_22 = *c;
}
for (unsigned f = 0; f < 69; f += 4)
  arr_45[f] = 0;
  }
}

driver.cpp
#include 

unsigned long long int a = 10693271954245845448ULL;
unsigned int b = 1144022456U;
long long int c = 42;
int var_20 = 0;
long long int var_22 = 0;
unsigned short arr_32 [13];
unsigned char arr_45 [69];

void test(int a, unsigned int b, long long int* c);

int main() {
test(a, b, );
printf("%llu\n", var_22);
}

Error:
>$ g++ -O3 -march=skylake-avx512 func.cpp driver.cpp && sde -skx -- ./a.out 
0
>$ g++ -O2 -march=skylake-avx512 func.cpp driver.cpp && sde -skx -- ./a.out 
42

GCC version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/testing/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /testing/gcc/gcc_src/configure --enable-multilib
--prefix=/testing/gcc/bin --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211004 (154fd0896ef22fcf5235e35e2b7953947a33) (GCC)

[Bug c++/102547] [11/12 Regression] g++ 11. ICE with NTTPs and partial specialization

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-4196-gd4c470c376b4cb82c9a0b7e8a4b88c44d5e4289d
Author: Patrick Palka 
Date:   Tue Oct 5 15:35:21 2021 -0400

c++: unifying equal NONTYPE_ARGUMENT_PACKs [PR102547]

Here during partial ordering of the two partial specializations we end
up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash shortly
thereafter because uses_template_parms(parms) calls potential_const_expr
which doesn't handle NONTYPE_ARGUMENT_PACK.

This patch fixes this by extending potential_constant_expression to handle
NONTYPE_ARGUMENT_PACK appropriately.

PR c++/102547

gcc/cp/ChangeLog:

* constexpr.c (potential_constant_expression_1): Handle
NONTYPE_ARGUMENT_PACK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-partial2.C: New test.
* g++.dg/cpp0x/variadic-partial2a.C: New test.

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #19 from Thiago Macieira  ---
(In reply to H.J. Lu from comment #17)
> Created attachment 51558 [details]
> The v6 patch
> 
> Please try this.

Confirmed for all inputs.

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

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

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

--- Comment #18 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #16)
> (In reply to H.J. Lu from comment #14)
> > Created attachment 51556 [details]
> > The v5 patch
> > 
> > Changes in v5:
> > 
> > 1. Check SSA_NAME before SSA_NAME_OCCURS_IN_ABNORMAL_PHI.
> 
> Why don't you just move this to match.pd instead as suggested by Richard B.
> on the mailing list?  Then you get the check for
> SSA_NAME_OCCURS_IN_ABNORMAL_PHI for free and such.  Plus other passes will
> do the optimization too 

Without __atomic_fetch_or_* or __atomic_fetch_and_*, the conversion isn't
needed.  We also need to check the mask of the atomic builtin.

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #51556|0   |1
is obsolete||

--- Comment #17 from H.J. Lu  ---
Created attachment 51558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51558=edit
The v6 patch

Please try this.

[Bug c++/102607] [modules] option -g results in undefined reference to `typeinfo for type`

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
A workaround is to define `B`'s destructor as
`constexpr virtual ~B() { }`.

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2021-10-05
 Ever confirmed|0   |1

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

Reduced testcase:

subroutine s(x)
  character(*) :: x(:)
  print *, size (x%len)
end

[Bug c++/100557] [ICE] Internal compiler error: Error reporting routines re-entered.

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Luke Dalessandro  ---
Still failing in trunk, here's a CE link to the preprocessed source
https://godbolt.org/z/YPfTGnT5f.

[Bug target/102477] [12 Regression] ICE: in emit_move_insn, at expr.c:4026 at -Og and -O

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #4 from Zdenek Sojka  ---
Created attachment 51557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51557=edit
another testcase, failing at -O

$ x86_64-pc-linux-gnu-gcc -O testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:7:8: internal compiler error: in emit_move_insn, at expr.c:4026
7 |   v *= -(v >> 4 * 8 - 1);
  |^
0x6b91fa emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:4026
0xe38a03 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:4006
0xe38a03 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4040
0xe3eaff expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6082
0xe406ce execute
/repo/gcc-trunk/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/102621] New: [12 Regression] ICE in convert_nonlocal_reference_op, at tree-nested.c:1166

[gscfq--- via Gcc-bugs]

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

Bug ID: 102621
   Summary: [12 Regression] ICE in convert_nonlocal_reference_op,
at tree-nested.c:1166
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20210523 and 20210530 :
(contained function f is never referenced)


$ cat z1.f90
program p
   integer :: a(8)
   !$omp task affinity (iterator(j=1:8) : a(j))
   !$omp end task
contains
   integer function f(x)
  class(*) :: x
   end
end


$ cat z2.f90
program p
   integer :: a(8)
   !$omp task affinity (iterator(j=1:8) : a(j))
   !$omp end task
end


$ gfortran-12-20211003 -c z2.f90 -fopenmp
$
$ gfortran-12-20211003 -c z1.f90 -fopenmp
z1.f90:1:9:

1 | program p
  | ^
internal compiler error: Segmentation fault
0xd41bdf crash_signal
../../gcc/toplev.c:331
0xdd51b3 convert_nonlocal_reference_op
../../gcc/tree-nested.c:1166
0xfd9892 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:11016
0xab6f3d walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:221
0xab7168 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:620
0xab7310 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xab71f1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:629
0xab7310 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xab71d9 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:665
0xab7310 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xab71f1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:629
0xab7310 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xdd1da8 walk_body
../../gcc/tree-nested.c:811
0xdd24e8 walk_function
../../gcc/tree-nested.c:822
0xdd24e8 walk_all_functions
../../gcc/tree-nested.c:887
0xdd75e0 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3732
0x95284d cgraph_node::analyze()
../../gcc/cgraphunit.c:676
0x9553f7 analyze_functions
../../gcc/cgraphunit.c:1234
0x955dbd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2508

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

This variant compiles and runs, but should also give an error :


$ cat z2.f90
program p
   character(3), allocatable :: y(:)
   y = ['abc', 'xyz']
   call s(y)
contains
   subroutine s(x)
  character(*), allocatable :: x(:)
  integer :: i
  print *, [(len_trim(x(i)), i=1,size(x%len))]
   end
end


$ gfortran-12-20211003 z2.f90 && ./a.out
   3   3
$

[Bug fortran/102620] New: [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865

[gscfq--- via Gcc-bugs]

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

Bug ID: 102620
   Summary: [12 Regression] ICE in gfc_get_array_span, at
fortran/trans-array.c:865
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

The result of len(c) or c%len is always a scalar.
It can't be an argument of size(x) where x must be an array.
Issue started between 20210530 and 20210606 :


$ cat z1.f90
program p
   character(3), allocatable :: y(:)
   y = ['abc', 'xyz']
   call s(y)
contains
   subroutine s(x)
  character(*) :: x(:)
  integer :: i
  print *, [(len_trim(x(i)), i=1,size(x%len))]
   end
end


$ cat z1b.f90
program p
   character(:), allocatable :: y(:)
   y = ['abc', 'xyz']
   call s(y)
contains
   subroutine s(x)
  character(*) :: x(:)
  integer :: i
  print *, [(len_trim(x(i)), i=1,size(x%len))]
   end
end


$ gfortran-12-20210530 -c z1.f90
$
$ gfortran-12-20211003 -c z1.f90
z1.f90:9:50:

9 |   print *, [(len_trim(x(i)), i=1,size(x%len))]
  |  1
internal compiler error: in gfc_get_array_span, at fortran/trans-array.c:865
0x84d8aa gfc_get_array_span(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.c:865
0x8597c0 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7739
0x88ce8f gfc_conv_intrinsic_size
../../gcc/fortran/trans-intrinsic.c:8064
0x8a488a gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10718
0x87956a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9066
0x87c443 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9119
0x857580 gfc_trans_array_constructor_value
../../gcc/fortran/trans-array.c:1942
0x85892a trans_array_constructor
../../gcc/fortran/trans-array.c:2769
0x85892a gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:3049
0x858ff5 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5293
0x8aa9e5 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2646
0x84aee7 trans_code
../../gcc/fortran/trans.c:2138
0x8a836e build_dt
../../gcc/fortran/trans-io.c:2026
0x84aec7 trans_code
../../gcc/fortran/trans.c:2110
0x871974 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6905
0x871774 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5899
0x871774 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6837
0x7f77b6 translate_all_program_units
../../gcc/fortran/parse.c:6572
0x7f77b6 gfc_parse_file()
../../gcc/fortran/parse.c:6841
0x843f3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/102619] [10/11/12 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

While synonym z0.f90 compiles, the other variants don't :


$ cat z0.f90
program p
contains
   function f(x) result(z)
  real :: x(:)
  real, allocatable :: z(:)
  z = g(x)
   end
   function g(x)
  real :: x(..)
  real :: g(size(x))
   end
end


$ cat z2.f90
program p
contains
   function f(x) result(z)
  real :: x(:)
  real, allocatable :: z(:)
  z = g(x)
   end
   function g(x)
  real :: x(..)
  real :: g(product(ubound(x)-lbound(x)+1))
   end
end


$ cat z3.f90
program p
contains
   function f(x) result(z)
  real :: x(:)
  real, allocatable :: z(:)
  z = g(x)
   end
   function g(x)
  real :: x(..)
  real :: g(product(ubound(x)))
   end
end

[Bug fortran/102619] New: [10/11/12 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215

[gscfq--- via Gcc-bugs]

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

Bug ID: 102619
   Summary: [10/11/12 Regression] ICE in
gfc_conv_descriptor_dtype, at
fortran/trans-array.c:215
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r9, changed between 20190310 and 20190331 :


$ cat z1.f90
program p
contains
   function f(x) result(z)
  real :: x(:)
  real, allocatable :: z(:)
  z = g(x)
   end
   function g(x)
  real :: x(..)
  real :: g(product(shape(x)))
   end
end


$ gfortran-9-20190310 -c z1.f90
$
$ gfortran-12-20211003 -c z1.f90
z1.f90:6:14:

6 |   z = g(x)
  |  1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.c:140
0x84b7e0 gfc_get_descriptor_field
../../gcc/fortran/trans-array.c:140
0x84ca2f gfc_conv_descriptor_dtype(tree_node*)
../../gcc/fortran/trans-array.c:215
0x84cab5 gfc_conv_descriptor_rank(tree_node*)
../../gcc/fortran/trans-array.c:249
0x8a3ac1 gfc_conv_intrinsic_shape
../../gcc/fortran/trans-intrinsic.c:6742
0x8a3ac1 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10182
0x87956a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9066
0x858440 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:3029
0x858ff5 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5293
0x89cae0 gfc_conv_intrinsic_arith
../../gcc/fortran/trans-intrinsic.c:4931
0x8a4cc4 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10694
0x87956a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9066
0x87ba1a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
../../gcc/fortran/trans-expr.c:4874
0x84da17 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*)
../../gcc/fortran/trans-array.c:949
0x886056 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:7140
0x8876dc gfc_trans_arrayfunc_assign
../../gcc/fortran/trans-expr.c:10541
0x88b3b4 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool)
../../gcc/fortran/trans-expr.c:11710
0x84ac37 trans_code
../../gcc/fortran/trans.c:1918
0x871974 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6905
0x871774 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5899
0x871774 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6837

[Bug middle-end/102606] large array in a dead-code is not optimized away at -O0

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

--- Comment #4 from Karine EM  ---
That would make sense, and I think it is also what happens when compiling the
example with Clang and -O0 since the compilation takes only a few seconds then.

[Bug demangler/102618] New: d-demangle: anonymous symbols are not being properly skipped

[contact at lsferreira dot net via Gcc-bugs]

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

Bug ID: 102618
   Summary: d-demangle: anonymous symbols are not being properly
skipped
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: contact at lsferreira dot net
  Target Milestone: ---

According to the D ABI specification, symbol names can contain an arbitrary
number of anonymous symbols. Currently, libiberty can't demangle the following
properly:

_D8demangle9anonymous03fooZ
demangle.anonymous.foo

On the other hand, the official demangler can successfully demangle it as a D
symbol.

[Bug c++/102490] Erroneous optimization of default constexpr operator== of struct with bitfields

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|jakub at gcc dot gnu.org   |jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Latest patch version
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580706.html
Jason was kind enough to take it over as more work needs to be done, e.g. to
make  the synthesization work on binfos rather than base FIELD_DECLs that might
not exist yet.

[Bug c++/102616] [C++23] P2334R1 - Add support for preprocessing directives elifdef and elifndef

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580941.html

[Bug c++/102617] [C++23] P2360R0 - Extend init-statement to allow alias-declaration

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

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

Marek Polacek  changed:

   What|Removed |Added

 Blocks||98940
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-10-05
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug c++/102617] New: [C++23] P2360R0 - Extend init-statement to allow alias-declaration

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

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

Bug ID: 102617
   Summary: [C++23] P2360R0 - Extend init-statement to allow
alias-declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2360r0

[Bug c++/102616] New: [C++23] P2334R1 - Add support for preprocessing directives elifdef and elifndef

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

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

Bug ID: 102616
   Summary: [C++23] P2334R1 - Add support for preprocessing
directives elifdef and elifndef
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2334r1

[Bug c++/102615] [C++23] P2316R2 - Consistent character literal encoding

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Also likely a nop but we might want some testcase.

[Bug c++/102615] New: [C++23] P2316R2 - Consistent character literal encoding

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

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

Bug ID: 102615
   Summary: [C++23] P2316R2 - Consistent character literal
encoding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2316r2

[Bug c++/102614] New: [C++23] P2314R4 - Character sets and encodings

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

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

Bug ID: 102614
   Summary: [C++23] P2314R4 - Character sets and encodings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2314

[Bug c++/102613] New: [C++23] P2246R1 - Character encoding of diagnostic text

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

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

Bug ID: 102613
   Summary: [C++23] P2246R1 - Character encoding of diagnostic
text
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2246r1

This might be a noop, but we should include some tests probably.

[Bug c++/102612] [C++23] P2242R3 - Non-literal variables (and labels and gotos) in constexpr functions

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-05

--- Comment #1 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580960.html

[Bug c++/102612] New: [C++23] P2242R3 - Non-literal variables (and labels and gotos) in constexpr functions

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

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

Bug ID: 102612
   Summary: [C++23] P2242R3 - Non-literal variables (and labels
and gotos) in constexpr functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2242r3

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #13 from qingzhe huang  ---
(In reply to Patrick Palka from comment #12)
> (In reply to qingzhe huang from comment #11)
> > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> > run by compiler cc1plus with latest code.
> 
> Hmm, I can't reproduce that on latest trunk.  Is your working tree clean?

I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull. It
won't show anything when compiling with driver, i.e. g++, but if you run
"cc1plus", it will crash. For example,
${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus -std=c++20
./lambda-uneval11.C

Thank you

[Bug c++/102611] New: [C++23] P2128R6 - Multidimensional subscript operator

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

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

Bug ID: 102611
   Summary: [C++23] P2128R6 - Multidimensional subscript operator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2128r6

[Bug middle-end/102606] large array in a dead-code is not optimized away at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Or VLA.
Anyway, even at -O0 we can optimize away some if (0)s, but we need assurance
that there are no labels in there and that the code really dead.  So, e.g. if
constexpr (0) can be optimized away because there is a language guarantee that
one can't jump into those bodies.

[Bug target/102604] arm v7m_extra_costs for SFmode inaccurate?

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

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

--- Comment #2 from Christophe Lyon  ---
Right, using -Os makes these tests pass (but vsqrt.f32 and vsqrt.f64 would
fail), but I'm still wondering about the purpose of vmla?

Rather than benchmarking, the costs may come from the Architecture
documentation? But then, if vmla is so costly, when is it supposed to be used?
Only when optimizing for size?

Note that the DP/f64 version does not have this problem.

[Bug c++/102610] New: [C++23] P2036R3 - Change scope of lambda trailing-return-type

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

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

Bug ID: 102610
   Summary: [C++23] P2036R3 - Change scope of lambda
trailing-return-type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See https://wg21.link/p2036r3

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #14)
> Created attachment 51556 [details]
> The v5 patch
> 
> Changes in v5:
> 
> 1. Check SSA_NAME before SSA_NAME_OCCURS_IN_ABNORMAL_PHI.

Why don't you just move this to match.pd instead as suggested by Richard B. on
the mailing list?  Then you get the check for SSA_NAME_OCCURS_IN_ABNORMAL_PHI
for free and such.  Plus other passes will do the optimization too 

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #15 from Thiago Macieira  ---
Works now for the failing case. Additionally:

bool tbit(std::atomic )
{
  return i.fetch_and(~CONSTANT, std::memory_order_relaxed) & (CONSTANT);
}

Will properly produce LOCK BTR (CONSTANT=2):

lock btrq   $1, (%rdi)
setc%al
ret

CONSTANT=(1L<<62):

lock btrq   $62, (%rdi)
setc%al
ret

But not for CONSTANT=1 or CONSTANT=(1L<<63):
movq(%rdi), %rax
.L2:
movq%rax, %rcx
movq%rax, %rdx
andq$-2, %rcx
lock cmpxchgq   %rcx, (%rdi)
jne .L2
movl%edx, %eax
andl$1, %eax
ret

Same applies to 1<<31 for atomic.

[Bug c++/102609] New: [C++23] P0847R7 - Deducing this

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

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

Bug ID: 102609
   Summary: [C++23] P0847R7 - Deducing this
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
Blocks: 98940
  Target Milestone: ---

See https://wg21.link/p0847r7


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug debug/102507] ICE in btf_finalize when compiling with -gbtf

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

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

Indu Bhagat  changed:

   What|Removed |Added

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

--- Comment #4 from Indu Bhagat  ---
Tested and verified it works. Closing the bug.

[Bug tree-optimization/102608] [12 regression] Recent change to VN causes bogus Wuninitialized warnings & kernel build failures

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/102608] [12 regression] Recent change to VN causes bogus Wuninitialized warnings & kernel build failures

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

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

--- Comment #1 from Andrew Pinski  ---
   old32_34 = .DEFERRED_INIT (4, 2, 0);

...

-  _24 = .DEFERRED_INIT (4, 2, 0);
-  __res ={v} _24;
+  __res ={v} old32_34;


# 68 "../arch/mips/include/asm/cmpxchg.h"
This is due to __typeof(*((volatile u32 *)ptr)) __ret



The warning is kinda of correct but wrong as it uses the wrong decl :).

Fre maybe should be disabled for DEFERRED_INIT 

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #51551|0   |1
is obsolete||

--- Comment #14 from H.J. Lu  ---
Created attachment 51556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51556=edit
The v5 patch

Changes in v5:

1. Check SSA_NAME before SSA_NAME_OCCURS_IN_ABNORMAL_PHI.

[Bug tree-optimization/102608] New: [12 regression] Recent change to VN causes bogus Wuninitialized warnings & kernel build failures

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

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

Bug ID: 102608
   Summary: [12 regression] Recent change to VN causes bogus
Wuninitialized warnings & kernel build failures
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51555=edit
Testcase

This change:
55a3be2f5255d69e740d61b2c5aaba1ccbc643b8 is the first bad commit
commit 55a3be2f5255d69e740d61b2c5aaba1ccbc643b8
Author: Richard Biener 
Date:   Mon Oct 4 10:57:45 2021 +0200

tree-optimization/102570 - teach VN about internal functions

We're now using internal functions for a lot of stuff but there's
still missing VN support out of laziness.  The following instantiates
support and adds testcases for FRE and PRE (hoisting).

Is causing mips64-linux-gnu and mips64el-linux-gnu kernel build failures due to
a bogus uninitialized warning with the attached file when compiled with -O2
-ftrivial-auto-var-init=zero:

../arch/mips/kernel/cmpxchg.c: In function '__xchg_small':
../arch/mips/kernel/cmpxchg.c:44:36: warning: 'old32' is used uninitialized
[-Wuninitialized]
../arch/mips/kernel/cmpxchg.c:12:6: note: 'old32' was declared here
 __cmpxchg_small
../arch/mips/kernel/cmpxchg.c: In function '__cmpxchg_small':
../arch/mips/kernel/cmpxchg.c:100:36: warning: 'mask' may be used uninitialized
[-Wmaybe-uninitialized]
../arch/mips/kernel/cmpxchg.c:53:6: note: 'mask' was declared here


I haven't tracked this down any further.

[Bug c++/102607] New: [modules] option -g results in undefined reference to `typeinfo for type`

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102607
   Summary: [modules] option -g results in undefined reference to
`typeinfo for type`
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

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

mod.cpp:
```C++
export module mod;
export struct B {
  virtual ~B() = default;
};
```

main.cpp:
```C++
import mod;
int main() {
  struct D : B {};
  (void)D{};
}
```

Commands:
```
g++ -std=c++23 -fmodules-ts -g -c mod.cpp
g++ -std=c++23 -fmodules-ts -g -c main.cpp
g++ mod.o main.o
```

Output:
```
/usr/bin/ld: main.o:(.data.rel.ro+0x8): undefined reference to `typeinfo for B'
/usr/bin/ld: main.o:(.data.rel.ro+0x30): undefined reference to `typeinfo for
B'
collect2: error: ld returned 1 exit status
```

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-4187-gd4f6dbe18374385b8199ca3d6121e37a1189b589
Author: Richard Biener 
Date:   Tue Oct 5 14:18:09 2021 +0200

Allow more kinds of invariant addresses in GIMPLE FE

The gimple FE is too restrictive in what it accepts as
literals, the following makes it also accept [10] for example.

2021-10-05  Richard Biener  

PR c/102605
gcc/c/
* gimple-parser.c (c_parser_gimple_postfix_expression):
Accept more address _Literals.

gcc/testsuite/
* gcc.dg/gimplefe-46.c: New testcase.

[Bug target/102604] arm v7m_extra_costs for SFmode inaccurate?

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

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

--- Comment #1 from Richard Earnshaw  ---
I wonder if it might be better to change this test to use -Os, since then the
cost model is much more consistent as it's based on size rather than speed.

[Bug c++/53164] Undefined reference to template function instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
(In reply to Jonathan Wakely from comment #1)
> Looks as though we need to call mark_used for function templates used as
> non-type template parameters

Yep :)

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

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

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

--- Comment #12 from Patrick Palka  ---
(In reply to qingzhe huang from comment #11)
> The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> run by compiler cc1plus with latest code.

Hmm, I can't reproduce that on latest trunk.  Is your working tree clean?

[Bug tree-optimization/102571] FAIL: libgomp.c/../libgomp.c-c++-common/atomic-21.c execution test

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 51554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51554=edit
gcc12-pr102571.patch

Untested patch for the OpenMP optimization that will result in this bug not
triggering for OpenMP, but it will still trigger for when the user uses
__builtin_clear_padding and __builtin_memcmp by hand (or eventually through
).

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 102603 Summary: Compile-time evaluation of indirection via dangling pointer 
is not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102603

   What|Removed |Added

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

[Bug c++/70331] missing error dereferencing a dangling pointer (out of scope) in constexpr function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

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

[Bug c++/102603] Compile-time evaluation of indirection via dangling pointer is not rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 70331.

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

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 93389 Summary: Failure to detect UB in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93389

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/70331] missing error dereferencing a dangling pointer (out of scope) in constexpr function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||klaus.doldinger64@googlemai
   ||l.com

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

[Bug c++/93389] Failure to detect UB in constexpr context

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Dup of bug 70331.

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

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

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

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

--- Comment #2 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #1)
> You need
> 
>   if (p_2(D) == _Literal (char *) [2])
> 
> and of course you need to provide the
> 
> char global[10];
> 
> declaration.  And then we still need to fix some sanity checking in the
> frontend.

Thanks for the patch.  I'll need something like it in order to write some jump
threading tests for missing MEM_REF cases.

It would be nice if -fdump-tree-*-gimple would match what -fgimple expects, at
the least with regards to this _Literal business.

BTW, the __MEM_REF output from the dumps does not work in -fgimple either. 
More errors.

Thanks.

[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #8 from Andrew Macleod  ---

> > 
> > It would probably resolve an entire class of things where we don't 
> > recognize an
> > equivalence between a cast and a bitmask of equivalent precision.
> > 
> > This would also mean the reverse would apply.. ie if we instead branched on 
> > _2
> > != 0 we would also understand that _6 will be non-zero.
> 
> I believe tracking known zero/one bits in addition to a range is more
> useful - would that help in this case?

Thats in plan and what I first thought would fix it.  Reflecting on this
problem however, it would only help on the zero side where all the bits are
known zero, but the non-zero property we are looking for can't be reflected by
known ones or zeros.. 

Unfortunately I don't see how we can solve this particular problem by tracking
known bit values.. there wont be any known 1s or 0s in a.0_1...  just a
particular bit pattern that cannot occur.

Another option would be if I can get a cheap enough low-opt pass of evrp (also
on my list) we could run it really early before things get rearranged and then
run the higher levels later.

Anyway, I'll keep thinking about this...

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 98930 Summary: ICE with static variable in template function used as 
template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98930

   What|Removed |Added

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

[Bug c++/98930] ICE with static variable in template function used as template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 12, thanks for the bug report.

[Bug c++/98930] ICE with static variable in template function used as template argument

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-4186-gf3930418cb82000fae3cb4e98e870428800cf295
Author: Patrick Palka 
Date:   Tue Oct 5 09:50:02 2021 -0400

c++: templated static local var has value-dep addr [PR98930]

Here uses_template_parms returns false for the dependent type A<::i>,
which causes tsubst_aggr_type to think it's non-dependent and not bother
substituting into it, leading to breakage.

This patch fixes this by making has_value_dependent_address also return
true for templated static local variables.

PR c++/98930

gcc/cp/ChangeLog:

* pt.c (has_value_dependent_address): Return true for a static
local variable from a function template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype4.C: New test.
* g++.dg/cpp1z/nontype4a.C: New test.

[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr

[nisse at lysator dot liu.se via Gcc-bugs]

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

--- Comment #11 from Niels Möller  ---
Here's a bit more docs on using std::unique_ptr [[clang::trivial_abi]] with
clang and its C++ library.

https://libcxx.llvm.org//DesignDocs/UniquePtrTrivialAbi.html

As for "No, it needs co-operation between G++ and all other compilers using the
same ABI", I would think that if gcc and clang could agree, others would start
moving.

[Bug target/102602] [10/11/12 Regression] 32bit mips: Error: branch out of range

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||mips
   Target Milestone|--- |10.4

[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-10-05

--- Comment #1 from Richard Biener  ---
You need

  if (p_2(D) == _Literal (char *) [2])

and of course you need to provide the

char global[10];

declaration.  And then we still need to fix some sanity checking in the
frontend.

diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index c8d9db61f0a..c43ee38a2cf 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -1622,16 +1622,20 @@ c_parser_gimple_postfix_expression (gimple_parser
)
  tree val = c_parser_gimple_postfix_expression (parser).value;
  if (! val
  || val == error_mark_node
- || (!CONSTANT_CLASS_P (val)
- && !(addr_p
-  && (TREE_CODE (val) == STRING_CST
-  || DECL_P (val)
+ || (!CONSTANT_CLASS_P (val) && !addr_p))
{
  c_parser_error (parser, "invalid _Literal");
  return expr;
}
  if (addr_p)
-   val = build1 (ADDR_EXPR, type, val);
+   {
+ val = build1 (ADDR_EXPR, type, val);
+ if (!is_gimple_invariant_address (val))
+   {
+ c_parser_error (parser, "invalid _Literal");
+ return expr;
+   }
+   }
  if (neg_p)
{
  val = const_unop (NEGATE_EXPR, TREE_TYPE (val), val);

[Bug middle-end/102606] large array in a dead-code is not optimized away at -O0

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Richard Biener  ---
Yes, even though the variable is in a local not executed scope the allocation
of stack space happens statically at function scope.  If you want this not
to happen you can use alloca() for allocation.

[Bug middle-end/102606] large array in a dead-code is not optimized away at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|miscompilation of a program |large array in a dead-code
   |with large array in a   |is not optimized away at
   |dead-code   |-O0

--- Comment #1 from Andrew Pinski  ---
I don't think this is miscompiled but rather you just run out of stack space
because gcc at -O0 does not remove the the otherwise unused array.

This is by design.
Yes gcc could be improved to remove it but it is not a miscompile.

[Bug c/102606] New: miscompilation of a program with large array in a dead-code

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

Bug ID: 102606
   Summary: miscompilation of a program with large array in a
dead-code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.even-mendoza at imperial dot ac.uk
  Target Milestone: ---

This program miscompiled with gcc-12 (and also older versions) with -O0:

#include "stdio.h"
void foo(int *p)
{
  if(0) // Dead-code
  {
  int *i[(3500)][(300)];
  }
}
int main()
{
  int i = 1;
  foo();
  printf("1\n");
  return 0;
}

the program terminates with Segmentation fault when compiled with -O0 and GCC,
but 
with -O1,O2,O3,Os and clang (all flags), it prints "1" and return 0. 
I assume the definition of "i" is being pulled up, out side the if(0) block.
I used gcc (GCC) 12.0.0 20210811 (experimental).