[Bug c/96540] gcc fails to build on Darwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
It seems that the problem is in the declaration of the following variables in
value_range.h:
  template  friend void gt_ggc_mx (int_range *);
  template  friend void gt_pch_nx (int_range *);
  template  friend void gt_pch_nx (int_range *,
   gt_pointer_operator, void *);
  // ?? hash-traits.h has its own extern for these, which is causing
  // them to never be picked up by the templates.  For now, define  
  // elsewhere. 
  //template friend void gt_ggc_mx (int_range *&);   
  //template friend void gt_pch_nx (int_range *&);

This declaration is commented out, but above it is set, which looks suspicious.
If I comment out the three declarations for friend void gt_ggc_mx, then the
code seems to compile.

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
Most likely this was that commit:
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 150)   template
 friend void gt_ggc_mx (int_range *);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 151)   template
 friend void gt_pch_nx (int_range *);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 152)   template
 friend void gt_pch_nx (int_range *,
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 153) 
   gt_pointer_operator, void *);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 154)   // ??
hash-traits.h has its own extern for these, which is causing
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 155)   // them to
never be picked up by the templates.  For now, define
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 156)   // elsewhere.
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 157)  
//template friend void gt_ggc_mx (int_range *&);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 158)  
//template friend void gt_pch_nx (int_range *&);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 159)   friend void
gt_ggc_mx (int_range<1> *&);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 160)   friend void
gt_pch_nx (int_range<1> *&);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 161) 
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 162)   tree
m_ranges[N*2];

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Martin Liška  ---
Thank you for the report, I can take a look.
Can you please provide steps how to build Mesa with -O3 and -flto?
About the addr_to_index function: am I right that unreachable is defined in
your configuration as __builtin_unreachable? Can you please replace it with
fprintf that prints the value?

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Just uncommenting the declarations doesn't help because later on compilation
fails with
n file included from gtype-desc.c:52:
../../gcc/value-range.h:352:21: error: 'm_ranges' is a private member of
'int_range<1>'
  gt_ggc_mx (x->m_ranges[i * 2]);
^

