[Bug target/104946] [12 regression] Suboptimal gimple foding for blendvpd under sse4.1

2022-03-15 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104946

Hongtao.liu  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Hongtao.liu  ---
I think we should restrict gimple folding for __builtin_ia32_blendvpd under
TARGET_SSE4_2.

For other blendv builtins, corresponding vec_cmp is available as long as
builtin isa matches.

[Bug target/104946] New: [12 regression] Suboptimal gimple foding for blendvpd under sse4.1

2022-03-15 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104946

Bug ID: 104946
   Summary: [12 regression] Suboptimal gimple foding for blendvpd
under sse4.1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

When working on PR104666, i found

cat test.c

typedef double __m128d __attribute__((__vector_size__(16), __may_alias__));
__m128d sse4_1_blendvpd (__m128d a, __m128d b, __m128d c)
__attribute__((__target__("sse4.1")));

__m128d
generic_blendvpd (__m128d a, __m128d b, __m128d c)
{
  return __builtin_ia32_blendvpd (a, b, c);
}

gcc -O2 -msse4.1 -mno-sse4.2

generic_blendvpd:
movqrax, xmm2
movapd  xmm3, xmm0
testrax, rax
jns .L3
movapd  xmm0, xmm1
.L3:
pextrq  rax, xmm2, 1
unpckhpdxmm3, xmm3
testrax, rax
jns .L5
unpckhpdxmm1, xmm1
movapd  xmm3, xmm1
.L5:
unpcklpdxmm0, xmm3
ret

It's because it pcmpgtq is under sse4.2 w/o which vec_cmpv2di will be lower to
scalar operations and not combined back.

w/ sse4.2 gcc can generate optimal code.

generic_blendvpd:
movapd  xmm3, xmm0
movdqa  xmm0, xmm2
blendvpdxmm3, xmm1, xmm0
movapd  xmm0, xmm3
ret

[Bug tree-optimization/104941] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

[Bug tree-optimization/104942] ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

[Bug libstdc++/104945] std::hash ignores the top 32 bits when size_t is 32 bit

2022-03-15 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945

--- Comment #1 from Andrew Pinski  ---
Yes this is definitely an issue I think:
  // Explicit specializations for integer types.
#define _Cxx_hashtable_define_trivial_hash(_Tp) \
  template<>\
struct hash<_Tp> : public __hash_base  \
{   \
  size_t\
  operator()(_Tp __val) const noexcept  \
  { return static_cast(__val); }\
};


  /// Explicit specialization for long long.
  _Cxx_hashtable_define_trivial_hash(long long)


  /// Explicit specialization for unsigned long long.
  _Cxx_hashtable_define_trivial_hash(unsigned long long)


With no check on size of size_t vs long long.

[Bug libstdc++/104945] New: std::hash ignores the top 32 bits when size_t is 32 bit

2022-03-15 Thread pdimov at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945

Bug ID: 104945
   Summary: std::hash ignores the top 32 bits when
size_t is 32 bit
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

A benchmark in Boost.Unordered uses uint64_t keys of the form `i << 40`:

https://github.com/boostorg/unordered/blob/33f81fd49039bccd1aa3dfd5a29ef6073b93009c/benchmark/uint64.cpp#L65

which leads to pathological behavior with std::unordered_map in 32 bit mode,
because std::hash ignores the top 32 bits:

https://godbolt.org/z/PncKbT7aq

I'm not entirely sure whether this would be considered a bug, but decided that
it's worth reporting. Ideally, std::hash ought to take into account all bits of
the integral input, instead of truncating it to size_t.

[Bug c++/104944] New: incorrect alignas(void) accepted (with warning if templated)

2022-03-15 Thread gccbugbjorn at fahller dot se via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944

Bug ID: 104944
   Summary: incorrect alignas(void) accepted (with warning if
templated)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugbjorn at fahller dot se
  Target Milestone: ---

The erroneous code:

struct alignas(void) S{};

Is accepted without any diagnostic with g++
(Compiler-Explorer-Build-gcc-98cd717fca9f21625b9c79c9231c2e909d1d93a3-binutils-2.36.1)
12.0.1 20220306 (experimental)

https://godbolt.org/z/q7das4G1W

With 'void' coming from a template, a confusing warning is issued:

template 
struct alignas(T) S {};

S s;

The message is:

In instantiation of 'struct S':
:4:9:   required from here
:2:16: warning: invalid application of '__alignof__' to a void type
[-Wpointer-arith]
2 | struct alignas(T) S {};
  |^


This is not entirely incorrect, but I believe most programmers would recognize
that they have no `__alignof__` in their code, nor any pointer arithmetics.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

2022-03-15 Thread roger at nextmovesoftware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 101895, which changed state.

Bug 101895 Summary: [11/12 Regression] SLP Vectorizer change pushes 
VEC_PERM_EXPR into bad location spoiling further optimization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895

   What|Removed |Added

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

[Bug tree-optimization/101895] [11/12 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities

2022-03-15 Thread roger at nextmovesoftware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|11.3|12.0

--- Comment #7 from Roger Sayle  ---
This should now be fixed on mainline.

[Bug analyzer/104943] New: Analyzer fails to purge state for local structs

2022-03-15 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943

Bug ID: 104943
   Summary: Analyzer fails to purge state for local structs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

State purging only happens for SSA names, and locals of struct type aren't SSA
names.

Given e.g.:

struct boxed {
  int value;
};

extern struct boxed boxed_add (struct boxed a, struct boxed b);
extern struct boxed boxed_mul (struct boxed a, struct boxed b);

struct boxed
test (struct boxed a, struct boxed b)
{
  struct boxed result = boxed_add (boxed_mul (a, a),
   boxed_mul (b, b));
  return result;
}

without optimization we have this gimple:

struct boxed test (struct boxed a, struct boxed b)
{
  struct boxed result;
  struct boxed D.1994;
  struct boxed D.1993;
  struct boxed D.1992;

   :
  D.1992 = boxed_mul (b, b);
  D.1993 = boxed_mul (a, a);
  result = boxed_add (D.1993, D.1992);
  D.1994 = result;
  result ={v} {CLOBBER(eol)};

   :
:
  return D.1994;

}

and this final exploded node:

EN 11:
preds: EN: 10
succs: 
callstring: []
after SN: 3
rmodel:
stack depth: 1
  frame (index 0): frame: ‘test’@1
clusters within frame: ‘test’@1
  cluster for: : CONJURED(D.1992 = boxed_mul (b, b);, )
  cluster for: : CONJURED(D.1993 = boxed_mul (a, a);, )
  cluster for: : CONJURED(result = boxed_add (D.1993, D.1992);,
result)
  cluster for: : CONJURED(result = boxed_add (D.1993, D.1992);,
result)
m_called_unknown_fn: TRUE
constraint_manager:
  equiv classes:
  constraints:

where the various  are the values of the local temporaries of struct
type, which ought to be purged; they don't matter anymore.

Seen on linux kernel: drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c which
amongst other things has:

struct bw_fixed {
  int64_t value;
};

with numerous calls to manipulate values; the states get bloated with bindings
for temporaries that persist far longer than they are needed.

[Bug analyzer/95000] -fanalyzer confused by switch on non-int type

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-7659-gd1d95846e3c901faea6fe36a36e47b9169f5b133
Author: David Malcolm 
Date:   Tue Mar 15 17:56:29 2022 -0400

analyzer: add test coverage for PR 95000

PR analyzer/95000 isn't fixed yet; add test coverage with XFAILs.

gcc/testsuite/ChangeLog:
PR analyzer/95000
* gcc.dg/analyzer/pr95000-1.c: New test.

Signed-off-by: David Malcolm 

[Bug tree-optimization/104941] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941

--- Comment #1 from Martin Liška  ---
And a similar problem from openssl:

$ cat bn_ctx.i
int BN_CTX_startBN_STACK_push_newsize;

void
memcpy2(void *__dest, void *__src, int __len) {
  long __trans_tmp_1 = __builtin_dynamic_object_size(__dest, 0);
  __builtin___memcpy_chk(__dest, __src, __len, __trans_tmp_1);
}

int *CRYPTO_malloc() __attribute__((alloc_size(1)));

void
BN_CTX_startBN_STACK_push_st() {
  int *newitems = CRYPTO_malloc(BN_CTX_startBN_STACK_push_newsize);
  memcpy2(newitems, BN_CTX_startBN_STACK_push_st, sizeof(int));
}

$ gcc bn_ctx.i -c -m32 -O3 -D_FORTIFY_SOURCE=3
bn_ctx.i: In function ‘BN_CTX_startBN_STACK_push_st’:
bn_ctx.i:12:1: error: non-trivial conversion in ‘ssa_name’
   12 | BN_CTX_startBN_STACK_push_st() {
  | ^~~~
unsigned int
int
_6 = BN_CTX_startBN_STACK_push_newsize.2_1;
during GIMPLE pass: objsz
bn_ctx.i:12:1: internal compiler error: verify_gimple failed
0xf97bf5 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.cc:5561
0xe55f3e execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2084
0xe5655b execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2138
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/104942] ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-15
   Target Milestone|--- |12.0
 Ever confirmed|0   |1

[Bug tree-optimization/104942] New: ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942

Bug ID: 104942
   Summary: ICE in size_for_offset, at tree-object-size.cc:352
since r12-6482-g06bc1b0c539e3a60
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
  Target Milestone: ---

Reduced from gzip package:

$ cat savedir.i
char *streamsavedir_name_space;
long streamsavedir_used;

void *ximalloc() __attribute__((__alloc_size__(1)));

const char **x;

void
streamsavedir___src() {
  streamsavedir_name_space = ximalloc(streamsavedir_used);
  char *dest = streamsavedir_name_space + streamsavedir_used;
  long __trans_tmp_1 = __builtin_dynamic_object_size(dest, 1);
  __builtin___stpcpy_chk(dest, *x, __trans_tmp_1);
}

$ gcc savedir.i -D_FORTIFY_SOURCE=3 -O
during GIMPLE pass: objsz
savedir.i: In function ‘streamsavedir___src’:
savedir.i:9:1: internal compiler error: in size_for_offset, at
tree-object-size.cc:352
9 | streamsavedir___src() {
  | ^~~
0x79987d size_for_offset
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:352
0x1006124 plus_stmt_object_size
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1354
0x1006124 collect_object_sizes_for
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1645
0x10070a7 compute_builtin_object_size(tree_node*, int, tree_node**)
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1106
0xa1d849 fold_builtin_object_size
/home/marxin/Programming/gcc/gcc/builtins.cc:10397
0xa1d849 fold_builtin_2
/home/marxin/Programming/gcc/gcc/builtins.cc:9420
0xa1d849 fold_builtin_n
/home/marxin/Programming/gcc/gcc/builtins.cc:9528
0x1007d2e dynamic_object_sizes_execute_one
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:1974
0x1007d2e object_sizes_execute
/home/marxin/Programming/gcc/gcc/tree-object-size.cc:2034
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/104941] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-15
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

[Bug tree-optimization/104941] New: ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941

Bug ID: 104941
   Summary: ICE error: invalid (pointer) operands ‘minus_expr’
since r12-6482-g06bc1b0c539e3a60
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
  Target Milestone: ---

Reduced from exfatprogs package:

$ cat exfatprogs.i
struct bsx64 {
  char reserved2[7];
};

struct pbr {
  int bpb;
  struct bsx64 bsx;
} static exfat_setup_boot_sector(struct pbr *ppbr) {
  struct bsx64 *pbsx = >bsx;
  long __trans_tmp_1 = __builtin_dynamic_object_size(pbsx->reserved2, 0);
  __builtin___memset_chk(pbsx, 0, 7, __trans_tmp_1);
}

int x;

void
exfat_write_boot_sector_bd_0() {
  struct pbr *ppbr = __builtin_malloc(x);
  exfat_setup_boot_sector(ppbr);
}

$ gcc exfatprogs.i -c -D_FORTIFY_SOURCE=3 -O
exfatprogs.i: In function ‘exfat_write_boot_sector_bd_0’:
exfatprogs.i:17:1: error: type mismatch in binary expression
   17 | exfat_write_boot_sector_bd_0() {
  | ^~~~
long unsigned int

long unsigned int

struct bsx64 *

_6 = MAX_EXPR <_2, 4B>;
exfatprogs.i:17:1: error: invalid (pointer) operands ‘minus_expr’
_11 = _6 - 4B;
during GIMPLE pass: objsz
exfatprogs.i:17:1: internal compiler error: verify_gimple failed
0xf97bf5 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.cc:5561
0xe55f3e execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2084
0xe5655b execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2138
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/104908] [11/12 Regression] incorrect Fortran out-of-bound runtime error.

2022-03-15 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|gfortran 11/trunk   |[11/12 Regression]
   |regression: incorrect   |incorrect Fortran
   |Fortran out-of-bound|out-of-bound runtime error.
   |runtime error.  |
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-15
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
Likely caused by the fix for PR95331 (r11-1235).  Class-related.
Applying

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index cfb6eac11c7..3a14600101f 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3864,8 +3864,8 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar,
gfc_expr *expr,
 }

   decl = se->expr;
