[Bug c/100501] ICE: segmentation fault on embedded asm code

2021-05-12 Thread cnsun at uwaterloo dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100501

--- Comment #3 from Chengnian Sun  ---
A duplicate.

foo() { __asm__("" : : "m"(({}))); }

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-12 Thread lucier at math dot purdue.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

--- Comment #54 from lucier at math dot purdue.edu ---
After an update to Fink's dejagnu, I got similar results.

[Bug c++/100580] New: ICE with -fdump-passes

2021-05-12 Thread fxue at os dot amperecomputing.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580

Bug ID: 100580
   Summary: ICE with -fdump-passes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

Created attachment 50805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50805=edit
Source file

Reproduce ICE using the command:

g++ -fpreprocessed TimeControl.ii -std=c++98 -fdump-passes

[Bug c++/100579] New: [coroutines] Poor codegen using an optional-like type with co_await

2021-05-12 Thread rs2740 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100579

Bug ID: 100579
   Summary: [coroutines] Poor codegen using an optional-like type
with co_await
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

#ifdef __clang__
#include 
namespace stdx = std::experimental;
#else
#include 
namespace stdx = std;
#endif
struct O {
 ~O() {}
 struct promise_type {
 O get_return_object() { return O{this};}
 stdx::suspend_never initial_suspend() { return {}; }
 stdx::suspend_never final_suspend() noexcept { return {}; }
 void return_void(){ value->b = true; }
 void unhandled_exception(){ throw; }

 auto await_transform(O o) {
 struct A {
 bool await_ready() {
 return o_.b;
 }
 void await_resume() {}
 void await_suspend(stdx::coroutine_handle<> h){
 h.destroy();
 }
 O o_;
 };
 return A{o};
 }
 O* value;
 };

 explicit O(promise_type* p){ p->value = this; }
 explicit O(bool b) : b(b) {}

 bool b = false;
};

O g();

O f() { co_await g();  co_return; }

This is basically a reduced version of
https://github.com/facebook/folly/blob/99f856ae2009a80b157b5121e44b1f70f61bd7c9/folly/Optional.h#L613-L678

GCC does not appear to be able to optimize away the coroutine frame allocation,
while Clang does: https://gcc.godbolt.org/z/7981o81ne