because the friend declaration is missing. :(

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
that patch makes ccp to actually use the bit info ipa-cp determines. Before we
used it only to detect pointer alignments if I remember correctly. So it looks
like propagation bug uncovered by the change.  Smaller testcase or reproduction
steps would be indeed welcome.

[Bug c++/96535] GCC 10 ignoring function __attribute__ optimize for all x86

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
for cmdline option, it's handled in process_options which will enable
flag_cunroll_grow_size which is the real effective flag to unroll the loop in
testcase.

cut from toplev.c
---
  /* Unrolling all loops implies that standard loop unrolling must also
 be done.  */
  if (flag_unroll_all_loops)
flag_unroll_loops = 1;

  /* Allow cunroll to grow size accordingly.  */
  if (flag_cunroll_grow_size == AUTODETECT_VALUE)
flag_cunroll_grow_size
  = flag_unroll_loops || flag_peel_loops || optimize >= 3;

  /* web and rename-registers help when run after loop unrolling.  */
  if (flag_web == AUTODETECT_VALUE)
flag_web = flag_unroll_loops;

  if (flag_rename_registers == AUTODETECT_VALUE)
flag_rename_registers = flag_unroll_loops;

---

But for attribute ((optimize ("unroll-loops")))
it's handled in handle_optimize_attribute which doesn't enable
flag_cunroll_grow_size.

[Bug target/96243] For vector compare to mask register, UNSPEC is needed instead of comparison operator

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by hongtao Liu
:

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

commit r10-8599-gf098bc87dcae5646d11a351cfb55d0e1124c7f60
Author: liuhongt 
Date:   Mon Jul 20 10:13:58 2020 +0800

Using UNSPEC for vector compare to mask register.

For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
boolean value and try to do some optimization. But it is not true for
vector compare, also other places in rtl passes hold the same
assumption.

2020-07-20  Hongtao Liu  

gcc/
PR target/96243
* config/i386/i386-expand.c (ix86_expand_sse_cmp): Refine for
maskcmp.
(ix86_expand_mask_vec_cmp): Change prototype.
* config/i386/i386-protos.h (ix86_expand_mask_vec_cmp): Change
prototype.
* config/i386/i386.c (ix86_print_operand): Remove operand
modifier 'I'.
* config/i386/sse.md
(*_cmp3):
Deleted.
(*_cmp3): Ditto.
(*_ucmp3): Ditto.
(*_ucmp3,
avx512f_maskcmp3): Ditto.

gcc/testsuite
* gcc.target/i386/pr92865-1.c: Adjust testcase.

[Bug c/96549] New: Wrong evaluation of a comparison between long & short

[zhige.yu18 at imperial dot ac.uk]

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

Bug ID: 96549
   Summary: Wrong evaluation of a comparison between long & short
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhige.yu18 at imperial dot ac.uk
  Target Milestone: ---

The following code snippet:


#include 
long c = -1L;
long b = 0L;
int main(void) {
  if (3L > (short) ((c ^= (b = 1L)) * 3L))
printf("hello ");
  printf("world!\n");
}


> $ /usr/gcc-trunk/bin/gcc -O0 bug.c -o a.out; ./a.out 
> world!
> $ clang-10 -O0 bug.c -o a.out; ./a.out
> hello world!


When compiled with -O0/1/2/3, GCC omits the then-branch of the if-statement,
and prints "world!" only. This bug can be found in GCC-10.2.0 and GCC-11.0.0
20200804 (experimental). GCC-9.3.0 and earlier versions of GCC do not have this
bug.

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez  ---
Does this patch fix the problem?

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html

[Bug c/96549] [10/11 Regression] Wrong evaluation of a comparison between long & short

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-08-10
Summary|Wrong evaluation of a   |[10/11 Regression] Wrong
   |comparison between long &   |evaluation of a comparison
   |short   |between long & short

--- Comment #1 from Martin Liška  ---
Thank you for the report!

Slighly modified test-case:

long c = -1L;
long b = 0L;
int main(void) {
  if (3L > (short) ((c ^= (b = 1L)) * 3L))
return 0;
  __builtin_abort ();
}

Started with r10-7921-gbca558de2a24b2a7.

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter  ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html

It looks like, still compiling. In the meantime I changed this in the same way,
as the error message clearly showed that there is both a dynamic and a static
declaration present. I'm waiting for the build to complete and report back.

[Bug bootstrap/96541] Bootstrap fails on Daerwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Sorry, this is a duplicate of #96540.

[Bug middle-end/96549] [10/11 Regression] Wrong evaluation of a comparison between long & short

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-10
 Ever confirmed|0   |1
Summary|Wrong evaluation of a   |[10/11 Regression] Wrong
   |comparison between long &   |evaluation of a comparison
   |short   |between long & short
   Target Milestone|--- |10.3
 Status|UNCONFIRMED |NEW

[Bug middle-end/96549] Wrong evaluation of a comparison between long & short

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[10/11 Regression] Wrong|Wrong evaluation of a
   |evaluation of a comparison  |comparison between long &
   |between long & short|short
   Keywords||wrong-code
 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0
  Component|c   |middle-end
   Last reconfirmed|2020-08-10 00:00:00 |

[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
I'm testing patch like

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b24a4557871..269c528c3ad 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -19132,15 +19132,15 @@

   /* Compare through substraction the saved and the current ssp to decide
 if ssp has to be adjusted.  */
-  tmp = gen_rtx_SET (reg_ssp, gen_rtx_MINUS (word_mode, reg_ssp,
-ssp_slot));
-  clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
-  tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
-  emit_insn (tmp);
+  emit_insn ((word_mode == SImode)
+ ? gen_subsi3 (reg_ssp, reg_ssp, ssp_slot)
+ : gen_subdi3 (reg_ssp, reg_ssp, ssp_slot));
+  tmp = gen_rtx_COMPARE (CCZmode, reg_ssp, const0_rtx);
+  flags = gen_rtx_REG (CCZmode, FLAGS_REG);
+  emit_insn (gen_rtx_SET (flags, tmp));

   /* Compare and jump over adjustment code.  */
   noadj_label = gen_label_rtx ();
-  flags = gen_rtx_REG (CCZmode, FLAGS_REG);
   tmp = gen_rtx_EQ (VOIDmode, flags, const0_rtx);
   tmp = gen_rtx_IF_THEN_ELSE (VOIDmode, tmp,
  gen_rtx_LABEL_REF (VOIDmode, noadj_label),
@@ -19184,14 +19184,10 @@
   emit_insn ((word_mode == SImode)
 ? gen_incsspsi (reg_255)
 : gen_incsspdi (reg_255));
-  tmp = gen_rtx_SET (reg_adj, gen_rtx_MINUS (ptr_mode,
-reg_adj,
-GEN_INT (255)));
-  clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
-  tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
-  emit_insn (tmp);
-
-  tmp = gen_rtx_COMPARE (CCmode, reg_adj, GEN_INT (255));
+  emit_insn ((ptr_mode == SImode)
+ ? gen_subsi3 (reg_adj, reg_adj, GEN_INT (255))
+ : gen_subdi3 (reg_adj, reg_adj, GEN_INT (255)));
+  tmp = gen_rtx_COMPARE (CCmode, reg_adj, const0_rtx);
   flags = gen_rtx_REG (CCmode, FLAGS_REG);
   emit_insn (gen_rtx_SET (flags, tmp));

[Bug bootstrap/96541] Bootstrap fails on Daerwin 19.6.0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Liška  ---
Dup.

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

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
*** Bug 96541 has been marked as a duplicate of this bug. ***

[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Hongtao.liu from comment #1)
> I'm testing patch like

You can probably use gen_sub2_insn here.

On a related note, "@" prefix can be used for rdssp, so one can pass mode to an
expander. This would eliminate e.g. "(word_mode == SImode) ? gen_rdsspsi
(reg_ssp) : gen_rdsspdi (reg_ssp)" constructs with just one call to the
expander.

[Bug middle-end/96549] [10/11 Regression] Wrong evaluation of a comparison between long & short

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug middle-end/96549] [10/11 Regression] Wrong evaluation of a comparison between long & short

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug libstdc++/90704] filesystem::path overloads for file streams are not conforming

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
FWIW I opened https://cplusplus.github.io/LWG/issue3430 to say string_view
should be usable directly.

It makes absolutely no sense for construction from a string_view to convert to
filesystem::path just to add a null terminator to the end. It's not even clear
that we want implicit conversion from string_view to work.

[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Hongtao.liu from comment #1)
> > I'm testing patch like
> 
> You can probably use gen_sub2_insn here.
> 
> On a related note, "@" prefix can be used for rdssp, so one can pass mode to
> an expander. This would eliminate e.g. "(word_mode == SImode) ? gen_rdsspsi
> (reg_ssp) : gen_rdsspdi (reg_ssp)" constructs with just one call to the
> expander.

Yes, thanks for pointing out.

[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
Summary|filesystem::path overloads  |[LWG 3430] filesystem::path
   |for file streams are not|overloads for file streams
   |conforming  |are not conforming

--- Comment #4 from Jonathan Wakely  ---
I think I'm going to suspend this until the committee expresses a preferred
direction for the issue.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
unsigned char
foo (unsigned int x)
{
  _Bool y = x;
  return (((unsigned char) ~0) >> y) * 2;
}

unsigned char
bar (unsigned int x)
{
  return (((unsigned char) ~0) >> (_Bool) x) * 2;
}

In bar, this is optimized, because fold_binary_op_with_conditional_arg
optimizes
255 >> (x ? 1 : 0) into x ? 127 : 255 and when multiplied by two in unsigned
char this results in x ? 254 : 254.
We don't have anything comparable in match.pd yet I believe (and should we?).
Or shall say VRP try harder if it sees [0, 1] ranges?
Though, shouldn't we optimize e.g.
unsigned
baz (unsigned int x)
{
  if (x >= 4) return 32;
  return (-1U >> x) * 16;
}
too to return x >= 4 ? 32U : -16U; ?
Not sure where and how to generalize it though.
Value range of -1U >> [0, 3] is not really useful here, nonzero bits either.
And having a specialized (const1 >> x) * const2 optimizer based on x's value
range would work, but not sure if it has a real-world benefit.

[Bug c++/92139] Segmentation fault on constraints verification

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
OK closed, thanks.

[Bug c++/96543] null check on template pointer parameter fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-10
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is only a warning. Please use -Werror to report bugs about warnings.

It's only an error because you asked GCC to make it an error.

[Bug c++/96537] Missing std::pair constructor

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
FWIW the change was implemented for GCC 6.0 by r225189

[Bug c++/96537] Missing std::pair constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #2 from Jonathan Wakely  ---
Not a bug. C++11 and C++14 said for the relevant pair(U&&, V&&) constructor:

Remarks: If U is not implicitly convertible to first_type or V is not
implicitly convertible to second_type this constructor shall not participate in
overload resolution.

That was changed for C++17 by http://wg21.link/n4387 which was accepted into
the C++17 draft in 2015, so you can't expect C++11 compilers released before
then to support the new API.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #1)
> In bar, this is optimized, because fold_binary_op_with_conditional_arg
> optimizes
> 255 >> (x ? 1 : 0) into x ? 127 : 255 and when multiplied by two in unsigned
> char this results in x ? 254 : 254.
> We don't have anything comparable in match.pd yet I believe (and should we?).

We have something for VEC_COND_EXPR to fold a op (b?c:d), but not for
COND_EXPR, which you would be unlikely to see in gimple (and the generator of
phiopt transforms from match.pd patterns hasn't appeared yet). Also, we only
have x!=0, and while fold_binary_op_with_conditional_arg tries to handle it
like x!=0?1:0, we indeed don't do anything like that for gimple. And it seems
possibly better suited to forward propagation than backward like match.pd.

> Or shall say VRP try harder if it sees [0, 1] ranges?

If a range has only 2 (or some other small number) values, try propagating each
and see if some variables end up with the same value in both cases? Or if
enough simplifications occur that it is worth introducing a conditional? I am
not sure it would be worth the trouble.

> Though, shouldn't we optimize e.g.
> unsigned
> baz (unsigned int x)
> {
>   if (x >= 4) return 32;
>   return (-1U >> x) * 16;
> }
> too to return x >= 4 ? 32U : -16U; ?
> Not sure where and how to generalize it though.
> Value range of -1U >> [0, 3] is not really useful here, nonzero bits either.
> And having a specialized (const1 >> x) * const2 optimizer based on x's value
> range would work, but not sure if it has a real-world benefit.

And here this is complicated by the fact that we do not narrow the operation,
so it is less obvious that the constant is -1.

[Bug c++/96537] Missing std::pair constructor

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Tom de Vries from comment #0)
>   std::unordered_map> m;
>   m.emplace (1, new A(1));

This code isn't exception-safe anyway. If allocating a new node in the map
throws an exception your pointer will be leaked.

This will compile on old C++11 compilers *and* be correct:

  m.emplace (1, std::unique_ptr(new A(1)));

For C++14 you should use std::make_unique(1) instead.

[Bug c++/96537] Missing std::pair constructor

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Jonathan Wakely from comment #2)
> Not a bug. C++11 and C++14 said for the relevant pair(U&&, V&&) constructor:
> 
> Remarks: If U is not implicitly convertible to first_type or V is not
> implicitly convertible to second_type this constructor shall not participate
> in overload resolution.
> 
> That was changed for C++17 by http://wg21.link/n4387 which was accepted into
> the C++17 draft in 2015, so you can't expect C++11 compilers released before
> then to support the new API.

Thanks for the comment.  Still, if this is a language version issue, I used
-std=c++11 with 7.5.0, shouldn't I then get the same behaviour as with gcc
4.8.5?

[Bug target/96454] [11 Regression] wrong code with -Og -march=cascadelake since r11-1445

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on master with r10-7054-g5358e8f5800daa00.

[Bug c++/96537] Missing std::pair constructor

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Tom de Vries from comment #4)
> Thanks for the comment.  Still, if this is a language version issue, I used
> -std=c++11 with 7.5.0, shouldn't I then get the same behaviour as with gcc
> 4.8.5?

No, because N4387 was resolving a number of DRs so we apply it retroactively to
older standard modes. But for compilers released before the defects were
resolved, obviously we only implement the old rules.

The point is that GCC 4.8 is a compiler from 2013 and correctly implements the
spec from that time.

[Bug c++/96537] Missing std::pair constructor

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
... warts and all.

[Bug tree-optimization/96466] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:122 with -Og -finline-functions-called-once -fno-tree-ccp

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Started with my r11-1445-g502d63b6d6141597.

[Bug target/96453] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:167 with -Og -fno-early-inlining -fno-tree-ccp -mavx -mno-sse4.2

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Started with my r11-1445-g502d63b6d6141597.

[Bug c/96545] ICE in get_atomic_generic_size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com

--- Comment #3 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #2)
> > Or shall say VRP try harder if it sees [0, 1] ranges?
> 
> If a range has only 2 (or some other small number) values, try propagating
> each and see if some variables end up with the same value in both cases?

Maybe.  The question is if it should be done in forwprop, or say vrp or in the
ranger code (does that one do forward propagation)?
In any case, it should be limited to ranges with small number of values
(perhaps decided with a param) and also bound on how many immediate use stmts
it attempts to propagate it through.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
As for COND_EXPR, if we do it that way, it should be rather keyed on a range
with only two possible values in the range.

[Bug tree-optimization/95433] Failure to completely optimize simple compare after operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

https://gcc.gnu.org/g:287522613d661b4c5ba8403b051eb470c1674cba

commit r11-2629-g287522613d661b4c5ba8403b051eb470c1674cba
Author: Marc Glisse 
Date:   Mon Aug 10 12:50:42 2020 +0200

Simplify X * C1 == C2 with wrapping overflow

Odd numbers are invertible in Z / 2^n Z, so X * C1 == C2 can be rewritten
as X == C2 * inv(C1) when overflow wraps.

mod_inv should probably be updated to better match the other wide_int
functions, but that's a separate issue.

2020-08-10  Marc Glisse  

PR tree-optimization/95433
* match.pd (X * C1 == C2): Handle wrapping overflow.
* expr.c (maybe_optimize_mod_cmp): Qualify call to mod_inv.
(mod_inv): Move...
* wide-int.cc (mod_inv): ... here.
* wide-int.h (mod_inv): Declare it.

* gcc.dg/tree-ssa/pr95433-2.c: New file.

[Bug target/95235] Failure to properly optimize out register use in bit-twiddling code

[gabravier at gmail dot com]

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

Gabriel Ravier  changed:

   What|Removed |Added

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

--- Comment #2 from Gabriel Ravier  ---
Just rechecked and it looks like it was fixed at some point since I filed this
bug report.

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-8600-gb5cc5c95664347082100a504710f5ca0467306a5
Author: Jonathan Wakely 
Date:   Mon Aug 10 12:04:27 2020 +0100

libstdc++: Use _wstat64 for Windows [PR 95749]

In order to handle large files on Windows we need to use stat API with
64-bit st_size member.

libstdc++-v3/ChangeLog:

PR libstdc++/95749
* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(stat_type): Change to __stat64.
(stat): Use _wstat64.

(cherry picked from commit 9939be5758b52ed2fe1a7e56b94ce6d0f4d81580)

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-8800-gcaac3ee7008286404323c4aa93ee0e1c4753c4c2
Author: Jonathan Wakely 
Date:   Mon Aug 10 11:10:26 2020 +0100

libstdc++: Use _wstat64 for Windows [PR 95749]

In order to handle large files on Windows we need to use stat API with
64-bit st_size member.

libstdc++-v3/ChangeLog:

PR libstdc++/95749
* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(stat_type): Change to __stat64.
(stat): Use _wstat64.

(cherry picked from commit 9939be5758b52ed2fe1a7e56b94ce6d0f4d81580)

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.4 and 10.3, thanks for the report.

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Also fixed on master by g:9939be5758b52ed2fe1a7e56b94ce6d0f4d81580 but I'm not
sure why that didn't get added here.

[Bug c/96550] New: gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

Bug ID: 96550
   Summary: gcc is smart in figuring out a non-returning function.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.E.Wolff at BitWizard dot nl
  Target Milestone: ---

This is the small probgram that reproduces this: 
---
#include 

#define FAIL

struct test {
#ifdef FAIL
  char *t;
#else
  char t[8];
#endif
} ; 

extern void somefunc (struct test *t);

void myfunc (void) 
{
  struct test mt;
  memset (&mt, 0, sizeof (mt));
  mt.t[0] = 1;
  somefunc (&mt);
}
---
Here the struct was defined in another part of the code, and I'd guessed
(wrong) that the declaration was like in the FALSE branch of the IFDEF. As it
turns out the declaration was different. 

So what happens is that the compiler decides that I set the pointer to zero,
and that the assignment through that pointer WILL fail. 

So the generated assembly starts with: 
---
myfunc:
@ Function supports interworking.
@ Volatile: function does not return.
---

So... without saying anything the compiler decided that my function will never
return. It might be right about that (That's not true: This is on an embedded
system and I can map RAM to address zero!) but then IMHO, a warning would be
warranted. A function goes from not being declared volatile by me to being
volatile (not returning). 

It's perfectly legal C code in there, but might not be what the user wanted
Just like if (a = 3) ... I think a warning might be issued. 

Reproduced on: gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516
not reproduced on: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
reproduced on (originally ran into): arm-none-eabi-gcc (GNU Arm Embedded
Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Does -fno-delete-null-pointer-checks help?

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
If FAIL is defined, your myfunc will always trigger undefined behavior if
called, and as such anything can happen.
Derefencing NULL is UB.
If you are on an embedded system where there is memory mapped, you can use
-fno-delete-null-pointer-checks (for some embedded targets it is even the
default).

[Bug libstdc++/93904] LWG 561 not implemented: std::inserter overly generic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed in r11-2632

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Roger Wolff from comment #0)
> So... without saying anything the compiler decided that my function will
> never return. It might be right about that (That's not true: This is on an
> embedded system and I can map RAM to address zero!) but then IMHO, a warning
> would be warranted. A function goes from not being declared volatile by me
> to being volatile (not returning). 
> 
> It's perfectly legal C code in there, but might not be what the user
> wanted Just like if (a = 3) ... I think a warning might be issued. 

GCC *does* warn:

null.c: In function ‘myfunc’:
null.c:19:11: warning: null pointer dereference [-Wnull-dereference]
   19 |   mt.t[0] = 1;
  |   ^~~

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |9.3.1

--- Comment #4 from Jonathan Wakely  ---
And if you read the manual for the -Wnull-dereference warning you'll see it
also mentions -fdelete-null-pointer-checks, and if you read about that you
should find the solution you need.

[Bug target/96453] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:167 with -Og -fno-early-inlining -fno-tree-ccp -mavx -mno-sse4.2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
So the problem here is that we newly meet:

  _5 = { -1, -1 };
  _6 = VEC_COND_EXPR <_5, { -1, -1 }, { 0, 0 }>;

which we before the revision removed in copyprop6.

[Bug tree-optimization/96466] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:122 with -Og -finline-functions-called-once -fno-tree-ccp

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
It's the same store as PR96453: copyprop can eliminate that to:

Folding statement: _3 = { 5 };
Queued stmt for removal.  Folds to: { 5 }
Folding statement: _4 = VEC_COND_EXPR <_3 > { 4441221374 }, { -1 }, { 0 }>;
gimple_simplified to _4 = { 0 };
Folded into: _4 = { 0 };

@Richi: Can we teach copyprop to fold constant expressions for VEC_COND_EXPRs
that have first argument equal to a constant?

[Bug rtl-optimization/96539] Unnecessary no-op copy with Os and tail call with struct argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  At GIMPLE we already optimize away memmove etc. calls with the
same destination as source, but for the arguments copying this didn't get
through GIMPLE memmove call, so the patch just does nothing at the RTL level
too.  For -O2 the copying was expanded piecewise and as such was later
optimized away when the generic code seed noop copying.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #5 from Roger Wolff  ---
Guys, The compiler found a bug in my code, but it didn't tell me. Like the if
(a = 3) situation, the compiler is correct when it compiles the code according
to the C rules. 

I like to compile my code with -Wall for this reason: 99% of the cases, the
compiler will find and warn about stupid stuff that's not a problem. But in
that 1% of the cases, the compiler will warn about something that's a bug that
would've taken lots of time to find.  SO when you get that one warning, you
have the compiler telling you: You have a bug on line X of your program. 

That's what could've happened here: I had a bug in my code, but didn't expect
the binary to suddenly go from 75k to 14k because of a bug.

Something like: 
Line 18: dereferencing NULL pointer is undefined behaviour. Assuming execution
stops here. 

would be a usable error message. 

This is actually one of those 1% of the cases where the warning COULD have been
given and finding the bug would've been seconds whereas without the warning
lots of time was wasted looking for the bug in the wrong places. 

This is not a bug per se, you can suggest workarounds for: "What if you want to
store stuff at address zero" all you want, but I had a bug and I've asked gcc
to issue warnings where I'm doing fishy stuff that might be a bug. And I didn't
get that warning. 

So this issue is not a bug in that the wrong code is generated, but an
enhancement request: Please issue that warning. 

All this is "not for me": I've now run into this issue, the bug in my project
has been fixed and for me it's on to the rest of the code. And I've been
subjected to this "way of gcc telling me there is a bug", so in the future, if
I make this mistake again, I'll not spend as much time on it as I did this
weekend. 

So I'm trying to make things easier for those others that might run into this
in the future.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #6 from Roger Wolff  ---
So, I've added "-Wall" to my Makefile to get ALL warnings, giving me the
biggest chance of finding bugs through the compiler telling me you have a bug
on line X of file Y. 

So IMHO -Wnull-dereference should be part of -Wall. I'm not a compiler guy. I
just use the stuff. So now the question becomes: Why is that warning not part
of -Wall ?

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The compiler can't diagnose this as an error (unless -Werror* is used), because
it is only an error if such code is ever called at runtime, which the compiler
can't determine at compile time.
That is why it is just a warning.
And, as an optimizing compiler, the compiler can and does optimize anything
that would be only reachable through that statement with UB.
This isn't an attempt to punish those who write broken code, but it actually
helps a lot in real-world code, something like that can happen frequently, but
usually in code that will not be actually encountered at runtime, just the
compiler can't prove that.

[Bug c++/96552] New: GCC accepts "alignas(auto)" in function parameter list

[haoxintu at gmail dot com]

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

Bug ID: 96552
   Summary: GCC accepts "alignas(auto)" in function parameter list
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

Following code is invalid I think, the "alignas" shouldn't be in function
parameter. I guess GCC only finds a "auto" in function parameter list rather
than "alignas(auto)", also "alignas(auto)" itself is invalid.

Code:
class Test{
Test &operator || (alignas(auto) int);
};

While Clang says "error: 'auto' not allowed here".

Every version from GCC-6.1 upwards behaves the same.

Thanks,
Haoxin

[Bug target/96551] New: [10 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)

[hjl.tools at gmail dot com]

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

Bug ID: 96551
   Summary: [10 Regression] FAIL: gcc.target/i386/vectorize8.c
(internal compiler error)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: crazylht at gmail dot com
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86_64

ommit f098bc87dcae5646d11a351cfb55d0e1124c7f60
Author: liuhongt 
Date:   Mon Jul 20 10:13:58 2020 +0800

Using UNSPEC for vector compare to mask register.

For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
boolean value and try to do some optimization. But it is not true for
vector compare, also other places in rtl passes hold the same
assumption.

caused:

FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]16[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]16[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]16[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]32[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]32[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]32[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]64[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]64[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]64[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]8[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]8[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]8[\t ] 6
FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)

with

$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/vectorize8.c --target_board='unix{-m64\
-march=cascadelake,-m32\ -march=cascadelake}'"

[Bug c++/96553] New: ICE in unexpected expression ‘__alignof__ (auto:1)’ of kind alignof_expr

[haoxintu at gmail dot com]

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

Bug ID: 96553
   Summary: ICE in unexpected expression ‘__alignof__ (auto:1)’ of
kind alignof_expr
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, reduced by C-Vise, makes GCC-trunk ICE and released versions
"confused by earlier errors, bailing out".

Input:
//small.cc
class Test{
Test &operator || ( alignas (auto) enum{});
};

Command:
g++ small.cc

Output:
small.cc:2:34: warning: use of ‘auto’ in parameter declaration only available
with ‘-fconcepts-ts’
2 | Test &operator || ( alignas (auto) enum{});
  |  ^~~~
small.cc:2:40: error: types may not be defined in parameter types
2 | Test &operator || ( alignas (auto) enum{});
  |^~~~
small.cc:2:45: internal compiler error: unexpected expression ‘__alignof__
(auto:1)’ of kind alignof_expr
2 | Test &operator || ( alignas (auto) enum{});
  | ^
0x8e014c cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6567
0x8e068f cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6772
0x8e4aab maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7045
0x95075b cp_check_const_attributes(tree_node*)
../../gcc/cp/decl2.c:1428
0x955b72 cp_check_const_attributes(tree_node*)
../../gcc/cp/decl2.c:1416
0x955b72 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.c:1584
0x9f27a4 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22725
0x9f2b21 cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22622
0x9df4f1 cp_parser_direct_declarator
../../gcc/cp/parser.c:21299
0x9df4f1 cp_parser_declarator
../../gcc/cp/parser.c:21163
0x9df045 cp_parser_declarator
../../gcc/cp/parser.c:21141
0x9fe4ce cp_parser_member_declaration
../../gcc/cp/parser.c:25291
0x9d0ea8 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24904
0x9d0ea8 cp_parser_class_specifier_1
../../gcc/cp/parser.c:24001
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0xa002fe cp_parser_declaration
../../gcc/cp/parser.c:13510
0xa009db cp_parser_translation_unit
../../gcc/cp/parser.c:4793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

My GCC version is updated on 2020-08-08.

Thanks,
Haoxin

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:90f7636bf8df50940e0f749af60a6b374a8f09b4

commit r11-2633-g90f7636bf8df50940e0f749af60a6b374a8f09b4
Author: Jonathan Wakely 
Date:   Mon Aug 10 13:21:59 2020 +0100

libstdc++: Make C++17 ignore --disable-libstdcxx-filesystem-ts [PR 94681]

The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.

libstdc++-v3/ChangeLog:

PR libstdc++/94681
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
$enable_libstdcxx_filesystem_ts.
* configure: Regenerate.

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Only fixed on master so far.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #8 from Roger Wolff  ---
Please, start to read what is written. Please.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Roger Wolff from comment #6)
> So, I've added "-Wall" to my Makefile to get ALL warnings,

It doesn't enable ALL warnings, as documented in the manual.

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html

Yes, with that fix (as anticipated by you) build and bootstrap work.

[Bug c/96554] New: -Wall does not include -Wnull-dereference

[R.E.Wolff at BitWizard dot nl]

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

Bug ID: 96554
   Summary: -Wall does not include -Wnull-dereference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.E.Wolff at BitWizard dot nl
  Target Milestone: ---

As reported in c/96550, the fact that -Wall didn't include -Wnull-dereference
cost me a lot of time in trying to figure out what the problem was with my
code. 

I add -Wall to get lots of warnings about potential bugs. if (a = 3) is an
example where a simple typo in the code leads to perfectly valid C, but such a
"high likelyhood of a bug" that a warning is warranted. 

Same here: I wrote a bug that caused the compiler to a) not warn me and b) do
unexpected things. I think the -Wnull-dreference is a valid warning to enable
with -Wall.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #10 from Roger Wolff  ---
Technically correct.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #11 from Roger Wolff  ---
Just FYI: I added  -Wnull-dereference to my makefile of my real project. It
doesn't trigger a warning in my project when I revert to the buggy code. The
compiler does detect and act upon the null dereference.

[Bug testsuite/96519] [11 regression] new test case gcc.dg/ia64-sync-5.c fails

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
   ||aarch64 arm
 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
Seen also on aarch64 and arm

[Bug c/96554] -Wall does not include -Wnull-dereference

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This warning is intentionally not enabled at -Wall, because it has too many
false positives (technically correct warnings, but about dead code).
See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351#c35

[Bug c++/96543] null check on template pointer parameter fails

[vlad at petric dot cc]

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

--- Comment #2 from Vlad Petric  ---
Got it, should I refile/change this bug?

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

Roger Wolff  changed:

   What|Removed |Added

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

--- Comment #12 from Roger Wolff  ---
better description in: 96554

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #8 from Aldy Hernandez  ---
Fixed upstream.

[Bug c/96554] -Wall does not include -Wnull-dereference

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #2 from Roger Wolff  ---
In my case it promotes a function I didn't declare as  into
one that  and thereby it caused 80% of my code to become
"dead". It'd be nice to differentiate between the case where a simple
optimization removes a few lines of code due to an extra null-check not being
reachable due to the trap  on the null dereference and the case where big
unexpected things start happening. 

Maybe the promotion of a function from "does return" to "does not return" is
something you might warn about. This satisfies the "you can easily modify the
code to silence the warning".

[Bug c/96554] -Wall does not include -Wnull-dereference

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

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

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

[Bug c/96550] gcc is smart in figuring out a non-returning function.

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #13 from Andreas Schwab  ---


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

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Roger Wolff from comment #11)
> Just FYI: I added  -Wnull-dereference to my makefile of my real project. It
> doesn't trigger a warning in my project when I revert to the buggy code. The
> compiler does detect and act upon the null dereference.

It will only warn when optimisations are performed, including the
-fdelete-null-pointer-checks optimisation. I would expect it to either not act
on the null dereference, or act and warn.

Please don't change status to FIXED when nothing was changed in GCC, let alone
fixed.

[Bug c/96554] -Wall does not include -Wnull-dereference

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #4 from Roger Wolff  ---
Update: LTO messes with the warning. When LTO is enabled, the warning from
-Wnull-dreference is suppressed.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #15 from Roger Wolff  ---
I marked it as "resolved', the system then told me to type a message and I did,
but then it had added the "FIXED" tag. Not my idea.

[Bug tree-optimization/96548] [11 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 since r11-2574-g6aec53ee4f75a64c

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Here is another test case which demonstrates the fault:

int a, b, c, e;
int *d;
void f() {
  if (0) {
for (; b;) {
  c = f;
g:
  for (; e;)
;
}
c |= a ?: 1;
if (*d)
  d = e;
  }
  goto g;
}

Flag -O2 required.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> AFAICT, from the point of view of the PTX isa, there's no reason why we
> couldn't support this.
> 
> So, unless a testsuite run points to some problem, we should enable the
> sync_int_long for nvptx.

Well, I found a problem with test-case gcc/testsuite/gcc.dg/pr86314.c.

There we try to do an atomic insn on stack, and since stack is implemented as
.local, and the atom insn is not supported for .local, we run into:
...
 nvptx-run: error getting kernel result: operation not supported on
global/shared address space
...

Something like this would work:
...
$ git diff
diff --git a/gcc/testsuite/gcc.dg/pr86314.c b/gcc/testsuite/gcc.dg/pr86314.c
index 8962a3cf2ff..565fb02eee2 100644
--- a/gcc/testsuite/gcc.dg/pr86314.c
+++ b/gcc/testsuite/gcc.dg/pr86314.c
@@ -1,5 +1,5 @@
 // PR target/86314
-// { dg-do run { target sync_int_long } }
+// { dg-do run { target sync_int_long_stack } }
 // { dg-options "-O2" }

 __attribute__((noinline, noclone)) unsigned long
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index e79015b4d54..a870b1de275 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7704,7 +7704,16 @@ proc check_effective_target_sync_int_long { } {
 || [istarget cris-*-*]
 || ([istarget sparc*-*-*] && [check_effective_target_sparc_v9])
 || ([istarget arc*-*-*] && [check_effective_target_arc_atomic])
-|| [check_effective_target_mips_llsc] }}]
+|| [check_effective_target_mips_llsc]
+|| [istarget nvptx*-*-*]
+}}]
+}
+
+proc check_effective_target_sync_int_long_stack { } {
+return [check_cached_effective_target sync_int_long_stack {
+  expr { ![istarget nvptx*-*-*]
+&& [check_effective_target_sync_int_long]   
+}}]
 }

 # Return 1 if the target supports atomic operations on "char" and "short".
