[Bug target/98218] [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for 64bit vector

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-10
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/98216] [C++20] std::array template parameter error with negative values

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

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

--- Comment #1 from Richard Biener  ---
I guess the issue has to be with you using 'static constexpr auto arr' and
that not being correctly templated on the expression.

Well, confirmed your observation.

Voicemail To Email

[BuBleik SAL via Gcc-bugs]

BuBleik SAL
Virtual Office & Virtual Assistant





Working from home and you don't want to miss a call. We got you covered.


The Voicemail To Email subscription with BuBleik SAL, offers you the luxury to 
have a city land line telephone number, answered by an automated welcome 
message of your choice and once your caller leaves you a message, you will 
immediately receive in your inbox by email, and on 24/7 bases. 


No worries sharing your home telephone line with your business accounts.




+961 1 411 222
sa...@bubleik.com








SUBSCRIBE NOW[Ads961.com] Professional Advertisement in Lebanon(email) 

b...@adsleb.com (Tel) 

+961 1 411 410 (whatsapp) 

+961 71 072 786If you no longer wish to receive mail from us, you can   
 

unsubscribe

Ads961, Badaro, Beirut, LB, 50-110, Lebanon

[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Marc Glisse from comment #8)
> (In reply to Richard Biener from comment #4)
> > We already handle IX86_BUILTIN_SHUFPD there but not IX86_BUILTIN_SHUFPS for
> > some reason.
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2019-May/521983.html
> I was checking with just one builtin if this was the right approach, and
> never got to extend it to others, sorry. Handling shufps in a similar way
> seems good to me, if anyone has time to do it.

I'll take a look, assume I also need to fold those shuffle builtins for
avx/avx512.

[Bug target/98219] User-interrupt return pop corrupt RIP

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

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

--- Comment #7 from H.J. Lu  ---
Created attachment 49725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49725&action=edit
An alternate patch

This patch may generate better debug info.

[Bug c++/82099] internal compiler error: in type_throw_all_p, at cp/except.c:1186 when using a function pointer for templated predicate

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/98219] User-interrupt return pop corrupt RIP

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-12-10
 Status|UNCONFIRMED |NEW

--- Comment #6 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #5)
> Shouldn't condition like
> 
>(cfun->machine->func_type == TYPE_EXCEPTION \
> +   ||  (cfun->machine->func_type == TYPE_INTERRUPT   \
> + && TARGET_UINTR && TARGET_64BIT ))

You are right.

[Bug target/98219] User-interrupt return pop corrupt RIP

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
Shouldn't condition like

   (cfun->machine->func_type == TYPE_EXCEPTION \
+   ||  (cfun->machine->func_type == TYPE_INTERRUPT \
+   && TARGET_UINTR && TARGET_64BIT ))

[Bug target/98219] User-interrupt return pop corrupt RIP

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

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

--- Comment #4 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Created attachment 49723 [details]
> > A patch
> > 
> > Hongtao, can you take it over?
> 
> I'll validate it.

Please verify that we can correctly access struct __uintr_frame.

[Bug target/98219] User-interrupt return pop corrupt RIP

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #49723|0   |1
is obsolete||

--- Comment #3 from H.J. Lu  ---
Created attachment 49724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49724&action=edit
A patch with a testcase

[Bug target/98219] User-interrupt return pop corrupt RIP

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #1)
> Created attachment 49723 [details]
> A patch
> 
> Hongtao, can you take it over?

I'll validate it.

[Bug target/98219] User-interrupt return pop corrupt RIP

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

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

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

Hongtao, can you take it over?

[Bug target/98219] New: User-interrupt return pop corrupt RIP

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 98219
   Summary: User-interrupt return pop corrupt RIP
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

According to SDM, for user-interrupt delivery, it push 4 64-bits values

Push tempRSP;
Push RFLAGS;
Push RIP;
Push UIRRV; // 64-bit push; upper 58 bits pushed as 0


But uiret only pop 3 64-bits values.

Pop tempRIP;
Pop tempRFLAGS; // see below for how this is used to load RFLAGS
Pop tempRSP;

Looks like the interrupt handler has to POP the vector before it calls UIRET. I
think the current compiler might not be handling that.

[Bug target/98218] New: [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for 64bit vector

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 98218
   Summary: [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander
for 64bit vector
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*

Refer to https://godbolt.org/z/sYE88f

cat test.c

typedef char v8qi __attribute__ ((vector_size(8)));
v8qi f1(v8qi a, v8qi b) {
  return a == b;
}

gcc -O2 -msse4.1 -S

f1(char __vector(8), char __vector(8)):
pextrb  edx, xmm0, 0
pextrb  eax, xmm1, 0
pextrb  ecx, xmm0, 1
cmp dl, al
pextrb  eax, xmm1, 1
pextrb  esi, xmm0, 2
setne   dl
pextrb  edi, xmm0, 3
pextrb  r8d, xmm0, 4
sub edx, 1
cmp cl, al
pextrb  eax, xmm1, 2
setne   cl
pextrb  r9d, xmm0, 5
movzx   edx, dl
sub ecx, 1
cmp sil, al
pextrb  eax, xmm1, 3
setne   sil
pextrb  r10d, xmm0, 6
pextrb  r11d, xmm0, 7
movzx   ecx, cl
sub esi, 1
cmp dil, al
pextrb  eax, xmm1, 4
setne   dil
movzx   esi, sil
sub edi, 1
cmp r8b, al
pextrb  eax, xmm1, 5
setne   r8b
movzx   edi, dil
sub r8d, 1
cmp r9b, al
pextrb  eax, xmm1, 6
setne   r9b
movzx   r8d, r8b
sub r9d, 1
cmp r10b, al
pextrb  eax, xmm1, 7
setne   r10b
movzx   r9d, r9b
sub r10d, 1
cmp r11b, al
setne   al
movzx   r10d, r10b
sub eax, 1
movzx   eax, al
sal rax, 8
or  rax, r10
sal rax, 8
or  rax, r9
sal rax, 8
or  rax, r8
sal rax, 8
or  rax, rdi
sal rax, 8
or  rax, rsi
sal rax, 8
or  rax, rcx
sal rax, 8
or  rax, rdx
movqxmm0, rax
ret

It should be better with

f1(char __vector(8), char __vector(8)):   # @f1(char
__vector(8), char __vector(8))
pcmpeqb xmm0, xmm1
ret

[Bug c/98217] Prefer a warning for when VLAs declared on stack

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #6 from Richard Smith  ---
Hi GCC folks! My preferred approach to take on the Clang side would be to
change -Wvla to not warn on function parameter types, if GCC is prepared to
make the same change. I don't think the current meaning of -Wvla is useful, and
warning only in cases where there is a variably-modified type on the stack
seems like the better meaning for -Wvla.

[Bug ipa/92800] IPA escape analysis for structs

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||egallager at gcc dot gnu.org
   Last reconfirmed||2020-12-09
   Assignee|unassigned at gcc dot gnu.org  
|erick.ochoa@theobroma-syste
   ||ms.com

--- Comment #4 from Eric Gallager  ---
Erick Ochoa is working on this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561108.html

[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jozef.l at somniumtech dot com

--- Comment #3 from H.J. Lu  ---
Jozef, SHF_GNU_RETAIN is yours.

[Bug bootstrap/98188] [11 Regression] ICE in decompose, at wide-int.h:984

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

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

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

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

commit r11-5890-g7d9767cb8eea0f21c5b23b0183c53840e0433397
Author: Jakub Jelinek 
Date:   Wed Dec 9 23:52:25 2020 +0100

phiopt: Fix up two_value_replacement BOOLEAN_TYPE handling for Ada
[PR98188]

For Ada with LTO, boolean_{false,true}_node can be 1-bit precision boolean,
while TREE_TYPE (lhs) can be 8-bit precision boolean and thus we can end up
with wide_int mismatches.

This patch for non-VR_RANGE just use VARYING min/max manually.
The min + 1 != max check will then do the rest.

2020-12-09  Jakub Jelinek  

PR bootstrap/98188
* tree-ssa-phiopt.c (two_value_replacement): Don't special case
BOOLEAN_TYPEs for ranges, instead if get_range_info doesn't return
VR_RANGE, set min/max to wi::min/max_value.

[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

 Resolution|MOVED   |---
 Status|RESOLVED|REOPENED
   Last reconfirmed||2020-12-09
 Ever confirmed|0   |1

--- Comment #2 from Alan Modra  ---
When the gold patch goes in, gcc should have a configure test such that the
combination of gold being the default linker and SHF_GNU_RETAIN support should
not be allowed unless gold has the patch.  And even if gold is not the default
linker it is required for split-stack go support, so go being compiled also
ought to trigger a dependence on gold being recent enough.

[Bug c++/91953] [8 Regression] G++ rejects lambda with constexpr variable

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
Fixed for 8.5 as well.

[Bug c++/91953] [8 Regression] G++ rejects lambda with constexpr variable

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

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

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

https://gcc.gnu.org/g:56943ab07c0c0e6878806adf7372dccad84b78d7

commit r8-10671-g56943ab07c0c0e6878806adf7372dccad84b78d7
Author: Jason Merrill 
Date:   Mon Mar 2 14:42:47 2020 -0500

c++: Allow parm of empty class type in constexpr.

Since copying a class object is defined in terms of the copy constructor,
copying an empty class is OK even if it would otherwise not be usable in a
constant expression.

gcc/cp/ChangeLog

PR c++/91953
* constexpr.c (potential_constant_expression_1) [PARM_DECL]: Allow
empty class type.

gcc/testsuite/ChangeLog:

PR c++/91953
* g++.dg/cpp1z/constexpr-if12.C: Remove error.
* g++.dg/cpp0x/constexpr-empty14.C: New test.

[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

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

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

--- Comment #6 from Jakub Jelinek  ---
Or shall it instead do:
--- gcc/dojump.c.jj 2020-12-09 15:11:17.042888002 +0100
+++ gcc/dojump.c2020-12-09 20:34:13.124398356 +0100
@@ -1148,9 +1148,8 @@ do_compare_rtx_and_jump (rtx op0, rtx op
  if (and_them)
{
  rtx_code_label *dest_label;
- prob = prob.invert ();
- profile_probability first_prob = prob.split (cprob).invert
();
- prob = prob.invert ();
+ profile_probability first_prob
+   = prob.split (cprob.invert ()).invert ();
  /* If we only jump if true, just bypass the second jump.  */
  if (! if_false_label)
{
?  With the rationale that for and_them we basically invert the first condition
because we pass non-NULL false label and NULL true label, so if first_code is
ORDERED and cprob is thus 99% for and_them we will emit UNORDERED and want it
to be very unlikely, while if first_code is UNORDERED and cprob is thus 1% for
and_them we will emit ORDERED and want it to be very likely (though that case
doesn't happen, if first_code is ORDERED, then and_them is always true, if
first_code is UNORDERED, then and_them is always false, plus there is one case
where first_code is neither of them, then cprob is even.

[Bug tree-optimization/95396] [8/9/10/11 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621

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

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

--- Comment #11 from Martin Liška  ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Looks like this might have gone latent on trunk.  First thought
> was that it might be g:7b4ea2827d2003c8ffc76cd478f8974360cbd78f,
> but it seems not.

You should still be able to see the problem with --param=evrp-mode=legacy on
the master. It's latent without the param since r11-3685-gfcae5121154d1c33.

[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So, for the corge case, do_compare_rtx_and_jump is called with EQ,
if_false_label non-NULL, if_true_label NULL (i.e. fall through) and prob of
10%.
The target doesn't support it and so x == y is being split into
x ord y && x u== y.
first_prob is computed as 10.9% and prob 91.74%, it is expanded as
if (x unord y) goto if_false_label; // prob of goto 89.1%
if (x u== y) goto dummy; // prob of goto 91.74%
goto if_false_label;
dummy:;

1133  profile_probability cprob
1134= profile_probability::guessed_always ();
1135  if (first_code == UNORDERED)
1136cprob = cprob.apply_scale (1, 100);
1137  else if (first_code == ORDERED)
1138cprob = cprob.apply_scale (99, 100);
1139  else
1140cprob = profile_probability::even ();
1141  /* We want to split:
1142 if (x) goto t; // prob;
1143 into
1144 if (a) goto t; // first_prob;
1145 if (b) goto t; // prob;
1146 such that the overall probability of jumping to t
1147 remains the same and first_prob is prob * cprob.  */
1148  if (and_them)
...
1151  prob = prob.invert ();
1152  profile_probability first_prob = prob.split
(cprob).invert ();
1153  prob = prob.invert ();

The comment only describes how !and_them looks like, for and_them it is
actually:
if (x) goto t; // prob;
goto f;
into:
if (a) goto f; // 1 - first_prob;
if (b) goto t; // prob;
goto f;
(at least for the case where we have both f and t).
prob.split is documented as:
 Split *THIS (ORIG) probability into 2 probabilities, such that
 the returned one (FIRST) is *THIS * CPROB and *THIS is
 adjusted (SECOND) so that FIRST + FIRST.invert () * SECOND
 == ORIG.  This is useful e.g. when splitting a conditional
 branch like:
 if (cond)
   goto lab; // ORIG probability
 into
 if (cond1)
   goto lab; // FIRST = ORIG * CPROB probability
 if (cond2)
   goto lab; // SECOND probability
So, if we talk about baz above with prob of jumping to t 90%, the computed
first_prob is 1-((1-90%)*99%), so 90.1%, which means if (op0 unord op1) goto f;
with 8.9% probability.
For corge prob of jumping to t is 10%, the computed first_prob is
1-((1-10%)*99%), so 10.9% which means
if (op0 unord op1) goto f; // with 89.1% probability.  NaNs are never that
common!
if (op0 uneq op1) goto t; // with 91.74% probability.
I think the right thing would be to for these < 50% initial prop and ORDERED
first_code would be to use something like:
profile_probability first_prob = prob.split (cprob).invert ();
without the two prob = prob.invert (); around it.

With:
--- gcc/dojump.c.jj 2020-12-09 15:11:17.042888002 +0100
+++ gcc/dojump.c2020-12-09 20:05:59.535234206 +0100
@@ -1148,9 +1148,15 @@ do_compare_rtx_and_jump (rtx op0, rtx op
  if (and_them)
{
  rtx_code_label *dest_label;
- prob = prob.invert ();
- profile_probability first_prob = prob.split (cprob).invert
();
- prob = prob.invert ();
+ profile_probability first_prob;
+ if (prob < profile_probability::even ())
+   first_prob = prob.split (cprob).invert ();
+ else
+   {
+ prob = prob.invert ();
+ first_prob = prob.split (cprob).invert ();
+ prob = prob.invert ();
+   }
  /* If we only jump if true, just bypass the second jump.  */
  if (! if_false_label)
{
I get the output I'm looking for, so bar/baz/qux stay the same and corge
becomes:
corge:  ucomiss %xmm1, %xmm0
jp  .L14
je  .L18
.L14:   ret
.L18:   jmp foo

Honza, what do you think?

[Bug c/98217] Prefer a warning for when VLAs declared on stack

[svoboda at cert dot org via Gcc-bugs]

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

--- Comment #5 from David Svoboda  ---
Oops, the Clang bug entry is really here:
https://bugs.llvm.org/show_bug.cgi?id=48460

[Bug c/98217] Prefer a warning for when VLAs declared on stack

[svoboda at cert dot org via Gcc-bugs]

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

--- Comment #4 from David Svoboda  ---
Martin:

Thanks. It looks like -Wvla-larger-than=0 is (theoretically) a good way to
catch VLA stack declarations.

There is still the issue that GCC's -Wvla did not flag use of array[*].  To me
that is lower-priority, but is still an issue.

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)

>   function kn1() result(hm2)
> complex :: hm(1:2), hm2(1:2)
> data (hm(md)%re, md=1,2)/1.0, 2.0/
> hm2 = hm
>   end function kn1

Are you sure that this is valid Fortran?  I cannot
find anything in the Fortran standard that says hm%im
is defined.  Thus, 'hm2=hm' is referencing a variable
that is no completely defined.


19.6.1 Definition of objects and subobjects

2 Arrays, including sections, and variables of derived, character,
  or complex type are objects that consist of zero or more subobjects.
  Associations may be established between variables and subobjects and
  between subobjects of different variables. These subobjects may become
  defined or undefined.

5 A complex or character scalar object is defined if and only if all
  of its subobjects are defined.

[Bug c++/93083] [C++20] copy deduction rejected when doing CTAD for NTTP

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 10.2/11.

[Bug c++/93083] [C++20] copy deduction rejected when doing CTAD for NTTP

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-9133-ge6e42891d80c12c4fac36d6273b8d4e31a3d0a2a
Author: Jason Merrill 
Date:   Wed Nov 25 17:05:24 2020 -0500

c++: Fix deduction from auto template parameter [PR93083]

The check in do_class_deduction to handle passing one class placeholder
template parm as an argument for itself needed to be extended to also
handle
equivalent parms from other templates.

gcc/cp/ChangeLog:

PR c++/93083
* pt.c (convert_template_argument): Handle equivalent placeholders.
(do_class_deduction): Look through EXPR_PACK_EXPANSION, too.

gcc/testsuite/ChangeLog:

PR c++/93083
* g++.dg/cpp2a/nontype-class40.C: New test.

[Bug c/98217] Prefer a warning for when VLAs declared on stack

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
 CC||msebor at gcc dot gnu.org
   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-12-09

--- Comment #3 from Martin Sebor  ---
-Wvla-larger-than= seems close to the feature you're looking for:

$ cat pr98217.c && gcc -O2 -S -Wvla-larger-than=0 pr98217.c
void f (void*, ...);

void func1(int n, int array[n]) /* ok, no warning */
{
  int array2[n]; /* bad, VLA on stack, warn! */
  int (*array3)[n];  /* ok, no VLA on stack, so no warning */
  f (array, array2, array3);
}
pr98217.c: In function ‘func1’:
pr98217.c:5:7: warning: argument to variable-length array may be too large
[-Wvla-larger-than=]
5 |   int array2[n]; /* bad, VLA on stack, warn! */
  |   ^~

The warning triggers whenever a VLA is either a) known to be larger than the
limit or b) not known to be less than or equal to it.  Please let us know if
this isn't sufficient.

For better portability, the solution to the VLA bound parameter problem I would
recommend for single-dimensional VLAs over the forward parameter declaration is
attribute access:

$ cat pr98217-2.c && gcc -S pr98217-2.c
typedef __SIZE_TYPE__ size_t;

__attribute__ ((access (read_write, 1, 2)))
void my_memset (char *p, size_t n, char v)
{
  __builtin_memset (p, v, n);
}

char a[3];

void f (void)
{
  my_memset (a, 3 * sizeof a, 0);
}
pr98217-2.c: In function ‘f’:
pr98217-2.c:13:3: warning: ‘my_memset’ accessing 9 bytes in a region of size 3
[-Wstringop-overflow=]
   13 |   my_memset (a, 3 * sizeof a, 0);
  |   ^~
pr98217-2.c:4:6: note: in a call to function ‘my_memset’ declared with
attribute ‘access (read_write, 1, 2)’
4 | void my_memset (char p[], size_t n, char v)
  |  ^

(Worth noting is that neither works reliably when the function is inlined and
the association between the array and its bound is lost.)

[Bug c/98217] Prefer a warning for when VLAs declared on stack

[svoboda at cert dot org via Gcc-bugs]

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

--- Comment #2 from David Svoboda  ---
I have also submitted a similar bug report to Clang, it is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217

[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe

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

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

--- Comment #3 from Paul Thomas  ---
Created attachment 49722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49722&action=edit
Tentative patch for the PR

The attached regtests OK and the following runs correctly:
module ur
contains
  function kn1() result(hm2)
complex :: hm(1:2), hm2(1:2)
data (hm(md)%re, md=1,2)/1.0, 2.0/
hm2 = hm
  end function kn1

  function kn2() result(hm2)
complex :: hm(1:2), hm2(1:2)
data (hm(md)%im, md=1,2)/1.0, 2.0/
hm2 = hm
  end function kn2
end module ur

  use ur
  if (any (kn1() .ne. [(1.0,0.0),(2.0,0.0)])) stop 1
  if (any (kn2() .ne. [(0.0,1.0),(0.0,2.0)])) stop 2
end

I have yet to test inquiry references of derived type components. I suspect
that a bit more work is needed.

Watch this space

Paul

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #7 from Andrea Corallo  ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Andrea Corallo from comment #5)
>> "rsandifo at gcc dot gnu.org via Gcc-bugs" 
>> writes:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>> >
>> > --- Comment #4 from rsandifo at gcc dot gnu.org > > gnu.org> ---
>> > (In reply to Andrea Corallo from comment #3)
>> >> Created attachment 49710 [details]
>> >> PR97092.patch
>> >> 
>> >> What is going on is that in 'update_costs_from_allocno' we try to
>> >> identify the smallest mode using narrower_subreg_mode to then update the
>> >> costs.
>> >> 
>> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> >> are not ordered we ICE in 'paradoxical_subreg_p'.
>> >> 
>> >> Now I don't know if the strategy we want is:
>> >> 
>> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
>> >>   calling 'narrower_subreg_mode' just keep the current one.
>> >> 
>> >> - Always select the cheapest mode in terms of cost.
>> >> 
>> >> The attached I'm testing implements the second.
>> 
>> Hi Richard,
>> 
>> thanks for commenting.
>> 
>> > I think instead we should consider recomputing “mode” in each
>> > iteration of the loop, rather than carry over the result of
>> > previous iterations.  I.e. use:
>> >
>> > mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>> >  ALLOCNO_MODE (cp->second));
>> 
>> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
>> (cp->second) always satisfying 'ordered_p'?
> Yeah, I think so.  If the modes aren't ordered then we shouldn't
> create a copy between them.

Great, I'm going to test the suggested then.

Thanks

  Andrea

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo via Gcc-bugs]

"rsandifo at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Andrea Corallo from comment #5)
>> "rsandifo at gcc dot gnu.org via Gcc-bugs" 
>> writes:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>> >
>> > --- Comment #4 from rsandifo at gcc dot gnu.org > > gnu.org> ---
>> > (In reply to Andrea Corallo from comment #3)
>> >> Created attachment 49710 [details]
>> >> PR97092.patch
>> >> 
>> >> What is going on is that in 'update_costs_from_allocno' we try to
>> >> identify the smallest mode using narrower_subreg_mode to then update the
>> >> costs.
>> >> 
>> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> >> are not ordered we ICE in 'paradoxical_subreg_p'.
>> >> 
>> >> Now I don't know if the strategy we want is:
>> >> 
>> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
>> >>   calling 'narrower_subreg_mode' just keep the current one.
>> >> 
>> >> - Always select the cheapest mode in terms of cost.
>> >> 
>> >> The attached I'm testing implements the second.
>> 
>> Hi Richard,
>> 
>> thanks for commenting.
>> 
>> > I think instead we should consider recomputing “mode” in each
>> > iteration of the loop, rather than carry over the result of
>> > previous iterations.  I.e. use:
>> >
>> > mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>> >  ALLOCNO_MODE (cp->second));
>> 
>> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
>> (cp->second) always satisfying 'ordered_p'?
> Yeah, I think so.  If the modes aren't ordered then we shouldn't
> create a copy between them.

Great, I'm going to test the suggested then.

Thanks

  Andrea

[Bug tree-optimization/95396] [8/9/10/11 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621

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

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Looks like this might have gone latent on trunk.  First thought
was that it might be g:7b4ea2827d2003c8ffc76cd478f8974360cbd78f,
but it seems not.

[Bug target/97875] suboptimal loop vectorization

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

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

--- Comment #5 from Christophe Lyon  ---
Interestingly, if I make arm_builtin_support_vector_misalignment() behave the
same for MVE and Neon, the generated code (with __restrict__) becomes:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
push{r4, r5, r6, r7, r8, r9, r10, fp}   @ 61[c=8 l=4] 
*push_multi
ldrdr10, fp, [r1, #8]   @ 75[c=8 l=4]  *thumb2_ldrd
ldrdr6, r7, [r2, #8]@ 76[c=8 l=4]  *thumb2_ldrd
ldr r4, [r2]@ 14[c=12 l=4]  *thumb2_movsi_vfp/5
ldr r8, [r1]@ 9 [c=12 l=4]  *thumb2_movsi_vfp/6
ldr r9, [r1, #4]@ 10[c=12 l=4]  *thumb2_movsi_vfp/6
ldr r5, [r2, #4]@ 15[c=12 l=4]  *thumb2_movsi_vfp/5
vmovd6, r8, r9  @ v4si  @ 35[c=4 l=8]  *mve_movv4si/1
vmovd7, r10, fp
vmovd4, r4, r5  @ v4si  @ 36[c=4 l=8]  *mve_movv4si/1
vmovd5, r6, r7
sub sp, sp, #16 @ 62[c=4 l=4]  *arm_addsi3/11
mov r3, sp  @ 37[c=4 l=2]  *thumb2_movsi_vfp/0
vsub.i32q3, q3, q2  @ 18[c=80 l=4]  mve_vsubqv4si
vstrw.32q3, [r3]@ 34[c=4 l=4]  *mve_movv4si/7
ldrdr4, r1, [sp]@ 77[c=8 l=4]  *thumb2_ldrd_base
ldrdr2, r3, [sp, #8]@ 78[c=8 l=4]  *thumb2_ldrd
strdr4, r1, [r0]@ 79[c=8 l=4]  *thumb2_strd_base
strdr2, r3, [r0, #8]@ 80[c=8 l=4]  *thumb2_strd
add sp, sp, #16 @ 66[c=4 l=4]  *arm_addsi3/5
@ sp needed @ 67[c=8 l=0]  force_register_use
pop {r4, r5, r6, r7, r8, r9, r10, fp}   @ 68[c=8 l=4] 
*load_multiple_with_writeback
bx  lr  @ 69[c=8 l=4]  *thumb2_return


The Neon version has:
vld1.32 {q8}, [r1]  @ 8 [c=8 l=4]  *movmisalignv4si_neon_load
vld1.32 {q9}, [r2]  @ 9 [c=8 l=4]  *movmisalignv4si_neon_load
vsub.i32q8, q8, q9  @ 10[c=80 l=4]  *subv4si3_neon
vst1.32 {q8}, [r0]  @ 11[c=8 l=4]  *movmisalignv4si_neon_store
bx  lr  @ 21[c=8 l=4]  *thumb2_return

So it seems MVE needs movmisalign pattern.

[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

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

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

--- Comment #4 from Jakub Jelinek  ---
As for f2, only the case of a == b when the jump is predicted unlikely looks
weird, e.g. take:
void foo (void);

void
bar (float a, float b)
{
  if (__builtin_expect (a != b, 1))
foo ();
}

void
baz (float a, float b)
{
  if (__builtin_expect (a == b, 1))
foo ();
}

void
qux (float a, float b)
{
  if (__builtin_expect (a != b, 0))
foo ();
}

void
corge (float a, float b)
{
  if (__builtin_expect (a == b, 0))
foo ();
}

bar:ucomiss %xmm1, %xmm0
jp  .L4
je  .L1
.L4:jmp foo
.L1:ret
baz:ucomiss %xmm1, %xmm0
jp  .L6
jne .L6
jmp foo
.L6:ret
qux:ucomiss %xmm1, %xmm0
jp  .L13
jne .L13
ret
.L13:   jmp foo
corge:  ucomiss %xmm1, %xmm0
jnp .L18
.L14:   ret
.L18:   jne .L14
jmp foo
I guess I need to debug the branch probabilities in that case, we should
certainly predict that operands are most of the time non-NaN and thus that PF
bit will not be set in 99% of cases or so.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

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

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to Andrea Corallo from comment #5)
> "rsandifo at gcc dot gnu.org via Gcc-bugs" 
> writes:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
> >
> > --- Comment #4 from rsandifo at gcc dot gnu.org  > gnu.org> ---
> > (In reply to Andrea Corallo from comment #3)
> >> Created attachment 49710 [details]
> >> PR97092.patch
> >> 
> >> What is going on is that in 'update_costs_from_allocno' we try to
> >> identify the smallest mode using narrower_subreg_mode to then update the
> >> costs.
> >> 
> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
> >> are not ordered we ICE in 'paradoxical_subreg_p'.
> >> 
> >> Now I don't know if the strategy we want is:
> >> 
> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
> >>   calling 'narrower_subreg_mode' just keep the current one.
> >> 
> >> - Always select the cheapest mode in terms of cost.
> >> 
> >> The attached I'm testing implements the second.
> 
> Hi Richard,
> 
> thanks for commenting.
> 
> > I think instead we should consider recomputing “mode” in each
> > iteration of the loop, rather than carry over the result of
> > previous iterations.  I.e. use:
> >
> > mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
> >  ALLOCNO_MODE (cp->second));
> 
> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
> (cp->second) always satisfying 'ordered_p'?
Yeah, I think so.  If the modes aren't ordered then we shouldn't
create a copy between them.

> I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.
I think the difficulty is that for the x86 situation described in
the comment, the cost for the wider mode might not be meaningful.
It might be dangerous to rely on it having a larger value than
the narrower (meaningful) mode.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

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

--- Comment #5 from Andrea Corallo  ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>> 
>> What is going on is that in 'update_costs_from_allocno' we try to
>> identify the smallest mode using narrower_subreg_mode to then update the
>> costs.
>> 
>> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> are not ordered we ICE in 'paradoxical_subreg_p'.
>> 
>> Now I don't know if the strategy we want is:
>> 
>> - In 'update_costs_from_allocno' when modes are not ordered instead of
>>   calling 'narrower_subreg_mode' just keep the current one.
>> 
>> - Always select the cheapest mode in terms of cost.
>> 
>> The attached I'm testing implements the second.

Hi Richard,

thanks for commenting.

> I think instead we should consider recomputing “mode” in each
> iteration of the loop, rather than carry over the result of
> previous iterations.  I.e. use:
>
> mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>  ALLOCNO_MODE (cp->second));

Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
(cp->second) always satisfying 'ordered_p'?  In case not I think we
can't use 'narrower_subreg_mode'.

I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.

> instead of:
>
> mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
>
> Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
> was a loop invariant, so it made sense to set it outside
> the loop.  I think the intention of that patch was to use
> the smaller of the two modes involved in the copy, and carrying
> the result over to future copies might have been unintentional.
>
> The difficulty with carrying the mode over to later copies
> is that the costs then become dependent on the order of
> the copies, whereas I'm not sure the order of the copies
> is significant.

I see

Thanks!

  Andrea

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo via Gcc-bugs]

"rsandifo at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>> 
>> What is going on is that in 'update_costs_from_allocno' we try to
>> identify the smallest mode using narrower_subreg_mode to then update the
>> costs.
>> 
>> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> are not ordered we ICE in 'paradoxical_subreg_p'.
>> 
>> Now I don't know if the strategy we want is:
>> 
>> - In 'update_costs_from_allocno' when modes are not ordered instead of
>>   calling 'narrower_subreg_mode' just keep the current one.
>> 
>> - Always select the cheapest mode in terms of cost.
>> 
>> The attached I'm testing implements the second.

Hi Richard,

thanks for commenting.

> I think instead we should consider recomputing “mode” in each
> iteration of the loop, rather than carry over the result of
> previous iterations.  I.e. use:
>
> mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>  ALLOCNO_MODE (cp->second));

Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
(cp->second) always satisfying 'ordered_p'?  In case not I think we
can't use 'narrower_subreg_mode'.

I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.

> instead of:
>
> mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
>
> Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
> was a loop invariant, so it made sense to set it outside
> the loop.  I think the intention of that patch was to use
> the smaller of the two modes involved in the copy, and carrying
> the result over to future copies might have been unintentional.
>
> The difficulty with carrying the mode over to later copies
> is that the costs then become dependent on the order of
> the copies, whereas I'm not sure the order of the copies
> is significant.

I see

Thanks!

  Andrea

[Bug middle-end/98190] [11 Regression] GCC11 miscompiles code using _Bool when inlining: bfxil instruction misused since r11-165

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

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

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #12)
> (In reply to rsand...@gcc.gnu.org from comment #10)
> > If we can't assert, I guess the rule is that we need to extend
> > whenever we're storing to the MSB of the inner register.  We can
> > do that either by extending the source value and the range to
> > the outer register, or by assigning to the inner register and
> > then extending it separately.
> 
> So perhaps:
> --- gcc/expr.c.jj 2020-12-09 00:00:08.622548080 +0100
> +++ gcc/expr.c2020-12-09 10:36:12.198801940 +0100
> @@ -5451,6 +5451,33 @@ expand_assignment (tree to, tree from, b
>  mode1, to_rtx, to, from,
>  reversep))
>   result = NULL;
> +  else if (SUBREG_P (to_rtx)
> +&& SUBREG_PROMOTED_VAR_P (to_rtx))
> + {
> +   /* If to_rtx is a promoted subreg, this must be a store to the
> +  whole variable, otherwise to_rtx would need to be MEM.
> +  We need to zero or sign extend the value afterwards.  */
> +   gcc_assert (known_eq (bitpos, 0)
> +   && known_eq (bitsize,
> +GET_MODE_BITSIZE (GET_MODE (to_rtx;
> +   if (TREE_CODE (to) == MEM_REF && !REF_REVERSE_STORAGE_ORDER (to))
> + result = store_expr (from, to_rtx, 0, nontemporal, false);
> +   else
> + {
> +   result = store_field (to_rtx, bitsize, bitpos,
> + bitregion_start, bitregion_end,
> + mode1, from, get_alias_set (to),
> + nontemporal, reversep);
> +   rtx to_rtx1
> + = lowpart_subreg (subreg_unpromoted_mode (to_rtx),
> +   SUBREG_REG (to_rtx),
> +   subreg_promoted_mode (to_rtx));
> +   to_rtx1 = convert_to_mode (subreg_promoted_mode (to_rtx),
> +  to_rtx1,
> +  SUBREG_PROMOTED_SIGN (to_rtx));
> +   emit_move_insn (SUBREG_REG (to_rtx), to_rtx1);
> + }
> + }
> else
>   result = store_field (to_rtx, bitsize, bitpos,
> bitregion_start, bitregion_end,
> 
> then?  As in, if store_expr can handle it, use that, otherwise perform the
> extension at the end.
LGTM FWIW, although I shouldn't be the one to review.  I'm not
sure off-hand whether it's OK to store an unpromoted value to
a promoted subreg lhs, with the promoted subreg being temporarily
invalid.  If that's a problem, it might be safer to pass to_rtx1
to store_field instead.

[Bug tree-optimization/98213] [11 Regression] Never ending compilation at -O3 since r11-161-g283cb9ea6293e813

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/98213] [11 Regression] Never ending compilation at -O3 since r11-161-g283cb9ea6293e813

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

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

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

https://gcc.gnu.org/g:84d08255f9f2f7137caf648fcc9dc36101bc893c

commit r11-5886-g84d08255f9f2f7137caf648fcc9dc36101bc893c
Author: Richard Biener 
Date:   Wed Dec 9 15:48:36 2020 +0100

tree-optimization/98213 - cache PHI walking result in SM

This avoids exponential work when walking PHIs in loop store motion.
Fails are quickly propagated and thus need no caching.

2020-12-09  Richard Biener  

PR tree-optimization/98213
* tree-ssa-loop-im.c (sm_seq_valid_bb): Cache successfully
processed PHIs.
(hoist_memory_references): Adjust.

* g++.dg/pr98213.C: New testcase.

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

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

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

--- Comment #9 from Nathan Sidwell  ---
Created attachment 49721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49721&action=edit
v3

oh, I think I'm supposed to run ./genfixes too ...

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

[iii at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from Ilya Leoshkevich  ---
Hm, can it be that fixincludes/tests/base/sys/types.h simply needs to be
updated?

For example, here is a similar commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=081b3517b4df826ac917147eb906bbb8fc6528b1

There, both fixincludes/inclhack.def and fixincludes/tests/base/sys/inttypes.h
are updated.
I tried the following and it helped:

diff --git a/fixincludes/tests/base/sys/types.h
b/fixincludes/tests/base/sys/types.h
index 683b5e9..a318f9b 100644
--- a/fixincludes/tests/base/sys/types.h
+++ b/fixincludes/tests/base/sys/types.h
@@ -9,6 +9,11 @@



+#if defined( AIX_PHYSADR_T_CHECK )
+typedef struct __physadr_s {
+#endif  /* AIX_PHYSADR_T_CHECK */
+
+
 #if defined( GNU_TYPES_CHECK )
 #if !defined(_GCC_PTRDIFF_T)
 #define _GCC_PTRDIFF_T

[Bug c/98217] Prefer a warning for when VLAs declared on stack

[svoboda at cert dot org via Gcc-bugs]

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

David Svoboda  changed:

   What|Removed |Added

 CC||svoboda at cert dot org

--- Comment #1 from David Svoboda  ---
The GCC docs (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) define
the "-Wvla" flag to do the following:

Warn if a variable-length array is used in the code. -Wno-vla prevents the
-Wpedantic warning of the variable-length array.

The -Wvla flag causes both GCC 10 and Clang 12 to holler about this declaration
having a VLA:

  void func1(int n, int array[n]);

This happens even if func1 is called with a regular array or an int pointer.
Whether you consider 'array' to be a VLA or not depends on how you interpret
ISO C17 6.7.6.3p4.  A colleague called the declaration of array a "heisen-VLA"
on the grounds that array may be cast to a VLA before being immediately cast to
an int pointer.

Clang 12 also hollers about this line, but GCC 10 doesn't:

  void func2(int array[*]);

ISO C17 6.7.6.3p4 is pretty clear that an array declared this way is indeed a
VLA.

But both code examples use VLAs only as an actual parameter argument type. The
main hazard of VLAs is being declared as a stack variable with an unsecured
dimension, where they could potentially exhaust your stack.

Most experts on VLAs would suggest that casting something to a VLA is not a
problem per se, and the real danger of VLAs is declaring a VLA on the stack
(because of the potential for stack exhaustion).  However, neither GCC nor
Clang seem to have a warning to detect VLA stack declarations. This would be a
useful feature, as either a replacement for -Wvla's current behavior, or for a
new warning flag.

void func1(int n, int array[n]) { /* ok, no warning */
  int array2[n]; /* bad, VLA on stack, warn! */
  int (*array3)[n];  /* ok, no VLA on stack, so no warning */
}

Finally, declaring a function argument type as a VLA with an explicit
(non-compile-time) array bounds can improve software security, as a VLA bounds
conveys useful semantic information to programmers. Also a VLA bounds can be
checked by the compiler or a static-analysis tool. At CERT, we call such an
array a "conformant array". For more background, see CERT guideline:

  API05-C. Use conformant array parameters
  https://wiki.sei.cmu.edu/confluence/x/n9UxBQ


(This bug report reports the same problem as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997 but provides a more
comprehensive solution.)

[Bug c/98217] New: Prefer a warning for when VLAs declared on stack

[svoboda at cert dot org via Gcc-bugs]

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

Bug ID: 98217
   Summary: Prefer a warning for when VLAs declared on stack
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: svoboda at cert dot org
  Target Milestone: ---

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

[dpozar at ecs dot umass.edu via Gcc-bugs]

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

--- Comment #17 from dpozar at ecs dot umass.edu ---
No, I don't think it is compiled with static option. I am using code blocks,
which does not seem to even allow a static option.

From: sgk at troutmask dot apl.washington.edu 
Sent: Wednesday, December 9, 2020 10:37 AM
To: David Pozar 
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #16 from Steve Kargl  ---
On Wed, Dec 09, 2020 at 01:24:20PM +, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
>
> --- Comment #15 from dpozar at ecs dot umass.edu ---
> attached is the output file from
>
> c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt
>
> don't see any reference to libraries, though.
>

Is testcsqrt.exe compiled with the -static option?  cmdout.txt
shows

[152](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x1210 _csqrtf
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0

On my FreeBSD system and a static binary, I see

% gfcx -o z -static a.f90
% objdump -t z | grep csqrt
 ldf *ABS*   s_csqrtf.c
08078a90 g F .text  021d csqrtf

On my FreeBSD system and a dynamic binary, I see

% gfcx -o z a.f90
% objdump -t z | grep csqrt
   F *UND*    csqrtf@@FBSD_1.1

This info is sufficient to tell me that csqrtf lives in FreeBSD's libm.

objdump has several options that may help determine where
csqrtf() resides.   I don't know MingW (or windows 10) to
be of any additional help.

--
You are receiving this mail because:
You reported the bug.

[Bug c++/98216] [C++20] std::array template parameter error with negative values

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-09
 Ever confirmed|0   |1
   Keywords||wrong-code

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

[iii at linux dot ibm.com via Gcc-bugs]

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

--- Comment #7 from Ilya Leoshkevich  ---
Still a similar error:



sys/types.h /home/iii/gcc/fixincludes/tests/base/sys/types.h differ: byte 243,
line 12
*** sys/types.h 2020-12-09 15:57:57.575959676 +
--- /home/iii/gcc/fixincludes/tests/base/sys/types.h2020-04-14
11:43:52.317860128 +
***
*** 9,20 



- #if defined( AIX_PHYSADR_T_CHECK )
- typedef struct __physadr_s { int r[1]; } *physadr_t;
- 
- #endif  /* AIX_PHYSADR_T_CHECK */
- 
- 
  #if defined( GNU_TYPES_CHECK )
  #if !defined(_GCC_PTRDIFF_T)
  #define _GCC_PTRDIFF_T
--- 9,14 

There were fixinclude test FAILURES



What I don't quite get is why does this kick in on Linux?
It seems to be gated by `mach  = "*-*-aix*"`, just like other similar fixes
which don't cause issues.

[Bug c++/88355] [c++20] Placeholder non-type template argument type deduction fails with custom types

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/88355] [c++20] Placeholder non-type template argument type deduction fails with custom types

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

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

--- Comment #5 from Jonathan Wakely  ---
It was fixed by r273591 so maybe a dup of PR c++/90098 or PR c++/90099 or PR
c++/90101

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

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

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

--- Comment #6 from Nathan Sidwell  ---
Created attachment 49720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49720&action=edit
v2

Ok, I think I'm understanding what fixinclude's testsuite is looking for. 
Here's an updated patch, using the actual text from sys/types.h

[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization

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

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

--- Comment #3 from Jonathan Wakely  ---
I think it's QoI whether this works.

"The objects are constructed and the associations are established at some time
prior to or during the first time an object of class ios_base::Init is
constructed, ..."

"The results of including  in a translation unit shall be as if
 defined an instance of ios_base::Init with static storage duration."

So there's no guarantee that the global iostreams will be usable during the
static initialization phase, because there's no guarantee that a given
constructor will be before the first ios_base::Init constructor.

The problem is *not* that the counters use atomics rather than waiting.

Even if the initialization is done as in the patch below, it still crashes:

--- a/libstdc++-v3/src/c++98/ios_init.cc
+++ b/libstdc++-v3/src/c++98/ios_init.cc
@@ -77,7 +77,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   ios_base::Init::Init()
   {
-if (__gnu_cxx::__exchange_and_add_dispatch(&_S_refcount, 1) == 0)
+struct do_init
+{
+  do_init()
   {
// Standard streams default to synced with "C" operations.
_S_synced_with_stdio = true;
@@ -116,8 +118,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// streams are not re-initialized with uses of ios_base::Init
// besides  static object, ie just using  with
// ios_base::Init objects.
-   __gnu_cxx::__atomic_add_dispatch(&_S_refcount, 1);
+   _S_refcount = 1;
   }
+};
+#ifndef __cpp_threadsafe_static_init
+# warning "ios_base::Init::Init() initialization is not thread-safe"
+#endif
+static const do_init once __attribute__((unused)) = do_init();
+
+__gnu_cxx::__exchange_and_add_dispatch(&_S_refcount, 1);
   }

   ios_base::Init::~Init()

This doesn't help, because the thread1 and thread2 objects in file1.cc are
still constructed before the static ios_base::Init object in file2.cc and so
they still try to use std::cout before the first _S_refcount increment has
happened.

Waiting for the iostream initialization to finish doesn't help if it hasn't
started yet. And isn't relevant in your program, because only one
ios_base::Init constructor ever runs in the whole program. Making the second
one wait for the first doesn't help if there is only one.

What does make your program work is:

--- a/libstdc++-v3/include/std/iostream
+++ b/libstdc++-v3/include/std/iostream
@@ -71,7 +71,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   //@}

   // For construction of filebuffers for cout, cin, cerr, clog et. al.
-  static ios_base::Init __ioinit;
+  static ios_base::Init __ioinit __attribute__((__init_priority__(50)));

 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace

And this works with or without changing the Schwarz counter.

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

[iii at linux dot ibm.com via Gcc-bugs]

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

--- Comment #5 from Ilya Leoshkevich  ---
Oh, just in case: gcc121 is x86_64 CentOS Linux 7, not AIX.

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

[iii at linux dot ibm.com via Gcc-bugs]

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

--- Comment #4 from Ilya Leoshkevich  ---
Unfortunately not, with this patch I get:

sys/types.h gcc/fixincludes/tests/base/sys/types.h differ: byte 243, line 12
*** sys/types.h 2020-12-09 15:46:15.843503181 +
--- gcc/fixincludes/tests/base/sys/types.h  2020-04-14 11:43:52.317860128
+
***
*** 9,19 



- #if defined( AIX_PHYSADR_T_CHECK )
- typedef struct __physadr_s { random text } *physadr_t;
- #endif  /* AIX_PHYSADR_T_CHECK */
- 
- 
  #if defined( GNU_TYPES_CHECK )
  #if !defined(_GCC_PTRDIFF_T)
  #define _GCC_PTRDIFF_T
--- 9,14 

There were fixinclude test FAILURES

[Bug c++/98216] New: [C++20] std::array template parameter error with negative values

[emmanuel.le-trong--- via Gcc-bugs]

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

Bug ID: 98216
   Summary: [C++20] std::array template parameter error
with negative values
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emmanuel.le-tr...@cnrs-orleans.fr
  Target Milestone: ---

Sorry for the bad title, I can't figure out how to summarize this:

#include 
#include 

using
an_array = std::array ;

constexpr auto
add_array (an_array a, an_array const& b)
{
a[0] += b[0];
return a;
}

template 
struct
wrapper
{
static constexpr auto
arr = A;
};


template 
auto
add (wrapper  const&, wrapper  const&)
{
return wrapper  {};
}

constexpr auto ONE   = an_array {{  1. }};
constexpr auto MINUS_ONE = an_array {{ -1. }}; 
constexpr auto MINUS_TWO = an_array {{ -2. }}; 

int
main ()
{
auto a = wrapper  {};
auto b = wrapper  {};
auto c = add (a, b);
assert (c.arr == MINUS_TWO); // <- should fail
assert (c.arr == MINUS_ONE); // <- should pass
}

Compiled with version 11.0.0 20201209, the first assertion passes and the
second fails. It should be the opposite.

FWIW, if you replace double by float, it works as intended.

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

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

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

--- Comment #3 from Nathan Sidwell  ---
Created attachment 49719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49719&action=edit
patch

does this fix it?  I can't run the fixinclude testsuite on gcc119 as autogen
doesn't appear to be there:
nathan@power8-aix:28>cd fixincludes/
nathan@power8-aix:29>make check
autogen -T ../../../src/fixincludes/check.tpl
../../../src/fixincludes/inclhack.def
/bin/bash: autogen: command not found
Makefile:176: recipe for target 'check' failed
make: *** [check] Error 127

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #16 from Steve Kargl  ---
On Wed, Dec 09, 2020 at 01:24:20PM +, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
> 
> --- Comment #15 from dpozar at ecs dot umass.edu ---
> attached is the output file from
> 
> c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt
> 
> don't see any reference to libraries, though.
> 

Is testcsqrt.exe compiled with the -static option?  cmdout.txt
shows

[152](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x1210 _csqrtf
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0

On my FreeBSD system and a static binary, I see 

% gfcx -o z -static a.f90
% objdump -t z | grep csqrt
 ldf *ABS*   s_csqrtf.c
08078a90 g F .text  021d csqrtf

On my FreeBSD system and a dynamic binary, I see

% gfcx -o z a.f90
% objdump -t z | grep csqrt
   F *UND*    csqrtf@@FBSD_1.1

This info is sufficient to tell me that csqrtf lives in FreeBSD's libm.

objdump has several options that may help determine where
csqrtf() resides.   I don't know MingW (or windows 10) to
be of any additional help.

[Bug c++/88355] [c++20] Placeholder non-type template argument type deduction fails with custom types

[emmanuel.le-trong--- via Gcc-bugs]

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

Emmanuel Le Trong  changed:

   What|Removed |Added

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

--- Comment #4 from Emmanuel Le Trong  ---
This bug has disappeared, both tests above compile with version 10.0.0
20200108.

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/97875] suboptimal loop vectorization

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

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

--- Comment #4 from Christophe Lyon  ---

In both cases (Neon and MVE), DR_TARGET_ALIGNMENT is 8, so the decision to emit
a useless loop tail comes from elsewhere.

And yes, MVE vldrw.32 and vstrw.32 share the same alignment properties.

[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above

[jamesgua at ca dot ibm.com via Gcc-bugs]

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

--- Comment #8 from jamesgua at ca dot ibm.com ---
one more function found the same issue:
memcpy
I guess more functions in libc might have same issue.

[Bug middle-end/98190] [11 Regression] GCC11 miscompiles code using _Bool when inlining: bfxil instruction misused since r11-165

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Wed, 9 Dec 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
> 
> --- Comment #12 from Jakub Jelinek  ---
> (In reply to rsand...@gcc.gnu.org from comment #10)
> > If we can't assert, I guess the rule is that we need to extend
> > whenever we're storing to the MSB of the inner register.  We can
> > do that either by extending the source value and the range to
> > the outer register, or by assigning to the inner register and
> > then extending it separately.
> 
> So perhaps:
> --- gcc/expr.c.jj   2020-12-09 00:00:08.622548080 +0100
> +++ gcc/expr.c  2020-12-09 10:36:12.198801940 +0100
> @@ -5451,6 +5451,33 @@ expand_assignment (tree to, tree from, b
>mode1, to_rtx, to, from,
>reversep))
> result = NULL;
> +  else if (SUBREG_P (to_rtx)
> +  && SUBREG_PROMOTED_VAR_P (to_rtx))
> +   {
> + /* If to_rtx is a promoted subreg, this must be a store to the
> +whole variable, otherwise to_rtx would need to be MEM.

Yes, that's true - all !DECL_NOT_GIMPLE_REG_P may not have partial defs.

> +We need to zero or sign extend the value afterwards.  */
> + gcc_assert (known_eq (bitpos, 0)
> + && known_eq (bitsize,
> +  GET_MODE_BITSIZE (GET_MODE (to_rtx;
> + if (TREE_CODE (to) == MEM_REF && !REF_REVERSE_STORAGE_ORDER 
> (to))
> +   result = store_expr (from, to_rtx, 0, nontemporal, false);
> + else
> +   {
> + result = store_field (to_rtx, bitsize, bitpos,
> +   bitregion_start, bitregion_end,
> +   mode1, from, get_alias_set (to),
> +   nontemporal, reversep);
> + rtx to_rtx1
> +   = lowpart_subreg (subreg_unpromoted_mode (to_rtx),
> + SUBREG_REG (to_rtx),
> + subreg_promoted_mode (to_rtx));
> + to_rtx1 = convert_to_mode (subreg_promoted_mode (to_rtx),
> +to_rtx1,
> +SUBREG_PROMOTED_SIGN (to_rtx));
> + emit_move_insn (SUBREG_REG (to_rtx), to_rtx1);
> +   }
> +   }
>   else
> result = store_field (to_rtx, bitsize, bitpos,
>   bitregion_start, bitregion_end,
> 
> then?  As in, if store_expr can handle it, use that, otherwise perform the
> extension at the end.
> 
> As for BIT_INSERT_EXPR, I'm not sure if SSA_NAMEs can get promoted SUBREGs or
> not, but in any case it wouldn't be this code path, it would be store_expr
> which handles the promoted SUBREGs already, because destination would not be a
> MEM_REF with non-mem decl or reversed order, nor handled_component_p, nor
> ARRAY_TYPE destination.

True.

[Bug c++/92576] Definition of variable template without initializer is treated as declaration

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed in GCC 10.

[Bug c++/92446] [C++20] template argument deduction fails for custom non-type parameters

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||9.2.0
   Target Milestone|--- |9.3
 Resolution|--- |FIXED
  Known to work||10.0, 9.3.0

--- Comment #4 from Jason Merrill  ---
Fixed in 9.3/10.

[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49718&action=edit
gcc11-pr98212.patch

Untested attempt to fix f1.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #5)
> If I then disable tracking pointer values via de-references in the on entry
> cache, memory consumption goes back to normal.  Since hybrid EVRP still has
> EVRP tracking the non-null pointer values , I am considering this as an
> option just within EVRP for this release since we shouldn't miss anything.

Perhaps it could be disabled only if the CFG is large for some definition of
large?

[Bug tree-optimization/98213] [11 Regression] Never ending compilation at -O3 since r11-161-g283cb9ea6293e813

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

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

--- Comment #3 from Richard Biener  ---
OK, so it's "merely" taking a long time (exponential) walking all paths through
the CFG.  Meh.

I have a patch fixing this case but will have to think about some more.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-12-09
 CC||amacleod at redhat dot com
 Ever confirmed|0   |1

--- Comment #5 from Andrew Macleod  ---
I am working on this. 
The memory being allocated is the on-entry cache. With a very large CFG, the
on-entry cache propagator is consuming excessive memory.

First step is to recognize that if an ssa-name is never exported from GORI in
any block, then its only range is it's global range, and we don't need to
propagate any on-entry range around for it. I had planned to eventually get to
this, now its seems more important.  It is also a general speedup to avoid ever
looking at names which are irrelevant

This is true for all ranges except pointers which can become non-zero at a
dereference point.  And more generally, for anything which is the product of a
statement side effect. Dereferences are currently the only thing ranger tracks
which fall into this category. 

Implementing this tweak get back about half that memory.  The other half is
still tracking around the non-zero-ness of pointers across this massive CFG.

I have longer term plans for dealing with statement side effects like this that
are beyond the scope of this release, as well as different plans for pointer
ranges when we get to supporting other kinds of ranges beyond just integral.

If I then disable tracking pointer values via de-references in the on entry
cache, memory consumption goes back to normal.  Since hybrid EVRP still has
EVRP tracking the non-null pointer values , I am considering this as an option
just within EVRP for this release since we shouldn't miss anything.

I am continuing to look at it though and will come back with firmer conclusions

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #13 from Jason Merrill  ---
I vaguely remember us supporting this in the distant past, but removing that
support to be conforming.

Ah, yes, in 1998: r0-18485

[Bug c++/97517] 'nullptr_type' not supported by simple_type_specifier'nullptr_type' not supported by direct_abstract_declarator

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/97517] 'nullptr_type' not supported by simple_type_specifier'nullptr_type' not supported by direct_abstract_declarator

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

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

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

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

commit r11-5884-gfe70679b80f5e6193a0976be41b68d590c7cb2f3
Author: Marek Polacek 
Date:   Tue Dec 8 16:44:53 2020 -0500

c++: Fix printing of decltype(nullptr) [PR97517]

The C++ printer doesn't handle NULLPTR_TYPE, so we issue the ugly
"'nullptr_type' not supported by...".  Since NULLPTR_TYPE is
decltype(nullptr), it seemed reasonable to handle it where we
handle DECLTYPE_TYPE, that is, in the simple-type-specifier handler.

gcc/cp/ChangeLog:

PR c++/97517
* cxx-pretty-print.c (cxx_pretty_printer::simple_type_specifier):
Handle
NULLPTR_TYPE.
(pp_cxx_type_specifier_seq): Likewise.
(cxx_pretty_printer::type_id): Likewise.

gcc/testsuite/ChangeLog:

PR c++/97517
* g++.dg/diagnostic/nullptr.C: New test.

[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Martin Liška  ---
Should be fixed now.

[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:33d2f41785b24ad43c5a9d52aa289e33ac838f86

commit r11-5883-g33d2f41785b24ad43c5a9d52aa289e33ac838f86
Author: Martin Liska 
Date:   Wed Dec 9 15:24:36 2020 +0100

testsuite: fix 2 tests on aarch64

gcc/testsuite/ChangeLog:

PR tree-optimization/98182
* gcc.dg/tree-ssa/if-to-switch-1.c: Add case-values-threshold in
order to fix them for aarch64.
* gcc.dg/tree-ssa/if-to-switch-10.c: Likewise.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

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

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to Andrea Corallo from comment #3)
> Created attachment 49710 [details]
> PR97092.patch
> 
> What is going on is that in 'update_costs_from_allocno' we try to
> identify the smallest mode using narrower_subreg_mode to then update the
> costs.
> 
> The two modes involved here are E_DImode and E_VNx2QImode, cause these
> are not ordered we ICE in 'paradoxical_subreg_p'.
> 
> Now I don't know if the strategy we want is:
> 
> - In 'update_costs_from_allocno' when modes are not ordered instead of
>   calling 'narrower_subreg_mode' just keep the current one.
> 
> - Always select the cheapest mode in terms of cost.
> 
> The attached I'm testing implements the second.
I think instead we should consider recomputing “mode” in each
iteration of the loop, rather than carry over the result of
previous iterations.  I.e. use:

mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
 ALLOCNO_MODE (cp->second));

instead of:

mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));

Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
was a loop invariant, so it made sense to set it outside
the loop.  I think the intention of that patch was to use
the smaller of the two modes involved in the copy, and carrying
the result over to future copies might have been unintentional.

The difficulty with carrying the mode over to later copies
is that the costs then become dependent on the order of
the copies, whereas I'm not sure the order of the copies
is significant.

[Bug target/98214] [10/11 Regression] SVE: Wrong code with -O3 -msve-vector-bits=512

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

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

Alex Coplan  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Summary|SVE: Wrong code with -O3|[10/11 Regression] SVE:
   |-msve-vector-bits=512   |Wrong code with -O3
   ||-msve-vector-bits=512

--- Comment #1 from Alex Coplan  ---
Started with r10-4752-g2d56600c8de397d09a16dedd33d310a763a832ae

[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK

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

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

Nathan Sidwell  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-09
 CC||nathan at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Nathan Sidwell  ---
sigh, guess I get to reverse engineer that testing a bit more ...

[Bug c++/93310] Incorrect constexpr virtual evaluation inside a constructor

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed in 10.2/11.  I doubt anyone is still using GCC 9 for C++20 code.

[Bug c++/56838] [4.9 regression] GCC svn doesn't compile libreoffice 4.0.1.2

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

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

Bug 17232 Summary: [DR 1640] classes and class template specializations treated 
differently w.r.t. core issue #337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232

   What|Removed |Added

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

[Bug c++/17232] [DR 1640] classes and class template specializations treated differently w.r.t. core issue #337

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #27 from Jason Merrill  ---
Resolved in GCC 11 by the patch for bug 86252.

[Bug libstdc++/21796] (v7-branch) std::search not using std::find

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

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

Bug 20408 Summary: Unnecessary code generated for empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408

   What|Removed |Added

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

[Bug middle-end/20408] Unnecessary code generated for empty structs

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #23 from Jason Merrill  ---
Fixed in GCC 10.

[Bug c++/86943] [7 Regression] Wrong code when converting stateless generic lambda to function pointer

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

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|8.5 |8.3
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Jason Merrill  ---
Fixed in all active releases.

[Bug c++/84938] [7 Regression] internal compiler error: in gen_reg_rtx, at emit-rtl.c:1187 (gen_reg_rtx()/maybe_legitimize_operand())

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|8.5 |8.0
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jason Merrill  ---
Fixed in all active releases.

[Bug debug/65821] [7 regression] incorrect debug line # info for main

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #18 from Jason Merrill  ---
Fixed in all active releases.

[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)

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

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

--- Comment #8 from Christophe Lyon  ---
Indeed if-to-switch-1.c fails on aarch64 too, the other ones pass.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #41 from abebeos at lazaridis dot com ---
[RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0
conversion)

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561427.html

[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Now fixed for GCC 11.

[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Martin Liška  ---
Let's reopen it now.

[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)

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

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

--- Comment #6 from Martin Liška  ---
(In reply to Christophe Lyon from comment #5)
> The new test if-to-switch-10.c fails on aarch64:
> FAIL: gcc.dg/tree-ssa/if-to-switch-10.c scan-tree-dump iftoswitch "Condition
> chain with [^\n\r]* BBs transformed into a switch statement."

I can confirm that. The test will need --param case-values-threshold=5 as the
default for aarch64 is 17 if I see correctly.

Can you please check also the other test-cases (if-to-switch*.c), I bet they
will suffer from the same.

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

[dpozar at ecs dot umass.edu via Gcc-bugs]

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

--- Comment #15 from dpozar at ecs dot umass.edu ---
attached is the output file from

c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt

don't see any reference to libraries, though.

thanks,
dave

From: sgk at troutmask dot apl.washington.edu 
Sent: Tuesday, December 8, 2020 11:38 PM
To: David Pozar 
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #14 from Steve Kargl  ---
On Wed, Dec 09, 2020 at 12:28:49AM +, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
>
> --- Comment #13 from dpozar at ecs dot umass.edu ---
> Ok, I have objdump, and the .exe file. What switch options do I need to use in
> objdump?
>

Don't use windows, so only guessing.

cmd> objdump -t name_of_file.exe

--
You are receiving this mail because:
You reported the bug.

[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Moved.

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

[rene.jacobsen at deic dot dk via Gcc-bugs]

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

--- Comment #2 from rene.jacobsen at deic dot dk ---
Created attachment 49716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49716&action=edit
nvptx preprocessed source

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

[rene.jacobsen at deic dot dk via Gcc-bugs]

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

--- Comment #1 from rene.jacobsen at deic dot dk ---
Created attachment 49715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49715&action=edit
preprocessed source

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

[rene.jacobsen at deic dot dk via Gcc-bugs]

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

Bug ID: 98215
   Summary: Coalescing memory in target region creates slower code
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene.jacobsen at deic dot dk
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49714&action=edit
Code that produces the bug

Exact compiler version: g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0
System: Ubuntu 20.10
Command line: g++ -fopenmp -fcf-protection=none -foffload=nvptx-none
-fno-stack-protector -foffload=-misa=sm_35 -foffload=-lm gcc_coalescing_bug.cpp

The attached code shows two possible ways of running code on the GPU. The
coalesced function should be faster, due to coalesced memory access, but is ~4x
slower.

When running it on our system we get the following output:
non_coalesced: 
  Elapsed time: 0.13381

coalesced: 
  Elapsed time: 0.48244

non_coalesced: 
  Elapsed time: 0.133868

coalesced: 
  Elapsed time: 0.481802

non_coalesced: 
  Elapsed time: 0.133794

coalesced: 
  Elapsed time: 0.481685

non_coalesced: 
  Elapsed time: 0.133875

coalesced: 
  Elapsed time: 0.481841

[Bug tree-optimization/98213] [11 Regression] Never ending compilation at -O3 since r11-161-g283cb9ea6293e813

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

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

--- Comment #2 from Martin Liška  ---
Sure:

long var_23, min___a;
int var_24, test_var_8, test_arr_16;
extern bool arr_20[][13];
char arr_21_0_0_0_0_0;
const unsigned long long &min(unsigned long long &__b) {
  if (__b)
return __b;
  return min___a;
}
const unsigned long long &max(const unsigned long long &__a,
  const unsigned long long &__b) {
  if (__b)
return __b;
  return __a;
}
int *test_arr_0;
unsigned long long test_var_1;
void test() {
  for (;;) {
for (int i_6 = 0; i_6 < 19; i_6 += 4)
  for (long i_7(test_var_8); i_7; i_7 += 2) {
arr_20[0][i_7] = arr_21_0_0_0_0_0 = 0;
var_23 = test_arr_0[0];
  }
const unsigned long long &__trans_tmp_1 = min(test_var_1);
var_24 = max(test_arr_16, __trans_tmp_1);
  }
}

[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
f1 is currently unoptimal by design, the compiler is unable to merge trapping
and non-trapping instructions. There is already a PR for that.

f2 is not optimal. The conditional jump to the unconditional jump can be
merged, but the compiler currently does not perform that optimization.

[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|X86 unoptimal code for  |[10/11 Regression] X86
   |float equallity comparison  |unoptimal code for float
   |followed by jump|equallity comparison
   ||followed by jump
 Target||x86_64-*-* i?86-*-*
   Target Milestone|--- |10.3
   Host|x86 |

[Bug tree-optimization/98213] [11 Regression] Never ending compilation at -O3 since r11-161-g283cb9ea6293e813

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Can you reduce to w/o ?