[Bug libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100577

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Created attachment 50804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50804=edit
wip library-side patch

The attached WIP patch implements the library-side workaround mentioned in
comment #2.  With it, we recover the same diagnostics that GCC 10 gave us,
though we need to pass -fconcepts-diagnostics-depth=3 to see them.

[Bug libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100577

--- Comment #2 from Patrick Palka  ---
Some context: the purpose of this deleted operator() is so that when invoking
an adaptor object as an rvalue, we don't ever select the const&-qualified
operator() overload, because doing so would break the perfect forwarding call
wrapper semantics required of partially applied adaptor objects and pipelines,
and cause us to silently accept the P2281 example 'x |
views::split(non_view_range)' (forming a split_view containing a dangling
reference).  This deleted const&&-qualified overload always wins over the
const&-qualified overload in the rvalue case, and so prevents this breakage
from happening.

This PR arguably calls for an improvement on the frontend side -- the
diagnostic for when overload resolution chooses a deleted function could also
perhaps explain why the other candidates weren't selected.

But I think we can also work around this deficiency on the library side by
essentially disabling the perfect forwarding call wrapper machinery for range
adaptors that don't need it, which currently is all of them except for
views::split.  For the other adaptors, we could get away with just a single
overload for  _Partial::operator() and _Pipe::operator().

[Bug tree-optimization/100578] New: [12 Regression] ICE Segmentation fault during GIMPLE pass: fre (under -g -O2/O3/Os)

2021-05-12 Thread haoxintu at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100578

Bug ID: 100578
   Summary: [12 Regression] ICE Segmentation fault during GIMPLE
pass: fre (under -g -O2/O3/Os)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi all.

$cat small.c
#include 
void a() {
  int b;
c:
  int8_t d = 3;
  if (b |= d ^= a >= 5)
;
  else
goto c;
}


$gcc -w -g -O2 (same as -O3 and -Os)
during GIMPLE pass: fre
small.c: In function ‘a’:
small.c:2:6: internal compiler error: Segmentation fault
2 | void a() {
  |  ^
0xba009f crash_signal
../../gcc/toplev.c:327
0xd1a01e eliminate_dom_walker::eliminate_stmt(basic_block_def*,
gimple_stmt_iterator*)
../../gcc/tree-ssa-sccvn.c:6336
0xd1b64d eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:6579
0xd1b64d eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:6512
0x144e967 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:309
0xd12f10 eliminate_with_rpo_vn(bitmap_head*)
../../gcc/tree-ssa-sccvn.c:6759
0xd21d03 do_rpo_vn
../../gcc/tree-ssa-sccvn.c:7872
0xd22a90 execute
../../gcc/tree-ssa-sccvn.c:7954
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Note that this only crashes on the current trunk version of GCC, and I don't
see any crash on released GCC versions.

The output in Godbolt (https://godbolt.org/z/bbjnbGYb4) is:
```
#1 with x86-64 gcc (trunk)
during GIMPLE pass: evrp
: In function 'a':
:10:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
   10 | }
```

Another interesting behavior is that GCC-11 accepts this code while GCC-10
downwards versions reject it. GCC-10 output is (in
https://godbolt.org/z/W34EnfhqM):
```
5:3: error: a label can only be part of a statement and a declaration
is not a statement
5 |   int8_t d = 3;
  |   ^~
```

GCC version in my machine is:
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/tuhaoxin/compilers/gcc/build/
--enable-bootstrap --enable-checking=release --enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210510 (experimental) (GCC) 


Thanks,
Haoxin

[Bug libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100577

Patrick Palka  changed:

   What|Removed |Added

  Known to work||10.1.0, 10.2.0, 10.3.0
   Keywords||diagnostic
   Target Milestone|--- |11.2
  Known to fail||11.1.0

--- Comment #1 from Patrick Palka  ---
Diagnostics for ill-formed calls to adaptor pipelines regress similarly:

#include 

int main() {
  extern int x[100];
  (std::views::join | std::views::join)(x);
}

: In function ‘int main()’:
:5:40: error: use of deleted function ‘constexpr auto
std::ranges::views::__adaptor::_Pipe<_Lhs, _Rhs>::operator()(_Range&&) const &&
[with _Range = int (&)[100]; _Lhs = std::ranges::views::_Join; _Rhs = 
std::ranges::views::_Join]’
In file included from :1:
/home/patrick/code/gcc-master/libstdc++-v3/include/std/ranges:901:9: note:
declared here
  901 | operator()(_Range&& __r) const && = delete;
  | ^~~~

[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a

2021-05-12 Thread guojiufu at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537

--- Comment #13 from Jiu Fu Guo  ---
(In reply to Ian Lance Taylor from comment #12)
> A change to go-gcc.cc should not change any of the error messages emitted by
> the Go frontend.  It should not change the way that issue4458.go is handled.
> Those errors messages are emitted long before any of the code in go-gcc.cc
> is called.  I'm not sure what is happening.

It is interesting,  I rerun for trunk (without the patch), the message is
"error: type has no method 'foo'"
With the patch, the message is "error: method 'foo' is ambiguous"

At expressions.cc:14655
  if (!is_ambiguous)
go_error_at(location, "type has no method %<%s%>",
Gogo::message_name(name).c_str());
  else
go_error_at(location, "method %<%s%> is ambiguous",
Gogo::message_name(name).c_str());

is_ambiguous:
  if (nt != NULL)
method = nt->method_function(name, _ambiguous);
  else if (st != NULL)
method = st->method_function(name, _ambiguous);

[Bug libstdc++/100577] New: [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100577

Bug ID: 100577
   Summary: [11/12 Regression] Unhelpful diagnostics for
ill-formed call to partially applied range adaptor
object
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

For the following invalid testcase:

#include 

int main() {
  extern int x[100];
  std::views::take(nullptr)(x);
}

GCC 10 emits the following errors:

In file included from :1:
/usr/include/c++/10/ranges: In instantiation of
‘std::ranges::views:: [with _Range = int (&)[100]; _Tp
= std::nullptr_t]’: 
/usr/include/c++/10/ranges:1142:27:   required from
‘std::ranges::views::__adaptor::_RangeAdaptor<_Callable>::operator()<{std::nullptr_t}>::
[with _Range = int (&)[100]]’   
/usr/include/c++/10/ranges:1162:44:   required from ‘constexpr auto
std::ranges::views::__adaptor::_RangeAdaptorClosure<_Callable>::operator()(_Range&&)
const [with _Range = int (&)[100]; _Callable = std::ranges
::views::__adaptor::_RangeAdaptor<_Callable>::operator()<{std::nullptr_t}>::]’
 
:5:30:   required from here  
/usr/include/c++/10/ranges:2148:68: error: class template argument deduction
failed: 
 2148 |  return take_view{std::forward<_Range>(__r), std::forward<_Tp>(__n)};   
  |^
/usr/include/c++/10/ranges:2148:68: error: no matching function for call to
‘take_view(int [100], std::nullptr_t)’ 
   [...]
/usr/include/c++/10/ranges:2140:5: note: candidate:
‘std::ranges::take_view(_Range&&, std::ranges::range_difference_t<_Range>)->
std::ranges::take_view > [with _Range = int
(&)[
100]; std::ranges::views::all_t<_Range> = std::ranges::ref_view;
std::ranges::range_difference_t<_Range> = long int]’
 2140 | take_view(_Range&&, range_difference_t<_Range>) 
  | ^   


Whereas GCC 11, after r11-8053, emits an almost useless error:

:5:28: error: use of deleted function ‘constexpr auto
std::ranges::views::__adaptor::_Partial<_Adaptor, _Arg>::operator()(_Range&&)
const && [with _Range = int (&)[100]; _Adaptor = std::ranges::views::_Take;
_Arg = std::nullptr_t]’
In file included from :1:
/home/patrick/code/gcc-master/libstdc++-v3/include/std/ranges:865:9: note:
declared here
  865 | operator()(_Range&& __r) const && = delete;
  | ^~~~

[Bug libstdc++/100567] views::take and views::drop should conditionally use _RangeAdaptor::operator()

2021-05-12 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100567

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #2 from 康桓瑋  ---
(In reply to Patrick Palka from comment #1)
> Hmm, I believe we're behaving correctly according to wg21.link/p2281.  This
> paper clarifies that partial application of a range adaptor stores the extra
> arguments in their decayed form, so in particular we discard their
> cv-qualifications.

Oops, you are right. Tim made a big change to the range adaptor objects in
P2281. Thank you for correcting me.

[Bug tree-optimization/100574] [11/12 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570236.html

[Bug target/100549] [12 Regression] ICE: Segmentation fault with __builtin_ia32_pcmpgtw128 since r12-110-gc54a9f7259fce1a2

2021-05-12 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100549

--- Comment #3 from Hongtao.liu  ---
when args0 and args1 is the same, gimple_build (, GT_EXPR, cmp_type,
args0, args1) will just return 0 w/o set stmts, which cause ICE in
gsi_insert_before (gsi, *NULL*, GSI_SAME_STMT);

[Bug target/100549] [12 Regression] ICE: Segmentation fault with __builtin_ia32_pcmpgtw128 since r12-110-gc54a9f7259fce1a2

2021-05-12 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100549

--- Comment #2 from Hongtao.liu  ---
(In reply to Martin Liška from comment #1)
> Started with r12-110-gc54a9f7259fce1a2.

Mine.

[Bug target/94680] Missed optimization with __builtin_shuffle and zero vector

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94680

--- Comment #6 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:94de7e225c1fda079052c3f0725c926437d56c94

commit r12-760-g94de7e225c1fda079052c3f0725c926437d56c94
Author: liuhongt 
Date:   Thu Apr 22 15:33:16 2021 +0800

Optimize __builtin_shuffle when it's used to zero the upper bits of the
dest. [PR target/94680]

If the second operand of __builtin_shuffle is const vector 0, and with
specific mask, it can be optimized to movq/vmovps.

.i.e.
foo128:
-   vxorps  %xmm1, %xmm1, %xmm1
-   vmovlhps%xmm1, %xmm0, %xmm0
+   vmovq   %xmm0, %xmm0

 foo256:
-   vxorps  %xmm1, %xmm1, %xmm1
-   vshuff32x4  $0, %ymm1, %ymm0, %ymm0
+   vmovaps %xmm0, %xmm0

 foo512:
-   vxorps  %xmm1, %xmm1, %xmm1
-   vshuff32x4  $68, %zmm1, %zmm0, %zmm0
+   vmovaps %ymm0, %ymm0

gcc/ChangeLog:

PR target/94680
* config/i386/sse.md (ssedoublevecmode): Add attribute for
V64QI/V32HI/V16SI/V4DI.
(ssehalfvecmode): Add attribute for V2DI/V2DF.
(*vec_concatv4si_0): Extend to VI124_128.
(*vec_concat_0): New pre-reload splitter.
* config/i386/predicates.md (movq_parallel): New predicate.

gcc/testsuite/ChangeLog:

PR target/94680
* gcc.target/i386/avx-pr94680.c: New test.
* gcc.target/i386/avx512f-pr94680.c: New test.
* gcc.target/i386/sse2-pr94680.c: New test.

[Bug c/100550] [11/12 Regression] ICE: in fold_convert_loc with function call VLA argument

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100550

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Keywords||patch
 Status|NEW |ASSIGNED

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570229.html

[Bug tree-optimization/100349] [11/12 Regression] ICE Segmentation fault during GIMPLE pass: evrp (under -O2 to -Os)

2021-05-12 Thread tlwang at uwaterloo dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100349

Theodore Wang  changed:

   What|Removed |Added

 CC||tlwang at uwaterloo dot ca

--- Comment #3 from Theodore Wang  ---
A possible duplicate:

$ /home/cnsun/usr/bin/gcc-trunk -v
Using built-in specs.
COLLECT_GCC=/home/cnsun/usr/bin/gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.BriefQJ2R3-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210511 (experimental) [master revision
:61d4686bb:71d38ec80008afdbb9a059253407d80598b765c0] (GCC)

$ cat program3.c
int a;
void c() {
  char b;
d:
  for (;;) {
b = -16;
for (; b; b = ({
unsigned char e = b;
e + 1;
  }))
  for (;;) {
if (a)
  break;
unsigned f = b;
goto d;
  }
  }
}

$ /home/cnsun/usr/bin/gcc-trunk -O2 -c program3.c
during GIMPLE pass: evrp
program3.c: In function ‘c’:
program3.c:18:1: internal compiler error: Segmentation fault
   18 | }
  | ^
0xef6d63 crash_signal
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/toplev.c:327
0x12630f3 bounds_of_var_in_loop(tree_node**, tree_node**, range_query*, loop*,
gimple*, tree_node*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/vr-values.c:1658
0x191d98d gimple_ranger::range_of_ssa_name_with_loop_info(irange&, tree_node*,
loop*, gphi*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-range.cc:1229
0x191dd2b gimple_ranger::range_of_phi(irange&, gphi*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-range.cc:568
0x191e15d gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-range.cc:376
0x191e514 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-range.cc:1077
0x19192a2 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-range.cc:960
0x120f8b4 range_query::value_of_expr(tree_node*, gimple*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/value-query.cc:86
0x192b125 hybrid_folder::value_of_expr(tree_node*, gimple*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-ssa-evrp.c:235
0x10ab78d substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/tree-ssa-propagate.c:776
0x18ed787 dom_walker::walk(basic_block_def*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/domwalk.c:309
0x10aad29 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/tree-ssa-propagate.c:987
0x192ad8e execute_early_vrp
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/gimple-ssa-evrp.c:349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366

--- Comment #9 from Martin Sebor  ---
Just to clarify: when I said the warning is justified I meant that there is
nothing in the IL to keep the warning from triggering.  I.e., it works as
designed.  The problem may be solved by optimizing the code better, which might
be possible by enhancing the optimizers or by changing or annotating the
libstdc++ code to enable existing optimizations.  In the latter case it will of
course only help libstdc++ and not other code like it.  A third possibility is
to make the warning itself smarter than the optimizer and figure out the code
is unreachable without its help.

[Bug tree-optimization/100574] [11/12 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.2
   Last reconfirmed||2021-05-12
 CC||msebor at gcc dot gnu.org
 Blocks||88443
 Ever confirmed|0   |1


Referenced Bugs:

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

[Bug c/100576] New: ICE at -O1 and above: in decompose, at wide-int.h:984

2021-05-12 Thread cnsun at uwaterloo dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576

Bug ID: 100576
   Summary: ICE at -O1 and above: in decompose, at wide-int.h:984
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.BriefQJ2R3-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210511 (experimental) [master revision
:61d4686bb:71d38ec80008afdbb9a059253407d80598b765c0] (GCC)

$ cat mutant.c
const char si16_4_rep[] = {0x12};
eq_si16_x() {
  int n, b = sizeof si16_4_rep;
  const *p, *q = si16_4_rep;
  n += memcmp(p, q, b);
  if (n)
__builtin_abort();
}

$ gcc-trunk -O1 mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | eq_si16_x() {
  | ^
mutant.c: In function ‘eq_si16_x’:
mutant.c:4:10: warning: type defaults to ‘int’ in declaration of ‘p’
[-Wimplicit-int]
4 |   const *p, *q = si16_4_rep;
  |  ^
mutant.c:4:14: warning: type defaults to ‘int’ in declaration of ‘q’
[-Wimplicit-int]
4 |   const *p, *q = si16_4_rep;
  |  ^
mutant.c:4:18: warning: initialization of ‘const int *’ from incompatible
pointer type ‘const char *’ [-Wincompatible-pointer-types]
4 |   const *p, *q = si16_4_rep;
  |  ^~
mutant.c:5:8: warning: implicit declaration of function ‘memcmp’
[-Wimplicit-function-declaration]
5 |   n += memcmp(p, q, b);
  |^~
mutant.c:1:1: note: include ‘’ or provide a declaration of ‘memcmp’
  +++ |+#include 
1 | const char si16_4_rep[] = {0x12};
mutant.c:5:21: warning: ‘memcmp’ argument 3 type is ‘int’ where ‘long unsigned
int’ is expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
5 |   n += memcmp(p, q, b);
  | ^
: note: built-in ‘memcmp’ declared here
during RTL pass: expand
mutant.c:5:8: internal compiler error: in decompose, at wide-int.h:984
5 |   n += memcmp(p, q, b);
  |^~~
0x679a02 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/wide-int.h:984
0x67e3d1 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/tree.h:3479
0x67e3d1 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/wide-int.h:1034
0x67e3d1 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/wide-int.h:790
0x67e3d1 bool wi::ltu_p >,
generic_wide_int
>(generic_wide_int > const&,
generic_wide_int const&)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/wide-int.h:1937
0x67e3d1 bool wi::leu_p,
generic_wide_int >
>(generic_wide_int const&,
generic_wide_int > const&)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/wide-int.h:1979
0x67e3d1 check_nul_terminated_array(tree_node*, tree_node*, tree_node*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/builtins.c:1228
0xa0ad9e check_access(tree_node*, tree_node*, tree_node*, tree_node*,
tree_node*, access_mode, access_data const*)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/builtins.c:4669
0xa0d0e7 check_read_access
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/builtins.c:4909
0xa0e1a1 check_read_access
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/builtins.c:4904
0xa0e1a1 expand_builtin_memcmp
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/builtins.c:7049
0xa12154 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/builtins.c:10226
0xb6243c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/expr.c:11405
0xb6cf58 store_expr(tree_node*, rtx_def*, int, bool, bool)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/expr.c:5986
0xb6e59f expand_assignment(tree_node*, tree_node*, bool)
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/expr.c:5721
0xa3cb0b expand_call_stmt
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/cfgexpand.c:2841
0xa3cb0b expand_gimple_stmt_1
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/cfgexpand.c:3847
0xa3cb0b expand_gimple_stmt
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/cfgexpand.c:4011
0xa42809 expand_gimple_basic_block
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/cfgexpand.c:6048

[Bug middle-end/100536] ICE: in expand_call with large union (1GB) argument

2021-05-12 Thread cnsun at uwaterloo dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100536

--- Comment #3 from Chengnian Sun  ---
A duplicate here.



typedef struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  struct {
struct {
  int f;
} f[8];
  } f[8];
} f[8];
  } f[8];
} f[8];
  } f[8];
} f[8];
  } f[8];
} f[8];
  } f[8];
} T;
f(w) T *w;
{
  int i;
  g(w[i]);
}

[Bug c/100575] New: ICE: in expand_stack_alignment, at cfgexpand.c:6385

2021-05-12 Thread cnsun at uwaterloo dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100575

Bug ID: 100575
   Summary: ICE: in expand_stack_alignment, at cfgexpand.c:6385
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.BriefQJ2R3-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210511 (experimental) [master revision
:61d4686bb:71d38ec80008afdbb9a059253407d80598b765c0] (GCC)

$ cat mutant.c
int main(int __attribute__((vector_size(1 << 29 { return 0; }

$ gcc-trunk  mutant.c
mutant.c: In function ‘main’:
mutant.c:1:5: note: the ABI for passing parameters with 268435456-byte
alignment has changed in GCC 4.6
1 | int main(int __attribute__((vector_size(1 << 29 { return 0; }
  | ^~~~
during RTL pass: expand
mutant.c:1:65: internal compiler error: in expand_stack_alignment, at
cfgexpand.c:6385
1 | int main(int __attribute__((vector_size(1 << 29 { return 0; }
  | ^
0x68c38b expand_stack_alignment
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/cfgexpand.c:6385
0x68c38b execute
/tmp/tmp.BriefQJ2R3-gcc-builder/gcc/gcc/cfgexpand.c:6845
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c

2021-05-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573

--- Comment #1 from Tobias Burnus  ---
Created attachment 50803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50803=edit
Reduced testcase - works with hostfall back but fails with GCN and nvptx

[Bug middle-end/100571] bogus -Wstringop-overflow with VLA of elements larger than byte

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

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

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

commit r12-756-gdb514f98a383b2ebdcfe74feb80f98f406cec174
Author: Martin Sebor 
Date:   Wed May 12 15:57:34 2021 -0600

Add test for PR middle-end/100571.

gcc/testsuite:
PR middle-end/100571
* gcc.dg/Wstringop-overflow-67.c: New test.

[Bug middle-end/100571] bogus -Wstringop-overflow with VLA of elements larger than byte

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed in r10-9819.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 100571, which changed state.

Bug 100571 Summary: bogus -Wstringop-overflow with VLA of elements larger than 
byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

   What|Removed |Added

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

[Bug middle-end/100571] bogus -Wstringop-overflow with VLA of elements larger than byte

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Sebor
:

https://gcc.gnu.org/g:0d1e4025b2bd2ce36d6ee2a5d836d31ec8a12999

commit r10-9819-g0d1e4025b2bd2ce36d6ee2a5d836d31ec8a12999
Author: Martin Sebor 
Date:   Wed May 12 15:45:44 2021 -0600

PR middle-end/100571 - bogus -Wstringop-overflow with VLA of elements
larger than byte

gcc/ChangeLog:
PR middle-end/100571
* calls.c (maybe_warn_rdwr_sizes): Clear object size if it can't
be determined.

gcc/testsuite/ChangeLog:
PR middle-end/100571
* gcc.dg/Wstringop-overflow-67.c: New test.

[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a

2021-05-12 Thread ian at airs dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537

--- Comment #12 from Ian Lance Taylor  ---
A change to go-gcc.cc should not change any of the error messages emitted by
the Go frontend.  It should not change the way that issue4458.go is handled. 
Those errors messages are emitted long before any of the code in go-gcc.cc is
called.  I'm not sure what is happening.

[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults

2021-05-12 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551

--- Comment #3 from anlauf at gcc dot gnu.org ---
Below fixes this PR and does not break the other testcase:

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index cce18d094a6..ebc9ea42beb 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5826,7 +5826,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 _array);
}
   else if (UNLIMITED_POLY (fsym) && e->ts.type != BT_CLASS
-  && gfc_expr_attr (e).flavor != FL_PROCEDURE)
+  && (gfc_expr_attr (e).flavor != FL_PROCEDURE
+  || gfc_expr_attr (e).proc == PROC_INTRINSIC))
{
  /* The intrinsic type needs to be converted to a temporary
 CLASS object for the unlimited polymorphic formal.  */

I would hope that Paul can explain why this works, or if this is the right
thing.

[Bug c/100521] [12 Regression] ICE at -O2 and above: in verify_range, at value-range.cc:384 since r12-127-g694c956b6b877e48

2021-05-12 Thread aldyh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100521

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
Fixed in trunk.

[Bug c/100521] [12 Regression] ICE at -O2 and above: in verify_range, at value-range.cc:384 since r12-127-g694c956b6b877e48

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100521

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r12-755-gd902a1b57606536982a1001670f998de685eaf7c
Author: Aldy Hernandez 
Date:   Wed May 12 15:22:15 2021 -0400

Skip out on processing __builtin_clz when varying.

The previous changes to irange::constant_p return TRUE for
VARYING, since VARYING has numerical end points like any other
constant range.  The problem is that some users of constant_p
depended on constant_p excluding the full domain.  The
range handler for __builtin_clz, that is shared between ranger
and vr_values, is one such user.

This patch excludes varying_p(), to match the original behavior
for clz.

gcc/ChangeLog:

PR c/100521
* gimple-range.cc (range_of_builtin_call): Skip out on
  processing __builtin_clz when varying.

[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3

2021-05-12 Thread simon.marchi at polymtl dot ca via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

Simon Marchi  changed:

   What|Removed |Added

 CC||simon.marchi at polymtl dot ca

--- Comment #7 from Simon Marchi  ---
Indeed, as soon as I build something with more than two CUs (no LTO involved),
I get these import 0x0:

$ gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 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.
$ cat test.c
#include 

void foo();

int main() {
foo();
}
$ cat test2.c
#include 

void foo()
{
}
$ gcc test.c test2.c -g3 -O0 -o test
$ readelf --debug-dump=macro test | less
...
 Offset:  0x1a81
  Version: 4
  Offset size: 4
  Offset into .debug_line: 0x1c1

 DW_MACRO_import - offset : 0x0
 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test2.c
 DW_MACRO_start_file - lineno: 31 filenum: 2 filename:
/usr/include/stdc-predef.h
 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file
 DW_MACRO_start_file - lineno: 1 filenum: 3 filename: /usr/include/unistd.h
 DW_MACRO_define_strp - lineno : 23 macro : _UNISTD_H 1
 DW_MACRO_start_file - lineno: 25 filenum: 4 filename: /usr/include/features.h
 DW_MACRO_import - offset : 0x0
 DW_MACRO_start_file - lineno: 473 filenum: 5 filename:
/usr/include/sys/cdefs.h
 DW_MACRO_import - offset : 0x0
 DW_MACRO_start_file - lineno: 462 filenum: 6 filename:
/usr/include/bits/wordsize.h
 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file
 DW_MACRO_start_file - lineno: 463 filenum: 7 filename:
/usr/include/bits/long-double.h
 DW_MACRO_define_strp - lineno : 21 macro : __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI
0
 DW_MACRO_end_file
 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file
 DW_MACRO_start_file - lineno: 497 filenum: 8 filename:
/usr/include/gnu/stubs.h
...

[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults

2021-05-12 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Martin Liška from comment #1)
> Started with r11-6928-g4225af228b5d52e8.

The partial revert:

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index cce18d094a6..91efb67ac87 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5826,7 +5826,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 _array);
}
   else if (UNLIMITED_POLY (fsym) && e->ts.type != BT_CLASS
-  && gfc_expr_attr (e).flavor != FL_PROCEDURE)
+//&& gfc_expr_attr (e).flavor != FL_PROCEDURE)
+  )
{
  /* The intrinsic type needs to be converted to a temporary
 CLASS object for the unlimited polymorphic formal.  */

fixes this issue but breaks testcase proc_ptr_52.f90.

Further reduced testcase for this PR:

program p
  implicit none
  integer :: result
  result = 1
! result = test ((result)) ! works
  result = test (int (result)) ! fails
  write(*,*) result
contains
  integer function test(x)
class(*), intent(in) :: x
select type (x)
type is (integer)
   test = x
class default
   test = -1
end select
  end function test
end program

[Bug tree-optimization/100574] New: [11/12 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre

2021-05-12 Thread zsojka at seznam dot cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574

Bug ID: 100574
   Summary: [11/12 Regression] ICE: in size_remaining, at
builtins.c:413 with -O3 -ftracer
-fno-tree-dominator-opts -fno-tree-fre
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 50802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50802=edit
auto-reduced testcase (from OpenTTD sources)

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre
testcase.C 
during GIMPLE pass: strlen
testcase.C: In function 'void ReadTrackChunk()':
testcase.C:43:6: internal compiler error: in size_remaining, at builtins.c:413
   43 | void ReadTrackChunk() {
  |  ^~
0x714a5d
access_ref::size_remaining(generic_wide_int >*)
const
/repo/gcc-trunk/gcc/builtins.c:413
0xe2f36a access_ref::add_offset(generic_wide_int >
const&, generic_wide_int > const&)
/repo/gcc-trunk/gcc/builtins.c:517
0xe30211 handle_mem_ref
/repo/gcc-trunk/gcc/builtins.c:5407
0xe30211 compute_objsize_r
/repo/gcc-trunk/gcc/builtins.c:5549
0xe335d2 compute_objsize(tree_node*, int, access_ref*, pointer_query*)
/repo/gcc-trunk/gcc/builtins.c:5816
0x1514411 maybe_warn_overflow
/repo/gcc-trunk/gcc/tree-ssa-strlen.c:1952
0x151cbe1 maybe_warn_overflow
/repo/gcc-trunk/gcc/tree-ssa-strlen.c:2096
0x151cbe1 handle_store
/repo/gcc-trunk/gcc/tree-ssa-strlen.c:4788
0x151f4a6 check_and_optimize_stmt
/repo/gcc-trunk/gcc/tree-ssa-strlen.c:5426
0x151f4a6 strlen_dom_walker::before_dom_children(basic_block_def*)
/repo/gcc-trunk/gcc/tree-ssa-strlen.c:5622
0x1dcfc57 dom_walker::walk(basic_block_def*)
/repo/gcc-trunk/gcc/domwalk.c:309
0x1514f1e printf_strlen_execute
/repo/gcc-trunk/gcc/tree-ssa-strlen.c:5688
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgomp/100573] New: [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c

2021-05-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573

Bug ID: 100573
   Summary: [OpenMP] 'omp target teams' fails with nvptx and GCN
offloading: FAIL libgomp.c-c++-common/for-3.c +
for-9.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The testcase
  libgomp.c-c++-common/for-9.c
is a thin wrapper around libgomp.c-c++-common/for-3.c with slightly different
settings. Hence, it is affected as well.

libgomp.c-c++-common/for-3.c has:

  int err = 0;
  #pragma omp target teams reduction(|:err)
{
   err |= test_d_normal ();
...
}
  if (err)
abort ();

This will currently never fail because 'err' is mapped as firstprivate to the
target – at least until PR99928 is fixed (→ patch there).

Alternatively, manually adding a 'map(tofrom: err)' also works.

However, with that 'map added or the PR99928 patch applied:
* it still PASSES on x86-64-gnu-linux (-m64, -m32) with HOST FALLBACK
* BUT it FAILS both with AMD GCN and with NVPTX offloading.

But even without reduction and by checking each of the twenty-odd testcase
separately, it FAILS. Namely, I used the following:

  int err = 0, i = 1;

  #pragma omp target teams map(tofrom: err)
{ 
  err = test_d_normal ();
}
  __builtin_printf("%d -> %d\n", i++, err);
  err = 0;

And the result is '-> 1' for all of them.

However, when I use 'omp target' instead of 'target teams', it passes.

[Bug target/100572] arm: Assemble failures with MVE vcreateq intrinsic

2021-05-12 Thread acoplan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100572

Alex Coplan  changed:

   What|Removed |Added

 Target||arm
   Keywords||assemble-failure
  Known to fail||10.3.0, 11.1.0, 12.0
   Target Milestone|--- |10.4

[Bug target/100572] New: arm: Assemble failures with MVE vcreateq intrinsic

2021-05-12 Thread acoplan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100572

Bug ID: 100572
   Summary: arm: Assemble failures with MVE vcreateq intrinsic
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

GCC's output fails to assemble for the following:

$ cat test.c
#include 
uint64x2_t v;
void f(void) { v = vcreateq_u64(0, 0); }
$ ./arm-eabi-gcc -c test.c -march=armv8.1-m.main+mve -mfloat-abi=hard -O
/tmp/ccXeZkHP.s: Assembler messages:
/tmp/ccXeZkHP.s:31: Error: General purpose registers may not be the same --
`vmov q3[2],q3[0],r2,r2'
/tmp/ccXeZkHP.s:32: Error: General purpose registers may not be the same --
`vmov q3[3],q3[1],r3,r3'

The code generated for f here is:
f:
movsr2, #0
movsr3, #0
vmov q3[2], q3[0], r2, r2
vmov q3[3], q3[1], r3, r3
ldr r3, .L2
vstrw.32q3, [r3]
bx  lr

The problem also occurs for other types when used with vcreateq, e.g. for:

#include 
uint32x4_t v;
void f(void) { v = vcreateq_u32(0, 0); }

Here is a preprocessed testcase (not for the testsuite, but for testing with a
cc1):

__simd128_uint64_t v;
void f(void) { v = __builtin_mve_vcreateq_uv2di(0, 0); }

[Bug target/98218] [TARGET_MMX_WITH_SSE] Implement 64bit vector compares (AVX512 masked compares missing)

2021-05-12 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218

--- Comment #15 from David Binderman  ---
Bug first appears sometime between git hash 21dfb22920ce32fc,
dated yesterday and git hash 097fde5e7514e909, dated today.

[Bug target/98218] [TARGET_MMX_WITH_SSE] Implement 64bit vector compares (AVX512 masked compares missing)

2021-05-12 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218

--- Comment #14 from David Binderman  ---
(In reply to Uroš Bizjak from comment #13)
> A wild guess: you are compiling for TARGET_XOP?

Not sure. bdver2.

Reduced C code:

typedef float DBL;
struct {
  DBL c_x, c_y
} Random_Simis_Cur;
Random_Simis_i;
DBL Gauss_Rand() {
  int __trans_tmp_1;
  DBL S, y = exp(S) / 0;
  if (__trans_tmp_1)
return y;
  return -y;
}
draw_ifs() {
  while (Random_Simis_i--) {
Random_Simis_Cur.c_x = Gauss_Rand();
Random_Simis_Cur.c_y = Gauss_Rand();
  }
}

Command line is

$ /home/dcb/gcc/results/bin/gcc -c -w -O3 -march=bdver2 -ffast-math bug717.c

[Bug target/98218] [TARGET_MMX_WITH_SSE] Implement 64bit vector compares (AVX512 masked compares missing)

2021-05-12 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218

--- Comment #13 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #12)
> Yeah, this is a non-existent SSE "cmove". I tried to find all paths where
> this should divert to a sequence of logic instructions or PBLENDB, but due
> to plethora of ISAs some cmove expansions fell through the cracks.
> Fortunately, easy to fix problem, please just provide a testcase.

A wild guess: you are compiling for TARGET_XOP?

diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index d433c524652..7fc2e5d781c 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1816,11 +1816,11 @@

 ;; XOP parallel XMM conditional moves
 (define_insn "*xop_pcmov_"
-  [(set (match_operand:MMXMODEI 0 "register_operand" "=x")
-(if_then_else:MMXMODEI
-  (match_operand:MMXMODEI 3 "register_operand" "x")
-  (match_operand:MMXMODEI 1 "register_operand" "x")
-  (match_operand:MMXMODEI 2 "register_operand" "x")))]
+  [(set (match_operand:MMXMODE124 0 "register_operand" "=x")
+(if_then_else:MMXMODE124
+  (match_operand:MMXMODE124 3 "register_operand" "x")
+  (match_operand:MMXMODE124 1 "register_operand" "x")
+  (match_operand:MMXMODE124 2 "register_operand" "x")))]
   "TARGET_XOP && TARGET_MMX_WITH_SSE"
   "vpcmov\t{%3, %2, %1, %0|%0, %1, %2, %3}"
   [(set_attr "type" "sse4arg")])

[Bug middle-end/100571] bogus -Wstringop-overflow with VLA of elements larger than byte

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

Martin Sebor  changed:

   What|Removed |Added

URL||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=27832

--- Comment #1 from Martin Sebor  ---
See also https://sourceware.org/bugzilla/show_bug.cgi?id=27832

[Bug libstdc++/100558] std::ranges::views operator| fails to compile

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100558

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
(In reply to Jonathan Wakely from comment #2)
> Patrick, could you backport r12-321 please.

Done as r11-8406.

So we can now consider this fixed for GCC 11.2 and 12.

[Bug middle-end/100571] bogus -Wstringop-overflow with VLA of elements larger than byte

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

Martin Sebor  changed:

   What|Removed |Added

 Blocks||88443
 Ever confirmed|0   |1
   Last reconfirmed||2021-05-12
  Known to fail||10.1.0, 10.2.0, 10.3.0
  Known to work||11.1.0, 9.3.0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.4
 Status|UNCONFIRMED |ASSIGNED
   Keywords||diagnostic


Referenced Bugs:

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

[Bug middle-end/100571] New: bogus -Wstringop-overflow with VLA of elements larger than byte

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100571

Bug ID: 100571
   Summary: bogus -Wstringop-overflow with VLA of elements larger
than byte
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is probably a duplicate of an existing bug already fixed in GCC 11 but not
in GCC 10.  A recent enhancement to Glibc to add attribute access to a bunch of
APIs has triggered a couple of false positives in the test suite, including:
  https://sourceware.org/pipermail/libc-alpha/2021-May/125987.html
and
  https://sourceware.org/pipermail/libc-alpha/2021-May/126250.html

A simple test case for the problem is as follows:

$ cat t.c && gcc -O2 -S -Wall t.c
__attribute__ ((access (read_only, 1, 2))) void f (int *, int);

__SIZE_TYPE__ n;

void g (void)
{
  int a[n];
  a[0] = 0;
  f (a, n);
}
t.t: In function 'g':
t.c:9:3: warning: 'f' specified size 18446744073709551615 exceeds maximum
object size 9223372036854775807 [-Wstringop-overflow=]
9 |   f (a, n);
  |   ^~~~
t.t:1:49: note: in a call to function 'f' declared with attribute 'read_only
(1, 2)'
1 | __attribute__ ((access (read_only, 1, 2))) void f (int *, int);
  | ^

[Bug target/98218] [TARGET_MMX_WITH_SSE] Implement 64bit vector compares (AVX512 masked compares missing)

2021-05-12 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218

--- Comment #12 from Uroš Bizjak  ---
(In reply to David Binderman from comment #11)
> I might be seeing something similar:
> 
> caxcpy.f: In function 'caxcpy':
> caxcpy.f:53:72: error: unrecognizable insn:
>53 |   end subroutine
>   | 
> ^
> (insn 136 135 137 16 (set (reg:V2SF 107 [ vect__96.11 ])
> (if_then_else:V2SF (reg:V2SF 220)
> (reg:V2SF 84 [ _3 ])
> (reg:V2SF 219))) -1
>  (nil))
> during RTL pass: vregs
> caxcpy.f:53:72: internal compiler error: in extract_insn, at recog.c:2770

Yeah, this is a non-existent SSE "cmove". I tried to find all paths where this
should divert to a sequence of logic instructions or PBLENDB, but due to
plethora of ISAs some cmove expansions fell through the cracks. Fortunately,
easy to fix problem, please just provide a testcase.

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

2021-05-12 Thread abebeos at lazaridis dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #60 from abebeos at lazaridis dot com ---
Notable sub-message:

https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570039.html

And the final essence, from:

https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570044.html

"
GCC issue, GCC resources(!), GCC committers, GCC participants.

Be aware that each and every person which noticed the non-attribution and
the rigged vote, without intervening, does this:

=> Supporting IT-fascism, in the name of GCC/GNU.

Including you - whoever you are.
"

[Bug web/100480] Where to file complaints re project-maintainers?

2021-05-12 Thread abebeos at lazaridis dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100480

--- Comment #6 from abebeos at lazaridis dot com ---
All good. Just be aware that the usual OSS "volunteer excuse" is a bit cheap in
a project where names like Apple, Google, IBM, Redhat, ARM etc. appear.

My understanding is that complaints need to be filed publicly on the
high-volume list:

https://gcc.gnu.org/pipermail/gcc/

which is the "contact" for the steering committee:

https://gcc.gnu.org/steering.html

[Bug testsuite/100569] [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742

2021-05-12 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100569

Martin Liška  changed:

   What|Removed |Added

 CC|mliska at suse dot cz  |marxin at gcc dot 
gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-05-12

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

[Bug libstdc++/100567] views::take and views::drop should conditionally use _RangeAdaptor::operator()

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100567

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Hmm, I believe we're behaving correctly according to wg21.link/p2281.  This
paper clarifies that partial application of a range adaptor stores the extra
arguments in their decayed form, so in particular we discard their
cv-qualifications.

[Bug testsuite/100569] [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742

2021-05-12 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100569

--- Comment #1 from seurer at gcc dot gnu.org ---
OK, there were a LOT of new warnings and such:

previous run: g:227a2ecf663d69972b851f51f1934d18927b62cd, r12-741: 52 failures
this run: g:7d7d925d0d799eb9dda4a6bd6162af0a7db9c98b, r12-742: 233 failures

FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o link, -fPIC
-flto -flto-partition=1to1 -r -nostdlib
FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link,
-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link,
-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o-cp_lto_20081119_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o-cp_lto_20081119_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081119-1 cp_lto_20081119-1_0.o-cp_lto_20081119-1_1.o link,
-fPIC -flto -flto-partition=1to1 -r -nostdlib
FAIL: g++.dg/lto/20081123 cp_lto_20081123_0.o-cp_lto_20081123_1.o link, -flto
-flto-partition=1to1 -r -nostdlib -fPIC
FAIL: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o link, -flto
-flto-partition=1to1
FAIL: g++.dg/lto/20081127 cp_lto_20081127_0.o-cp_lto_20081127_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081204-1 cp_lto_20081204-1_0.o-cp_lto_20081204-1_1.o link,
-flto -flto-partition=1to1 -fPIC -r -nostdlib
FAIL: g++.dg/lto/20081209 cp_lto_20081209_0.o-cp_lto_20081209_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081209 cp_lto_20081209_0.o-cp_lto_20081209_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o-cp_lto_20081211-1_1.o link,
-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o-cp_lto_20081211-1_1.o link,
-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20081219 cp_lto_20081219_0.o-cp_lto_20081219_1.o link, -fPIC
-flto -flto-partition=1to1 -O2
FAIL: g++.dg/lto/20090302 cp_lto_20090302_0.o-cp_lto_20090302_1.o link, -fPIC
-flto -flto-partition=1to1 -r
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link,
-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link,
-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090312 cp_lto_20090312_0.o-cp_lto_20090312_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090312 cp_lto_20090312_0.o-cp_lto_20090312_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090313 cp_lto_20090313_0.o-cp_lto_20090313_1.o link, -flto
-flto-partition=1to1 -fPIC
FAIL: g++.dg/lto/20090315 cp_lto_20090315_0.o-cp_lto_20090315_1.o link, -O0
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20090315 cp_lto_20090315_0.o-cp_lto_20090315_1.o link, -O2
-flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20091026-1 cp_lto_20091026-1_0.o-cp_lto_20091026-1_1.o link,
-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20091026-1 cp_lto_20091026-1_0.o-cp_lto_20091026-1_1.o link,
-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link,
-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link,
-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20100603-1 cp_lto_20100603-1_0.o-cp_lto_20100603-1_1.o link,
-O0 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20100603-1 cp_lto_20100603-1_0.o-cp_lto_20100603-1_1.o link,
-O2 -flto -flto-partition=1to1 -fno-use-linker-plugin 
FAIL: g++.dg/lto/20101020-1 

[Bug target/98218] [TARGET_MMX_WITH_SSE] Implement 64bit vector compares (AVX512 masked compares missing)

2021-05-12 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #11 from David Binderman  ---
I might be seeing something similar:

caxcpy.f: In function 'caxcpy':
caxcpy.f:53:72: error: unrecognizable insn:
   53 |   end subroutine
  |   
^
(insn 136 135 137 16 (set (reg:V2SF 107 [ vect__96.11 ])
(if_then_else:V2SF (reg:V2SF 220)
(reg:V2SF 84 [ _3 ])
(reg:V2SF 219))) -1
 (nil))
during RTL pass: vregs
caxcpy.f:53:72: internal compiler error: in extract_insn, at recog.c:2770

[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434

2021-05-12 Thread jamborm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
Mine.

[Bug target/97102] [nvptx] PTX JIT compilation failed when using aliases

2021-05-12 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102
Bug 97102 depends on bug 96005, which changed state.

Bug 96005 Summary: Add possibility to use newer ptx isa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005

   What|Removed |Added

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

[Bug target/96005] Add possibility to use newer ptx isa

2021-05-12 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #6 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

[Bug target/96005] Add possibility to use newer ptx isa

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96005

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:2a1586401a21dcd43e0f904bb6eec26c8b2f366b

commit r12-751-g2a1586401a21dcd43e0f904bb6eec26c8b2f366b
Author: Tom de Vries 
Date:   Wed May 12 12:40:37 2021 +0200

[nvptx] Add -mptx=3.1/6.3

Add nvptx option -mptx that sets the ptx ISA version.  This is currently
hardcoded to 3.1.

Tested libgomp on x86_64-linux with nvptx accelerator, both with default
set to
3.1 and 6.3.

gcc/ChangeLog:

2021-05-12  Tom de Vries  

PR target/96005
* config/nvptx/nvptx-opts.h (enum ptx_version): New enum.
* config/nvptx/nvptx.c (nvptx_file_start): Print .version according
to ptx_version_option.
* config/nvptx/nvptx.h (TARGET_PTX_6_3): Define.
* config/nvptx/nvptx.md (define_insn "nvptx_shuffle")
(define_insn "nvptx_vote_ballot"): Use sync variant for
TARGET_PTX_6_3.
* config/nvptx/nvptx.opt (ptx_version): Add enum.
(mptx): Add option.
* doc/invoke.texi (Nvidia PTX Options): Add mptx item.

[Bug c++/100570] New: g++ does not suppress bitfield conversion warning even isystem is setted

2021-05-12 Thread fsmoke at mail dot ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100570

Bug ID: 100570
   Summary: g++ does not suppress bitfield conversion warning even
isystem is setted
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fsmoke at mail dot ru
  Target Milestone: ---

I set -isystem /usr/local/include/qt5/ to suppress Qt library internal warnings
- all warnings are successfully suppressed except warnings about bitfields

g++ -c -x c++
/home/user/projects/arcturus/trunk/bin/platform/x64/linux_temp/release/protocol/generated_files/moc_protocol_table.cpp
-I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/../../include
-I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/../../../../common/cpp/include
-I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/../../../../common/sql
-I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/../../../../../3dparty/incbin
-I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/../../../../../3dparty/fmt/include
-I /usr/local/include/qt5 -I /usr/local/include/qt5/QtCore -I
/usr/local/include/qt5/QtGui -I /usr/local/include/qt5/QtWidgets -I
/usr/local/include/qt5/QtXml -I /usr/include/postgresql -I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/include
-I
/home/user/projects/arcturus/trunk/src/platform/protocol_qt/build/vs2019/../../include
-I
/home/user/projects/arcturus/trunk/bin/platform/x64/linux_temp/release/protocol/generated_files
-g1 -o
"/home/user/projects/arcturus/trunk/bin/platform/x64/linux_temp/release/protocol/moc_protocol_table.o"
-Wall -Wswitch -W"no-deprecated-declarations" -W"empty-body" -Wconversion
-W"return-type" -Wparentheses -W"no-format" -Wuninitialized
-W"unreachable-code" -W"unused-function" -W"unused-value" -W"unused-variable"
-O3 -fno-strict-aliasing -fomit-frame-pointer -DNDEBUG -DFMT_HEADER_ONLY
-DBOOST_DLL_USE_STD_FS -DNDEBUG -fpic -fthreadsafe-statics -fexceptions -frtti
-std=c++20 -isystem /usr/local/include/qt5/
  moc_protocol_table.cpp
  /usr/local/include/qt5/QtCore/qvariant.h(401,20): warning : conversion from
‘uint’ {aka ‘unsigned int’} to ‘unsigned int:30’ may change value
[-Wconversion]
  Done compiling
'/home/user/projects/arcturus/trunk/bin/platform/x64/linux_temp/release/protocol/generated_files/moc_settings_ctrl.cpp'

[Bug tree-optimization/100566] [9/10/11/12 Regression] Miscompilation of mausezahn since r9-2635

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

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

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

commit r11-8405-gce3c70e9ed265578be896b8f7711851b0a7273f1
Author: Richard Biener 
Date:   Wed May 12 15:39:52 2021 +0200

tree-optimization/100566 - fix another predication issue in VN

This amends the fix for PR100053 where I failed to amend all edge
tests in dominated_by_p_w_unex.

2021-05-12  Richard Biener  

PR tree-optimization/100566
* tree-ssa-sccvn.c (dominated_by_p_w_unex): Properly handle
allow_back for all edge queries.

* gcc.dg/torture/pr100566.c: New testcase.

(cherry picked from commit 097fde5e7514e909f2e8472be2e008d0cab2260d)

[Bug testsuite/100569] New: [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742

2021-05-12 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100569

Bug ID: 100569
   Summary: [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has
lto warnings after r12-742
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:7d7d925d0d799eb9dda4a6bd6162af0a7db9c98b, r12-742
make  -k check-gcc RUNTESTFLAGS="atomic.exp=gcc.dg/atomic/c11-atomic-exec-2.c"
FAIL: gcc.dg/atomic/c11-atomic-exec-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
# of expected passes15
# of unexpected failures1

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-latomic -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -std=c11 -pedantic-errors -lm -o ./c11-atomic-exec-2.exe
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
lto-wrapper: note: see the '-flto' option documentation for more information
FAIL: gcc.dg/atomic/c11-atomic-exec-2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
Excess errors:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs

[Bug d/100324] gcc-10.2.0 (and earlier) fails to build on x86_64, but has builds just fine aarch64

2021-05-12 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100324

--- Comment #9 from Iain Buclaw  ---
Does configure succeed in all multilib subdirectories?

tail x86_64-linux-gnu/*/libphobos/config.log
x86_64-linux-gnu/libphobos/config.log

And if one doesn't, inspect it to see why.

[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a

2021-05-12 Thread guojiufu at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537

--- Comment #11 from Jiu Fu Guo  ---
Had a quick regression test on the patch:
issue4458.go which pass before, but fail on this patch.
Compiling message changed from "error: method expression requires named type or
pointer to named type" to "error: method 'foo' is ambiguous"

I'm not sure if this message change is expected or not.

issue4458.go:
package main

type T struct{}

func (T) foo() {}

func main() {
av := T{}
pav := 
(**T).foo() // ERROR "no method .*foo|requires named type or
pointer to named"
}

[Bug libstdc++/100558] std::ranges::views operator| fails to compile

2021-05-12 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100558

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions

2021-05-12 Thread acoplan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99988

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #9 from Alex Coplan  ---
Fixed everywhere.

[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99988

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:52a09050fdfafb0e41d56b6adf1625264f315b82

commit r9-9528-g52a09050fdfafb0e41d56b6adf1625264f315b82
Author: Alex Coplan 
Date:   Wed Apr 21 14:42:04 2021 +0100

aarch64: Avoid duplicating bti j insns for jump tables [PR99988]

This patch fixes PR99988 which shows us generating large (> 250)
sequences of back-to-back bti j instructions.

The fix is simply to avoid inserting bti j instructions at the target of
a jump table if we've already inserted one for a given label.

Co-Authored-By: Christophe Lyon 

gcc/ChangeLog:

PR target/99988
* config/aarch64/aarch64-bti-insert.c (aarch64_bti_j_insn_p): New.
(rest_of_insert_bti): Avoid inserting duplicate bti j insns for
jump table targets.

gcc/testsuite/ChangeLog:

PR target/99988
* gcc.target/aarch64/pr99988.c: New test.

(cherry picked from commit 1011bb8bc67cf34c45a9237d72a801a14ad9ef0f)

[Bug middle-end/100568] [12 regression] ICE at gcc/tree-ssa.c:1214 after r12-657

2021-05-12 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100568

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
dup

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

[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a

2021-05-12 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537

Richard Biener  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #10 from Richard Biener  ---
*** Bug 100568 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/100566] [9/10/11/12 Regression] Miscompilation of mausezahn since r9-2635

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

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

https://gcc.gnu.org/g:097fde5e7514e909f2e8472be2e008d0cab2260d

commit r12-750-g097fde5e7514e909f2e8472be2e008d0cab2260d
Author: Richard Biener 
Date:   Wed May 12 15:39:52 2021 +0200

tree-optimization/100566 - fix another predication issue in VN

This amends the fix for PR100053 where I failed to amend all edge
tests in dominated_by_p_w_unex.

2021-05-12  Richard Biener  

PR tree-optimization/100566
* tree-ssa-sccvn.c (dominated_by_p_w_unex): Properly handle
allow_back for all edge queries.

* gcc.dg/torture/pr100566.c: New testcase.

[Bug libstdc++/100558] std::ranges::views operator| fails to compile

2021-05-12 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100558

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Patrick, could you backport r12-321 please.

[Bug c++/47342] misleading diagnostic for member of undeclared class template partial specialization

2021-05-12 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47342

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-09-26 00:00:00 |2021-5-12
   Severity|enhancement |normal

--- Comment #4 from Jonathan Wakely  ---
I was about to report a new bug, but I think it's another case of this one:

template struct S { };

template struct X { };

template struct S>;  // line 5

void f(S>* s)
{
  s->x;
}

This prints:

loc.C: In function 'void f(S >*)':
loc.C:9:4: error: invalid use of incomplete type 'struct S >'
9 |   s->x;
  |^~
loc.C:1:29: note: declaration of 'struct S >'
1 | template struct S { };
  | ^

The note shows the declaration of the primary template, which is not
incomplete.

The relevant declaration is the one on line 5.

[Bug c++/99644] Add fix-it hint for constrained specialization declared as primary template

2021-05-12 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99644

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-05-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug middle-end/100477] Bogus -Wstringop-overflow warning on memset

2021-05-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477

--- Comment #10 from Martin Sebor  ---
You're right that the #pragma can be a little flakey with inlining.  This is a
recurring issue that can be made worse by LTO.  A fix I submitted for GCC 11
got deferred to GCC 12 (see pr98465 comment 12).  I have to dust it off and
resubmit it.

[Bug libstdc++/100558] std::ranges::views operator| fails to compile

2021-05-12 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100558

康桓瑋  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #1 from 康桓瑋  ---
(In reply to Jooseong Lee from comment #0)
> GCC 11.1.0 fails to compile this code
> 
> https://wandbox.org/permlink/yWSpe4tVZTI3ljKg
> 
> which has no problem in
> 
> GCC 12.0 HEAD 20210511 (https://wandbox.org/permlink/YWzUzsmIjdqe5zvH)
> GCC 10.1.0 (https://wandbox.org/permlink/wVsn1mqhLuS2R5vg)
> 
> Some updates in 11.1.0 must be broken

The problem here is narrowing conversion of list-initialization in require
clause of range adaptors, which been resolved in
https://github.com/gcc-mirror/gcc/commit/6e00d9bb113b531be15bc71cad2f1742648ba18a#diff-f6609135db2231e86a4562e8e69d605ff4ec06e6f02f43c5ffc23bc7126ab719.

[Bug ada/100559] Solaris SPARC GCC 11.1 Ada build: i-cexten.ads:278:28: modulus exceeds limit (2 ** 64)

2021-05-12 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559

Eric Botcazou  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org
 Status|WAITING |NEW

--- Comment #10 from Eric Botcazou  ---
Rainer, what's the name of the RTS subdir for the 32-bit Ada runtime in your
sparcv9-sun-solaris2.11 builds?  It's really rts_32 or rts_sparcv8plus?
-print-multi-directory

[Bug middle-end/100568] New: [12 regression] ICE at gcc/tree-ssa.c:1214 after r12-657

2021-05-12 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100568

Bug ID: 100568
   Summary: [12 regression] ICE at gcc/tree-ssa.c:1214 after
r12-657
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:a076632e274abe344ca7648b7c7f299273d4cbe0, r12-657

Occurs when building libgo on powerpc64.

libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-O2 -g -I . -c -fgo-pkgpath=syscall
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/dirent.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/endian_big.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/env_unix.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/errstr_glibc.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/exec_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/exec_unix.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_glibc.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_linux_utimesnano.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_posix.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_posix_largefile.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_posix_nonhurd.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_support.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_uname.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/libcall_wait4.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/lsf_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/msan0.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/net.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/netlink_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/setuidgid_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/sleep_select.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/sock_cloexec_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/sockcmsg_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/sockcmsg_unix.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/sockcmsg_unix_other.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/socket.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/socket_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/socket_linux_ppc64x_type.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/socket_posix.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/str.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/syscall.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/syscall_errno.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/syscall_funcs.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/syscall_glibc.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/syscall_linux.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/syscall_unix.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/time_nofake.go
/home/seurer/gcc/git/gcc-test/libgo/go/syscall/timestruct.go libcalls.go
sysinfo.go syscall_arch.go syscall_linknames.go epoll.go  -fPIC -o
.libs/syscall.o
In function 'syscall.forkExec':
go1: error: address taken, but ADDRESSABLE bit not set
PHI argument

for PHI node
err$__object_77 = PHI 
during GIMPLE pass: fre
go1: internal compiler error: verify_ssa failed
0x10eb5a33 verify_ssa(bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa.c:1214
0x10a4163f execute_function_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2049
0x10a4287b do_per_function
/home/seurer/gcc/git/gcc-test/gcc/passes.c:1687
0x10a42a93 execute_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [syscall.lo] Error 1
make[4]: Leaving directory
`/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libgo'


commit a076632e274abe344ca7648b7c7f299273d4cbe0
Author: Richard Biener 
Date:   Fri May 7 09:51:18 2021 +0200

middle-end/100464 - avoid spurious TREE_ADDRESSABLE in folding debug stmts

[Bug target/98461] Suboptimal codegen for negating a movemask

2021-05-12 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98461

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/100566] [9/10/11/12 Regression] Miscompilation of mausezahn since r9-2635

2021-05-12 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

--- Comment #4 from Richard Biener  ---
Created attachment 50801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50801=edit
patch

OK, so the issue is that predication is still bogus (similar to the other PR)
and we're treating a non-executable backedge optimistically here.

testing the attached

[Bug ipa/100491] [11/12 Regression] IPA-SRA is not happening any more

2021-05-12 Thread jamborm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100491

Martin Jambor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-05-12
 Status|UNCONFIRMED |NEW

--- Comment #6 from Martin Jambor  ---
It is the char[] part of the declaration that causes this, changing it
to a pointer also avoids the issue.

In GCC 11, functions with parameters which are these length-less
arrays automagically receive an access function type attribute and
IPA-SRA does not understand them and so punts.

Understanding some attributes, eventually including access, is on my
TODO list, meanwhile please use a pointer type.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.2/12+ so far.
Should be backported to 9 and 10 which do support task reductions.

[Bug preprocessor/100392] [11/12 Regression] compiling result of "g++ -E -fdirectives-only" causes "error: stray ‘#’ in program" if no newline at EOF

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100392

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 11.2/12+.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100508

--- Comment #7 from Jakub Jelinek  ---
Fixed for 11.2/12+ so far.

[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100508

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

https://gcc.gnu.org/g:5998192bff6313a49d1e78bb224f8d7600a6072d

commit r11-8403-g5998192bff6313a49d1e78bb224f8d7600a6072d
Author: Jakub Jelinek 
Date:   Wed May 12 10:38:35 2021 +0200

expand: Don't reuse DEBUG_EXPRs with vector type if they have different
modes [PR100508]

The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
in multiple functions.
Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
can be reused in multiple functions.
Neither of that is a major problem, DEBUG_EXPRs are just magic value
holders
and what value they stand for is independent in each function and driven by
what debug stmts or DEBUG_INSNs they are bound to.
Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
or some vector mode depending on whether current function's enabled ISAs
support that vector mode or not.  On the following testcase, we expand it
first in foo function without AVX2 enabled and so the DEBUG_EXPR is
BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
AVX2 enabled and expansion ICEs because of a mode mismatch.

The following patch fixes that by forcing recreation of a DEBUG_EXPR if
there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
will be still reused in between functions otherwise and within the same
function the mode should be always the same.

2021-05-12  Jakub Jelinek  

PR middle-end/100508
* cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
type, don't reuse DECL_RTL if it has different mode, instead force
creation of a new DEBUG_EXPR.

* gcc.dg/gomp/pr100508.c: New test.

(cherry picked from commit 19040050aa2c8ee890fc58dda48639fc91bf0af0)

[Bug preprocessor/100392] [11/12 Regression] compiling result of "g++ -E -fdirectives-only" causes "error: stray ‘#’ in program" if no newline at EOF

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100392

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

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

commit r11-8404-gb6ecd493886891f8150905a2fd3b7d54e88fc7be
Author: Jakub Jelinek 
Date:   Wed May 12 15:14:35 2021 +0200

libcpp: Fix up -fdirectives-only preprocessing of includes not ending with
newline [PR100392]

If a header doesn't end with a new-line, with -fdirectives-only we right
now
preprocess it as
int i = 1;# 2 "pr100392.c" 2
i.e. the line directive isn't on the next line, which means we fail to
parse
it when compiling.

GCC 10 and earlier libcpp/directives-only.c had for this:
  if (!pfile->state.skipping && cur != base)
{
  /* If the file was not newline terminated, add rlimit, which is
 guaranteed to point to a newline, to the end of our range.  */
  if (cur[-1] != '\n')
{
  cur++;
  CPP_INCREMENT_LINE (pfile, 0);
  lines++;
}

  cb->print_lines (lines, base, cur - base);
}
and we have the assertion
  /* Files always end in a newline or carriage return.  We rely on this
for
 character peeking safety.  */
  gcc_assert (buffer->rlimit[0] == '\n' || buffer->rlimit[0] == '\r');
So, this patch just does readd the more less same thing, so that we emit
a newline after the inline even when it wasn't there before.

2021-05-12  Jakub Jelinek  

PR preprocessor/100392
* lex.c (cpp_directive_only_process): If buffer doesn't end with
'\n',
add buffer->rlimit[0] character to the printed range and
CPP_INCREMENT_LINE and increment line_count.

* gcc.dg/cpp/pr100392.c: New test.
* gcc.dg/cpp/pr100392.h: New file.

(cherry picked from commit c6b664e2c4c127025e076d8b584abe0976694629)

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471

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

https://gcc.gnu.org/g:58ce04708738840fa1917c49f686ce0266ba6e77

commit r11-8402-g58ce04708738840fa1917c49f686ce0266ba6e77
Author: Jakub Jelinek 
Date:   Tue May 11 09:07:47 2021 +0200

openmp: Fix up taskloop reduction ICE if taskloop has no iterations
[PR100471]

When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
return, doesn't create any tasks and more importantly, doesn't create
a taskgroup and doesn't register task reductions.  But, the code emitted
in the callers assumes task reductions have been registered and performs
the reduction handling and task reduction unregistration.  The pointer
to the task reduction private variables is reused, on input it is the
alignment
and only on output it is the pointer, so in the case taskloop with no
iterations
the caller attempts to dereference the alignment value as if it was a
pointer
and crashes.  We could in the early returns register the task reductions
only to have them looped over and unregistered in the caller, but I think
it is better to tell the caller there is nothing to task reduce and bypass
all that.

2021-05-11  Jakub Jelinek  

PR middle-end/100471
* omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data
is 0, bypass the reduction loop including
GOMP_taskgroup_reduction_unregister call.

* taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not
GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task
reduction pointer.
* testsuite/libgomp.c/task-reduction-4.c: New test.

(cherry picked from commit 98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a)

[Bug libstdc++/100567] New: views::take and views::drop should conditionally use _RangeAdaptor::operator()

2021-05-12 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100567

Bug ID: 100567
   Summary: views::take and views::drop should conditionally use
_RangeAdaptor::operator()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Hi, the re-implemented range adaptors use _RangeAdaptor to handle the arg of
the adaptors, but for views::take and views::drop, the constraint that this arg
can perfectly forward to range::range_difference_t is lacking.

https://godbolt.org/z/j88q5Yn6Y

#include 
struct S {
  operator int() { return 0; }
};
const S obj;
auto r  = std::views::iota(0, 3);
auto d1 = r | std::views::drop(obj); // ok, should error
auto d2 = std::views::drop(r, obj);  // error
auto f1 = r | std::views::take(obj); // ok, should error
auto f2 = std::views::take(r, obj);  // error

[Bug preprocessor/100392] [11/12 Regression] compiling result of "g++ -E -fdirectives-only" causes "error: stray ‘#’ in program" if no newline at EOF

2021-05-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100392

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

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

commit r12-748-gc6b664e2c4c127025e076d8b584abe0976694629
Author: Jakub Jelinek 
Date:   Wed May 12 15:14:35 2021 +0200

libcpp: Fix up -fdirectives-only preprocessing of includes not ending with
newline [PR100392]

If a header doesn't end with a new-line, with -fdirectives-only we right
now
preprocess it as
int i = 1;# 2 "pr100392.c" 2
i.e. the line directive isn't on the next line, which means we fail to
parse
it when compiling.

GCC 10 and earlier libcpp/directives-only.c had for this:
  if (!pfile->state.skipping && cur != base)
{
  /* If the file was not newline terminated, add rlimit, which is
 guaranteed to point to a newline, to the end of our range.  */
  if (cur[-1] != '\n')
{
  cur++;
  CPP_INCREMENT_LINE (pfile, 0);
  lines++;
}

  cb->print_lines (lines, base, cur - base);
}
and we have the assertion
  /* Files always end in a newline or carriage return.  We rely on this
for
 character peeking safety.  */
  gcc_assert (buffer->rlimit[0] == '\n' || buffer->rlimit[0] == '\r');
So, this patch just does readd the more less same thing, so that we emit
a newline after the inline even when it wasn't there before.

2021-05-12  Jakub Jelinek  

PR preprocessor/100392
* lex.c (cpp_directive_only_process): If buffer doesn't end with
'\n',
add buffer->rlimit[0] character to the printed range and
CPP_INCREMENT_LINE and increment line_count.

* gcc.dg/cpp/pr100392.c: New test.
* gcc.dg/cpp/pr100392.h: New file.

[Bug other/98375] [meta bug] GCC 12 pending patches

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375
Bug 98375 depends on bug 98461, which changed state.

Bug 98461 Summary: Suboptimal codegen for negating a movemask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98461

   What|Removed |Added

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

[Bug target/98461] Suboptimal codegen for negating a movemask

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98461

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
I hope so.

[Bug target/100336] file trunk/gcc/config/i386/i386-isa.def doesn't get installed ok ?

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100336

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/98461] Suboptimal codegen for negating a movemask

2021-05-12 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98461

--- Comment #15 from H.J. Lu  ---
Is this fixed now?

[Bug tree-optimization/100566] [9/10/11/12 Regression] Miscompilation of mausezahn since r9-2635

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

--- Comment #3 from Jakub Jelinek  ---
The r9-2635 change miscompiles it during PRE,
   [local count: 347387062]:
  j_7 ={v} s;
  if (j_7 == 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 291805133]:
  # i_8 = PHI <0(2), i_2(6)>

   [local count: 1073741825]:
  foo ();
  if (j_7 == 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 955630225]:
  goto ; [100.00%]

   [local count: 118111601]:
  i_10 = i_8 + 1;

   [local count: 347387062]:
  # i_2 = PHI 
  if (i_2 < j_7)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 173693531]:
  return 0;
looks ok, but PRE assumes the second j_7 == 0 is always true and thus turns the
foo () call into a tight endless loop:
   [local count: 1073741825]:
  foo ();
  goto ; [100.00%]
That is the intention of the testcase when s == 0, but not otherwise.

[Bug tree-optimization/100566] [9/10/11/12 Regression] Miscompilation of mausezahn since r9-2635

2021-05-12 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

[Bug tree-optimization/100566] [11/12 Regression] Miscompilation of mausezahn since r9-2635

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|11.2|9.4
Summary|[11/12 Regression]  |[11/12 Regression]
   |Miscompilation of mausezahn |Miscompilation of mausezahn
   |since r11-2446  |since r9-2635

[Bug tree-optimization/100566] [11/12 Regression] Miscompilation of mausezahn since r11-2446

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

--- Comment #1 from Jakub Jelinek  ---
Though, on more reduced testcase from that it started already in
r9-2635-g78ea9abc2018243af7f7ada6135144ac90c6ad27
(likewise at -O2):
volatile int s, c;

__attribute__((noipa)) void
foo (void)
{
  if (c++ > 1)
__builtin_abort ();
}

__attribute__((noipa)) int
bar (void)
{
  int i = 0, j = s;
  if (j == 0)
goto lab;
  for (i = 0; i < j; i++)
{
lab:
  foo ();
  if (!j)
goto lab;
}
  return 0;
}

int
main ()
{
  s = 1;
  bar ();
  if (c != 1)
__builtin_abort ();
  return 0;
}

[Bug ada/100559] Solaris SPARC GCC 11.1 Ada build: i-cexten.ads:278:28: modulus exceeds limit (2 ** 64)

2021-05-12 Thread sumbera at volny dot cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559

--- Comment #9 from Petr Sumbera  ---
(In reply to Eric Botcazou from comment #8)
> Unlikely I'd say.  Could you go into the $(buildir]/gcc/ada directory and do:
>   ls -l rts/i-cexten.ads
>   ls -l rts_32/i-cexten.ads
> They should not point to the same source file.

There is indeed some problem:

intel:
rts/i-cexten.ads ->
/builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten__128.ads
rts_32/i-cexten.ads ->
/builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten.ads

SPARC:
rts/i-cexten.ads ->
/builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten__128.ads
rts_32/i-cexten.ads ->
/builds/psumbera/userland-gcc-11.1/components/gcc10/gcc-11.1.0/gcc/ada/libgnat/i-cexten__128.ads

[Bug tree-optimization/100566] [11/12 Regression] Miscompilation of mausezahn since r11-2446

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2021-05-12
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.2
 Ever confirmed|0   |1

[Bug tree-optimization/100566] New: [11/12 Regression] Miscompilation of mausezahn since r11-2446

2021-05-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100566

Bug ID: 100566
   Summary: [11/12 Regression] Miscompilation of mausezahn since
r11-2446
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase is miscompiled at -O2 since
r11-2446-g3e61a2056335ca7d4e2009823efae4ee2dc950ee
- it loops endlessly instead of terminating.

struct S { unsigned int s1, s2; int s3, s4, s5, s6, s7; unsigned int s8; };
struct S s;
enum E { E1, E2, E3, E4, E5, E6, E7, E8, E9, E10, E11, E12, E13, E14, E15 };
enum E e;
int f, g, h;

__attribute__((noipa)) void fn1 (void *l)
{
  asm volatile ("" : : "r" (l) : "memory");
}

__attribute__((noipa)) int fn2 (void *l)
{
  asm volatile ("" : : "r" (l) : "memory");
  return 0;
}

__attribute__((noipa)) int fn3 (void)
{
  asm volatile ("" : : : "memory");
  return 0;
}

__attribute__((nothrow, leaf, noipa)) int fn4 (void)
{
  asm volatile ("" : : : "memory");
  return 0;
}

__attribute__((noipa)) int fn5 (unsigned int l)
{
  asm volatile ("" : : "r" (l) : "memory");
  return 0;
}

__attribute__((noipa)) int fn6 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn7 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn8 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn9 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn10 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn11 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn12 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn13 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa)) int fn14 (void *l, int t)
{
  asm volatile ("" : : "r" (l), "r" (t) : "memory");
  return 0;
}

__attribute__((noipa))
int test (void *l, int y, int z)
{
  int i = 0, s1;
  int s8, s7, s6, s5, s4, j = 0;
  s1 = s.s1;
  s8 = s.s8;
  s7 = s.s7;
  s6 = s.s6;
  s5 = s.s5;
  s4 = s.s4 | s.s3;
  if (e == E11)
j = 1;
  if (s1 == 0)
goto lab;
  for (i = 0; i < s1; i++)
{
lab:
  if (f)
{
  switch (e)
{
case E6:
  fn12 (l, z);
  break;
case E7:
case E9:
case E11:
case E13:
  fn13 (l, z);
  break;
case E8:
  fn14 (l, z);
  break;
}
}
  if (g)
fn3 ();
  fn2 (l);
  if (h)
s.s2 = (unsigned int) s.s2 * fn4 () / 2147483647;
  if (s.s2)
fn5 (s.s2);
  if (s8)
{
  if (fn11 (l, z) == 0)
goto lab;
}
  if (s7)
{
  if (fn9 (l, z) == 0)
goto lab;
}
  if (s6)
{
  if (fn10 (l, z) == 0)
goto lab;
}
  if (s5)
{
  if (fn8 (l, y) == 0)
goto lab;
}
  if (s4)
{
  if (fn7 (l, y) == 0)
goto lab;
}
  if (j)
fn6 (l, z);
  if (!s1)
goto lab;
}
  fn1 (l);
  return 0;
}

int
main ()
{
  asm volatile ("" : : "g" (), "g" (), "g" (), "g" (), "g" () :
"memory");
  s.s1 = 1;
  e = E7;
  test (0, 2, 1);
  return 0;
}

[Bug target/100565] New: [nvptx] Need configure options for misa default

2021-05-12 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100565

Bug ID: 100565
   Summary: [nvptx] Need configure options for misa default
   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: ---

We have -misa, and soon we'll have -mptx (PR96005).

We can try to make sensible decisions about proper defaults, but we still may
get it wrong for some users.  So, better allow users to override the default in
a way that does not involve changing the sources.

Something like --with-nvptx-isa=sm_30 --with-nvptx-ptx-version=3.1.

[Bug bootstrap/100552] [11/12 Regression] configure: 32208: Syntax error: Bad substitution

2021-05-12 Thread mhillen at linux dot ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100552

--- Comment #1 from Marius Hillenbrand  ---
Indeed, that line should not use the bash-specific pattern substitution and
instead like this:


diff --git a/gcc/configure.ac b/gcc/configure.ac
index e9ba2af548a..4e788019d99 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -7499,7 +7499,8 @@ case $target in
   # cross build. are target headers available?
   # carefully coerce the build-system compiler to use target headers
   saved_CXXFLAGS="$CXXFLAGS"
-  CROSS_TEST_CXXFLAGS="-nostdinc ${XGCC_FLAGS_FOR_TARGET//-B/-idirafter/}"
+  fixed_XGCC_FLAGS_FOR_TARGET=`echo "$XGCC_FLAGS_FOR_TARGET" | sed
's/-B/-idirafter/g'`
+  CROSS_TEST_CXXFLAGS="-nostdinc $fixed_XGCC_FLAGS_FOR_TARGET"
   CXXFLAGS="$CROSS_TEST_CXXFLAGS"
   AC_COMPILE_IFELSE([AC_LANG_SOURCE([[


not fully tested yet, but it avoids the syntax error in dash and in NetBSD 9.1

[Bug target/96932] [nvptx] atomic_exchange missing barrier

2021-05-12 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932

--- Comment #4 from Tom de Vries  ---
(In reply to Tobias Burnus from comment #3)
> Crossref: PR100497 - fails on Volta without
>   membar.sys;
> before
>   atom.global.exch.b32
> 
> Unfortunately, compared to pre-Volta, it is very slow - membar.gl is still
> slow but a bit less.  Using (→ sm_70) fence.sys / fence.gnu instead of
> fence.sc.{sys,gnu} (= membar.{sys,gl} on >= sm_70) does not seem to make a

fence.sc.gpu, funny typo :)

> performance difference for PR100497.

The GOMP_atomic_start/GOMP_atomic_end are fallbacks, and unfortunately cannot
be expected to be too optimal.

Following the introduction of -mptx=6.3 we can add support for atom.cas.b16
(well, once we also introduce misa=sm_70), and that should be the optimal
solution.

[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.

2021-05-12 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908

--- Comment #8 from Richard Earnshaw  ---
Never mind, the original reference to arm was not the 'arm cpu', my mistake.

[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.

2021-05-12 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908

--- Comment #7 from Richard Earnshaw  ---
(In reply to Hongtao.liu from comment #6)
> Should be fixed in trunk.

The original report was about arm.  None of your changes are outside of the x86
backend, so no, this is not fixed for the original reporter.

  1   2   >