...

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
FTR, we could fix this by just mapping onto a nonatomic insn for .local (and
I'm not really sure why ptx doesn't).

But since we have generic pointers, we only known runtime whether something is
local (using isspacep), so that while that will help the standalone target be
more generic, it'll possibly make the offloading target slower and larger.

[Bug target/83812] nvptx-run: error getting kernel result: operation not supported on global/shared address space

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
See PR 96494.

[Bug c++/96523] variable templates of constant types have incorrect linkage

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[amacleod at redhat dot com]

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

--- Comment #5 from Andrew Macleod  ---
I think this all goes away when multi-range is enabled.

The original testcase produces:
=== BB 2 
x_4(D)  unsigned int VARYING
 :
tmp_5 = x_4(D) != 0;
_1 = (int) tmp_5;
_2 = 255 >> _1;
_3 = (unsigned char) _2;
_6 = _3 * 2;
return _6;

_1 : int [0, 1]
_2 : int [127, 255]
_3 : unsigned char [127, +INF]


A number of the range-ops routines are simply inherited from the single range
codebase of value_range, and are not multi-range enabled yet.

In particular, rshift here.   with a tweak to operator_rshift, we can take

255 >> [0,1] and instead calculate 
_2 = [127,127][255,255]
which would make the results:

_1 : int [0, 1]
_2 : int [127, 127][255, 255]
_3 : unsigned char [127, 127] [255, 255]

