[Bug c++/102739] compiler ICE when run libcxx's test

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-14

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source? That is required to file a bug.

[Bug c++/102739] New: compiler ICE when run libcxx's test

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 102739
   Summary: compiler ICE when run libcxx's test
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 51597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51597&action=edit
ice log

You can run libcxx's test by yourself

[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Martin Sebor from comment #3)
> It looks like it's just the the location of the warning that's off, the
> warning itself is still issued but it's swallowed by the dg-prune-output
> directive.
> 
> Since the test was added to verify the fix for an ICE without vectorization
> I think disabling vectorization should be fine.  Ideally, we would
> understand why the location is wrong so let's keep this bug open and add a
> comment to the test referencing this bug.

Add -fno-tree-vectorize and relative comments in r12-4386

[Bug tree-optimization/102738] Failure to optimize (signed) right shift if the range is already known to be [-1, 0]

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

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

--- Comment #2 from Andrew Pinski  ---
So this is interesting, I think clang/LLVM does this optimization late in their
pipeline take:
int a1(int f, int g)
{
if (f == 0 || f == 1)
return (f-1) >> g;
return 0;
}
They don't remove the shift at all.  But if you change return 0 to
__builtin_unreachable(), they remove the shift.

Anyways we should be able to do this optimization even in the above case.

And even here where clang/LLVM misses too:
int a1(int f, int g)
{
if (f == 6 || f == 7)
return (f-7) >> g;
__builtin_unreachable();
}

[Bug target/95740] Failure to avoid using the stack when interpreting a float as an integer when it is modified afterwards

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gabriel Ravier  ---
I've also encountered what looks like a duplicate of this bug, although I'm not
sure but it seems likely:

int foo(float f)
{
  union
  {
float f;
int i;
  } z = { .f = f };

  return z.i - 1;
}

Which outputs roughly the same assembly code as the initial test case.

[Bug tree-optimization/102738] Failure to optimize (signed) right shift if the range is already known to be [-1, 0]

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Failure to optimize right   |Failure to optimize
   |shift of 32-bit int after   |(signed) right shift if the
   |it's already been shifted   |range is already known to
   |by 31   |be [-1, 0]
   Severity|normal  |enhancement

[Bug tree-optimization/102738] Failure to optimize right shift of 32-bit int after it's already been shifted by 31

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-14
Summary|Failure to optimize right   |Failure to optimize right
   |shift of 128-bit value  |shift of 32-bit int after
   |after it's already been |it's already been shifted
   |shifted by 127  |by 31
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
GCC does not even do the int case:

int a(int f, int g)
{
return (f >> 31) >> g;
}


Actually this can be simplified down to this really (which clang does not
handle but handles a simular case; see below):
int a(int f, int g)
{
if (f == 0 || f == -1)
return f >> g;
__builtin_unreachable();
}

This should just return f here :).
Basically if GCC knows f is already 0 or -1, then f shifted by any value is
still f.

clang is able to handle this case though
int a1(int f, int g)
{
if (f == 0 || f == 1)
return (-f) >> g;
__builtin_unreachable();
}

[Bug tree-optimization/102738] New: Failure to optimize right shift of 128-bit value after it's already been shifted by 127

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102738
   Summary: Failure to optimize right shift of 128-bit value after
it's already been shifted by 127
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int a(__int128 f, int g)
{
return (f >> 127) >> g;
}

This can be optimized to `return f >> 127;`. This optimization is done by LLVM,
but not by GCC.

[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold

[arjan at linux dot intel.com via Gcc-bugs]

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

Arjan van de Ven  changed:

   What|Removed |Added

 CC||arjan at linux dot intel.com

--- Comment #6 from Arjan van de Ven  ---
the original bug was backported to the stable 11 branch...
.. should the fix be as well ?

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #3)
> A couple of data points: I see the same behavior for any constant address
> (not just null).  

Right because DSE does not compare MEM_ADDR_SPACE. It is literally a bug in
dse.c and there might be other places in the RTL side which misses out on
comparing MEM_ADDR_SPACE when it comes to memory accesses because it was an
after thought (and was originally added to support SPU memory accesses where a
function call would happen).

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

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

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

--- Comment #3 from Martin Sebor  ---
A couple of data points: I see the same behavior for any constant address (not
just null).  Clang 12 behaves the same as GCC, but Clang 13 emits both stores,
suggesting they fixed it as a bug:

  https://godbolt.org/z/xn7MWc4qn

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com,
   ||amacleod at redhat dot com

--- Comment #2 from Andrew Macleod  ---
works with  --disable-tree-vrp-thread1


Looking at the  .vrp-thread1 listing, I see a lot of

 Registering value_relation (_4 >= a.4_14) on (3->4)
 Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb4)
  [1] Registering jump thread: (4, 5) incoming edge;  (5, 7) joiner (7, 8)
normal (8, 9) nocopy;
 Registering value_relation (path_oracle) (iftmp.6_12 == iftmp.6_13) (bb6)
 Registering value_relation (path_oracle) (iftmp.6_12 == iftmp.6_13) (bb6)
  [2] Registering jump thread: (6, 7) incoming edge;  (7, 9) joiner;
 Registering value_relation (path_oracle) (iftmp.6_12 == iftmp.6_13) (bb6)
  [3] Registering jump thread: (6, 7) incoming edge;  (7, 8) joiner (8, 9)
nocopy;
 Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb5)
 Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb5)
 Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb5)
 Registering value_relation (path_oracle) (_4 < a.4_14) (bb3)
 Registering value_relation (path_oracle) (_3 == iftmp.3_15) (bb3)
 Registering value_relation (path_oracle) (_4 < a.4_14) (bb3)
 Registering value_relation (path_oracle) (_3 == iftmp.3_15) (bb3)
 Registering value_relation (path_oracle) (_5 == iftmp.6_13) (bb3)

And then 2 blocks get removed. I'd hazard a guess that we're getting a relation
wrong...  but we shall see.

[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice

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

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

--- Comment #14 from qinzhao at gcc dot gnu.org ---
All the 3 testing cases can be resolved by adding the following patch (check
whether the type has padding before adding call to __builtin_clear_padding):

I believe that this is a safe partial fix for this bug. We might need to put
this partial fix in first. 

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 7fcfef41f72..e100f5bd1f5 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -4651,6 +4651,31 @@ clear_padding_type_may_have_padding_p (tree type)
 }
 }

+/* Return true if TYPE contains any padding bits.  */
+
+bool
+clear_padding_type_has_padding_p (tree type)
+{
+  bool has_padding = false;
+  if (BITS_PER_UNIT == 8
+  && CHAR_BIT == 8
+  && clear_padding_type_may_have_padding_p (type))
+{
+  HOST_WIDE_INT sz = int_size_in_bytes (type), i;
+  gcc_assert (sz > 0);
+  unsigned char *buf = XALLOCAVEC (unsigned char, sz);
+  memset (buf, ~0, sz);
+  clear_type_padding_in_mask (type, buf);
+  for (i = 0; i < sz; i++)
+  if (buf[i] != (unsigned char) ~0)
+   {
+ has_padding = true;
+ break;
+   }
+}
+  return has_padding;
+}
+
 /* Emit a runtime loop:
for (; buf.base != end; buf.base += sz)
  __builtin_clear_padding (buf.base);  */
diff --git a/gcc/gimple-fold.h b/gcc/gimple-fold.h
index 397f4aeb7cf..eb750a68eca 100644
--- a/gcc/gimple-fold.h
+++ b/gcc/gimple-fold.h
@@ -37,6 +37,7 @@ extern tree maybe_fold_and_comparisons (tree, enum tree_code,
tree, tree,
 extern tree maybe_fold_or_comparisons (tree, enum tree_code, tree, tree,
   enum tree_code, tree, tree);
 extern bool clear_padding_type_may_have_padding_p (tree);
+extern bool clear_padding_type_has_padding_p (tree);
 extern void clear_type_padding_in_mask (tree, unsigned char *);
 extern bool optimize_atomic_compare_exchange_p (gimple *);
 extern void fold_builtin_atomic_compare_exchange (gimple_stmt_iterator *);
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index d8e4b139349..62684dd6338 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1955,7 +1955,8 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
 In order to make the paddings as zeroes for pattern init, We
 should add a call to __builtin_clear_padding to clear the
 paddings to zero in compatiple with CLANG.  */
- if (flag_auto_var_init == AUTO_INIT_PATTERN)
+ if (flag_auto_var_init == AUTO_INIT_PATTERN
+ && clear_padding_type_has_padding_p (TREE_TYPE (decl)))
gimple_add_padding_init_for_auto_var (decl, is_vla, seq_p);
}
 }