-  if (IS_CLASS_ARRAY (sym) && sym->attr.dummy && ar->as->type != AS_DEFERRED)
-decl = sym->backend_decl;
+  // if (IS_CLASS_ARRAY (sym) && sym->attr.dummy && ar->as->type !=
AS_DEFERRED)
+  //   decl = sym->backend_decl;

   cst_offset = offset = gfc_index_zero_node;
   add_to_offset (_offset, , gfc_conv_array_offset (decl));

apparently "fixes" the wrong bounds check.

[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937

--- Comment #4 from Jakub Jelinek  ---
https://gcc.gnu.org/legacy-ml/gcc/2001-11/msg00790.html
Regarding the debug info argument in there, this is being discussed for DWARF6.

[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937

--- Comment #3 from Jakub Jelinek  ---
For
_Complex unsigned
foo (_Complex unsigned x, _Complex unsigned y)
{
  return y / x;
}

int
main ()
{
  _Complex int a = foo (6 + 43i, 6 + 43i);
  __builtin_printf ("%d %d\n", __real__ a, __imag__ a);
  return 0;
}
from what I see if xr < xi we expand it as
t=xr/xi*xr + xi
((yr*xr/xi + yi) / t) + ((yi*xr/xi - yr) / t) * i
Now, for the given numbers that is t=43 and the result is
43 / 43 + (0 - 6) / 43 * i
For signed complex that "works" by producing 1 + 0i, but for unsigned
that 0U - 6U is some huge number divided by 43.
But now that I see it, I think it doesn't work properly in most cases for
_Complex int either - for signed the xr < xi is actually done as abs(xr) <
abs(xi), so for both signed and unsigned complex xr/xi is 0, and similarly the
other case where we use xi/xr, with the only exception when xr==xi and thus
xr/xi is 1.  I bet the algorithm is well suited only for floating point...

[Bug libfortran/104939] Reading a file with / in leads to corrupt data

2022-03-15 Thread robert.j.farmer37 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104939

Rob Farmer  changed:

   What|Removed |Added

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

--- Comment #1 from Rob Farmer  ---
I'm an idiot and this turns out to be a issue with the unformatted reads and /

[Bug analyzer/95000] -fanalyzer confused by switch on non-int type

2022-03-15 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000

David Malcolm  changed:

   What|Removed |Added

 Depends on||104940

--- Comment #6 from David Malcolm  ---
Still happens on trunk; adding to SMT tracker.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
[Bug 104940] RFE: integrate analyzer with an SMT solver

[Bug analyzer/104940] New: RFE: integrate analyzer with an SMT solver

2022-03-15 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940

Bug ID: 104940
   Summary: RFE: integrate analyzer with an SMT solver
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

-fanalyzer currently has its own constraint_manager class for tracking the
constraints that hold at a point on an execution path, but it only verifies
some of the interactions between constraints and symbolic values, which can
lead to false positives.

For example, consider:

#include "analyzer-decls.h"

void test (int x, int y)
{
  if (y == 3)
if (2 * x == y)
  __analyzer_dump_path ();
}

The current constraint_manager code has no knowledge that (2 * x == y) is
impossible for integers, and erroneously outputs:

../../src/gcc/testsuite/gcc.dg/analyzer/t.c: In function ‘test’:
../../src/gcc/testsuite/gcc.dg/analyzer/t.c:7:7: note: path
7 |   __analyzer_dump_path ();
  |   ^~~
  ‘test’: events 1-5
|
|5 |   if (y == 3)
|  |  ^
|  |  |
|  |  (1) following ‘true’ branch (when ‘y == 3’)...
|6 | if (2 * x == y)
|  |~~
|  ||  |
|  ||  (2) ...to here
|  |(3) following ‘true’ branch...
|7 |   __analyzer_dump_path ();
|  |   ~~~
|  |   |
|  |   (4) ...to here
|  |   (5) here
|

Idea: get out of the business of tracking constraints by instead calling out to
an SMT solver.

I have a work-in-progress prototype of the analyzer which can call express
constraints as an SMT-LIB2 script, and call out to an external z3 binary. 
Presumably we'd want an option to select between different constraint-tracking
implementations, to avoid depending on z3 (or other smt solvers).  Might be
faster to link it in-process, but let's cross that bridge when we come to it.

I'm filing this bug as a tracker bug for other constraint-tracking bugs.

[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined

2022-03-15 Thread zsojka at seznam dot cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937

--- Comment #2 from Zdenek Sojka  ---
There was PR104604 where _Complex unsigned division was fixed, but I didn't
notice any other related wrong-code PR.

[Bug sanitizer/104937] wrong code with _Complex division and -fsanitize=undefined

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Doesn't seem to be sanitizer specific.
Just change the testcase to:
_Complex unsigned
foo (_Complex unsigned x)
{
  _Complex unsigned y = x;
  return y / x;
}

int
main ()
{
  _Complex unsigned x = foo (6 + 43 * 1i);
  if (x != 1)
__builtin_abort ();
  return 0;
}
so that it doesn't get folded to 1 + 0i in the FE and at -O0 you'll get abort
as well.
I think division just doesn't work at all for _Complex unsigned, seems to work
for _Complex signed.
Don't we have some PR covering it?

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

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

Full untested patch.

[Bug libfortran/104939] New: Reading a file with / in leads to corrupt data

2022-03-15 Thread robert.j.farmer37 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104939

Bug ID: 104939
   Summary: Reading a file with / in leads to corrupt data
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert.j.farmer37 at gmail dot com
  Target Milestone: ---

program test

character(len=256) :: tmp,tmp2
integer :: iounit

open(newunit=iounit,file='./test.txt')

read(iounit,*) tmp,tmp2

write(*,*) len_trim(tmp),len_trim(tmp2)
write(*,*) trim(tmp),trim(tmp2)

end program

Compiled with: gfortran -o test testRead.f90

With the contents on test.txt being:

/ a

I get outputted:

 256 256
 p
�:Qu`�1 ��5R�5R�1   ��5R�   ��5R�0hQuf5Qu0hQu

flipping the file to be 

a / 

leads to:

   1 256
 a1���ߗߗ��0��-6��-0��--y��-


This was found as the file had a [fe/h] as a column name, but reducing down it
seems its the / that is breaking the read.

This lead to a somewhat puzzling error as in my full code tmp2 ended up with
the contents of a entirely different file that gfortran decided to start
reading in, mid-read statement.

I found this on linux with 11.2.1 but also have a confirmed failure on a mac
with 10.2

valgrind ./test
==145356== Memcheck, a memory error detector
==145356== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==145356== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==145356== Command: ./test
==145356== 
==145356== Conditional jump or move depends on uninitialised value(s)
==145356==at 0x4AD05D9: string_len_trim (string_intrinsics_inc.c:231)
==145356==by 0x4AD05D9: _gfortran_string_len_trim
(string_intrinsics_inc.c:186)
==145356==by 0x401359: MAIN__ (in /home/rob/src/test/test)
==145356==by 0x4014CA: main (in /home/rob/src/test/test)
==145356== 
==145356== Conditional jump or move depends on uninitialised value(s)
==145356==at 0x4AD05F7: string_len_trim (string_intrinsics_inc.c:240)
==145356==by 0x4AD05F7: _gfortran_string_len_trim
(string_intrinsics_inc.c:186)
==145356==by 0x401359: MAIN__ (in /home/rob/src/test/test)
==145356==by 0x4014CA: main (in /home/rob/src/test/test)
==145356== 
   1 256
==145356== Conditional jump or move depends on uninitialised value(s)
==145356==at 0x4AD05D9: string_len_trim (string_intrinsics_inc.c:231)
==145356==by 0x4AD05D9: _gfortran_string_len_trim
(string_intrinsics_inc.c:186)
==145356==by 0x4AD062B: _gfortran_string_trim (string_intrinsics_inc.c:168)
==145356==by 0x401449: MAIN__ (in /home/rob/src/test/test)
==145356==by 0x4014CA: main (in /home/rob/src/test/test)
==145356== 
==145356== Conditional jump or move depends on uninitialised value(s)
==145356==at 0x4AD05F7: string_len_trim (string_intrinsics_inc.c:240)
==145356==by 0x4AD05F7: _gfortran_string_len_trim
(string_intrinsics_inc.c:186)
==145356==by 0x4AD062B: _gfortran_string_trim (string_intrinsics_inc.c:168)
==145356==by 0x401449: MAIN__ (in /home/rob/src/test/test)
==145356==by 0x4014CA: main (in /home/rob/src/test/test)
==145356== 
==145356== Syscall param write(buf) points to uninitialised byte(s)
==145356==at 0x4D61817: write (write.c:26)
==145356==by 0x4AC2386: raw_write (unix.c:368)
==145356==by 0x4ACA5C1: UnknownInlinedFun (unix.h:59)
==145356==by 0x4ACA5C1: _gfortrani_fbuf_flush (fbuf.c:150)
==145356==by 0x4ABD404: _gfortrani_next_record (transfer.c:4087)
==145356==by 0x4AC03F9: finalize_transfer (transfer.c:4228)
==145356==by 0x4AC08B1: _gfortrani_st_write_done_worker (transfer.c:4419)
==145356==by 0x401493: MAIN__ (in /home/rob/src/test/test)
==145356==by 0x4014CA: main (in /home/rob/src/test/test)
==145356==  Address 0x4e71c62 is 2 bytes inside a block of size 512 alloc'd
==145356==at 0x484486F: malloc (vg_replace_malloc.c:381)
==145356==by 0x4894C58: _gfortrani_xmalloc (memory.c:38)
==145356==by 0x4ACA475: _gfortrani_fbuf_init (fbuf.c:42)
==145356==by 0x4AC17EB: _gfortrani_init_units (unit.c:674)
==145356==by 0x4893371: init (main.c:70)
==145356==by 0x400527D: call_init (dl-init.c:70)
==145356==by 0x400527D: call_init (dl-init.c:26)
==145356==by 0x400536B: _dl_init (dl-init.c:117)
==145356==by 0x401C6D9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
==145356==

[Bug debug/104938] New: Possibly wrong location definition in DWARF with -ftree-cpp at -Og only

2022-03-15 Thread assaiante at diag dot uniroma1.it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104938

Bug ID: 104938
   Summary: Possibly wrong location definition in DWARF with
-ftree-cpp at -Og only
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: assaiante at diag dot uniroma1.it
  Target Milestone: ---

In this minimized C example, variable l_3, which is initialized at line 5, is
associated to DWARF symbols having a possibly wrong location definition. This
causes the variable to not be available during debugging, for instance at line
6, until line 11 is reached. We observe the bug at -Og with the cause likely
being -ftree-ccp, while with other optimizations levels the variable is
correctly available at the lines where gdb can step (line 6 with -O1/O2/O3/Os,
also line 8 with -O1/Os). Please find below a detailed analysis for -Og on x64.

$ cat a.c
char a;
int b;
void foo(int *d) { a = 0; }
int main() {
int *l_3 = 
int **e = _3;
f:
if (a)
goto f;
*e = l_3;
foo(*e);
 }

GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) start
Temporary breakpoint 1 at 0x40048e: file a.c, line 8.
Starting program: /home/stepping/132/reduce/opt 

Temporary breakpoint 1, main () at a.c:8
8 if (a)
(gdb) info locals
l_3 = 
e = 
(gdb) n
11foo(*e);
(gdb) info locals
l_3 = 0x60102c 
e = 

By dumping the DWARF info, we can see how the location associated to the
variable is defined with a range that does not include the instruction
associated to line 8, where the variable's value is not available despite the
original program has assigned (and, incidentally, also used) it by then.

ASM:
0040048e :
  40048e:   80 3d 9b 0b 20 00 00cmpb   $0x0,0x200b9b(%rip)#
601030 
  400495:   75 f7   jne40048e 
  400497:   bf 2c 10 60 00  mov$0x60102c,%edi
  40049c:   e8 e5 ff ff ff  callq  400486 
  4004a1:   b8 00 00 00 00  mov$0x0,%eax
  4004a6:   c3  retq   
  4004a7:   66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
  4004ae:   00 00

DWARF info:
0x0084: DW_TAG_variable
  DW_AT_name("l_3")
  DW_AT_decl_file   ("/home/stepping/132/reduce/a.c")
  DW_AT_decl_line   (5)
  DW_AT_decl_column (0x08)
  DW_AT_type(0x00cc "int*")
  DW_AT_location(0x000e: 
 [0x00400497, 0x004004a1): DW_OP_addr
0x60102c, DW_OP_stack_value)
  DW_AT_GNU_locviews(0x000c)

Through some testing we found out that the optimization flag that introduces
the bug is likely -ftree-ccp. If we add -fno-tree-ccp to the compilation
command line used above, variable l_3 appears in the current frame with its
value correctly available at line 8. The location of the variable appears now
to be correctly defined with the range including the cmp instruction that
corresponds to line 8 according to the line number table in DWARF info.

ASM with -fno-tree-ccp:
  40048e:   48 83 ec 10 sub$0x10,%rsp
  400492:   48 c7 44 24 08 2c 10movq   $0x60102c,0x8(%rsp)
  400499:   60 00 
  40049b:   80 3d 8e 0b 20 00 00cmpb   $0x0,0x200b8e(%rip)#
601030 
  4004a2:   75 f7   jne40049b 
  4004a4:   bf 2c 10 60 00  mov$0x60102c,%edi
  4004a9:   e8 d8 ff ff ff  callq  400486 
  4004ae:   b8 00 00 00 00  mov$0x0,%eax
  4004b3:   48 83 c4 10 add$0x10,%rsp
  4004b7:   c3  retq   
  4004b8:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
  4004bf:   00

DWARF info with -fno-tree-ccp:
0x0093: DW_TAG_variable
  DW_AT_name("e")
  DW_AT_decl_file   ("/home/stepping/132/reduce/a.c")
  DW_AT_decl_line   (6)
  DW_AT_decl_column (0x09)
  DW_AT_type(0x00d4 "int**")
  DW_AT_location(0x000e: 
 [0x0040049b, 0x004004b8): DW_OP_fbreg -16,

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

2022-03-15 Thread wilco at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398

--- Comment #49 from Wilco  ---
(In reply to d_vampile from comment #48)
> (In reply to Jiu Fu Guo from comment #41)
> > (In reply to Wilco from comment #40)
> > > (In reply to Jiu Fu Guo from comment #39)
> > > > I’m thinking to draft a patch for this optimization.  If any 
> > > > suggestions,
> > > > please point out, thanks.
> > > 
> > > Which optimization to be precise? Besides unrolling I haven't seen a
> > > proposal for an optimization which is both safe and generally applicable.
> > 
> > 1. For unroll, there are still branches in the loop. And then need careful
> > merge on those reading and comparison.  Another thing about unroll would be
> > that, if we prefer to optimize this early in GIMPLE, we still not GIMPLE
> > unroll on it.
> > while (len != max)
> > {
> > if (p[len] != cur[len])
> >   break; ++len;
> > if (p[len] != cur[len])
> >   break; ++len;
> > if (p[len] != cur[len])
> >   break; ++len;
> > 
> > }
> > 
> > 2. Also thinking about if it makes sense to enhance GIMPLE vectorization
> > pass.  In an aspect that using a vector to read and compare, also need to
> > handle/merge compares into vector compare and handle early exit carefully.
> > if (len + 8 < max && buffers not cross page) ///(p&4K) == (p+8)&4k?
> > 4k:pagesize
> >  while (len != max)
> > {
> >  vec a = xx p;
> >  vec b = xx cur;
> >  if (a != b) /// may not only for comparison 
> >   {;break;}
> >  len += 8;
> > }
> > 
> > 3. Introduce a new stand-alone pass to optimize reading/computing shorter
> > types into large(dword/vector) reading/computing.
> > 
> > Thanks a lot for your comments/suggestions!
> 
> Any progress or patches for the new pass mentioned in point 3? Or new ideas?

A new standalone pass would have to redo a lot of the work of the existing loop
optimizers and vectorizer. And you wouldn't be able to skip the extra checks to
guarantee safety of the optimization. This is why these optimizations are
typically done in the source code.

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

--- Comment #14 from Jakub Jelinek  ---
Wonder about:
--- gcc/gimplify.cc.jj  2022-03-04 15:14:53.197812540 +0100
+++ gcc/gimplify.cc 2022-03-15 17:44:45.110734179 +0100
@@ -6997,8 +6997,6 @@ gimplify_target_expr (tree *expr_p, gimp

   if (init)
 {
-  tree cleanup = NULL_TREE;
-
   /* TARGET_EXPR temps aren't part of the enclosing block, so add it
 to the temps list.  Handle also variable length TARGET_EXPRs.  */
   if (!poly_int_tree_p (DECL_SIZE (temp)))
@@ -7019,37 +7017,6 @@ gimplify_target_expr (tree *expr_p, gimp
  gimple_add_tmp_var (temp);
}

-  /* If TARGET_EXPR_INITIAL is void, then the mere evaluation of the
-expression is supposed to initialize the slot.  */
-  if (VOID_TYPE_P (TREE_TYPE (init)))
-   ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
-  else
-   {
- tree init_expr = build2 (INIT_EXPR, void_type_node, temp, init);
- init = init_expr;
- ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
- init = NULL;
- ggc_free (init_expr);
-   }
-  if (ret == GS_ERROR)
-   {
- /* PR c++/28266 Make sure this is expanded only once. */
- TARGET_EXPR_INITIAL (targ) = NULL_TREE;
- return GS_ERROR;
-   }
-  if (init)
-   gimplify_and_add (init, pre_p);
-
-  /* If needed, push the cleanup for the temp.  */
-  if (TARGET_EXPR_CLEANUP (targ))
-   {
- if (CLEANUP_EH_ONLY (targ))
-   gimple_push_cleanup (temp, TARGET_EXPR_CLEANUP (targ),
-CLEANUP_EH_ONLY (targ), pre_p);
- else
-   cleanup = TARGET_EXPR_CLEANUP (targ);
-   }
-
   /* Add a clobber for the temporary going out of scope, like
 gimplify_bind_expr.  */
   if (gimplify_ctxp->in_cleanup_point_expr
@@ -7079,8 +7046,32 @@ gimplify_target_expr (tree *expr_p, gimp
}
}
}
-  if (cleanup)
-   gimple_push_cleanup (temp, cleanup, false, pre_p);
+
+  /* If TARGET_EXPR_INITIAL is void, then the mere evaluation of the
+expression is supposed to initialize the slot.  */
+  if (VOID_TYPE_P (TREE_TYPE (init)))
+   ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
+  else
+   {
+ tree init_expr = build2 (INIT_EXPR, void_type_node, temp, init);
+ init = init_expr;
+ ret = gimplify_expr (, pre_p, post_p, is_gimple_stmt, fb_none);
+ init = NULL;
+ ggc_free (init_expr);
+   }
+  if (ret == GS_ERROR)
+   {
+ /* PR c++/28266 Make sure this is expanded only once. */
+ TARGET_EXPR_INITIAL (targ) = NULL_TREE;
+ return GS_ERROR;
+   }
+  if (init)
+   gimplify_and_add (init, pre_p);
+
+  /* If needed, push the cleanup for the temp.  */
+  if (TARGET_EXPR_CLEANUP (targ))
+   gimple_push_cleanup (temp, TARGET_EXPR_CLEANUP (targ),
+CLEANUP_EH_ONLY (targ), pre_p);

   /* Only expand this once.  */
   TREE_OPERAND (targ, 3) = init;
i.e. emitting the clobber gimple_push_cleanup for the TARGET_EXPRs before the
gimplification of the TARGET_EXPR_INITIAL instead of after it (and emitting the
WCE earlier means the cleanup is later (as in, outer try/finally).

[Bug c++/79318] [DR 1726] conversion member function preceded with & is not marked as error

2022-03-15 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79318

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
CWG 1726 is now a DR.

[Bug sanitizer/104937] New: wrong code with _Complex division and -fsanitize=undefined

2022-03-15 Thread zsojka at seznam dot cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937

Bug ID: 104937
   Summary: wrong code with _Complex division and
-fsanitize=undefined
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 52631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52631=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -fsanitize=undefined testcase.c
$ ./a.out 
Aborted

The __imag__ part seems to be garbage.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7654-20220315102422-gda24fce323e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7654-20220315102422-gda24fce323e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220315 (experimental) (GCC)

[Bug fortran/104927] Invalid array size specification accepted

2022-03-15 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927

--- Comment #3 from Steve Kargl  ---
On Tue, Mar 15, 2022 at 04:10:41PM +, federico.perini at gmail dot com
wrote:
> --- Comment #2 from federico  ---
> Yeah I'm surprised but wrong. The "overriding" option of the rhs size
> specification is pretty clear from that statement from the standard.
> 

Thanks for the bug report.  We would rather see a bug report that
is proven to be invalid than to have actual bugs go unreported.

[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106

--- Comment #4 from Tom de Vries  ---
This:
...
$ cat alias.c
void __f ()
{
  __builtin_printf ("hello\n");
}

void f () __attribute__ ((alias ("__f")));

int
main (void)
{
  f ();
  return 0;
}
...
works fine at -O0 and -O1:
...
$ ./gcc.sh -O0 ./alias.c
$ ./install/bin/nvptx-none-run a.out
hello
$ ./gcc.sh -O1 ./alias.c
$ ./install/bin/nvptx-none-run a.out
hello
...
but at -O2 we have:
...
$ ./gcc.sh -O2 ./alias.c
$ ./install/bin/nvptx-none-run a.out
fatal   : Internal error: reference to deleted section
nvptx-run: cuLinkComplete failed: unknown error (CUDA_ERROR_UNKNOWN, 999)
...

This seems to be due to f/__f being inlined into main, after which we have an
alias declaration which is unused:
...
.visible .func f;
.alias f,__f;
...
Removing these two lines make the executable run fine again.

Note: same thing when using nvptx-none-run -O0.

Fixed by:
...
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index ab1f62359d4b..3e51bf15776c 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -77,6 +77,7 @@
 #include "opts.h"
 #include "tree-pretty-print.h"
 #include "rtl-iter.h"
+#include "cgraph.h"

 /* This file should be included last.  */
 #include "target-def.h"
@@ -7396,6 +7397,10 @@ nvptx_mem_local_p (rtx mem)
 void
 nvptx_asm_output_def_from_decls (FILE *stream, tree name, tree value)
 {
+  if (!cgraph_node::get (name)->referred_to_p ())
+/* Prevent "Internal error: reference to deleted section".  */
+return;
+
   std::stringstream s;
   write_fn_proto (s, false, get_fnname_from_decl (name), name);
   fputs (s.str().c_str(), stream);
...

[Bug sanitizer/104934] -fsanitize=undefined codegen err

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
.

[Bug sanitizer/104934] -fsanitize=undefined codegen err

2022-03-15 Thread dimhen at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934

--- Comment #2 from Dmitry G. Dyachenko  ---
(In reply to Jakub Jelinek from comment #1)
> And the bug is?
> The S class doesn't have the key method defined, so some other TU needs to
> define it and thus provide the vtable and rtti for it.
> Without -fsanitize=vptr the typeinfo isn't needed on this particular
> testcase and the vtable isn't needed either, which is why you don't get an
> undefined symbol in that case and you get it with -fsanitize=vptr or
> -fsanitize=undefined that implies that.

Thank you, Jakub.
So, close as 'INVALID'?

[Bug fortran/104927] Invalid array size specification accepted

2022-03-15 Thread federico.perini at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927

federico  changed:

   What|Removed |Added

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

--- Comment #2 from federico  ---
Yeah I'm surprised but wrong. The "overriding" option of the rhs size
specification is pretty clear from that statement from the standard.

This makes it even more evident: 

program test_invalid_shape
implicit none

integer, dimension(2,2) :: a(3),b(2,5),c

print *, 'shape(a) = ',shape(a)
print *, 'shape(b) = ',shape(b)
print *, 'shape(c) = ',shape(c)

end program test_invalid_shape

produces 

 shape(a) =3
 shape(b) =2   5
 shape(c) =2   2

[Bug target/104936] New: [nvptx] Handle weak decl/def distinction in common code

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104936

Bug ID: 104936
   Summary: [nvptx] Handle weak decl/def distinction in common
code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

At docs for ASM_WEAKEN_LABEL (stream, name) we find:
...
If you don’t define this macro or ASM_WEAKEN_DECL, GCC will not support weak
symbols and you should not define the SUPPORTS_WEAK macro. 
...

However, we have:
...
$ grep define.*WEAKEN gcc/config/nvptx/*
$ 
...
but still:
...
$ grep SUPPORTS_WEAK gcc/config/nvptx/*
gcc/config/nvptx/nvptx.h:#define SUPPORTS_WEAK 1
...

I think an argument for the discrepancy is made here:
...
  /*  We support weak defintions, and hence have the right  
  ASM_WEAKEN_DECL definition.  Diagnose the problem here.  */
  if (DECL_WEAK (decl))
error_at (DECL_SOURCE_LOCATION (decl),
  "PTX does not support weak declarations"
  " (only weak definitions)");
...
where it's my understanding that the "right ASM_WEAKEN_DECL" is meant to refer
to ASM_WEAKEN_DECL not being defined.

It would be nice to solve this somehow in the common code instead of deviating
from prescribed target macro usage.

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

--- Comment #13 from Jakub Jelinek  ---
What the gimplifier sees is:
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe8f0bd20
fields 
addressable used public external autoinline decl_3 QI
pr103984.C:21:8 align:16 warn_if_not_align:0 context 
full-name "Z& Z::operator=(Z&&) noexcept"
not-really-extern chain >
context 
full-name "struct Z"
needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0
use_template=0 interface-unknown
pointer_to_this  reference_to_this
 chain >
side-effects addressable
arg:0 
addressable used ignored read BLK pr103984.C:32:3 size  unit-size 
align:64 warn_if_not_align:0 context >
arg:1 >
side-effects head 0x7fffe8e73660 tail 0x7fffe8e73780 stmts
0x7fffe8e860e0 0x7fffe8f61af0 0x7fffe8e861a0 0x7fffe8e3b758

stmt 
side-effects
arg:0 
side-effects
arg:0 
arg:0  arg:1 >
arg:1 
side-effects tree_0 arg:0 
arg:1 
side-effects
arg:0 
arg:1 
constant arg:0 >
arg:2 
arg:3 
readonly arg:0 
pr103984.C:30:7 start: pr103984.C:30:7 finish:
pr103984.C:30:9>>
arg:2 
side-effects nothrow
fn 
constant arg:0 >
arg:0 
arg:0 >>
pr103984.C:30:14 start: pr103984.C:30:7 finish:
pr103984.C:30:15>>
pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1>
stmt 
side-effects static arg:0 
arg:1 
arg:2 
side-effects arg:0 
arg:1 
side-effects nothrow
fn 
constant arg:0 >
arg:0 

arg:0 
arg:0  arg:1
>>>
arg:2 
constant>>
pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1>
stmt 
side-effects
arg:0 
side-effects
arg:0 
arg:0  arg:1 >
arg:1 
side-effects
fn 
constant arg:0 >
arg:0 
side-effects
arg:0 
side-effects tree_0 arg:0  arg:1 >>
pr103984.C:31:15 start: pr103984.C:31:7 finish:
pr103984.C:31:19>>
pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1>
stmt 
side-effects arg:0 
arg:1 
pr103984.C:35:1 start: pr103984.C:35:1 finish: pr103984.C:35:1>>
arg:2 
side-effects nothrow
fn 
constant arg:0 >
arg:0 
arg:0 >>
pr103984.C:29:28 start: pr103984.C:29:28 finish: pr103984.C:32:3>

i.e. the ~Z () is a cleanup is outer, while the ~string ()
cleanup is on an TARGET_EXPR inside of it (the one with D.31544 var).
But the inner TARGET_EXPR has CLEANUP_EH_ONLY set on it, while the outer one
(with D.31524 var) doesn't.
Jason, is there any way how to arrange for such cases (with help of the C++ FE,
say with some new flag on something or just pure gimplifier) to defer the
D.31524 clobber only to outside of where the eh only cleanup is handled (that
is on the enclosing CLEANUP_POINT_EXPR, right?)?

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

2022-03-15 Thread avi at scylladb dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #21 from Avi Kivity  ---
Benno, many thanks for the fix. Please consider posting it to gcc-patches as
that may speed up review and merging.

[Bug fortran/104927] Invalid array size specification accepted

2022-03-15 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
A sure that code is invalid.  F2018, p. 92.

The type declaration statement also specifies the attributes whose keywords
appear in the attr-spec, except that the DIMENSION attribute can be specified
or overridden for an entity by the appearance of array-spec in its entity-decl,
...

Modifying your code to


  program test_invalid_shape

  implicit none

  integer, dimension(3,3) :: a(4)
  integer, dimension(3)   :: b(2,2)
  integer, dimension(3,3) :: c(6,6)

  print *, 'shape(a) = ',shape(a) 
  print *, 'shape(b) = ',shape(b) 
  print *, 'shape(c) = ',shape(c) 

  end program test_invalid_shape

gives

 shape(a) =4
 shape(b) =2   2
 shape(c) =6   6

which is in line with the words from the Fortran standard.

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

--- Comment #12 from Jakub Jelinek  ---
In particular, in ehcleanup1 it is the sink_clobbers optimization added for
PR51117.
I think it would be strongly preferrable to fix this in the FE, because if we'd
need to change sink_clobbers, I'd be afraid we'd get significantly worse code
generation with -flifetime-dse than before.

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

--- Comment #11 from Jakub Jelinek  ---
And it is ehcleanup that sinks the clobber.  Before ehcleanup1 we have:
;;   basic block 16, loop depth 0, maybe hot
;;prev block 15, next block 17, flags: (NEW, REACHABLE, VISITED)
;;pred:   15 (EH,EXECUTABLE)
:
  D.31524 ={v} {CLOBBER(eol)};
  resx 10
;;succ:   17 (EH,EXECUTABLE)

;;   basic block 17, loop depth 0, maybe hot
;;prev block 16, next block 18, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 (EH,EXECUTABLE)
;;16 (EH,EXECUTABLE)
  # _3 = PHI <1(4), 0(16)>
:
  D.31523 ={v} {CLOBBER(eol)};
  resx 9
;;succ:   18 (EH,EXECUTABLE)

;;   basic block 18, loop depth 0, maybe hot
;;prev block 17, next block 19, flags: (NEW, REACHABLE, VISITED)
;;pred:   17 (EH,EXECUTABLE)
:
  if (_3 != 0)
goto ; [INV]
  else
goto ; [INV]
;;succ:   19 (TRUE_VALUE,EXECUTABLE)
;;22 (FALSE_VALUE,EXECUTABLE)

;;   basic block 19, loop depth 0, maybe hot
;;prev block 18, next block 20, flags: (NEW, REACHABLE, VISITED)
;;pred:   18 (TRUE_VALUE,EXECUTABLE)
  _55 = MEM[(const struct basic_string *)]._M_dataplus._M_p;

so at this point, if we enter bb 17 from the edge from bb 4, D.31524 isn't
clobbered and the
_55 load is done (and conditional operator delete later), if we enter bb 16
then D.31524 is clobbered and then _3 is 0 and we don't try to delete it again.
But ehcleanup1, probably on the assumption that such conditional cleanups
aren't valid, turns that into:
...
;;   basic block 14, loop depth 0, maybe hot
;;prev block 13, next block 15, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 (EH,EXECUTABLE)
;;13 (EH,EXECUTABLE)
  # _3 = PHI <1(4), 0(13)>
:
  D.31524 ={v} {CLOBBER(eol)};
  D.31523 ={v} {CLOBBER(eol)};
  if (_3 != 0)
goto ; [INV]
  else
goto ; [INV]
;;succ:   15 (TRUE_VALUE,EXECUTABLE)
;;18 (FALSE_VALUE,EXECUTABLE)

;;   basic block 15, loop depth 0, maybe hot
;;prev block 14, next block 16, flags: (NEW, REACHABLE, VISITED)
;;pred:   14 (TRUE_VALUE,EXECUTABLE)
  _55 = MEM[(const struct basic_string *)]._M_dataplus._M_p;
i.e. now D.31524 ={v} {CLOBBER(eol)}; is done no matter which path we enver
that bb from and then uninit pass is right about the warning, because
the _55 = MEM... load reads an uninitialized var.

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

2022-03-15 Thread poulhies at adacore dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744

--- Comment #18 from Marc Poulhiès  ---
Solved our regressions in  pr99744-{1,2,4,5}.c, thanks!

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

2022-03-15 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744

--- Comment #17 from H.J. Lu  ---
(In reply to Marc Poulhiès from comment #16)
> Hi!
> I'm seeing regressions in pr99744-{1,2,4,5}.c for an i586 target where
> MMX/SSE are not enabled.

Please try

https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591716.html

[Bug c++/69623] Invalid deduction of non-trailing template parameter pack

2022-03-15 Thread xmh970252187 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623

--- Comment #9 from jim x  ---
After reading [temp.deduct.call] p1 more carefully, I think you're right. Since
the first function parameter pack does not participate in template argument
deduction, the deduction will start to perform from the second function
parameter to the last.

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329-g4f6bc28fc7dd86bd

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984

--- Comment #10 from Jakub Jelinek  ---
What the C++ FE emits looks just weird to me.  In the gimple dump:
[pr103984.C:35:1] D.31524.name = string_piece::str
([pr103984.C:35:1] ); [return slot optimization]
[pr103984.C:35:1] D.31544 = 1;
[pr103984.C:29:27] try
  {
[pr103984.C:31:15] string_piece::string_piece
([pr103984.C:31:15] , [pr103984.C:31:16] );
try
  {
[pr103984.C:31:15] _2 = to_stage ([pr103984.C:31:15]
);
[pr103984.C:35:1] D.31524.stage = _2;
[pr103984.C:35:1] D.31544 = 0;
try
  {
try
  {
[pr103984.C:29:27]
std::vector::emplace_back ([pr103984.C:29:27] _files,
[pr103984.C:29:28] );
  }
finally
  {
[pr103984.C:29:28] Z::~Z ([pr103984.C:29:28]
);
  }
  }
finally
  {
[pr103984.C:29:28] D.31524 = {CLOBBER(eol)};
  }
  }
finally
  {
[pr103984.C:31:15] D.31523 = {CLOBBER(eol)};
  }
  }
catch
  {
[pr103984.C:35:1] if (D.31544 != 0) goto ; else
goto ;
:
[pr103984.C:35:1]
std::__cxx11::basic_string::~basic_string ([pr103984.C:35:1]
);
goto ;
:
:
  }
Note the D.31524 CLOBBER being added only conditionally (if string_piece ctor
doesn't throw), while if it throws, there is a dtor on its element after that
and
no CLOBBER.  The first spot that initializes part of the D.31524 temporary is
the above first line, so it would make more sense to me to wrap this whole
sequence above into try { ... } finally { [pr103984.C:29:28] D.31524 =
{CLOBBER(eol)}; } and remove the inner try finally that does that.

[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.

2022-03-15 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911

--- Comment #5 from Iain Buclaw  ---
(In reply to Rainer Orth from comment #4)
> typesem.s indeed shows small codegen differences, while for semantic3.s
> there are
> both codegen differences per se as well as label renamings that may not
> effect the
> object files.
With typesem.s, it looks like `byte.min' (-128) is being turned into 128
somewhere.  Though I can't see how any change in the front-end would have
caused that.

With semantic3.s, it looks like the middle-end optimizer is removing some
branches as dead code, when there should be no way it would possibly be able to
infer that.

[Bug target/104923] [11/12 Regression] MMA __builtin_mma_disassemble_acc test case ICEs in LRA

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104923

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r12-7657-gb5baf569f77e1f172061642d4d8593e1ea737add
Author: Peter Bergner 
Date:   Tue Mar 15 08:46:47 2022 -0500

rs6000: Fix invalid address passed to __builtin_mma_disassemble_acc
[PR104923]

The mma_disassemble_output_operand predicate is too lenient on the types
of addresses it will accept, leading to combine creating invalid address
that eventually lead to ICEs in LRA.  The solution is to restrict the
addresses to indirect, indexed or those valid for quad memory accesses.

2022-03-15  Peter Bergner  

gcc/
PR target/104923
* config/rs6000/predicates.md (mma_disassemble_output_operand):
Restrict
acceptable MEM addresses.

gcc/testsuite/
PR target/104923
* gcc.target/powerpc/pr104923.c: New test.

[Bug sanitizer/104934] -fsanitize=undefined codegen err

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934

--- Comment #1 from Jakub Jelinek  ---
And the bug is?
The S class doesn't have the key method defined, so some other TU needs to
define it and thus provide the vtable and rtti for it.
Without -fsanitize=vptr the typeinfo isn't needed on this particular testcase
and the vtable isn't needed either, which is why you don't get an undefined
symbol in that case and you get it with -fsanitize=vptr or -fsanitize=undefined
that implies that.

[Bug target/104768] [nvptx] Exploit Independent Thread Scheduling for sm_70+

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104768

--- Comment #1 from Tom de Vries  ---
Hmm, reading about it a bit more, it's more about enabling algorithms that were
not possible before, than about performance improvements.

So, we should aim at having test-cases, both openacc and openmp that hang on
previous architectures but pass with sm_70+.

[Bug target/104893] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -msoft-stack

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104893

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> The per-thread call stack is handled for .local memory by the CUDA driver.
> 
> For the 'soft stack' that's not the case.

Hmm, actually there's .local memory used, just not "directly".  Possibly the
documentation needs updating to point that out.

So, there doesn't seem to be an issue related to overlapping storage.

So I wonder, is the stack pointer also per thread then? Or still per-warp?

[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931

--- Comment #2 from Richard Biener  ---
But maybe the code relies on a positive 'delta' - after all the same issue must
exist for integer typed IVs.  Probably most interesting cases get folded early
in the correct way if they do not iterate.

Given niter_type is unsigned_type_for (type) the use of FLOOR_MOD_EXPR seems
pointless but would be required when doing a signed floor-mod as in the fix.

Note there's


  tree niter_type = TREE_TYPE (step);
  tree mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step);
..
  if (integer_nonzerop (mod))
mod = fold_build2 (MINUS_EXPR, niter_type, step, mod);
..
  mpz_init (mmod);
  wi::to_mpz (wi::to_wide (mod), mmod, UNSIGNED);
  mpz_neg (mmod, mmod);

so there's evidence that 'mod' is assumed to be positive in the end but
'delta' can be effectively signed here.  Note 'step' is the absolute
value of step, it's always (made) positive.

The code has been this way since Zdenek wrote it.

The proposed patch has passed bootstrap & testing (but I believe it's
incomplete).

[Bug target/104666] [12 Regression] ICE in related_vector_mode, at stor-layout.c:537

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104666

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
.

[Bug tree-optimization/104935] [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935

--- Comment #2 from Martin Liška  ---
And the revision is also responsible for slower build time here of 481.wrf:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.270.8

[Bug c++/103177] incorrect error message for ambiguous lookup with a static member function from a private base

2022-03-15 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103177

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/103177] incorrect error message for ambiguous lookup with a static member function from a private base

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103177

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

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

commit r12-7656-gffe9c0a0d3564a6083ea6194eb3374a89c29c085
Author: Patrick Palka 
Date:   Tue Mar 15 08:50:24 2022 -0400

c++: extraneous access error with ambiguous lookup [PR103177]

When a lookup is ambiguous, lookup_member still attempts to check
access of the first member found before diagnosing the ambiguity and
propagating the error, and this may cause us to issue an extraneous
access error as in the testcase below (for B1::foo).

This patch fixes this by swapping the order of the ambiguity and access
checks within lookup_member.  In passing, since the only thing that could
go wrong during lookup_field_r is ambiguity, we might as well hardcode
that in lookup_member and get rid of lookup_field_info::errstr.

PR c++/103177

gcc/cp/ChangeLog:

* search.cc (lookup_field_info::errstr): Remove this data
member.
(lookup_field_r): Don't set errstr.
(lookup_member): Check ambiguity before checking access.
Simplify accordingly after errstr removal.  Exit early upon
error or empty result.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/ambig6.C: New test.

[Bug target/91229] RISC-V ABI problem with zero-length bit-fields and float struct fields

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229

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

https://gcc.gnu.org/g:98afdc3e2bfccf0a1337013b54f2c5634ef40ee5

commit r12-7655-g98afdc3e2bfccf0a1337013b54f2c5634ef40ee5
Author: Jakub Jelinek 
Date:   Tue Mar 15 13:34:33 2022 +0100

riscv: Allow -Wno-psabi to turn off ABI warnings [PR91229]

While checking if all targets honor -Wno-psabi for ABI related warnings
or messages, I found that almost all do, except for riscv.
In the testsuite when we want to ignore ABI related messages we
typically use -Wno-psabi -w, but it would be nice to get rid of those
-w uses eventually.

The following allows silencing those warnings with -Wno-psabi rather than
just -w even on riscv.

2022-03-15  Jakub Jelinek  

PR target/91229
* config/riscv/riscv.cc (riscv_pass_aggregate_in_fpr_pair_p,
riscv_pass_aggregate_in_fpr_and_gpr_p): Pass OPT_Wpsabi instead of
0
to warning calls.

[Bug tree-optimization/104935] [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

--- Comment #1 from Richard Biener  ---
Possibly back to the level it had before (or with GCC 11).  There's likely
quite some changes, somebody needs to extract examples.

[Bug rtl-optimization/104814] [10/11 Regression] ifcvt: Deleting live variable in IF-CASE-2

2022-03-15 Thread stefansf at linux dot ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814

--- Comment #7 from Stefan Schulze Frielinghaus  
---
Gave trunk a try and it worked fine for me.  Thanks for the fix!

[Bug tree-optimization/104935] New: [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935

Bug ID: 104935
   Summary: [12 Regression] 554.roms_r ELF binary increased with
r12-7612-g69619acd8d9b5856
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

Can be seen here:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=475.528.4

increased (w/o debug info) from 1316272 B to 1414656 B.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug sanitizer/104934] New: -fsanitize=undefined codegen err

2022-03-15 Thread dimhen at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104934

Bug ID: 104934
   Summary: -fsanitize=undefined codegen err
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

r12-7608 FAIL

Probably FAIL long ago: gcc-8 FAIL
gcc version 8.0.1 20180125 (experimental) [trunk revision 257061] (GCC)


$ g++ -fsanitize=undefined -c -o x.o x.ii && nm -u --reverse-sort x.o
 U _ZTI1S
$ g++ -c -o x.o x.ii && nm -u --reverse-sort x.o

$ cat x.ii
struct a {};
struct b {
  a c;
};
struct S : a {
  virtual int d();
};
struct e : b {
  unsigned f();
};
unsigned e::f() { static_cast(); return 0; }

$ ~/arch-gcc/gcc_current/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native
--enable-libstdcxx-debug
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220311 (experimental) [master r12-7608-g5e28be89665] (GCC)

[Bug target/104933] New: [nvptx] muniform-simt optimization: determine inside/outside SIMT region at compile time

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104933

Bug ID: 104933
   Summary: [nvptx] muniform-simt optimization: determine
inside/outside SIMT region at compile time
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The switch -muniform-simt attempts to deal with a problem outside simt regions
by rewriting the instruction stream.

In the general case we don't know for an insn whether it's inside or outside an
simt region, so the reorg pass nvptx_reorg_uniform_simt rewrites all insns.

However, inside the simt regions, the rewrite should have no effect, and this
is done by maintaining predicates in some registers which have different values
inside and outside an simt region.

But for a function that contains SIMT entry/exit markers, we do known whether
an insn is inside or outside and SIMT region, and we could evaluate these
predicates at compile time, which might be more optimal, and might make the
code more readable.

[Bug target/104482] ICE: Segmentation fault (in rs6000_builtin_type_compatible), or ICE: tree check: expected class 'type', have 'reference' (attr_addr_expr) in cp_type_quals, at cp/typeck.cc:10955

2022-03-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482

--- Comment #2 from Kewen Lin  ---
One fix has been posted via
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591768.html

[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.

2022-03-15 Thread ro at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911

--- Comment #4 from Rainer Orth  ---
Created attachment 52630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52630=edit
stage 2 and 3 objects and assembler output

I've now compiled typesem.d and semantic3.d using the stage 1 and 2 gdc
respectively
with -save-temps added (with a source tree as of
1b85638affe6c987a33427c54e0369b819cd7915,
i.e. before the problematic commit, so I could repeat the procedure before and
after with the same sources).

typesem.s indeed shows small codegen differences, while for semantic3.s there
are
both codegen differences per se as well as label renamings that may not effect
the
object files.

[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916

--- Comment #3 from Tom de Vries  ---
Anyway, having reread the volta architecture whitepaper again, I think it's ok
to use the solution I already found that does work (see PR104783): add a warp
sync at simt exit.

The tricky bit is that we rely on the warps to stay uniform after that warp
sync until the next simt region entry.  Which AFAICT is not something enforced
by specification, but rather by a assuming that the 'Convergence optimizer' has
a sane implementation.

[Bug c++/69623] Invalid deduction of non-trailing template parameter pack

2022-03-15 Thread ed at catmur dot uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623

--- Comment #8 from Ed Catmur  ---
(In reply to jim x from comment #7)
> 
> auto f(auto..., auto a, auto...) { return a; }
> 
> IIUC, this is just disallowed since all arguments would only match the first
> function parameter pack.

Maybe? But all 4 major compilers currently permit it (with identical behavior),
so is it worth breaking existing code by disallowing it?

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

2022-03-15 Thread poulhies at adacore dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744

Marc Poulhiès  changed:

   What|Removed |Added

 CC||poulhies at adacore dot com

--- Comment #16 from Marc Poulhiès  ---
Hi!
I'm seeing regressions in pr99744-{1,2,4,5}.c for an i586 target where MMX/SSE
are not enabled.

IIUC, your patch inserts "general-regs-only" in x86gprintrin.h if MMX or SSE is
enabled and makes the inlining of the calls in theses tests (using
target("general-regs-only")) be compatible with the intrinsics defined in the
header.

In my case, MMX/SSE being both disabled, the calls can't be inlined (mismatch
of target options).

Would that still be correct to change the

 #if defined __MMX__ || defined __SSE__

by

 #if defined __i686__

?

[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931

--- Comment #1 from Richard Biener  ---
I think the issue is latent on trunk.  The fix should be

diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index b767056aeb0..21e25cabbd2 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -1171,7 +1171,17 @@ number_of_iterations_lt_to_ne (tree type, affine_iv
*iv0, affine_iv *iv1,
   bool exit_must_be_taken, bounds *bnds)
 {
   tree niter_type = TREE_TYPE (step);
-  tree mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step);
+  tree mod;
+  if (POINTER_TYPE_P (type))
+{
+  /* For pointers both step and delta have to be interpreted signed.  */
+  mod = fold_build2 (FLOOR_MOD_EXPR, ssizetype,
+fold_convert (ssizetype, *delta),
+fold_convert (ssizetype, step));
+  mod = fold_convert (niter_type, mod);
+}
+  else
+mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step);
   tree tmod;
   mpz_t mmod;
   tree assumption = boolean_true_node, bound, noloop;

[Bug target/104932] New: [nvptx] Subreg validation error for V2SI

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104932

Bug ID: 104932
   Summary: [nvptx] Subreg validation error for V2SI
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When building with the patch from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916#c2 , but allowing a shuffle
for V2SImode, we run into an assert when trying to create a subreg here:
...
case E_V2SImode:
  {
rtx src0 = gen_rtx_SUBREG (SImode, src, 0);
rtx src1 = gen_rtx_SUBREG (SImode, src, 4); < HERE >
rtx dst0 = gen_rtx_SUBREG (SImode, dst, 0);
rtx dst1 = gen_rtx_SUBREG (SImode, dst, 4);
...

So, is this code otherwise not triggered and has it bitrotted, or is there
something specific about src that triggers the assert?

Assert looks like:
...
during RTL pass: mach
/home/vries/oacc/trunk/source-gcc/newlib/libc/stdlib/arc4random.c: In function
‘_rs_stir’:
/home/vries/oacc/trunk/source-gcc/newlib/libc/stdlib/arc4random.c:103:1:
internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1022
  103 | }
  | ^
0xde1b17 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>)
/home/vries/oacc/trunk/source-gcc/gcc/emit-rtl.cc:1022
0x197aedc nvptx_gen_shuffle(rtx_def*, rtx_def*, rtx_def*, nvptx_shuffle_kind)
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:2000
0x1981165 nvptx_unisimt_handle_set
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:3303
0x19816af nvptx_reorg_uniform_simt
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:3386
0x1987bb7 nvptx_reorg
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:5773
0x13c3e38 execute
/home/vries/oacc/trunk/source-gcc/gcc/reorg.cc:3927
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
...

The assert is triggered here in emit-rtl.c:
...
  if (maybe_lt (osize, regsize)
  && ! (lra_in_progress && (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode
{
  /* It is invalid for the target to pick a register size for a mode
 that isn't ordered wrt to the size of that mode.  */
  poly_uint64 block_size = ordered_min (isize, regsize);
  unsigned int start_reg;
  poly_uint64 offset_within_reg;
  if (!can_div_trunc_p (offset, block_size, _reg, _within_reg)
  || (BYTES_BIG_ENDIAN
  ? maybe_ne (offset_within_reg, block_size - osize)
  : maybe_ne (offset_within_reg, 0U)))
return false;
}
...

Specifially, this bit returns true, and causes the subreg validation error:
...
  : maybe_ne (offset_within_reg, 0U)))
...

[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-15
  Known to fail||10.3.1, 11.2.1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Keywords||wrong-code
  Known to work||12.0
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/104931] New: wrong-code with number_of_iterations_lt_to_ne

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931

Bug ID: 104931
   Summary: wrong-code with number_of_iterations_lt_to_ne
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The premake tool is miscompiled when building it with LTO on i586-linux,
resulting in it immediately segfaulting via

==9912== Invalid read of size 4
==9912==at 0x8162378: UnknownInlinedFun (lapi.c:197)
==9912==by 0x8162378: lua_rotate.constprop.0 (lapi.c:217)
==9912==by 0x8063881: luaL_requiref (lauxlib.c:983)
==9912==by 0x807DF76: luaL_openlibs (linit.c:64)
==9912==by 0x8061128: main (premake_main.c:15)
==9912==  Address 0x43816dc is 12 bytes before a block of size 408 alloc'd
==9912==at 0x4035EDB: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so)
==9912==by 0x80806A3: luaM_realloc_ (lmem.c:86)
==9912==by 0x807727E: luaD_reallocstack (ldo.c:182)

this can be reproduced with GCC 10 and GCC 11 but not on trunk.  After checking
out https://github.com/premake/premake-core.git do

make -f Bootstrap.mak linux CC="gcc-11 -m32" CFLAGS="-O2 -flto -g"

and ./bin/release/premake will then segfault.

I've narrowed this down to the first IPA CP clone of lua_rotate being
miscompiled, we enter number_of_iterations_lt_to_ne for

  exit condition [(struct TValue *) (_2 + 4294967272) + 12, + ,
24](no_overflow) < _2 + 4294967272

with delta being 4294967284, the step type is unsigned int.  The problem
is that for pointer IVs the step type has to be interpreted as signed, but
the code uses an unsigned FLOOR_MOD to compute the condition under which
the loop will not iterate which it computes to

  result:
zero if (struct TValue *) (_2 + 4294967272) + 12 > _2 + 4294967292
# of iterations 178956971, bounded by 0

which is always false (but not folded).  When making sure to use a signed
type to compute the modulo the miscompile is gone and we manage to
compute the correct

  result:
zero if (struct TValue *) (_2 + 4294967272) + 12 > _2 + 4294967284(OVF)
# of iterations 0(OVF), bounded by 0

I've failed to create a small testcase - there seem to be special circumstances
required that make us enter niter analysis with exactly this SCEV.  The
simplified testcase

struct X { int x[3]; };
static void reverse (struct X *from, struct X *to)
{
  do
{
  struct X temp = *from;
  *from = *to;
  *to = temp;
  from++;
  to--;
}
  while (from < to);
}
void
lua_rotate (struct X **L)
{
  struct X *y = *L;
  struct X *to = y - 1;
  struct X *from = y - 2;
  reverse (from, to);
} 

does not exhibit this problem.

[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781

--- Comment #15 from Jakub Jelinek  ---
r12-7654-gda24fce323eaf088 should fix that.

[Bug target/104916] [nvptx] Handle Independent Thread Scheduling for sm_70+ with -muniform-simt

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916

--- Comment #2 from Tom de Vries  ---
Created attachment 52629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52629=edit
Attempt, runs into driver internal error

FTR, this is an attempt at a fix.

It does the "predicate ld/st to only execute in lane 0, and propagate ld
result", expect for modes where we run into a problem with producing a shuffle
(HFmode, V2SImode), where we use the "wrap each ld/st in two bar.warp.sync"
approach instead.

For libgomp/testsuite/libgomp.c++/target_teams_distribute__parallel_for__simd.C
(copied from OvO) I end up with:
...
Linking
Link complete: 0.00ms
Link log warning : Stack size for entry function
'_Z48test_target_teams_distribute__parallel_for__simdv$_omp_fn$0' cannot be
statically determined

libgomp: Link error log fatal   : Internal error: reference to deleted section
...

This may be due to a problem with the patch or the driver, I'm not sure.

[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap

2022-03-15 Thread drepper.fsp+rhbz at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781

Ulrich Drepper  changed:

   What|Removed |Added

 CC||drepper.fsp+rhbz at gmail dot 
com

--- Comment #14 from Ulrich Drepper  ---
My standard build now fails in stage 1 with this patch when compiling
unwind-dw2.c for x86:

.../gcc-builds/20220315/gcc/include/cetintrin.h: In function
‘_Unwind_RaiseException’:
.../gcc-builds/20220315/gcc/include/cetintrin.h:47:1: error: inlining failed in
call to ‘always_inline’ ‘_get_ssp’: target specific option mismatch
   47 | _get_ssp (void)
  | ^~~~
.../gnu/gcc/libgcc/config/i386/shadow-stack-unwind.h:32:26: note: called from
here
   32 |   _Unwind_Word ssp = _get_ssp ();   \
  |  ^~~
.../gnu/gcc/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro
‘_Unwind_Frames_Extra’
 1654 |   _Unwind_Frames_Extra (FRAMES);   
\
  |   ^~~~
.../gnu/gcc/libgcc/unwind.inc:140:3: note: in expansion of macro
‘uw_install_context’
  140 |   uw_install_context (_context, _context, frames);


and so on for the other CET functions.  When I comment out the
LIBGCC2_UNWIND_ATTRIBUTE definition in config/i386/i386.h it works.

The compiler command line that is used is

.../gcc-builds/20220315/./gcc/xgcc -B.../gcc-builds/20220315/./gcc/
-B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem
/usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include 
 -fno-checking -g -O2 -m32 -O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../../.././gcc -I.../gcc/libgcc
-I.../gcc/libgcc/. -I.../gcc/libgcc/../gcc -I.../gcc/libgcc/../include
-I.../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
-DUSE_TLS  -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep
-fexceptions -c .../gcc/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS

This is on an up-to-date Fedora 35 system with gcc 11.2.1-9

[Bug target/104930] built-in function requires "-flax-vector-conversions" to get better warning

2022-03-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930

--- Comment #2 from Kewen Lin  ---
It's regressed from r12-5752-gd08236359eb229, in the new bif infrastructure we
don't use the type opaque_V4SI_type_node for prototype of overloaded built-in
functions any more.

[Bug sanitizer/104929] UBSAN: false positive with sprintf

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929

--- Comment #3 from Jakub Jelinek  ---
In this particular case the problem is that UBSAN adds the non-NULL tests, so
the IL becomes if (!s) __ubsan_handle_nonnull_arg (...); sprintf(s,  " "); if
(!s) __ubsan_handle_nonnull_arg (...); return __builtin_strlen(s);
and then jump threading thinks it is a good idea to thread it, so turns it into
if (!s) { __ubsan_handle_nonnull_arg (...); sprintf(NULL, " ");
__ubsan_handle_nonnull_arg (...); } else sprintf(s, " ");
and that is why the warning is emitted (pain of all the middle-end warnings).
The ways out of this might be convince jump threading to punt in such cases
(when  those are clearly ubsan tests) because we expect them to be extremely
unlikely,
or use some new internal function from between the ubsan pass and sanopt, where
the test for non-NULL wouldn't be explicit in the IL until very late (that
would also prevent the jump threading), or during the jump threading when we
detect these ubsan-ish tests suppress some of the warnings on the threaded
stmts.

[Bug target/104930] built-in function requires "-flax-vector-conversions" to get better warning

2022-03-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930

Kewen Lin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
Although it's related to error messages change and users can get more
reasonable error messages with extra option -flax-vector-conversions, I think
we still want the previous behavior?

[Bug target/104930] New: built-in function requires "-flax-vector-conversions" to get better warning

2022-03-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104930

Bug ID: 104930
   Summary: built-in function requires "-flax-vector-conversions"
to get better warning
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

- Test case -

$cat new_test.c

typedef vector unsigned int v4u;

extern v4u vg;

v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }

- Option -

-mcpu=power9

===

GCC emits:

new_test.c: In function ‘testXXPERMDI’:
new_test.c:5:1: note: use ‘-flax-vector-conversions’ to permit conversions
between vectors with differing element types or numbers of subparts
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
  | ^~~
new_test.c:5:56: error: incompatible type for argument 1 of
‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
  |^~
  ||
  |v4u {aka
__vector(4) unsigned int}
new_test.c:5:56: note: expected ‘__vector signed char’ {aka ‘__vector(16)
signed cha ’} but argument is of type ‘v4u’ {aka ‘__vector(4) unsigned int’}
new_test.c:5:60: error: incompatible type for argument 2 of
‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
  |^~
  ||
  |v4u {aka
__vector(4) unsigned int}
new_test.c:5:60: note: expected ‘__vector signed char’ {aka ‘__vector(16)
signed cha ’} but argument is of type ‘v4u’ {aka ‘__vector(4) unsigned int’}
new_test.c:5:33: error: too few arguments to function ‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
  | ^~

But with r12-5751-gc9dd01314d8467, it only has:

new_test.c: In function ‘testXXPERMDI’:
new_test.c:5:33: error: too few arguments to function ‘__builtin_vsx_xxpermdi’
5 | v4u testXXPERMDI(void) { return __builtin_vsx_xxpermdi(vg, vg); }
  | ^~

[Bug sanitizer/104929] UBSAN: false positive with sprintf

2022-03-15 Thread schwab--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929

--- Comment #2 from Andreas Schwab  ---
I think the point here is that s is not guaranteed to be non-NULL.  You can add 
if (s == 0) __builtin_unreachable();
to suppress the warning.

[Bug sanitizer/104929] UBSAN: false positive with sprintf

2022-03-15 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929

--- Comment #1 from Martin Liška  ---
It's a quite known limitation that usage of sanitizers tends to emit false
positives of various warnings.

[Bug sanitizer/104929] New: UBSAN: false positive with sprintf

2022-03-15 Thread jengelh at inai dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929

Bug ID: 104929
   Summary: UBSAN: false positive with sprintf
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

// g++ -Wall -fsanitize=undefined -O2 -c t.cpp
#include 
size_t fun(char *s)
{
sprintf(s, " ");
return __builtin_strlen(s);
}

Observed:
t.cpp: In function ‘size_t fun(char*)’:
t.cpp:5:16: warning: null destination pointer [-Wformat-overflow=]
5 | sprintf(s, " ");
//gcc version 11.2.1 20220103 [revision
d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6] (SUSE Linux), Linux amd64 glibc-2.35

Expected:
Don't warn(?)

[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-cet --with-arch-32=i686)

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890

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

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

commit r12-7654-gda24fce323eaf088239e0f900dd23f6b05d552c1
Author: Jakub Jelinek 
Date:   Tue Mar 15 10:24:22 2022 +0100

i386: Use no-mmx,no-sse for LIBGCC2_UNWIND_ATTRIBUTE [PR104890]

Regardless of the outcome of the general-regs-only stuff in x86gprintrin.h,
apparently general-regs-only is much bigger hammer than no-sse, and e.g.
using 387 instructions in the unwinder isn't a big deal, it never needs
to realign the stack because of it.

So, the following patch uses no-sse (and adds no-mmx to it, even when not
strictly needed).

2022-03-15  Jakub Jelinek  

PR target/104890
* config/i386/i386.h (LIBGCC2_UNWIND_ATTRIBUTE): Use no-mmx,no-sse
instead of general-regs-only.

[Bug tree-optimization/104917] No runtime alias test required for dependent reductions

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104917

--- Comment #2 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #1)
> What if x = y + 1 or y = x + 1 ?

We then do

  (y+1)[i] += a[i];
  (y+1)[i+1] += a[i+1];
  y[i] += a[i];
  y[i+1] += a[i+1];

instead of

  (y+1)[i] += a[i];
  y[i] += a[i];
  (y+1)[i+1] += a[i+1];
  y[i+1] += a[i+1];

which should be OK if re-associating the adds to y[i+1] is OK.

[Bug libstdc++/104928] std::counting_semaphore on Linux can sleep forever

2022-03-15 Thread angelsl at in04 dot sg via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928

--- Comment #1 from Tee Hao Wei  ---
Created attachment 52628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52628=edit
Preprocessed, gzipped reproducer

[Bug libstdc++/104928] New: std::counting_semaphore on Linux can sleep forever

2022-03-15 Thread angelsl at in04 dot sg via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928

Bug ID: 104928
   Summary: std::counting_semaphore on Linux can sleep forever
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: angelsl at in04 dot sg
  Target Milestone: ---

The __atomic_semaphore implementation of std::counting_semaphore can sometimes
sleep forever, especially when there is high contention.

Here is a possible sequence of events that can lead to the issue:

1. _M_counter is 1.
2. thread A enters (semaphore_base.h) _M_acquire -> (atomic_wait.h)
__atomic_wait_address_bare -> _S_do_spin.
3. In _S_do_spin, thread A does __atomic_load on _M_counter and reads 1.
4. A different thread manages to decrement the semaphore. _M_counter is now 0.
5. Thread A enters __atomic_spin, and all calls to __pred (which just does
_S_do_try_acquire) fail, since _M_counter is now 0. Thread A returns from
__atomic_spin and _S_do_spin with false.
6. Another thread signals the semaphore. _M_counter is back to 1.
7. Thread A returns to __atomic_wait_address_bare and proceeds to call
__platform_wait using the value of _M_counter read in step 3 (= 1).
8. In __platform_wait, thread A calls futex on _M_counter with WAIT_PRIVATE and
value 1. Since _M_counter is still 1, the kernel puts thread A to sleep.
9. Unless the semaphore later reaches 0 again, thread A will never be awoken
since _M_release does not call futex WAKE unless the counter is 0.

This is sort of an ABA problem. I think the most proper solution would be to
make it so that futex is called with value 0 (since that is what we are waiting
for _M_counter to change from). But it will need some restructuring to the
current abstractions over futex that are being used here.

Here is an almost 100%-reliable minimal reproducible example for the issue:

---
// g++ -O2 -std=c++20 -o hang hang.cpp
#include 
#include 
#include 
#include 

int main(int argc, char *argv[]) {
  std::counting_semaphore s{0};
  std::vector threads;
  for (size_t i = 0; i < 10; ++i) {
threads.emplace_back([]() {
  for (size_t i = 0; i < 100; ++i) {
s.acquire();
  }
});
threads.emplace_back([]() {
  for (size_t i = 0; i < 100; ++i) {
s.release();
  }
});
  }
  for (auto  : threads) t.join();
  return 0;
}
---

If you run it, you will observe one or two acquirer threads sleeping
indefinitely at the end. If you observe them in gdb, you will see that they are
waiting on futex, and also that the semaphore counter is actually positive.

Other notes:
- This probably affects the implementation of atomic::wait as well, but I have
not tried that.
- FWIW, libc++ also has this exact issue, but they sidestep it by passing a
timeout to futex(). I don't know whether specifying a timeout was done
intentionally to avoid this issue. I also don't personally think that that is a
great solution to this. (If you run the MRE with clang++ -stdlib=libc++, you
will observe the issue manifesting as some acquirer threads sleeping for a few
seconds until the futex timeout expires.)

System information:

Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

I have attached the preprocessed version of the above MRE.

[Bug tree-optimization/104917] No runtime alias test required for dependent reductions

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104917

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
What if x = y + 1 or y = x + 1 ?

[Bug tree-optimization/101895] [11/12 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:49fb0af9bf8f16907980d383c2bbc85e185ec2e0

commit r12-7653-g49fb0af9bf8f16907980d383c2bbc85e185ec2e0
Author: Roger Sayle 
Date:   Tue Mar 15 09:05:28 2022 +

PR tree-optimization/101895: Fold VEC_PERM to help recognize FMA.

This patch resolves PR tree-optimization/101895 a missed optimization
regression, by adding a costant folding simplification to match.pd to
simplify the transform "mult; vec_perm; plus" into "vec_perm; mult; plus"
with the aim that keeping the multiplication and addition next to each
other allows them to be recognized as fused-multiply-add on suitable
targets.  This transformation requires a tweak to match.pd's
vec_same_elem_p predicate to handle CONSTRUCTOR_EXPRs using the same
SSA_NAME_DEF_STMT idiom used for constructors elsewhere in match.pd.

The net effect is that the following code example:

void foo(float * __restrict__ a, float b, float *c) {
  a[0] = c[0]*b + a[0];
  a[1] = c[2]*b + a[1];
  a[2] = c[1]*b + a[2];
  a[3] = c[3]*b + a[3];
}

when compiled on x86_64-pc-linux-gnu with -O2 -march=cascadelake
currently generates:

vbroadcastss%xmm0, %xmm0
vmulps  (%rsi), %xmm0, %xmm0
vpermilps   $216, %xmm0, %xmm0
vaddps  (%rdi), %xmm0, %xmm0
vmovups %xmm0, (%rdi)
ret

but with this patch now generates the improved:

vpermilps   $216, (%rsi), %xmm1
vbroadcastss%xmm0, %xmm0
vfmadd213ps (%rdi), %xmm0, %xmm1
vmovups %xmm1, (%rdi)
ret

2022-03-15  Roger Sayle  
Marc Glisse  
Richard Biener  

gcc/ChangeLog
PR tree-optimization/101895
* match.pd (vec_same_elem_p): Handle CONSTRUCTOR_EXPR def.
(plus (vec_perm (mult ...) ...) ...): New reordering
simplification.

gcc/testsuite/ChangeLog
PR tree-optimization/101895
* gcc.target/i386/pr101895.c: New test case.

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I.e. r11-2768-g95f17e26112d8a0700e so that it works as a hyperlink.

[Bug c++/104847] [11/12 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104847

--- Comment #3 from Jakub Jelinek  ---
Though the nontype-class-union1.C testcase doesn't have explicit designator
syntax either.

[Bug c++/104847] [11/12 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104847

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
struct S { int i; };
union U { S k; };
template  T sink(T&&, Ts&&...);
template 
decltype(sink(U{.k={.i=1}},T())) f(T) { return U{1}; }
int main() { f(3); }

compiles fine.  I guess the question is if ce->index == NULL should be mangled
without the di production of , or we should implicitly find
the first initializable field and use that with di, i.e. if this should mangle
as
_Z1fIiEDTcl4sinktl1Udi1kilLi1EEEcvT__EEES1_
or as
_Z1fIiEDTcl4sinktl1ULi1EEcvT__EEES1_

[Bug fortran/104927] New: Invalid array size specification accepted

2022-03-15 Thread federico.perini at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927

Bug ID: 104927
   Summary: Invalid array size specification accepted
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.perini at gmail dot com
  Target Milestone: ---

Created attachment 52627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52627=edit
test program

A low priority bug, I guess.

The following invalid code with double array size specifications is accepted by
gfortran 10.3.0 all the way down to at least 8.1.0:

integer, allocatable, dimension(:,:) :: a(:)
integer, allocatable, dimension(:)   :: b(:,:)
integer, allocatable, dimension(:,:) :: c(:,:)

It appears that the shape then picked by gfortran is that on the right hand
side, but no errors/warning are printed. I've attached a test program for this.

Thanks for the hardwork on gfortran!
Federico

[Bug target/104926] New: [nvptx] Use human-readable register names

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104926

Bug ID: 104926
   Summary: [nvptx] Use human-readable register names
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There are some pseudo registers that are used for a specific function, like
cfun->machine->unisimt_outside_simt_predicate.

It would be good to print these as '%outside_simt_p' or '%r_outside_simt_p' or
some such.

Perhaps the latter is better, to be able to easily distinguish them from ptx
special registers like '%tid'.

[Bug rtl-optimization/104637] [9/10/11 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE:
   |ICE: maximum number of LRA  |maximum number of LRA
   |assignment passes is|assignment passes is
   |achieved (30) with -Og  |achieved (30) with -Og
   |-fno-forward-propagate  |-fno-forward-propagate
   |-mavx since |-mavx since
   |r9-5221-gd8fcab689435a29d   |r9-5221-gd8fcab689435a29d

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug target/104925] New: [nvptx] Use "%" as register prefix

2022-03-15 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104925

Bug ID: 104925
   Summary: [nvptx] Use "%" as register prefix
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In the ptx isa doc I read:
...
PTX allows the percentage sign as the first character of an identifier. The
percentage sign can be used to avoid name conflicts, e.g., between user-
defined variable names and compiler-generated names.
...

I've been using variable names for for instance temporary variables in various
insn patterns without percentage signs, so there's the potential for a clash
with user-defined names.

This should be fixed by prefixing with '%'.

[Bug rtl-optimization/104814] [10/11 Regression] ifcvt: Deleting live variable in IF-CASE-2

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression] ifcvt:
   |ifcvt: Deleting live|Deleting live variable in
   |variable in IF-CASE-2   |IF-CASE-2

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/104623] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.cc:4107

2022-03-15 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104623

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE in   |[11 Regression] ICE in
   |cp_parser_skip_to_pragma_eo |cp_parser_skip_to_pragma_eo
   |l, at cp/parser.cc:4107 |l, at cp/parser.cc:4107

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.
It is ice-on-invalid-code, so I'm a hesistant to backport this.

[Bug c++/104623] [11/12 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.cc:4107

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104623

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

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

commit r12-7652-gefd1582926f3278a5e57ebab7d87fc870f06ecea
Author: Jakub Jelinek 
Date:   Tue Mar 15 09:15:27 2022 +0100

c++: Fix up cp_parser_skip_to_pragma_eol [PR104623]

We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it calls
cp_parser_skip_to_pragma_eol, which calls cp_lexer_purge_tokens_after.
That call purges all the tokens from CPP_PRAGMA until CPP_PRAGMA_EOL,
excluding the initial CPP_PRAGMA though (but including the final
CPP_PRAGMA_EOL).  This means the second time we parse this, we see
CPP_PRAGMA with no tokens after it from the pragma, most importantly
not the CPP_PRAGMA_EOL, so either if it is the last pragma in the TU,
we ICE, or if there are other pragmas we treat everything in between
as a pragma.

I've tried various things, including making the CPP_PRAGMA token
itself also purged, or changing the cp_parser_skip_to_end_of_statement
(and cp_parser_skip_to_end_of_block_or_statement) to call it with
NULL instead of token, so that this purging isn't done there,
but each patch resulted in lots of regressions.
But removing the purging altogether surprisingly doesn't regress anything,
and I think it is the right thing, if we e.g. parse tentatively, why can't
we parse the pragma multiple times or at least skip over it?

2022-03-15  Jakub Jelinek  

PR c++/104623
* parser.cc (cp_parser_skip_to_pragma_eol): Don't purge any tokens.

* g++.dg/gomp/pr104623.C: New test.

[Bug rtl-optimization/104814] [10/11/12 Regression] ifcvt: Deleting live variable in IF-CASE-2

2022-03-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814

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

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

commit r12-7651-ga2645cd8fb33b36d737b310e26f4c47401305c7b
Author: Jakub Jelinek 
Date:   Tue Mar 15 09:12:03 2022 +0100

ifcvt: Punt if not onlyjump_p for find_if_case_{1,2} [PR104814]

find_if_case_{1,2} implicitly assumes conditional jumps and rewrites them,
so if they have extra side-effects or are say asm goto, things don't work
well, either the side-effects are lost or we could ICE.
In particular, the testcase below on s390x has there a doloop instruction
that decrements a register in addition to testing it for non-zero and
conditionally jumping based on that.

The following patch fixes that by punting for !onlyjump_p case, i.e.
if there are side-effects in the jump instruction or it isn't a plain PC
setter.

Also, it assumes BB_END (test_bb) will be always non-NULL, because basic
blocks with 2 non-abnormal successor edges should always have some
instruction
at the end that determines which edge to take.

2022-03-15  Jakub Jelinek  

PR rtl-optimization/104814
* ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb
doesn't
end with onlyjump_p.  Assume BB_END (test_bb) is always non-NULL.

* gcc.c-torture/execute/pr104814.c: New test.

[Bug target/104923] [11/12 Regression] MMA __builtin_mma_disassemble_acc test case ICEs in LRA

2022-03-15 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104923

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.0|11.3
   Priority|P3  |P2
Summary|MMA |[11/12 Regression] MMA
   |__builtin_mma_disassemble_a |__builtin_mma_disassemble_a
   |cc test case ICEs in LRA|cc test case ICEs in LRA

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

2022-03-15 Thread guojiufu at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743

Jiu Fu Guo  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |guojiufu at gcc dot 
gnu.org

--- Comment #4 from Jiu Fu Guo  ---
rot(a)==rot(b_)==> a==rot(b')

  1   2   >