Then when _6 is calculated as [127, 127][255, 255] * 2 , range-ops will
calculate the result to be [254, 254]


The whole thing will just fold away to return 254  (or -2 if you want to sign
it :-)

All we need to do is get the multi-range code enabled it's coming.

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523

[yevh.kolesnikov at gmail dot com]

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

--- Comment #5 from Yevhenii Kolesnikov  ---
(In reply to Martin Liška from comment #3)
> Thank you for the report, I can take a look.
> Can you please provide steps how to build Mesa with -O3 and -flto?

mesa is configured with meson. LTO can be enabled with builtin option
-b_lto=true. Options can be supplied to the compiler with -Dc_args and
-Dcpp_args. So, to enable O3 it's -Dc_args="-O3" -Dcpp_args="-O3". You'll also
need to set -Dbuildtype=plain, or otherwise these options will be overwritten. 

So, the full build process will look like this:

meson \
-Dbuildtype=plain \
-Dvalgrind=false \
-Ddri-drivers=i965 \
-Dgallium-drivers=iris,swrast \
-Dvulkan-drivers= \
-Dgallium-omx="disabled" \
-Dplatforms=x11,drm,surfaceless \
-Dllvm=false \
-Db_lto=true \
-Dc_args="-g \
  -O3 \
  " \
-Dcpp_args="-g \
-O3 \
" \
--prefix=~/builds/mesa-bug \
./mesa-bug

ninja -C ./mesa-bug install

The aforementioned functions and assembly code then will be in
~/builds/mesa-bug/lib/dri/iris_dri.so

> About the addr_to_index function: am I right that unreachable is defined in
> your configuration as __builtin_unreachable?

To be precise, unreachable is defined like this:

#define unreachable(str)\
do {\
   assert(!str);\
   __builtin_unreachable(); \
} while (0)

I'm not sure why this one-time loop is necessary, to be honest.

> Can you please replace it with fprintf that prints the value?

The value of addr_format? It doesn't print anything, since this branch is never
hit. Moreover, it prevents addr_to_index from being inlined, so the crash goes
away. The value of addr_format in my case is 3, which corresponds to the
nir_address_format_32bit_index_offset enum. So, in my case, the first branch is
always hit.

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
The commit r11-2633 broke the build of libstdc++ on aarch64-none-elf. My build
logs say:
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
In function 'std::filesystem::__cxx11::path std::filesystem::read_symlink(const
std::filesystem::__cxx11::path&, std::error_code&)':
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1178:9:
error: '::lstat' has not been declared; did you mean
'std::filesystem::__gnu_posix::lstat'?
 1178 |   if (::lstat(p.c_str(), &st))
  | ^
  | std::filesystem::__gnu_posix::lstat
