[Bug rtl-optimization/96539] New: Unnecessary no-op copy with Os and tail call with struct argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539
Bug ID: 96539
Summary: Unnecessary no-op copy with Os and tail call with
struct argument
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Test C code,
```
struct A {
int a;
int b;
int c;
int d;
int e;
int f;
void *p1;
void *p2;
void *p3;
void *p4;
void *p5;
void *p6;
void *p7;
};
int k(int a);
int f(int a, int b, int c, void *p, struct A s);
int g(int a, int b, int c, void *p, struct A s)
{
k(a);
return f(a, b, c, p, s);
}
```
At `-O2`, the code produced is
```
g:
pushq %r14
movq%rcx, %r14
pushq %r13
movl%edx, %r13d
pushq %r12
movl%esi, %r12d
pushq %rbp
movl%edi, %ebp
subq$8, %rsp
callk@PLT
addq$8, %rsp
movq%r14, %rcx
movl%r13d, %edx
movl%r12d, %esi
movl%ebp, %edi
popq%rbp
popq%r12
popq%r13
popq%r14
jmp f@PLT
```
I'm not sure why the spill of register and save the argument in those registers
(maybe for latency for the final call?) but both clang and gcc does that so I
assume that's good for performance. However, when I tried `-Os`, the code
produced is,
```
g:
pushq %r14
movq%rcx, %r14
pushq %r12
movl%esi, %r12d
pushq %rbp
movl%edi, %ebp
subq$16, %rsp
movl%edx, 12(%rsp)
callk@PLT
leaq48(%rsp), %rdi
movl$20, %ecx
movq%rdi, %rsi
rep movsl
movq%r14, %rcx
movl%r12d, %esi
movl%ebp, %edi
movl12(%rsp), %edx
addq$16, %rsp
popq%rbp
popq%r12
popq%r14
jmp f@PLT
```
AFAICT, the
```
movq%rdi, %rsi
rep movsl
```
is basically always a no-op (moving from and to the same memory location) other
than potentially triggering memory fault.
The memory being copied in place here is the area where the argument is stored
(80 bytes starting at `rsp + 48`) so maybe it's the copying of the argument
that failed to be removed when it becomes an no-op for tail call?
At `-O1`, the code produced is
```
g:
pushq %r13
pushq %r12
pushq %rbp
pushq %rbx
subq$8, %rsp
movl%edi, %ebx
movl%esi, %ebp
movl%edx, %r12d
movq%rcx, %r13
callk@PLT
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
pushq 120(%rsp)
movq%r13, %rcx
movl%r12d, %edx
movl%ebp, %esi
movl%ebx, %edi
callf@PLT
addq$88, %rsp
popq%rbx
popq%rbp
popq%r12
popq%r13
ret
```
which shows the copying of 10 pointers that was not no-op without tail call.
[Bug c++/96538] Integer overflow when there are multiple operands in addition operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96538
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
There is NO BUG here:
sum = arr[1]+arr[2]+arr[3];
Is done in integer type and then casted to long.
that is it is the same as:
sum = (long)(arr[1]+arr[2]+arr[3]);
While:
for(int j=0;j<5;j++)
{
sum = sum+ arr[j];
}
Is Done in long type.
You can fix the original code by doing:
sum = ((long)arr[1])+((long)arr[2])+((long)arr[3]);
[Bug target/96446] ICE when spilling an MMA accumulator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:38b240a9dc7186a51e577dd3ff73c31af3cfb0ab commit r10-8594-g38b240a9dc7186a51e577dd3ff73c31af3cfb0ab Author: Peter Bergner Date: Thu Aug 6 10:03:03 2020 -0500 rs6000: Don't ICE when spilling an MMA accumulator When we spill an accumulator that has a known zero value, LRA will emit a new (set (reg:PXI ...) 0) insn, but it does not use the mma_xxsetaccz pattern to do it, leading to an unrecognized insn ICE. The solution here is to move the xxsetaccz instruction into the movpxi pattern and have the xxsetaccz pattern call the move pattern. 2020-08-06 Peter Bergner gcc/ PR target/96446 * config/rs6000/mma.md (*movpxi): Add xxsetaccz generation. Disable split for zero constant source operand. (mma_xxsetaccz): Change to define_expand. Call gen_movpxi. gcc/testsuite/ PR target/96446 * gcc.target/powerpc/pr96446.c: New test. (cherry picked from commit 9c376d1c166e7c8b10bba6f1675d2471ffe8447f)
[Bug bootstrap/96492] : internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96492 --- Comment #5 from Rich Townsend --- So, given that gcc 4.1.2 is really ancient, I've tried building 10.2 using gcc 9.3.0 instead (but still inside the Docker container). This builds fine, and in fact I'm happy to go with this workaround. However, might be worth noting somewhere that gcc 10.X cannot be built with gcc 4.1.2. cheers, Rich
[Bug c++/96538] Integer overflow when there are multiple operands in addition operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96538
--- Comment #1 from Prateek Khade ---
(In reply to Prateek Khade from comment #0)
> I am trying to add int values present in the vector and store in long int
> type variable. If I am using for loop for calculating the sum of vector
> elements program produces correct sum. However if If I perform direct
> addition(e.g sum= arr[0]+arr[1]...=arr[n]), the results obtained is
> incorrect and seems that overflow is occurring. Below is the code snippet
> for you reference:
>
> Input:942381765 627450398 954173620 583762094 236817490
>
>
> Code leading to overflow/error:
> #include
> using namespace std;
>
> int main()
> {
> vector arr(5);
> for(int i=0;i<5;i++)
> {
> cin>>arr[i];
> }
> sort(arr.begin(),arr.end());
> long int sum = 0,min_sum=0,max_sum=0;
> sum = arr[1]+arr[2]+arr[3]
> min_sum = arr[0]+ sum;
> max_sum = arr[4]+ sum;
> cout<
> return 0;
> }
>
>
> Output :-190449 -1187199419
>
> Code producing correct output:
>
> #include
> using namespace std;
>
> int main()
> {
> vector arr(5);
> for(int i=0;i<5;i++)
> {
> cin>>arr[i];
> }
> sort(arr.begin(),arr.end());
> long int sum = 0,min_sum=0,max_sum=0;
> for(int j=1;j<4;j++)
> {
> sum = sum+ arr[j];//after for loop sum = arr[1]+arr[2]+arr[3]
> }
> min_sum = arr[0]+ sum;
> max_sum = arr[4]+ sum;
> cout<
> return 0;
> }
>
>
>
> Output(for same input as above):
> 3581402857 4298758987
[Bug c++/96538] New: Integer overflow when there are multiple operands in addition operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96538
Bug ID: 96538
Summary: Integer overflow when there are multiple operands in
addition operation.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: prateek_kd at yahoo dot co.in
Target Milestone: ---
I am trying to add int values present in the vector and store in long int type
variable. If I am using for loop for calculating the sum of vector elements
program produces correct sum. However if If I perform direct addition(e.g sum=
arr[0]+arr[1]...=arr[n]), the results obtained is incorrect and seems that
overflow is occurring. Below is the code snippet for you reference:
Input:942381765 627450398 954173620 583762094 236817490
Code leading to overflow/error:
#include
using namespace std;
int main()
{
vector arr(5);
for(int i=0;i<5;i++)
{
cin>>arr[i];
}
sort(arr.begin(),arr.end());
long int sum = 0,min_sum=0,max_sum=0;
sum = arr[1]+arr[2]+arr[3]
min_sum = arr[0]+ sum;
max_sum = arr[4]+ sum;
cout<
using namespace std;
int main()
{
vector arr(5);
for(int i=0;i<5;i++)
{
cin>>arr[i];
}
sort(arr.begin(),arr.end());
long int sum = 0,min_sum=0,max_sum=0;
for(int j=0;j<5;j++)
{
sum = sum+ arr[j];//after for loop sum = arr[1]+arr[2]+arr[3]
}
min_sum = arr[0]+ sum;
max_sum = arr[4]+ sum;
cout<
[Bug target/96530] MMA built-ins reject typedefs of MMA types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530 Peter Bergner changed: What|Removed |Added Target Milestone|--- |10.3 --- Comment #3 from Peter Bergner --- Fixed on trunk. Will let it bake a little before backporting to GCC 10.
[Bug target/96530] MMA built-ins reject typedefs of MMA types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530 --- Comment #2 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:e2882e76089cecdc268d0835c54cabfa80b5b0be commit r11-2616-ge2882e76089cecdc268d0835c54cabfa80b5b0be Author: Peter Bergner Date: Sat Aug 8 11:54:48 2020 -0500 rs6000: MMA built-ins reject typedefs of MMA types We do not allow conversions between the MMA types and other types. However, we are being too strict in not matching MMA types with typdefs of those types. Use TYPE_CANONICAL to see through the types to their canonical types before comparing them. 2020-08-08 Peter Bergner gcc/ PR target/96530 * config/rs6000/rs6000.c (rs6000_invalid_conversion): Use canonical types for type comparisons. Refactor code to simplify it. gcc/testsuite/ PR target/96530 * gcc.target/powerpc/pr96530.c: New test.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #35 from Ian Lance Taylor --- I don't know that anybody has looked at the BSD support recently. Thanks for your efforts. I agree that this is work for a programmer.
[Bug c++/96537] Missing std::pair constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537 Tom de Vries changed: What|Removed |Added Known to work||7.5.0 Target Milestone|--- |7.5 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to fail||4.8.5 --- Comment #1 from Tom de Vries --- Can be worked around by using: ... m.emplace (1, std::unique_ptr (new A(1))); ... This PR is probably a duplicate, but I'm not sure which one. Anyway, this is fixed starting 7.5.0, so closing it as resolved-fixed, perhaps someone can mark it a duplicate.
[Bug c++/96537] New: Missing std::pair constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
Bug ID: 96537
Summary: Missing std::pair constructor
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider test-case test.c:
...
#include
#include
class A {
public:
A (int a) { i = a; }
int i;
};
int main (void) {
std::unordered_map> m;
m.emplace (1, new A(1));
return 0;
}
...
With gcc 7.5.0, we have:
...
$ g++-7 test.c -O2 -std=c++11
$ ./a.out
$
...
With gcc 4.8.5, we have instead:
...
$ g++-4.8 test.c -O2 -std=c++11
In file included from /usr/include/c++/4.8/bits/hashtable.h:35:0,
from /usr/include/c++/4.8/unordered_map:47,
from test.c:2:
/usr/include/c++/4.8/bits/hashtable_policy.h: In instantiation of
‘std::__detail::_Hash_node<_Value, false>::_Hash_node(_Args&& ...) [with _Args
= {int, A*}; _Value = std::pair >]’:
/usr/include/c++/4.8/ext/new_allocator.h:120:4: required from ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
std::__detail::_Hash_node >, false>;
_Args = {int, A*}; _Tp = std::__detail::_Hash_node >, false>]’
/usr/include/c++/4.8/bits/hashtable.h:727:6: required from
‘std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash,
_RehashPolicy, _Traits>::__node_type* std::_Hashtable<_Key, _Value, _Alloc,
_ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy,
_Traits>::_M_allocate_node(_Args&& ...) [with _Args = {int, A*}; _Key = int;
_Value = std::pair >; _Alloc =
std::allocator > >; _ExtractKey =
std::__detail::_Select1st; _Equal = std::equal_to; _H1 = std::hash;
_H2 = std::__detail::_Mod_range_hashing; _Hash =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits; std::_Hashtable<_Key,
_Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy,
_Traits>::__node_type = std::__detail::_Hash_node >, false>]’
/usr/include/c++/4.8/bits/hashtable.h:1260:71: required from
‘std::pair::iterator, bool> std::_Hashtable<_Key,
_Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy,
_Traits>::_M_emplace(std::true_type, _Args&& ...) [with _Args = {int, A*}; _Key
= int; _Value = std::pair >; _Alloc =
std::allocator > >; _ExtractKey =
std::__detail::_Select1st; _Equal = std::equal_to; _H1 = std::hash;
_H2 = std::__detail::_Mod_range_hashing; _Hash =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits; typename
std::__detail::_Hashtable_base<_Key, _Value, _ExtractKey, _Equal, _H1, _H2,
_Hash, _Traits>::iterator = std::__detail::_Node_iterator >, false, false>; std::true_type =
std::integral_constant]’
/usr/include/c++/4.8/bits/hashtable.h:665:69: required from
‘std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash,
_RehashPolicy, _Traits>::__ireturn_type std::_Hashtable<_Key, _Value, _Alloc,
_ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits>::emplace(_Args&&
...) [with _Args = {int, A*}; _Key = int; _Value = std::pair >; _Alloc = std::allocator > >; _ExtractKey = std::__detail::_Select1st; _Equal =
std::equal_to; _H1 = std::hash; _H2 =
std::__detail::_Mod_range_hashing; _Hash = std::__detail::_Default_ranged_hash;
_RehashPolicy = std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits; std::_Hashtable<_Key,
_Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash, _RehashPolicy,
_Traits>::__ireturn_type =
std::pair
>, false, false>, bool>]’
/usr/include/c++/4.8/bits/unordered_map.h:311:54: required from
‘std::pair, _Alloc,
std::__detail::_Select1st, _Pred, _Hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits,
std::is_default_constructible<_Hash>, std::is_copy_assignable<_Hash>,
std::__detail::__is_noexcept_hash<_Key, _Hash> > >::value, false, true>
>::iterator, bool> std::unordered_map<_Key, _Tp, _Hash, _Pred,
_Alloc>::emplace(_Args&& ...) [with _Args = {int, A*}; _Key = int; _Tp =
std::unique_ptr; _Hash = std::hash; _Pred = std::equal_to; _Alloc
= std::allocator > >; typename
std::_Hashtable<_Key, std::pair, _Alloc,
std::__detail::_Select1st, _Pred, _Hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy,
std::__detail::_Hashtable_traits,
std::is_default_constructible<_Hash>, std::is_copy_assignable<_Hash>,
std::__detail::__is_noexcept_hash<_Key, _Hash> > >::value, false, true>
>::iterator = std::__detail::_Node_iterator >, false, false>]’
test.c:10:25: required from here
/usr/include/c++/4.8/bits/hashtable_policy.h:195:39: error: no matching
function for call to ‘std::pair >::pair(int, A*)’
:
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #28 from Susi Lehtola --- Harald, Andreas, thanks for clarifying: yes, "crash" == Fortran runtime error. The program should run just fine, since the return array has the proper size given by get_environment_variable. Instead, it ends in a runtime error in get_environment_variable. The root cause is that get_environment_variable_i4 in libgfortran/intrinsics/env.c checks for a zero size return array before it checks what size an array is needed: when the environment variable is set to an empty string, a zero-size Fortran array is sufficient. The return value size check should just be moved a few lines down to where the memcpy() is performed.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #34 from Curtis Hamilton --- Do you know if anyone has actively worked on the BSD code recently? I'm abandoning my effort go get this working on freebsd. I'm not a really a programmer and this is beyond my meager abilities. So unless this is interest in further exploration, I'm going to close this issue.
[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96101 --- Comment #2 from Paul Thomas --- (In reply to Martin Liška from comment #1) > Started with r6-3986-g38217d3ee7c6e1fe. Hi Martin, As Gerhardt says, it compiles OK with version 7.4.1 20191027. The patch you reference is dated 2015-10-18! Cheers Paul
[Bug fortran/96312] [10/11 Regression] Reallocation on assignment uses undefined variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Created attachment 49031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49031=edit Patch for the PR This is quite straightforward. The patch makes sure that references to the bounds only occur if the lhs is allocated on arrival at offending statement. It even regtests OK :-) Paul
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 Christian Zietz changed: What|Removed |Added CC||czietz at gmx dot net --- Comment #5 from Christian Zietz --- The call to __builtin_memset() is added by the "tree-ldist" pass. On x86_64 it is replaced by inline code in the "rtl-expand" pass. On m68k it isn't.
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #4 from Thorsten Otto --- Might be caused by x86 and s390 having a machine dependant pattern for setmem/cpymem, possibly eliminating the library call again, while other target's don't have such a pattern.
[Bug tree-optimization/96424] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 23); or ICE: Segmentation fault (in expand_omp_for_init_vars/contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96424 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/96536] New: -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536 Bug ID: 96536 Summary: -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- Target: x86_64 Noticed while working on an optimisation that the -fcf-protection code in restore_stack_nonlocal uses a branch based on a clobber result: (insn 14 13 15 2 (parallel [ (set (reg:DI 85) (minus:DI (reg:DI 85) (mem:DI (plus:DI (reg/f:DI 82) (const_int 16 [0x10])) [2 S8 A8]))) (clobber (reg:CC 17 flags)) ]) "gcc/testsuite/gcc.target/i386/cet-sjlj-1.c":16:3 -1 (nil)) (jump_insn 15 14 40 2 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref 28) (pc))) "gcc/testsuite/gcc.target/i386/cet-sjlj-1.c":16:3 -1 (int_list:REG_BR_PROB 536870916 (nil)) -> 28) IMO this is invalid RTL. A clobber: Represents the storing or possible storing of an unpredictable, undescribed value … but this usage requires it to be predictable. I think we need to use the parallel-SET *sub_2 representation instead.
[Bug c++/96535] New: GCC 10 ignoring function __attribute__ optimize for all x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96535
Bug ID: 96535
Summary: GCC 10 ignoring function __attribute__ optimize for
all x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: danielhanchen at gmail dot com
Target Milestone: ---
Hey GCC team!
In GCC 10.x, it seems like any argument to __attribute__((optimize(...)) is
ignored at the function level. GCC 9.x and previous do not have this issue. [Or
maybe only -funroll-loops is ignored not 100% sure]
Detailed example at: https://gcc.godbolt.org/z/PTK4WE
3 Scenarios
1. [GCC 10.2: -O2 -ffast-math -march=haswell -std=c++2a -fopenmp] +
[__attribute__((optimize("O2","fast-math","unroll-loops")))] DOES NOT unroll.
2. [GCC 10.2: -funroll-loops -O2 -ffast-math -march=haswell -std=c++2a
-fopenmp] + [__attribute__((optimize("O2","fast-math","unroll-loops")))] DOES
unroll.
3. [GCC 9.3: -O2 -ffast-math -march=haswell -std=c++2a -fopenmp] +
[__attribute__((optimize("O2","fast-math","unroll-loops")))] DOES unroll.
It seems that in GCC 10.x, you have to place -funroll-loops in the compilation
string, and function level __attribute__s are ignored?
PS: Code in godbolt is a matrix multiplication kernel. It multiplies 1 column *
1 row of a matrix.
[Bug fortran/93553] ICE in scan_omp_1_op, at omp-low.c:3485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:676b5525e8333005bdc1c596ed086f1da27a450f commit r11-2615-g676b5525e8333005bdc1c596ed086f1da27a450f Author: Jakub Jelinek Date: Sat Aug 8 11:10:30 2020 +0200 openmp: Handle clauses with gimple sequences in convert_nonlocal_omp_clauses properly If the walk_body on the various sequences of reduction, lastprivate and/or linear clauses needs to create a temporary variable, we should declare that variable in that sequence rather than outside, where it would need to be privatized inside of the construct. 2020-08-08 Jakub Jelinek PR fortran/93553 * tree-nested.c (convert_nonlocal_omp_clauses): For OMP_CLAUSE_REDUCTION, OMP_CLAUSE_LASTPRIVATE and OMP_CLAUSE_LINEAR save info->new_local_var_chain around walks of the clause gimple sequences and declare_vars if needed into the sequence. 2020-08-08 Tobias Burnus PR fortran/93553 * testsuite/libgomp.fortran/pr93553.f90: New test.
[Bug tree-optimization/96424] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 23); or ICE: Segmentation fault (in expand_omp_for_init_vars/contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96424 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:87d6dae308d604bad111b1c0bfea7835888eed8d commit r11-2614-g87d6dae308d604bad111b1c0bfea7835888eed8d Author: Jakub Jelinek Date: Sat Aug 8 11:07:09 2020 +0200 openmp: Avoid floating point comparison at the end of bb with -fnon-call-exceptions The following testcase ICEs with -fexceptions -fnon-call-exceptions because in that mode floating point comparisons should not be done at the end of bb in GIMPLE_COND. Fixed by forcing it into a bool SSA_NAME and comparing that against false. 2020-08-08 Jakub Jelinek PR tree-optimization/96424 * omp-expand.c: Include tree-eh.h. (expand_omp_for_init_vars): Handle -fexceptions -fnon-call-exceptions by forcing floating point comparison into a bool temporary. * c-c++-common/gomp/pr96424.c: New test.
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson --- This happens for multiple targets: I can reproduce it with gcc-10.2 crosses to m68k, sparc64, and aarch64, but not with a cross to s390x or natively on x86_64.
[Bug c++/92139] Segmentation fault on constraints verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92139 --- Comment #3 from Mateusz Pusz --- Oh sorry, it seems I forgot to attach a preprocessed file. I am not able to find it now so please close this issue. Sorry for the trouble. Best Mat pt., 7 sie 2020, 18:52 użytkownik redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> napisał: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92139 > > --- Comment #2 from Jonathan Wakely --- > Mateusz, the testcase wasn't attached. Are you still able to provide it? > If not > we'll have to close this. > > -- > You are receiving this mail because: > You reported the bug.