@@ -5390,6 +5391,7 @@ gimplify_init_constructor (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
  variable has be completely cleared already or it's initialized
  with an empty constructor.  */
   if (is_init_expr
+  && clear_padding_type_has_padding_p (type)
   && ((AGGREGATE_TYPE_P (type) && !cleared && !is_empty_ctor)
  || !AGGREGATE_TYPE_P (type))
   && is_var_need_auto_init (object))

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #16 from joseph at codesourcery dot com  ---
I don't think this bug is anything to do with -fsignaling-nans, for the 
same reason as applies to bug 58416 and bug 71460.

The option -fsignaling-nans is only about correctly handling programs 
that, in the abstract machine, interpret the bit pattern of a signaling 
NaN as a floating-point value (i.e. do lvalue-to-rvalue conversion on it 
in the relevant floating-point type).  Thus bug, and those other two, and 
maybe others, involves a different case: a bit pattern of a signaling NaN 
occurs somewhere, but is never converted to an rvalue in the abstract 
machine.

In such cases, the bit pattern should be handled correctly even without 
-fsignaling-nans (and, thus, on x87, it's incorrect to do single-precision 
or double-precision loads on any bit-pattern where an lvalue-to-rvalue 
conversion doesn't occur in the abstract machine, even without 
-fsignaling-nans).

[Bug target/102737] [9/10/11/12 Regression] extra mov with int->double conversion and addition (incoming arguments and return)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|enhancement |minor

--- Comment #2 from Andrew Pinski  ---
Note I think this might not be an important regression either because I suspect
it has to do with function arguments so this would be a micro-benchmark really
rather than hitting real code.

[Bug target/102737] [9/10/11/12 Regression] extra mov with int->double conversion and addition (incoming arguments and return)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
  Known to fail||10.1.0, 9.1.0
   Severity|normal  |enhancement
  Known to work||5.1.0, 8.1.0, 8.5.0
Summary|[x86] Failure to optimize   |[9/10/11/12 Regression]
   |out bad register usage  |extra mov with int->double
   |involving int->double   |conversion and addition
   |conversion  |(incoming arguments and
   ||return)

--- Comment #1 from Andrew Pinski  ---
GCC 8.5.0 (and before) would do:
pxor%xmm1, %xmm1
cvtsi2sd%edi, %xmm1
addsd   %xmm1, %xmm0
ret

So this is a regression.

Even with AVX, gcc has an extra move even if inputs don't have to be tied to
the output:
vmovsd  %xmm0, %xmm0, %xmm1
vxorps  %xmm0, %xmm0, %xmm0
vcvtsi2sdl  %edi, %xmm0, %xmm0
vaddsd  %xmm1, %xmm0, %xmm0
ret

[Bug target/102737] New: [x86] Failure to optimize out bad register usage involving int->double conversion

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102737
   Summary: [x86] Failure to optimize out bad register usage
involving int->double conversion
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

double foo(int s, double a)
{
  return s + a;
}

With -O3, GCC outputs this on AMD64:

foo(int, double):
movapd  xmm1, xmm0
pxorxmm0, xmm0
cvtsi2sdxmm0, edi
addsd   xmm0, xmm1
ret

LLVM outputs this:

foo(int, double):
cvtsi2sdxmm1, edi
addsd   xmm0, xmm1
ret

The movapd in GCC's version can be optimized out.

[Bug tree-optimization/102736] [12 Regression] wrong code at -O1 -ftree-vrp

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong code at -O2 and -O3   |[12 Regression] wrong code
   |on x86_64-linux-gnu |at -O1 -ftree-vrp
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-13

--- Comment #1 from Andrew Pinski  ---
Take:

int a, b = -1, c;
int d = 1;
static inline char e(char f, int g) { return g ? f : 0; }
static inline char h(char f) { return f < a ? f : f < a; }
static inline unsigned char i(unsigned char f, int g) { return g ? f : f > g; }
void j() {
L:
  c = e(1, i(h(b), d));
  if (b)
return;
  goto L;
}
int main() {
  j();
  if (c != 1)
__builtin_abort ();
  return 0;
}
 CUT 
This fails at -O1 -ftree-vrp or -O2 and above.

[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 11.3, thanks for the report.

[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair

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

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

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

https://gcc.gnu.org/g:9ef31bab15a426a6829acf0e7ae5420d3b10cbae

commit r11-9149-g9ef31bab15a426a6829acf0e7ae5420d3b10cbae
Author: Jonathan Wakely 
Date:   Wed Oct 13 17:02:59 2021 +0100

libstdc++: Fix dangling string_view in filesystem::path [PR102592]

When creating a path from a pair of non-contiguous iterators we pass the
iterators to _S_convert(Iter, Iter). That function passes the iterators
to __string_from_range to get a contiguous sequence of characters, and
then calls _S_convert(const C*, const C*) to perform the encoding
conversions. If the value type, C, is char8_t, then no conversion is
needed and the _S_convert(const char8_t*, const char8_t*)
specialization casts the pointer to const char* and returns a
std::string_view that refs to the char8_t sequence. However, that
sequence is owned by the std::u8string rvalue returned by
__string_from_range, which goes out of scope when _S_convert(Iter, Iter)
returns. That means the std::string_view is dangling and we get
undefined behaviour when parsing it as a path.

The same problem does not exist for the path members taking a "Source"
argument, because those functions all convert a non-contiguous range
into a basic_string immediately, using __effective_range(__source).
That means that the rvalue string returned by that function is still in
scope for the full expression, so the string_view does not dangle.

The solution for the buggy functions is to do the same thing, and call
__string_from_range immediately, so that the returned rvalue is still in
scope for the lifetime of the string_view returned by _S_convert. To
avoid reintroducing the same problem, remove the _S_convert(Iter, Iter)
overload that calls __string_from_range and returns a dangling view.

libstdc++-v3/ChangeLog:

PR libstdc++/102592
* include/bits/fs_path.h (path::path(Iter, Iter, format))
(path::append(Iter, Iter), path::concat(Iter, Iter)): Call
__string_from_range directly, instead of two-argument overload
of _S_convert.
(path::_S_convert(Iter, Iter)): Remove.
* testsuite/27_io/filesystem/path/construct/102592.C: New test.

(cherry picked from commit 85b24e32dc27ec2e70b853713e0713cbc1ff08c3)

[Bug tree-optimization/102736] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 102736
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

[592] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211013 (experimental) [master r12-4363-g52055987fba] (GCC) 
[593] % 
[593] % gcctk -Os small.c; ./a.out
[594] % 
[594] % gcctk -O2 small.c
[595] % ./a.out
Aborted
[596] % 
[596] % cat small.c
int a, b = -1, c;
int d = 1;
char e(char f, int g) { return g ? f : 0; }
char h(char f) { return f < a ? f : f < a; }
unsigned char i(unsigned char f, int g) { return g ? f : f > g; }
void j() {
L:
  c = e(1, i(h(b), d));
  if (b)
return;
  goto L;
}
int main() {
  j();
  if (c != 1)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/102648] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0) since r12-2381-g704e8a825c78b9a8

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
This is another case of insufficient range representation in the old
value_range.  The patch causing the issue allows us to produce better subranges
when the source ranges have small numbers of constants in them.

We have the sequence:

g.8_18 = (unsigned short) _2;
_19 = g.8_18 * 4;
_20 = (short int) _19;
if (_20 > 1)

we calculate that g.8_18 has a range of [0,1]
before this patch, we calculated:

_19 = unsigned short ~[1, 3]
_20 =   short int [-25536, 0]
if (_20 > 1) could then be folded as never taken.

With the precision change, we calculate _19 as [0,0][4,4], which when
converted to a value range, becomes [0,4].  This then causes
_20 be calculated as short int ~[-25535, -1] 
which can no longer correctly predict that the branch can never be taken.

This problem goes away if we run another evrp instance later instead of VRP as
this is a non issue with multi-ranges as we get:

g.8_18 : unsigned short [0, 1]
_19 : unsigned short [0, 0][4, 4]
_20 : short int [-25536, -25536][0, 0]
and can easily fold away the condition.

[Bug testsuite/102735] New: privatization-1-compute.c results in both XFAIL and PASS

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102735
   Summary: privatization-1-compute.c  results in both XFAIL and
PASS
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

This testcase "c-c++-common/goacc/privatization-1-compute.c" results as both
XFAIL and PASS which confuses "contrib/compare_tests". This appears to be so
since this testcase is first checked-in.


XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98  (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98  (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98  (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98  (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98  (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98  (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++98 (test for excess
errors)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
XFAIL: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (test for
warnings, line 27)
PASS: c-c++-common/goacc/privatization-1-compute.c  -std=c++14 TODO (t

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

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

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

--- Comment #27 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:8b333df9484c1697f3a80530a47aa90b1859e970

commit r11-9147-g8b333df9484c1697f3a80530a47aa90b1859e970
Author: Iain Sandoe 
Date:   Sat Jul 31 16:29:03 2021 +0100

Darwin, X86, config: Adjust 'as' command lines [PR100340].

Versions of the assembler using clang from XCode 12.5/12.5.1
have a bug which produces different code layout between debug and
non-debug input, leading to a compare fail for default configure
parameters.

This is a workaround fix to disable the optimisation that is
responsible for the bug.

Signed-off-by: Iain Sandoe 

PR target/100340 - Bootstrap fails with Clang 12.0.5 (XCode 12.5)

PR target/100340

gcc/ChangeLog:

* config.in: Regenerate.
* config/i386/darwin.h (EXTRA_ASM_OPTS): New
(ASM_SPEC): Pass options to disable branch shortening where
needed.
* configure: Regenerate.
* configure.ac: Detect versions of 'as' that support the
optimisation which has the bug.

(cherry picked from commit 743b8dd6fd757e997eb060d70fd4ae8e04fb56cd)

[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 9.5 too, thanks for the report.

This also prompted https://wg21.link/lwg3598

[Bug libstdc++/102667] Inconsistent result of std::regex_match

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.3, thanks for the report.

[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()

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

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

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

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

commit r9-9778-gb90b39a33154949979def3117ca868950ce8025c
Author: Jonathan Wakely 
Date:   Wed Sep 22 11:58:20 2021 +0100

libstdc++: std::system_category should know meaning of zero [PR102425]

Although 0 is not an errno value, it should still be recognized as
corresponding to a value belonging to the generic_category().

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102425
* src/c++11/system_error.cc
(system_error_category::default_error_condition): Add 0 to
switch.
* testsuite/19_diagnostics/error_category/102425.cc: New test.

(cherry picked from commit ce01e2e64c340dadb55a8a24c545a13e654804d4)

[Bug libstdc++/102667] Inconsistent result of std::regex_match

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

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

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

https://gcc.gnu.org/g:081f08b80db2ce8a10375b3af118db008308affc

commit r9-9774-g081f08b80db2ce8a10375b3af118db008308affc
Author: Jonathan Wakely 
Date:   Mon Oct 11 09:07:15 2021 +0100

libstdc++: Fix std::match_results::end() for failed matches [PR102667]

The end() function needs to consider whether the underlying vector is
empty, not whether the match_results object is empty. That's because the
underlying vector will always contain at least three elements for a
match_results object that is "ready". It contains three extra elements
which are stored in the vector but are not considered part of sequence,
and so should not be part of the [begin(),end()) range.

libstdc++-v3/ChangeLog:

PR libstdc++/102667
* include/bits/regex.h (match_result::empty()): Optimize by
calling the base function directly.
(match_results::end()): Check _Base_type::empty() not empty().
* testsuite/28_regex/match_results/102667.C: New test.

(cherry picked from commit 84088dc4bb6a546c896a068dc201463493babf43)

[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair

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

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

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

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

commit r12-4381-gb83b810ac440f72e7551b6496539e60ac30c0d8a
Author: Jonathan Wakely 
Date:   Wed Oct 13 17:19:57 2021 +0100

libstdc++: Refactor filesystem::path encoding conversions

Adjust the __detail::__effective_range overloads so they always return a
string or string view using std::char_traits, because we don't care
about the traits of an incoming string.

Use std::contiguous_iterator in the __effective_range(const Source&)
overload, to allow returning a basic_string_view in more cases. For the
non-contiguous casecl in both __effective_range and __string_from_range,
return a std::string instead of std::u8string when the value type of the
range is char8_t.  These changes avoid unnecessary basic_string
temporaries.

Also simplify __string_from_range(Iter, Iter) to not need
std::__to_address for the contiguous case.

Combine the _S_convert(string_type) and _S_convert(const T&) overloads
into a single _S_convert(T) function which also avoids the dangling
view problem of PR 102592 (should that recur somehow).

libstdc++-v3/ChangeLog:

* include/bits/fs_path.h (__detail::__is_contiguous): New
variable template to identify contiguous iterators.
(__detail::__unified_char8_t): New alias template to decide when
to treat char8_t as char without encoding conversion.
(__detail::__effective_range(const basic_string&)): Use
std::char_traits for returned string view.
(__detail::__effective_range(const basic_string_view&)):
Likewise.
(__detail::__effective_range(const Source&)): Use
__is_contiguous to detect mode cases of contiguous iterators.
Use __unified_char8_t to return a std::string instead of
std::u8string.

[Bug libstdc++/102592] [11/12 Regression] heap-use-after-free when constructing std::filesystem::path from iterator pair

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

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

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

https://gcc.gnu.org/g:85b24e32dc27ec2e70b853713e0713cbc1ff08c3

commit r12-4380-g85b24e32dc27ec2e70b853713e0713cbc1ff08c3
Author: Jonathan Wakely 
Date:   Wed Oct 13 17:02:59 2021 +0100

libstdc++: Fix dangling string_view in filesystem::path [PR102592]

When creating a path from a pair of non-contiguous iterators we pass the
iterators to _S_convert(Iter, Iter). That function passes the iterators
to __string_from_range to get a contiguous sequence of characters, and
then calls _S_convert(const C*, const C*) to perform the encoding
conversions. If the value type, C, is char8_t, then no conversion is
needed and the _S_convert(const char8_t*, const char8_t*)
specialization casts the pointer to const char* and returns a
std::string_view that refs to the char8_t sequence. However, that
sequence is owned by the std::u8string rvalue returned by
__string_from_range, which goes out of scope when _S_convert(Iter, Iter)
returns. That means the std::string_view is dangling and we get
undefined behaviour when parsing it as a path.

The same problem does not exist for the path members taking a "Source"
argument, because those functions all convert a non-contiguous range
into a basic_string immediately, using __effective_range(__source).
That means that the rvalue string returned by that function is still in
scope for the full expression, so the string_view does not dangle.

The solution for the buggy functions is to do the same thing, and call
__string_from_range immediately, so that the returned rvalue is still in
scope for the lifetime of the string_view returned by _S_convert. To
avoid reintroducing the same problem, remove the _S_convert(Iter, Iter)
overload that calls __string_from_range and returns a dangling view.

libstdc++-v3/ChangeLog:

PR libstdc++/102592
* include/bits/fs_path.h (path::path(Iter, Iter, format))
(path::append(Iter, Iter), path::concat(Iter, Iter)): Call
__string_from_range directly, instead of two-argument overload
of _S_convert.
(path::_S_convert(Iter, Iter)): Remove.
* testsuite/27_io/filesystem/path/construct/102592.C: New test.

[Bug fortran/102716] ICE in gfc_validate_kind(): Got bad kind

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-October/056711.html

[Bug fortran/102717] ICE in gfc_simplify_reshape, at fortran/simplify.c:6843

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-October/056710.html

[Bug tree-optimization/102705] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2637-g145bc41dae7c7bfa093d61e77346f98e6a595a0e

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Macleod  ---
That impact of that patch on this PR is that it teaches range extraction that
[0,1] % [5,5]  is [0,1], unlike before which came up with [0,4]

This in turn causes the thread1 pass to decide to thread something it didn't
thread before.

In the absence of thread1 making this decision (ie, before the patch), the next
pass is VRP/VRpthread which ends up performing the thread anyway, but via
different means, and ever so slightly different IL

By the time we hit DCE3, the differences are very slight:
(We know b.1_1 has a range of [0,1])
Original code where we get the optimization:

  _2 = 1 >> b.1_1;
  iftmp.0_10 = (char) _2;
  _3 = (int) iftmp.0_10;
  b = _3;
  _4 = iftmp.0_10 ^ 1;
  _5 = (int) _4;
  iftmp.6_22 = (short int) _5;
  _6 = (short int) iftmp.0_10;
  if (_6 == iftmp.6_22)
goto ; [49.37%]
  else
goto ; [50.63%]


The next pass is forwprop3, and it reports:
gimple_simplified to iftmp.6_22 = (short int) _4;
gimple_simplified to if (0 != 0)

I think it can see that with  iftmp.0_10 having range [0, 1] that _4,_5 and
iftmp.6_22 are therefore basically ~iftmp.0_10
Thus if can fold the condition as never being true.

And turns this into :

  _2 = 1 >> b.1_1;
  iftmp.0_10 = (char) _2;
  _3 = (int) iftmp.0_10;
  b = _3;
  _4 = iftmp.0_10 ^ 1;
  _5 = (int) _4;
  iftmp.6_22 = (short int) _4;
  _6 = (short int) iftmp.0_10;


Meanwhile, trunk threads earlier, and produces slightly different code .   At
DSE3 time it looks like:

  _2 = 1 >> b.1_1;
  iftmp.0_10 = (char) _2;
  b = _2; 
  _4 = iftmp.0_10 ^ 1;
  _5 = (int) _4;
  iftmp.6_22 = (short int) _5;
  _6 = (short int) _2;
  if (_6 == iftmp.6_22)
goto ; [50.37%]
  else
goto ; [49.63%]

So we have already skipped a few casts as use _2 more directly.

The problem is that the next pass, forwprop3 does not like this new code, and
does not perform the same fold, leaving the condition.   And thus we never lose
the call to foo().

again, _4,_5 and iftmp.6_22 would all be known to be ~iftmp.0_10,  but it looks
like forwprop no longer recognizes that _6 = (short int) _2 makes it 
equivalent to iftmp.0_10 ?

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> RTL level DSE removes the first store.  I suspect dse.c does not check
> ADDR_SPACE_GENERIC_P.

I mean MEM_ADDR_SPACE.  And yes it looks like it does not check MEM_ADDR_SPACE

There could be other places in the RTL level which does not check
MEM_ADDR_SPACE either.

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|target  |rtl-optimization
   Last reconfirmed||2021-10-13
   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
Gimple level is good:
  MEM[( int *)0B] = 1;
  MEM[( int *)0B] = 2;

Expansion seems to be correct (notice AS1 and AS2):
(insn 5 4 6 (set (reg/f:DI 82)
(const_int 0 [0])) "/app/example.cpp":17:7 -1
 (nil))

(insn 6 5 0 (set (mem:SI (reg/f:DI 82) [1 MEM[( int *)0B]+0 S4
A128 AS1])
(const_int 1 [0x1])) "/app/example.cpp":17:7 -1
 (nil))

;; MEM[( int *)0B] = 2;

(insn 7 6 8 (set (reg/f:DI 83)
(const_int 0 [0])) "/app/example.cpp":20:7 -1
 (nil))

(insn 8 7 0 (set (mem:SI (reg/f:DI 83) [1 MEM[( int *)0B]+0 S4
A128 AS2])
(const_int 2 [0x2])) "/app/example.cpp":20:7 -1
 (nil))


RTL level DSE removes the first store.  I suspect dse.c does not check
ADDR_SPACE_GENERIC_P.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #51595|0   |1
is obsolete||

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

Updated patch that handles even templates, including pack expansions.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[vajdaz at protonmail dot com via Gcc-bugs]

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

--- Comment #15 from Zoltan Vajda  ---
In my special case, I have an embedded realtime application with a lot of FP
atithmetic on Intel 32 bit architecture (huge and complex legacy codebase). FPU
exceptions are enabled, so loading an SNaN results in an exception. This is
intended, and we will don't want to change this configuration. In this context
the generated ASM code does result in an fld of an uninitialized local
variable, where looking on the C++ code such an access should not be possible.
If the content of the uninitialized local variable happens to be a SNaN by
accident (chances are very small, but not zero), an FPU exception happens. And
again, based on the C++ code no FPU exception should be possible (assuming d is
not an SNaN).

Here is a synthetic example that triggers the exception by "placing a bomb" on
the stack.

https://gcc.godbolt.org/z/aooex6dcT

Function place_bomb() has an effect on what happens in func(). That should not
be the case! This is all valid C++ code.

This may now accidentally happen in our application. The behavior is
unpredictable, because it depends on what previous function calls left on the
stack.

If you change "-march=i686" to "-march=i386" in the example linked above,
everything goes fine.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 102630 Summary: [12 Regression] Spurious -Warray-bounds with named address 
space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630

   What|Removed |Added

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

[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Fixed in r12-4376.

[Bug libstdc++/90787] filesystem tests fail if file permissions are not supported

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 10.4 and 11.3

[Bug modula2/101388] Unconditional use of __MAX_BAUD

[gaiusmod2 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Gaius Mulley  ---
Many thanks - I've applied the patch to the git repro.  Fixed now I believe.

[Bug c++/102734] New: Autodeduced method return type is available before the class is complete

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102734
   Summary: Autodeduced method return type is available before the
class is complete
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

I believe, this program must be ill-formed:
```
class A {
static constexpr auto GetInt() noexcept { return 6; }

template
int func() { return N; }
};
```
because auto-deduced type of GetInt() method is used in the default template
argument, where the class is not yet complete (so method bodies are not yet
inspected).

Both Clang and MSVC reject this program, demo:
https://gcc.godbolt.org/z/3e6o8f5sz

Related discussion with slightly different example:
https://stackoverflow.com/q/56969739/7325599

[Bug target/102733] New: missing fs:0 store when followed by one to gs:0

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

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

Bug ID: 102733
   Summary: missing fs:0 store when followed by one to gs:0
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing r12-4376 I noticed that when a fs:0 store is followed by one to
gs:0 the former is not emitted, otherwise when each is done on its own each is
also emitted on its own.  My very basic understanding is that the FS and GS
namespaces are distinct with null being a valid address of a distinct location
in each (and so I would expect both stores to be emitted) but I leave it
experts to confirm or resolve this as invalid.

$ cat z.c && gcc -O -S -Wall -o/dev/stdout z.c
void test_null_store_fs (void)
{
  int __seg_fs *fs = (int __seg_fs *)0;
  *fs = 1;   // fs:0 store emitted
}

void test_null_store_gs (void)
{
  int __seg_gs *gs = (int __seg_gs *)0;
  *gs = 2;   // gs:0 store emitted
}

void test_null_store_fs_gs (void)
{
  int __seg_fs *fs = (int __seg_fs *)0;
  *fs = 1;   // store missing

  int __seg_gs *gs = (int __seg_gs *)0;
  *gs = 2;   // gs:0 store emitted
}
.file   "z.c"
.text
.globl  test_null_store_fs
.type   test_null_store_fs, @function
test_null_store_fs:
.LFB0:
.cfi_startproc
movl$1, %fs:0
ret
.cfi_endproc
.LFE0:
.size   test_null_store_fs, .-test_null_store_fs
.globl  test_null_store_gs
.type   test_null_store_gs, @function
test_null_store_gs:
.LFB1:
.cfi_startproc
movl$2, %gs:0
ret
.cfi_endproc
.LFE1:
.size   test_null_store_gs, .-test_null_store_gs
.globl  test_null_store_fs_gs
.type   test_null_store_fs_gs, @function
test_null_store_fs_gs:
.LFB2:
.cfi_startproc
movl$2, %gs:0
ret
.cfi_endproc
.LFE2:
.size   test_null_store_fs_gs, .-test_null_store_fs_gs
.ident  "GCC: (GNU) 12.0.0 20211013 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug demangler/102732] New: quadratic/exponential time complexity on D demangler

[contact at lsferreira dot net via Gcc-bugs]

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

Bug ID: 102732
   Summary: quadratic/exponential time complexity on D demangler
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: contact at lsferreira dot net
  Target Milestone: ---

Feeding the initial mangled symbol
"_D3eeeS2RPRRS2RPRgRgRS4RPRgRggRgRS2RPRgPRRS6RPRgRgRRRS2RPRgPRRS2"
and subsequentially append "_D3eeeRS2RPRgPRRS6RPRgRgRRRS2RPRgPRRS2" to
it, makes the demangler demangle it in an excessive time.

This was found with libfuzzer, and other meaningful results can be found here:
https://lsferreira.net/public/assets/posts/d-saoc-2021-02/fuzzer-results/

This seems to be either quadratic or exponential in terms of time complexity.

Similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80002 , this needs to
be fixed until we add libiberty to Google OSS fuzz.

[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:54fa5567a27eb7ee72cd2321d0291c8a9b436ce9

commit r12-4376-g54fa5567a27eb7ee72cd2321d0291c8a9b436ce9
Author: Martin Sebor 
Date:   Wed Oct 13 10:31:37 2021 -0600

Check to see if null pointer is dereferenceable [PR102630].

Resolves:
PR middle-end/102630 - Spurious -Warray-bounds with named address space

gcc/ChangeLog:

PR middle-end/102630
* pointer-query.cc (compute_objsize_r): Handle named address
spaces.

gcc/testsuite/ChangeLog:

PR middle-end/102630
* gcc.target/i386/addr-space-2.c: Add -Wall.
* gcc.target/i386/addr-space-3.c: New test.

[Bug modula2/102323] gm2 testsuite needs to be parallelized

[gaiusmod2 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gaius Mulley  ---
Confirmed, thank you for the bug report.  Now fixed in the git repro.

[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

 CC||kees at outflux dot net

--- Comment #5 from Kees Cook  ---
I think this behavior may, unfortunately, be "as expected", due to how the
memcpy overflow checks are working (they're checking surrounding object, yes,
like bos(0) would)? The constant-expression bos() calculations do appear to
understand the base pointer object, but when faced with "i", it can't know for
sure -- it might have room (if "i" is < 3), or not. So it must return -1 as it
lacks any other context (like memcpy's "size" argument).

There may, however, be a missing opportunity for tightening the memcpy checker?

For example:


...
volatile unsigned i;

struct weird {
char a[4];
char b[8];
};

int main (void)
{
  {
struct weird instance;
char d [3];

P (d + i);
memcpy (d + i, "abcdef", 5); // always overflows d (the entire object)

i = 7;
P (instance.a + i); // can't see into "i"
P (instance.a + 7); // room left in instance (5), but not "a" (0)

memcpy (instance.a + i, "abcdef", 5); // misses a, doesn't overflow
instance. should this warn?

__builtin_printf ("%.0s", d);
  }
}


-1 -1  0  0
-1 -1  0  0
 5  0  5  5

[Bug middle-end/102731] inconsistent handling of dereferncing a null pointer

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||56456, 88443
   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99578

--- Comment #1 from Martin Sebor  ---
Ideally, all three instances of the invalid access would be handled the same:
by issuing an appropriate warning (preferably more descriptive of the problem
than the one below) and injecting a trap (perhaps under the control of some
option).

The -Warray-bounds (or, with it disabled, the equivalent -Wstringop-overflow)
instance is the result of the logic in compute_objsize() for constant
addresses:

  if (code == INTEGER_CST)
{
  /* Pointer constants other than null are most likely the result
 of erroneous null pointer addition/subtraction.  Set size to
 zero.  For null pointers, set size to the maximum for now
 since those may be the result of jump threading.  */
  if (integer_zerop (ptr))
pref->set_max_size_range ();
  else
pref->sizrng[0] = pref->sizrng[1] = 0;
  pref->ref = ptr;

  return true;
}

Warnings issued due to this logic are discussed in pr99578 and its duplicates. 
It's inconvenient for projects (like the kernel) that deliberately accesses
objects at constant addresses.  The purpose of this bug is to show that the
logic isn't sufficiently effective and the warnings issued due to it not
sufficiently clear for users to understand.  A better solution is needed,
preferably one that diagnoses the null pointer arithmetic before it's folded
into non-null constant dereference.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug middle-end/102731] New: inconsistent handling of dereferncing a null pointer

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

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

Bug ID: 102731
   Summary: inconsistent handling of dereferncing a null pointer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The test case below shows that GCC doesn't handle null pointer dereferences
consistently or as helpfully as it could or should.  Of the three equivalent
functions, GCC only issues a warning pointing out the invalid access only for
the first.  For the other two it doesn't warn even though it clearly detects
the invalid access and injects a trap after it.

$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
struct A { char n, a[4]; };

void f (struct A *p)
{
  if (p)
return;
  __builtin_memset (p->a, 0, 4);   // warning, no trap
}

void g (struct A *p)
{
  if (p)
return;

  p->a[0] = 0; // trap, no warning
  p->a[1] = 0;
  p->a[2] = 0;
  p->a[3] = 0;
}

void h (struct A *p)
{
  if (p)
return;

  for (int i = 0; i != 4; ++i)
p->a[i] = 0;   // trap, no warning
}

x.c: In function ‘f’:
x.c:7:3: warning: ‘__builtin_memset’ offset [0, 3] is out of the bounds [0, 0]
[-Warray-bounds]
7 |   __builtin_memset (p->a, 0, 4);   // warning, no trap
  |   ^

;; Function f (f, funcdef_no=0, decl_uid=1981, cgraph_uid=1, symbol_order=0)

Removing basic block 5
void f (struct A * p)
{
   [local count: 1073741824]:
  if (p_3(D) != 0B)
goto ; [70.93%]
  else
goto ; [29.07%]

   [local count: 312136752]:
  __builtin_memset (1B, 0, 4); [tail call]

   [local count: 1073741824]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1984, cgraph_uid=2, symbol_order=1)

void g (struct A * p)
{
   [local count: 1073741824]:
  if (p_2(D) != 0B)
goto ; [54.59%]
  else
goto ; [45.41%]

   [local count: 487586160]:
  MEM[(struct A *)0B].a[0] ={v} 0;
  __builtin_trap ();

   [local count: 1073741824]:
  return;

}



;; Function h (h, funcdef_no=2, decl_uid=1987, cgraph_uid=3, symbol_order=2)

void h (struct A * p)
{
   [local count: 472909864]:
  if (p_4(D) != 0B)
goto ; [54.59%]
  else
goto ; [45.41%]

   [local count: 214748368]:
  MEM[(struct A *)0B].a[0] ={v} 0;
  __builtin_trap ();

   [local count: 472909864]:
  return;

}

[Bug fortran/102729] Assumed rank: ICE when passing noncontiguous to CONTIGUOUS assume rank (assumed-rank loop handling)

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Blocks||102641

--- Comment #1 from Tobias Burnus  ---
An (UNRELATED) patch which contains the FULL TESTCASE (commented) is in file
   gfortran.dg/c-interop/fc-descriptor-7.f90
as modified by
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581575.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641
[Bug 102641] Bogus error for intent(out) dummy that is a polymorphic
assumed-rank array

[Bug tree-optimization/99580] False positive -Warray-bounds with nested loops

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2021-03-14 00:00:00 |2021-10-13
Summary|False positive  |False positive
   |-Warray-bounds with -O2 |-Warray-bounds with nested
   ||loops
  Known to fail||11.2.0, 12.0

--- Comment #2 from Martin Sebor  ---
Still present on trunk.

[Bug tree-optimization/100464] [11 Regression] emitted binary code changes when -g is enabled at -O3

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

--- Comment #15 from Chengnian Sun  ---
(In reply to Jakub Jelinek from comment #14)
> Yes.  You'll get an error, like:
> error: t.c: ‘-fcompare-debug’ failure (length)
> or
> error: t.c: ‘-fcompare-debug’ failure
> Under the hood, the driver invokes the compiler once with
> the options you've given plus -fdump-final-insns=sometempfile1
> and then also with the options you've given plus -gtoggle
> -fcompare-debug-second -fdump-final-insns=sometempfile2 (and will throw away
> stdout/stderr from the compiler).  The (length) failure means sometempfile1
> and sometempfile2 have different lengths, while the other error mean they
> have the same length, but their content differs.

Thank you.

[Bug libstdc++/90787] filesystem tests fail if file permissions are not supported

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

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

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

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

commit r10-10214-g4be4888d6bddbcc106efeb19e18c380e7c1d041a
Author: Jonathan Wakely 
Date:   Fri Aug 20 14:51:06 2021 +0100

libstdc++: Skip filesystem tests that depend on permissions [PR90787]

Tests that depend on filesystem permissions FAIL if run on Windows or as
root. Add a helper function to detect those cases, so the tests can skip
those checks gracefully.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/90787
* testsuite/27_io/filesystem/iterators/directory_iterator.cc:
Use new __gnu_test::permissions_are_testable() function.
*
testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.
* testsuite/27_io/filesystem/operations/exists.cc: Likewise.
* testsuite/27_io/filesystem/operations/is_empty.cc: Likewise.
* testsuite/27_io/filesystem/operations/remove.cc: Likewise.
* testsuite/27_io/filesystem/operations/remove_all.cc: Likewise.
* testsuite/27_io/filesystem/operations/status.cc: Likewise.
* testsuite/27_io/filesystem/operations/symlink_status.cc:
Likewise.
* testsuite/27_io/filesystem/operations/temp_directory_path.cc:
Likewise.
*
testsuite/experimental/filesystem/iterators/directory_iterator.cc:
Likewise.
*
testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.
* testsuite/experimental/filesystem/operations/exists.cc:
Likewise.
* testsuite/experimental/filesystem/operations/is_empty.cc:
Likewise.
* testsuite/experimental/filesystem/operations/remove.cc:
Likewise.
* testsuite/experimental/filesystem/operations/remove_all.cc:
Likewise.
*
testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise.
* testsuite/util/testsuite_fs.h
(__gnu_test::permissions_are_testable):
New function to guess whether testing permissions will work.

(cherry picked from commit 29b2fd371f18169141e20b90effa7205db68fb11)

[Bug c++/102730] New: Consistency of deprecation warning emission with type alias

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Bug ID: 102730
   Summary: Consistency of deprecation warning emission with type
alias
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

While trying to rename an enum from one name to another in an existing
framework, I try to use the following mechanism that works partially with gcc
(but not clang) of:
 - deprecating the old type declaration with [[deprecated]]
 - use some "using NewType = DeprecatedType;" statement to define the new name
our user shall use in their code.

I would expect that gcc correctly emit a warning when we use "DeprecatedType"
instead of "NewType" in the code, but not when I use "NewType", which allows
people to migrate to the new name without any impact on name mangling implied
by this name change. It seems that it works partially. See this snippet:

<

[Bug c++/102726] Does not warn for enum constant in boolean context

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed with the test case below:

$ cat pr102726.C && gcc -S -Wall pr102726.C 
void f (bool);

enum { E0, E1, E2 };

void f (void)
{
  f (E0);// missing warning
  f (E1);// missing warning
  f (E2);// -Wint-in-bool-context
}

pr102726.C: In function ‘void f()’:
pr102726.C:9:6: warning: enum constant in boolean context
[-Wint-in-bool-context]
9 |   f (E2);// -Wint-in-bool-context
  |  ^~

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

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

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

--- Comment #14 from Alexander Monakov  ---
Zoltan, excuse me, could you please clarify what specifically you are worried
about? Your bug title says "results in UB" and the opening comment said "the
behavior [..] is unpredictable", but as far as I see that is not the case here,
it's (as you also said) only raising an FPU exception where it shouldn't.
Unless the program inspects exception flags or enables signal delivery on FPU
exceptions, it won't notice. What is your main concern?

[Bug tree-optimization/102720] [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4324

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

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

--- Comment #6 from Christophe Lyon  ---
On aarch64, this also causes gcc.dg/loop-unswitch-4.c to fail

[Bug tree-optimization/102720] [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4324

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
 Target|powerpc64-linux-gnu,|powerpc64-linux-gnu,
   |powerpc64le-linux-gnu,  |powerpc64le-linux-gnu,
   |x86_64-linux-gnu|x86_64-linux-gnu, arm,
   ||aarch64

--- Comment #5 from Christophe Lyon  ---
Seen on arm and aarch64 too

[Bug fortran/102729] New: Assumed rank: ICE when passing noncontiguous to CONTIGUOUS assume rank (assumed-rank loop handling)

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

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

Bug ID: 102729
   Summary: Assumed rank: ICE when passing noncontiguous to
CONTIGUOUS assume rank (assumed-rank loop handling)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Related: PR 102708, PR54753, PR102641

That's an extended version of gfortran.dg/c-interop/fc-descriptor-7.f90

- - - -

  integer(C_INT), target :: bb(10,10)
  call ftest (bb(2:10:2, :), is_cont=.false._c_bool)
...
  subroutine ftest_ar (a, is_cont)
use iso_c_binding
integer(C_INT) :: a(..)
logical(c_bool), value, intent(in) :: is_cont
...
!call ftest_ar_con (a, is_cont=.true._c_bool)  ! <<< fixme!
  end subroutine

  subroutine ftest_ar_con (a, is_cont)
use iso_c_binding
integer(C_INT), contiguous :: a(..)
logical(c_bool), value, intent(in) :: is_cont



That gives an ICE as the loop handling does not work
for rank == -1 (= assumed-rank arrays)

  124 | call ftest_ar_con (a, is_cont=.true._c_bool)  ! <<< fixme!

internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:1491

0x6799b2 gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*,
tree_node*, tree_node*, bool, bool, bool, locus*)  fortran/trans-array.c:1491
0x98af9b gfc_conv_loop_setup(gfc_loopinfo*, locus*)  fortran/trans-array.c:5449
0x9be118 gfc_conv_subref_array_arg(gfc_se*, gfc_expr*, int, sym_intent, bool,
gfc_symbol const*, char const*, gfc_symbol*, bool)   fortran/trans-expr.c:4976

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

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 51595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51595&action=edit
gcc12-P2128R6-WIP.patch

Untested WIP, just template handling hasn't been added yet, so it is useful
only without templates so far.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Zoltan Vajda from comment #12)
> Using -mfpmath=sse here does not help on a 32 bit platfrom.
> https://gcc.godbolt.org/z/hs1Ef6aj4
> At line 31 the assembly code performs the speculative load.

Yeah, -msse2 is also needed.

[Bug c++/102728] New: requires statement fails to recognize lambda in unevaluated context

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102728
   Summary: requires statement fails to recognize lambda in
unevaluated context
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

Consider that this snippet of code gives error of no matching specialization
which is not rooted from lambda in function parameter, instead it is rooted
from "requires" statement violation of lambda in unevaluated-context. The
warning about no-return-statement in lambda within requirement exposes this is
"requires" issue.

#include 
template
concept IsLambda=requires(T t){
{t}->std::convertible_to; 
};

template // OK if replace IsLambda with "class"
void foo(T t){ t();}

template<>
void foo(decltype(+[]{}) t){
t();
}

Also, a proof that this is not lambda-in-function-parameter issue is that you
can replace template parameter "IsLambda" in template function declaration with
"class" and GCC works fine.

Both clang and MSVC++ accepts above code. (https://www.godbolt.org/z/xhW7Tofao)





: In substitution of 'template  requires  IsLambda void
foo(T) [with T = void (*)()]':
:12:44:   required from here
:5:40: warning: no return statement in function returning non-void
[-Wreturn-type]
5 | {t}->std::convertible_to;
  |^~~~
:12:6: error: template-id 'foo' for 'void foo(void (*)())'
does not match any template declaration
   12 | void foo(decltype(+[]{}) t){
  |  ^~~~
:9:6: note: candidate is: 'template  requires  IsLambda
void foo(T)'
9 | void foo(T t){ t();}
  |  ^~~

[Bug libstdc++/100287] Using iterator after std::move in ranges::partition

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for 10.4/11.3/12

[Bug libstdc++/100237] Unnecessary std::move in ranges::min, ranges::max and ranges::minmax

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for 10.4/11.3/12

[Bug libstdc++/100187] Helper lambda in ranges_algo.h misses forwarding return type

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Fixed for 10.4/11.3/12

[Bug libstdc++/100287] Using iterator after std::move in ranges::partition

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:139bafaaba0c775ca65712621bd60e079b488d73

commit r10-10210-g139bafaaba0c775ca65712621bd60e079b488d73
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

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

https://gcc.gnu.org/g:139bafaaba0c775ca65712621bd60e079b488d73

commit r10-10210-g139bafaaba0c775ca65712621bd60e079b488d73
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100187] Helper lambda in ranges_algo.h misses forwarding return type

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

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

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

https://gcc.gnu.org/g:139bafaaba0c775ca65712621bd60e079b488d73

commit r10-10210-g139bafaaba0c775ca65712621bd60e079b488d73
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100237] Unnecessary std::move in ranges::min, ranges::max and ranges::minmax

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:139bafaaba0c775ca65712621bd60e079b488d73

commit r10-10210-g139bafaaba0c775ca65712621bd60e079b488d73
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100287] Using iterator after std::move in ranges::partition

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-9145-gcb261f0e8fc08fb49f74002582ad5713cda684f7
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

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

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

commit r11-9145-gcb261f0e8fc08fb49f74002582ad5713cda684f7
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100237] Unnecessary std::move in ranges::min, ranges::max and ranges::minmax

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-9145-gcb261f0e8fc08fb49f74002582ad5713cda684f7
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug libstdc++/100187] Helper lambda in ranges_algo.h misses forwarding return type

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-9145-gcb261f0e8fc08fb49f74002582ad5713cda684f7
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

(cherry picked from commit d91e7eab3a2c3957c2220ad71e62d9fc78cccb9b)

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 90364 Summary: 521.wrf_r is 8-17% slower with PGO at -Ofast and native 
march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364

   What|Removed |Added

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

[Bug gcov-profile/90364] 521.wrf_r is 8-17% slower with PGO at -Ofast and native march/mtune

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[vajdaz at protonmail dot com via Gcc-bugs]

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

--- Comment #12 from Zoltan Vajda  ---
Using -mfpmath=sse here does not help on a 32 bit platfrom.
https://gcc.godbolt.org/z/hs1Ef6aj4
At line 31 the assembly code performs the speculative load.

[Bug modula2/102340] gm2 test sources shouldn't be executable

[gaiusmod2 at gmail dot com via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaiusmod2 at gmail dot com

--- Comment #1 from Gaius Mulley  ---
Confirmed and fixed now in the git repository.  Many thanks for the report.

[Bug gcov-profile/90364] 521.wrf_r is 8-17% slower with PGO at -Ofast and native march/mtune

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

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

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

https://gcc.gnu.org/g:72e0c742bd01f8e7e6dcca64042b9ad7e75979de

commit r12-4372-g72e0c742bd01f8e7e6dcca64042b9ad7e75979de
Author: Martin Liska 
Date:   Thu Sep 9 13:02:24 2021 +0200

gcov: make profile merging smarter

Support merging of profiles that are built from a different .o files
but belong to the same source file. Moreover, a checksum is verified
during profile merging and so we can safely combine such profile.

PR gcov-profile/90364

gcc/ChangeLog:

* coverage.c (build_info): Emit checksum to the global variable.
(build_info_type): Add new field for checksum.
(coverage_obj_finish): Pass object_checksum.
(coverage_init): Use 0 as checksum for .gcno files.
* gcov-dump.c (dump_gcov_file): Dump also new checksum field.
* gcov.c (read_graph_file): Read also checksum.
* doc/invoke.texi: Document the behaviour change.

libgcc/ChangeLog:

* libgcov-driver.c (merge_one_data): Skip timestamp and verify
checksums.
(write_one_data): Write also checksum.
* libgcov-util.c (read_gcda_file): Read also checksum field.
* libgcov.h (struct gcov_info): Add new field.

[Bug target/102688] [12 regression] gcc.dg/ipa/iinline-attr.c fails after r12-4288

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/102688] [12 regression] gcc.dg/ipa/iinline-attr.c fails after r12-4288

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

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

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

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

commit r12-4370-ge415bc4c035b1b655cf2cafcbe515382d1cefc93
Author: Martin Liska 
Date:   Tue Oct 12 16:05:49 2021 +0200

Fix handling of flag_rename_registers by a target.

PR target/102688

gcc/ChangeLog:

* common.opt: Use EnabledBy instead of detection in
finish_options and process_options.
* opts.c (finish_options): Remove handling of
x_flag_unroll_all_loops.
* toplev.c (process_options): Likewise for flag_web and
flag_rename_registers.

[Bug modula2/102339] gm2 testsuite leaves many files behind

[gaiusmod2 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gaius Mulley  ---
Confirmed as a bug and now fixed in the repository - many thanks for the
report.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Zoltan Vajda from comment #9)
> As I understand it, it is acknowledged, that this is a bug. However, the
> issue is in state NEW for a quite long time. The issue is still present in
> GCC 11.2. Do you see any chances for some progress in this case?

The Comment #5 summarises all the troubles with trapping FLDL/FLDS. I'm afraid
that trapping FLDL/FLDS renders -fsignaling-nans on x87 practically impossible
to implement.

Even the documentation advises against usage of -fsignaling-nans:

 This option is experimental and does not currently guarantee to
 disable all GCC optimizations that affect signaling NaN behavior.

You should really use -mfpmath=sse here.

[Bug c++/102724] ICE in genericize_spaceship, at cp/method.c:1089

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r11-5866-g4ed1dc1275bba89a.

[Bug tree-optimization/102711] [9/10/11 Regression] CDDCE removes condition that might lead to an infinite loop causing an unconditional infinite loop

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 13 Oct 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102711
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  CC||marxin at gcc dot gnu.org
> 
> --- Comment #4 from Martin Liška  ---
> Fixed on master with r12-2591-g2e96b5f14e402569.

OK, that likely made it latent only.

> Note it started with r8-2318-g34e5c5116fa58f77.

I see - probably makes sense since that subtly changes post-dominators
for backwards unreachable regions which reflects back on control
dependence.  But there's nothing "wrong" here, I think it avoided
placing the fake exit edges at the infinite loop headers as opposed
to the latch but I don't remember exactly.

[Bug fortran/102715] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184 since r12-4278-g74ccca380cde5e79

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-13
 Ever confirmed|0   |1
Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |gfc_simplify_transpose, at  |gfc_simplify_transpose, at
   |fortran/simplify.c:8184 |fortran/simplify.c:8184
   ||since
   ||r12-4278-g74ccca380cde5e79
 CC||anlauf at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-4278-g74ccca380cde5e79.

[Bug tree-optimization/102711] [9/10/11 Regression] CDDCE removes condition that might lead to an infinite loop causing an unconditional infinite loop

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Fixed on master with r12-2591-g2e96b5f14e402569.
Note it started with r8-2318-g34e5c5116fa58f77.

[Bug c++/102709] [11/12 Regression] ICE: in build_function_type with parameter packs not expanded in constructor while doing auto deduction since r11-2748-gb871301f09be7061

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE: in  |[11/12 Regression] ICE: in
   |build_function_type with|build_function_type with
   |parameter packs not |parameter packs not
   |expanded in constructor |expanded in constructor
   |while doing auto deduction  |while doing auto deduction
   ||since
   ||r11-2748-gb871301f09be7061
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r11-2748-gb871301f09be7061.

[Bug c++/102721] out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from qingzhe huang  ---
(In reply to qingzhe huang from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Note it is not array related either:
> > template<>
> > void A::foo(const decltype(+[]{}))
> > {}
> 
> Yes, it is not array-related. But it is definitely member function issue
> with out-of line definition. See this works fine:
> 
> template
> void foo(const T){}
> 
> template<>
> void foo(const decltype(+[]{})); //declaration
> 
> template<>
> void foo(const decltype(+[]{}))
> {}

Also interestingly, consider these following two cases:

1. template-class-member-function:
template
struct A{
void foo(const T){}
};

template<>
void A::foo(const decltype(+[]{})){}

2. class-with-template-member-function:
struct A{
template
void foo(const T){}
};

template<>
void A::foo(const decltype(+[]{})){}


Only case #1 has such issue.

[Bug fortran/102727] New: Warning for guaranteed interoperable type kind

[jahns at dkrz dot de via Gcc-bugs]

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

Bug ID: 102727
   Summary: Warning for guaranteed interoperable type kind
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jahns at dkrz dot de
  Target Milestone: ---

Created attachment 51594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51594&action=edit
Source file to reproduce the unexpected interop warning.

Compiling a source like the following (also attached) gives a warning with
-Wc-binding-type active:

SUBROUTINE fwrap(another_int)
  IMPLICIT NONE
  INTEGER, INTENT(in) :: another_int
  ENUM, BIND(c)
ENUMERATOR :: enu_a, enu_b
  END ENUM
  INTEGER, PARAMETER :: enu_type_kind = KIND(enu_a)
  INTERFACE
SUBROUTINE wrapped_c(enu) BIND(C, name='wrapped_c')
  IMPORT:: enu_type_kind
  INTEGER(enu_type_kind), VALUE :: enu
END SUBROUTINE wrapped_c
  END INTERFACE

  IF (another_int < 0_enu_type_kind .OR. &
   another_int > enu_b) &
   CALL abort()
  CALL wrapped_c(INT(another_int, enu_type_kind))
END SUBROUTINE fwrap

$ gfortran -c -o enum-warn.o  -Wall -Wextra -Wconversion -Wstrict-overflow
enum-warn.f90
enum-warn.f90:9:28:

9 | SUBROUTINE wrapped_c(enu) BIND(C, name='wrapped_c')
  |1
Warning: Variable 'enu' at (1) is a dummy argument of the BIND(C) procedure
'wrapped_c' but may not be C interoperable
[https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#index-Wc-binding-type-Wc-binding-type]

I also tried to change the interface block to

  INTERFACE
SUBROUTINE wrapped_c(enu) BIND(C, name='wrapped_c')
  IMPORT:: enu_a
  INTEGER(KIND(enu_a)), VALUE :: enu
END SUBROUTINE wrapped_c
  END INTERFACE

but that didn't seem to change anything.

This is on linux x86_64 with a compiler built with default spack configurations
applied. I can dig up more details if required.

The stackoverflow discussion leading to this report is at

[Bug c++/102726] New: Does not warn for enum constant in boolean context

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

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

Bug ID: 102726
   Summary: Does not warn for enum constant in boolean context
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We fail to warn for

   gsi_replace (&gsi, call, GSI_SAME_STMT);

with

extern bool gsi_replace (gimple_stmt_iterator *, gimple *, bool);


and

enum gsi_iterator_update
{
  GSI_NEW_STMT, /* Move the iterator to the first statement added.  */
  GSI_SAME_STMT,/* Leave the iterator at the same statement.  */
  GSI_CONTINUE_LINKING  /* Move iterator to whatever position is suitable
   for linking other statements in the same
   direction.  */
};

presumably because GSI_SAME_STMT is 1

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

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

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

--- Comment #4 from Richard Biener  ---
I think that 'strlen' is only used when it is explicitely declared.  Hmm, maybe
I'm mistaken and it's 'implicit' already because it is standard.

So loop distribution could check for builtin_decl_declared_p (BUILT_IN_STRLEN)
(but that likely only "works" for the C family frontends)

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||12.0
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed on trunk, not planning to backport at this point (we've not run into this
in the wild).

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

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

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

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

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

commit r12-4369-g3c0194d7ff21d61c02f3c6b111c83ef24a69e1f0
Author: Richard Biener 
Date:   Mon Oct 11 12:27:10 2021 +0200

tree-optimization/102659 - avoid undefined overflow after if-conversion

The following makes sure to rewrite arithmetic with undefined behavior
on overflow to a well-defined variant when moving them to be always
executed as part of doing if-conversion for loop vectorization.

2021-10-11  Richard Biener  

PR tree-optimization/102659
* tree-if-conv.c (need_to_rewrite_undefined): New flag.
(if_convertible_gimple_assign_stmt_p): Mark the loop for
rewrite when stmts with undefined behavior on integer
overflow appear.
(combine_blocks): Predicate also when we need to rewrite stmts.
(predicate_statements): Rewrite affected stmts to something
with well-defined behavior on overflow.
(tree_if_conversion): Initialize need_to_rewrite_undefined.

* gcc.dg/torture/pr69760.c: Adjust the testcase.
* gcc.target/i386/avx2-vect-mask-store-move1.c: Expect to move
the conversions to unsigned as well.

[Bug tree-optimization/102046] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 with -O3 -march=btver2 since r1

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/101925] [10 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/102046] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 with -O3 -march=btver2 since r1

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:967219bb3ef1869f6bd1c5efffea65544a310836

commit r10-10208-g967219bb3ef1869f6bd1c5efffea65544a310836
Author: Richard Biener 
Date:   Wed Aug 25 10:06:01 2021 +0200

tree-optimization/102046 - fix SLP build from scalars with patterns

When we swap operands for SLP builds we lose track where exactly
pattern defs are - but we fail to update the any_pattern member
of the operands info.  Do so conservatively.

2021-08-25  Richard Biener  

PR tree-optimization/102046
* tree-vect-slp.c (vect_build_slp_tree_2): Conservatively
update ->any_pattern when swapping operands.

* gcc.dg/vect/pr102046.c: New testcase.

(cherry picked from commit 29c77454e5ab33ce06a741eacdfbd5348fbccc95)

[Bug tree-optimization/101925] [10 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:66615029ec831da23b481cd3a01e90cff02c6891

commit r10-10207-g66615029ec831da23b481cd3a01e90cff02c6891
Author: Richard Biener 
Date:   Mon Aug 16 15:17:08 2021 +0200

tree-optimization/101925 - fix VN with reverse storage order

This fixes value-numbering breaking reverse storage order accesses
due to a missed check.  It adds a new overload for
reverse_storage_order_for_component_p and sets reversed on the
VN IL ops for component and array accesses accordingly.
It also compares the reversed reference ops flag on reference
lookup.

2021-08-16  Richard Biener  

PR tree-optimization/101925
* tree-ssa-sccvn.c (copy_reference_ops_from_ref): Set
reverse on COMPONENT_REF and ARRAY_REF according to
what reverse_storage_order_for_component_p does.
(vn_reference_eq): Compare reversed on reference ops.
(reverse_storage_order_for_component_p): New overload.
(vn_reference_lookup_3): Check
reverse_storage_order_for_component_p
on the reference looked up.

* gcc.dg/sso-16.c: New testcase.

(cherry picked from commit 0215b3559e55f39f38e10984a804c53907f7491c)

[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls

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

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

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

https://gcc.gnu.org/g:95a95ec274cd0ec125ce48ab002fad4e400e345b

commit r10-10206-g95a95ec274cd0ec125ce48ab002fad4e400e345b
Author: Richard Biener 
Date:   Tue Aug 17 08:38:35 2021 +0200

tree-optimization/101868 - avoid PRE of trapping mems across calls

This backports a fix for the omission of a check of trapping mems
when hoisting them across calls that might not return.  This was
originally done as part of a fix to handle const functions that throw
properly.

2021-08-17  Richard Biener  

PR tree-optimization/101373
PR tree-optimization/101868
* tree-ssa-pre.c (prune_clobbered_mems): Also prune trapping
references when the BB may not return.

* gcc.dg/lto/pr101868_0.c: New testcase.
* gcc.dg/lto/pr101868_1.c: Likewise.
* gcc.dg/lto/pr101868_2.c: Likewise.
* gcc.dg/lto/pr101868_3.c: Likewise.

(cherry picked from commit ee875b63b22e30a0dcb4b05f7532c2c416ba6cd0)

[Bug tree-optimization/101868] [9/10 Regression] Incorrect reordering in -O2 with LTO

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:95a95ec274cd0ec125ce48ab002fad4e400e345b

commit r10-10206-g95a95ec274cd0ec125ce48ab002fad4e400e345b
Author: Richard Biener 
Date:   Tue Aug 17 08:38:35 2021 +0200

tree-optimization/101868 - avoid PRE of trapping mems across calls

This backports a fix for the omission of a check of trapping mems
when hoisting them across calls that might not return.  This was
originally done as part of a fix to handle const functions that throw
properly.

2021-08-17  Richard Biener  

PR tree-optimization/101373
PR tree-optimization/101868
* tree-ssa-pre.c (prune_clobbered_mems): Also prune trapping
references when the BB may not return.

* gcc.dg/lto/pr101868_0.c: New testcase.
* gcc.dg/lto/pr101868_1.c: Likewise.
* gcc.dg/lto/pr101868_2.c: Likewise.
* gcc.dg/lto/pr101868_3.c: Likewise.

(cherry picked from commit ee875b63b22e30a0dcb4b05f7532c2c416ba6cd0)

[Bug tree-optimization/101824] [9/10 Regression] VOLATILE not honored

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-10205-ga68a1e06f2eea2f510649aa9bbb17303ef1efb9c
Author: Richard Biener 
Date:   Mon Aug 9 10:19:10 2021 +0200

middle-end/101824 - properly handle volatiles in nested fn lowering

When we build the COMPONENT_REF of a formerly volatile local off
the FRAME decl we have to make sure to mark the COMPONENT_REF
as TREE_THIS_VOLATILE.  While the GIMPLE operand scanner looks
at the FIELD_DECL this is not how volatile GENERIC refs work.

2021-08-09  Richard Biener  

PR middle-end/101824
* tree-nested.c (get_frame_field): Mark the COMPONENT_REF as
volatile in case the variable was.

* gcc.dg/tree-ssa/pr101824.c: New testcase.

(cherry picked from commit bb169406cdc9e044eaec500dd742c2fed40f5488)