In file included from
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:58:
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:131:14:
note: 'std::filesystem::__gnu_posix::lstat' declared here
  131 |   inline int lstat(const char* path, stat_type* buffer)
  |  ^
make[5]: *** [Makefile:572: fs_ops.lo] Error 1
make[5]: Leaving directory
'/tmp/7968837_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/src/c++17'
make[4]: *** [Makefile:732: all-recursive] Error 1

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod  ---
Likewise, for

unsigned
baz (unsigned int x)
{
  if (x >= 4) return 32;
  return (-1U >> x) * 16;
}


=== BB 2 
x_3(D)  unsigned int VARYING
_4  UNDEFINED
 :
if (x_3(D) > 3)
  goto ; [INV]
else
  goto ; [INV]

2->3  (T) x_3(D) :  unsigned int [4, +INF]
2->4  (F) x_3(D) :  unsigned int [0, 3]

=== BB 3 
_4  UNDEFINED
 :
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]


=== BB 4 
x_3(D)  unsigned int [0, 3]
 :
_1 = 4294967295 >> x_3(D);
_4 = _1 * 16;
_1 : unsigned int [536870911, +INF]

0x >> [0,3] is currently producing [0x2FFF, 0x]

again making operator_rshift capable of generating multi-ranges,

0x >> [0,3] should produce
[0x2FFF, 0x2FFF][0x4FFF, 0x4FFF][0x8FFF,
0x8FFF][0x, 0x] 

and then _4 = _1 *16 should automatically produce: [0xFFF0, 0xFFF0]
I think multiply does that today, if its given the proper input.




=== BB 5 
_4  unsigned int VARYING
 :
# _2 = PHI <32(3), _4(4)>
return _2;

And then this PHI will have the constant propagated and become:
# _2 = PHI <32(3), 0xFFF0(4)>
return _2

ANd given that, presumably phi-opt or maybe even VRPs simplfication will turn
that into the desired conditional once the constant is calculated.

[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from vehre at gcc dot gnu.org ---
Patch at https://gcc.gnu.org/pipermail/fortran/2020-August/054865.html

Waiting for review.

[Bug c++/96555] New: "template argument involves template parameter(s)" with dot or arrow operator in partial specialization

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 96555
   Summary: "template argument involves template parameter(s)"
with dot or arrow operator in partial specialization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/Kc98ea
struct A { int x; };
extern A a;
template struct B {};
template
struct B {};


:5:8: error: template argument '(int)sizeof (a.x)' involves template
parameter(s)
5 | struct B {};
  |^


GCC seems to have a problem only with expressions involving the dot operator
(e.g. `sizeof(a.x)`) and the arrow operator (e.g. `sizeof(p->x)`), but not any
other operators, which leads me to believe that the root cause here is related
to the root cause of bug 96215.

Grepbait: template argument involves template parameters

Same error message in different situations, all involving partial
specializations but none involving dot or arrow specifically: bug 67593, bug
83426, bug 90099

[Bug fortran/96556] New: [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

Bug ID: 96556
   Summary: [11.0 regression] ICE via segmentation violation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The attached code (I will shorten the reproducer soon) gives the following ICE
below. The offending commit should have taken place between Sunday Aug 9 and
now:
gfortran  -c polarizations.f90
f951: internal compiler error: Segmentation fault
0xe01a4f crash_signal
../../gcc/toplev.c:327
0x8bc210 gfc_sym_get_dummy_args(gfc_symbol*)
../../gcc/fortran/symbol.c:5239
0x960d46 doloop_contained_function_call
../../gcc/fortran/frontend-passes.c:2336
0x965b75 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5188
0x968045 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5613
0x9699d0 doloop_code
../../gcc/fortran/frontend-passes.c:2619
0x967f79 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5298
0x9680df gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5621
0x9680df gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5621
0x9687f8 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5324
0x9680df gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5621
0x9690fb doloop_warn
../../gcc/fortran/frontend-passes.c:3051
0x969120 doloop_warn
../../gcc/fortran/frontend-passes.c:3056
0x9695fa gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:156
0x884d07 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17344
0x884d07 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17317
0x8777e1 gfc_parse_file()
../../gcc/fortran/parse.c:6488
0x8c90ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:71: recipe for target 'polarizations.o' failed

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Created attachment 49036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49036&action=edit
First reproducer

[Bug tree-optimization/96554] -Wall does not include -Wnull-dereference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2020-08-10
  Component|c   |tree-optimization
 Blocks||86172
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
The latest trunk of GCC 11 has over 700 distinct instances of the
-Wnull-dereference warning so some work is still needed before it can be
enabled in either -Wextra or -Wall.  Here's the breakdown:

DiagnosticCount   UniqueFiles
-Wnull-dereference 3862  713  168
-Wimplicit-fallthrough=   411
-Wstringop-truncation 311
-Wreturn-local-addr   211
-Wmaybe-uninitialized 222

-Wnull-dereference Instances:
  cc1plus: warning: potential null pointer dereference [-Wnull-dereference]
  /src/gcc/trunk/gcc/analyzer/checker-path.cc:737
  /src/gcc/trunk/gcc/analyzer/checker-path.cc:745
  /src/gcc/trunk/gcc/analyzer/checker-path.cc:958
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:339
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:456
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:777
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:778
  /src/gcc/trunk/gcc/analyzer/engine.cc:1844
  /src/gcc/trunk/gcc/analyzer/engine.cc:2683
  /src/gcc/trunk/gcc/analyzer/engine.cc:3570
  /src/gcc/trunk/gcc/analyzer/engine.cc:3656
  /src/gcc/trunk/gcc/analyzer/engine.cc:834
  /src/gcc/trunk/gcc/analyzer/exploded-graph.h:263
  /src/gcc/trunk/gcc/analyzer/program-point.h:225
  /src/gcc/trunk/gcc/analyzer/program-state.cc:134
  /src/gcc/trunk/gcc/analyzer/program-state.cc:241
  /src/gcc/trunk/gcc/analyzer/program-state.cc:266
  /src/gcc/trunk/gcc/analyzer/program-state.cc:267
  /src/gcc/trunk/gcc/analyzer/program-state.cc:472
  /src/gcc/trunk/gcc/analyzer/program-state.cc:473
  /src/gcc/trunk/gcc/analyzer/program-state.cc:488
  /src/gcc/trunk/gcc/analyzer/program-state.cc:489
  /src/gcc/trunk/gcc/analyzer/program-state.cc:514
  /src/gcc/trunk/gcc/analyzer/program-state.cc:584
  /src/gcc/trunk/gcc/analyzer/program-state.cc:585
  /src/gcc/trunk/gcc/analyzer/region-model.cc:1486
  /src/gcc/trunk/gcc/analyzer/region-model.cc:1571
  /src/gcc/trunk/gcc/analyzer/region-model.cc:2126
  /src/gcc/trunk/gcc/analyzer/region-model.cc:2606
  /src/gcc/trunk/gcc/analyzer/region-model.cc:424
  /src/gcc/trunk/gcc/analyzer/region-model.h:1195
  /src/gcc/trunk/gcc/analyzer/region-model.h:121
  /src/gcc/trunk/gcc/analyzer/region-model.h:129
  /src/gcc/trunk/gcc/analyzer/region-model.h:1583
  /src/gcc/trunk/gcc/analyzer/region-model.h:1587
  /src/gcc/trunk/gcc/analyzer/region-model.h:484
  /src/gcc/trunk/gcc/analyzer/region-model.h:869
  /src/gcc/trunk/gcc/analyzer/region-model.h:882
  /src/gcc/trunk/gcc/analyzer/region-model.h:912
  /src/gcc/trunk/gcc/analyzer/state-purge.h:95
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:177
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:198
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:221
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:240
  /src/gcc/trunk/gcc/analyzer/supergraph.h:106
  /src/gcc/trunk/gcc/analyzer/supergraph.h:126
  /src/gcc/trunk/gcc/analyzer/supergraph.h:132
  /src/gcc/trunk/gcc/analyzer/supergraph.h:138
  /src/gcc/trunk/gcc/analyzer/supergraph.h:144
  /src/gcc/trunk/gcc/analyzer/supergraph.h:163
  /src/gcc/trunk/gcc/auto-profile.c:1517
  /src/gcc/trunk/gcc/bb-reorder.c:467
  /src/gcc/trunk/gcc/bitmap.h:393
  /src/gcc/trunk/gcc/bitmap.h:532
  /src/gcc/trunk/gcc/bitmap.h:576
  /src/gcc/trunk/gcc/bitmap.h:579
  /src/gcc/trunk/gcc/caller-save.c:906
  /src/gcc/trunk/gcc/calls.c:1960
  /src/gcc/trunk/gcc/c/c-parser.c:4442
  /src/gcc/trunk/gcc/c-family/c-ada-spec.c:1905
  /src/gcc/trunk/gcc/c-family/c-attribs.c:3906
  /src/gcc/trunk/gcc/c-family/c-common.c:721
  /src/gcc/trunk/gcc/cfg.c:338
  /src/gcc/trunk/gcc/cfgcleanup.c:2143
  /src/gcc/trunk/gcc/cfgcleanup.c:2409
  /src/gcc/trunk/gcc/cfgloop.c:332
  /src/gcc/trunk/gcc/cfgloop.h:532
  /src/gcc/trunk/gcc/cfgloop.h:541
  /src/gcc/trunk/gcc/cfgrtl.c:1170
  /src/gcc/trunk/gcc/cfgrtl.c:4358
  /src/gcc/trunk/gcc/cfgrtl.c:443
  /src/gcc/trunk/gcc/cfgrtl.c:530
  /src/gcc/trunk/gcc/cgraphbuild.c:403
  /src/gcc/trunk/gcc/cgraph.c:1971
  /src/gcc/trunk/gcc/cgraph.c:2003
  /src/gcc/trunk/gcc/cgraph.c:3089
  /src/gcc/trunk/gcc/cgraph.c:3298
  /src/gcc/trunk/gcc/cgraph.c:3848
  /src/gcc/trunk/gcc/cgraph.c:3875
  /src/gcc/trunk/gcc/cgraphclones.c:186
  /src/gcc/trunk/gcc/cgraphclones.c:259
  /src/gcc/trunk/gcc/cgraph.h:1350
  /src/gcc/trunk/gcc/cgraph.h:1356
  /src/gcc/trunk/gcc/cgraph.h:2189
  /sr

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2635-g5c64df80df274c753bfc8415bd902e1180e76f6a
Author: Jakub Jelinek 
Date:   Mon Aug 10 17:53:46 2020 +0200

c++: Fix constexpr evaluation of SPACESHIP_EXPR [PR96497]

The following valid testcase is rejected, because
cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling genericize_spaceship which
turns
it into a TARGET_EXPR with initialization, we call
cxx_eval_constant_expression
on it which succeeds, but then we fall through into code that will
VERIFY_CONSTANT (r) which FAILs because it is an address of a variable. 
Rather
than avoiding that for lval = true and SPACESHIP_EXPR, the patch just tail
calls cxx_eval_constant_expression - I believe that call should perform all
the needed verifications.

2020-08-10  Jakub Jelinek  

PR c++/96497
* constexpr.c (cxx_eval_binary_expression): For SPACESHIP_EXPR,
tail
call cxx_eval_constant_expression after genericize_spaceship to
avoid
undesirable further VERIFY_CONSTANT.

* g++.dg/cpp2a/spaceship-constexpr3.C: New test.

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
Created attachment 49037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49037&action=edit
2nd reproducer, single file, shortening further

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Thanks, I thought this might reveal some new issues :-)

I'll fix it asap.

[Bug c++/96543] null check on template pointer parameter fails

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
No, it's fine. I've categorized it as a diagnostic bug, i.e. a bug in a
warning.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
When you choose RESOLVED you can pick various types of resolution, FIXED,
INVALID, DUPLICATE, MOVED, WORKSFORME etc.

[Bug c++/96557] New: Diagnostics: Can you tell me why it's not a constant expression?

[barry.revzin at gmail dot com]

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

Bug ID: 96557
   Summary: Diagnostics: Can you tell me why it's not a constant
expression?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider:

struct X {
char storage[100] = {};
char const* head = storage;
};

void f() {
constexpr X x = {};
}

gcc correctly rejects this with:

error: 'X{"", ((const char*)(& x.X::storage))}' is not a constant expression
7 | constexpr X x = {};
  |  ^

It'd be great if the error here actually indicated _why_ it's not a constant
expression (or how to fix it). clang does a little bit better:

:7:17: error: constexpr variable 'x' must be initialized by a constant
expression
constexpr X x = {};
^   ~~
:7:17: note: pointer to subobject of 'x' is not a constant expression
:7:17: note: declared here

But ideally we get some message about specifically 'head' pointing to 'storage'
and a fixup suggesting making the variable x static.

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Dominique d'Humieres  ---
The patch works as expected and even fixes pr91862.