date:20200714

[Bug target/96201] x86 movsd/movsq string instructions and alignment inference

2020-07-14 Thread crazylht at gmail dot com

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
The issue is caused by pass_ivopt, ivopt select only one iv for f3(dn) which
seems not to be optimal, and select two iv for f4(sn,dn) which seems optimal.
---
loop in f3:

Selected IV set for loop 1 at pr96201.c:25, 10 avg niters, 1 IVs:
Candidate 8:
  Var befor: dn_24
  Var after: dn_18
  Incr POS: orig biv
  IV struct:
Type:   int *
Base:   (int *) _3
Step:   4
Biv:N
Overflowness wrto loop niter:   Overflow

loop in f4:

Selected IV set for loop 1 at pr96201.c:34, 10 avg niters, 2 IVs:
Candidate 6:
  Var befor: sn_26
  Var after: sn_20
  Incr POS: orig biv
  IV struct:
Type:   int *
Base:   sn_14
Step:   4
Object: (void *) sn_14
Biv:N
Overflowness wrto loop niter:   Overflow
Candidate 8:
  Var befor: dn_27
  Var after: dn_21
  Incr POS: orig biv
  IV struct:
Type:   int *
Base:   dn_16
Step:   4
Object: (void *) dn_16
Biv:N
Overflowness wrto loop niter:   Overflow

---

then it generate more instructions for f3 which pass_combine failed to combine
them.

---
loop in f3:

Trying 19 -> 22:
   19: r83:DI=r92:DI
   22: [r83:DI]=r89:SI
  REG_DEAD r89:SI
  REG_DEAD r83:DI
Can't combine i2 into i3

Trying 21 -> 22:
   21: r89:SI=[r93:DI]
  REG_DEAD r93:DI
   22: [r83:DI]=r89:SI
  REG_DEAD r89:SI
  REG_DEAD r83:DI
Failed to match this instruction:
(set (mem:SI (reg/v/f:DI 83 [ dn ]) [1 *dn_2+0 S4 A32])
(mem:SI (reg/f:DI 93 [ _20 ]) [1 *_20+0 S4 A32]))

Trying 18, 21 -> 22:
   18: {r93:DI=r92:DI+r102:DI;clobber flags:CC;}
  REG_UNUSED flags:CC
   21: r89:SI=[r93:DI]
  REG_DEAD r93:DI
   22: [r83:DI]=r89:SI
  REG_DEAD r89:SI
  REG_DEAD r83:DI
Can't combine i1 into i3

Trying 21, 19 -> 22:
   21: r89:SI=[r93:DI]
  REG_DEAD r93:DI
   19: r83:DI=r92:DI
   22: [r83:DI]=r89:SI
  REG_DEAD r89:SI
  REG_DEAD r83:DI
Can't combine i1 into i3

(insn 18 16 19 4 (parallel [
(set (reg/f:DI 93 [ _20 ])
(plus:DI (reg/v/f:DI 92 [ dn ])
(reg:DI 102)))
(clobber (reg:CC 17 flags))
]) 210 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 19 18 20 4 (set (reg/v/f:DI 83 [ dn ])
(reg/v/f:DI 92 [ dn ])) 74 {*movdi_internal}
 (nil))
(insn 20 19 21 4 (parallel [
(set (reg/v/f:DI 92 [ dn ])
(plus:DI (reg/v/f:DI 92 [ dn ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "pr96201.c":25:24 210 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 21 20 22 4 (set (reg:SI 89 [ _9 ])
(mem:SI (reg/f:DI 93 [ _20 ]) [1 *_20+0 S4 A32])) "pr96201.c":25:29 75
{*movsi_internal}
 (expr_list:REG_DEAD (reg/f:DI 93 [ _20 ])
(nil)))
(insn 22 21 24 4 (set (mem:SI (reg/v/f:DI 83 [ dn ]) [1 *dn_2+0 S4 A32])
(reg:SI 89 [ _9 ])) "pr96201.c":25:27 75 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 89 [ _9 ])
(expr_list:REG_DEAD (reg/v/f:DI 83 [ dn ])
(nil



loop in f4:

Trying 16, 18, 17 -> 19:
   16: {r89:DI=r89:DI+0x4;clobber flags:CC;}
  REG_UNUSED flags:CC
   18: r88:SI=[r89:DI-0x4]
   17: {r90:DI=r90:DI+0x4;clobber flags:CC;}
  REG_UNUSED flags:CC
   19: [r90:DI-0x4]=r88:SI
  REG_DEAD r88:SI
Successfully matched this instruction:
(parallel [
(set (mem:SI (reg/v/f:DI 90 [ dn ]) [1 MEM[base: dn_21, offset: -4B]+0
S4 A32])
(mem:SI (reg/v/f:DI 89 [ sn ]) [1 MEM[base: sn_20, offset: -4B]+0
S4 A32]))
(set (reg/v/f:DI 90 [ dn ])
(plus:DI (reg/v/f:DI 90 [ dn ])
(const_int 4 [0x4])))
(set (reg/v/f:DI 89 [ sn ])
(plus:DI (reg/v/f:DI 89 [ sn ])
(const_int 4 [0x4])))
])

(insn 16 15 17 3 (parallel [
(set (reg/v/f:DI 89 [ sn ])
(plus:DI (reg/v/f:DI 89 [ sn ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "pr96201.c":34:32 210 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 17 16 18 3 (parallel [
(set (reg/v/f:DI 90 [ dn ])
(plus:DI (reg/v/f:DI 90 [ dn ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "pr96201.c":34:24 210 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 18 17 19 3 (set (reg:SI 88 [ _9 ])
(mem:SI (plus:DI (reg/v/f:DI 89 [ sn ])
(const_int -4 [0xfffc])) [1 MEM[base: sn_20,
offset: -4B]+0 S4 A32])) "pr96201.c":34:29 75 {*movsi_internal}

[Bug tree-optimization/96195] aarch64: ICE during GIMPLE pass:vect

2020-07-14 Thread yangyang305 at huawei dot com

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

--- Comment #2 from yangyang  ---
(In reply to Jakub Jelinek from comment #1)
> Note the testcase is invalid, the loop iterator really shouldn't be changed
> in the simd body (well, can change, but only if it has the same value at the
> end of loop body as it has at the start of it).
The testcase comes from gcc/testsuite/gcc.dg/vect/pr92347.c. 

> What are the different modes?  vector(4) int and vector(4) int really look
> the same to me...
In the testcase, One of vector(4) int corresponds to VNx2SI (aarch64_sve_mode)
and the other corresponds to V4SI.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

2020-07-14 Thread bergner at gcc dot gnu.org

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

--- Comment #3 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> Doing everything but the final conversion down in round-to-odd mode works
> correctly always.  It's magic :-)

Ok, so Paul's sequence is what we want and we don't need anything for the other
cases I mentioned since they're not double casting.  Thanks.

[Bug target/96201] New: x86 movsd/movsq string instructions and alignment inference

2020-07-14 Thread michaeljclark at mac dot com

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

Bug ID: 96201
   Summary: x86 movsd/movsq string instructions and alignment
inference
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michaeljclark at mac dot com
  Target Milestone: ---

Taking the time to record some observations and extract minimal test code for
alignment (inference) and x86 string instruction selection.

GCC9 and GCC10 are not generating x86 string instructions in cases apparently
due to the compiler believing the addresses are not aligned.

GCC10 appears to have an additional issue whereby x86 string instructions are
not selected unless the address is aligned to twice the natural alignment.

Two observations:

* (GCC9/10) integer alignment is not inferred from expressions i.e. x & ~3
* (GCC10) __builtin_assume_aligned appears to require double the alignment

The double alignment issue was observed with both int/movsd and long/movsq
whereby GCC10 will only generate movsd or movsq if the alignment is double the
type's natural alignment. The test case here is for int.


--- BEGIN SAMPLE CODE ---

void f1(long d, long s, unsigned n)
{
int *sn = (int*)( (long)(s) & ~3l );
int *dn = (int*)( (long)(d) & ~3l );
int *de = (int*)( (long)(d + n) & ~3l );

while (dn < de) *dn++ = *sn++;
}

void f2(long d, long s, unsigned n)
{
int *sn = (int*)( (long)(s) & ~7l );
int *dn = (int*)( (long)(d) & ~7l );
int *de = (int*)( (long)(d + n) & ~7l );

while (dn < de) *dn++ = *sn++;
}

void f3(long d, long s, unsigned n)
{
int *sn = __builtin_assume_aligned( (int*)( (long)(s) & ~3l ), 4 );
int *dn = __builtin_assume_aligned( (int*)( (long)(d) & ~3l ), 4 );
int *de = __builtin_assume_aligned( (int*)( (long)(d + n) & ~3l ), 4 );

while (dn < de) *dn++ = *sn++;
}

void f4(long d, long s, unsigned n)
{
int *sn = __builtin_assume_aligned( (int*)((long)(s) & ~3l ), 8 );
int *dn = __builtin_assume_aligned( (int*)((long)(d) & ~3l ), 8 );
int *de = __builtin_assume_aligned( (int*)((long)(d + n) & ~3l ), 8 );

while (dn < de) *dn++ = *sn++;
}

--- END SAMPLE CODE ---


GCC9 generates this for f1, f2 and GCC10 generates this for f1, f2, f3

.Ln:
leaq(%rax,%rsi), %rcx
movq%rax, %rdx
addq$4, %rax
movl(%rcx), %ecx
movl%ecx, (%rdx)
cmpq%rax, %rdi
ja  .Ln

GCC9 generates this for f3, f4 and GCC10 generates this only for f4

.Ln:
movsl
cmpq%rdi, %rdx
ja  .Ln

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

2020-07-14 Thread sujian.liu at huawei dot com

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

--- Comment #8 from liusujian  ---
(In reply to Nathan Sidwell from comment #6)
> Ah, anonymous namespaces have internal linkage (and a program-wide unique
> identifier).  Their contents have the linkage they have.  but because
> they're within the anonumous namespace they cannot be named from elsewhere,
> so they have internal linkage for implementation purposes.
> 
> when we actually gave anonymous namespaces there would be no collisions
> between TUs for '::x'.  Now we give it a specific name and adjust the
> linkages of their contents. 
> 
> The C++ FE should adjust the linkage of '::x' too.

Hello, has there been any progress regarding the repair of this issue now?

[Bug target/87949] PowerPC saves CR registers across calls

2020-07-14 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #14 from Segher Boessenkool  ---
The target hook (macro) works just fine, and it results in code that
saves and restores CR fields significantly less often.

Unfortunately the resulting code is lower performance, too.  Not as
bad as when you completely disable the non-volatile CR fields, but
still pretty bad.

Unassigning myself.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

2020-07-14 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Segher Boessenkool  ---
If you first round the DFP extended to DFP long and then to DFP short, it
can round in the same direction twice, giving the wrong result (say, for
round-to-nearest-even, you can end up with something more than 0.5ulp from
what you started with).

Doing everything but the final conversion down in round-to-odd mode works
correctly always.  It's magic :-)

[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed for 11/10.2.

[Bug c++/96104] [10/11 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:681

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

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

https://gcc.gnu.org/g:315b87f63bcde4c881e9963c39d57258da08ccb5

commit r10-8497-g315b87f63bcde4c881e9963c39d57258da08ccb5
Author: Marek Polacek 
Date:   Mon Jun 22 21:26:49 2020 -0400

c++: Make convert_like complain about bad ck_ref_bind again [PR95789]

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* call.c (convert_like_real_1): Renamed from convert_like_real.
(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* g++.dg/conversion/ref4.C: New test.
* g++.dg/conversion/ref5.C: New test.
* g++.dg/conversion/ref6.C: New test.

(cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)

[Bug c++/96179] [10/11 Regression] g++-10.1 silently doesn't push_back the return of a void function

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

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

https://gcc.gnu.org/g:315b87f63bcde4c881e9963c39d57258da08ccb5

commit r10-8497-g315b87f63bcde4c881e9963c39d57258da08ccb5
Author: Marek Polacek 
Date:   Mon Jun 22 21:26:49 2020 -0400

c++: Make convert_like complain about bad ck_ref_bind again [PR95789]

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* call.c (convert_like_real_1): Renamed from convert_like_real.
(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* g++.dg/conversion/ref4.C: New test.
* g++.dg/conversion/ref5.C: New test.
* g++.dg/conversion/ref6.C: New test.

(cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)

[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:315b87f63bcde4c881e9963c39d57258da08ccb5

commit r10-8497-g315b87f63bcde4c881e9963c39d57258da08ccb5
Author: Marek Polacek 
Date:   Mon Jun 22 21:26:49 2020 -0400

c++: Make convert_like complain about bad ck_ref_bind again [PR95789]

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* call.c (convert_like_real_1): Renamed from convert_like_real.
(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* g++.dg/conversion/ref4.C: New test.
* g++.dg/conversion/ref5.C: New test.
* g++.dg/conversion/ref6.C: New test.

(cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)

[Bug target/94393] Powerpc suboptimal 64-bit constant comparison

2020-07-14 Thread segher at gcc dot gnu.org

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

--- Comment #6 from Segher Boessenkool  ---
It certainly would be nice to improve this :-)  It won't help most code
very much -- how often do two-word values happen at all -- but we have
to revisit how all this is decided anyway (for prefixed instructions),
so now would be a good time :-)

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-07-14 Thread wilson at gcc dot gnu.org

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

--- Comment #3 from Jim Wilson  ---
The location of the canary is not known to the attacker.  You are not supposed
to leak the address of the canary or the value of the canary.  If you leak
either, then an attacker has a chance to restore the canary after clobbering
it.

See the descriptions of the stack_protect_set and stack_protect_test patterns
in gcc/doc/md.texi which make clear that no intermediate values should be
allowed to survive past the end of the pattern.

[Bug tree-optimization/81809] missing -Wuninitialized due to alias analysis limitation

2020-07-14 Thread msebor at gcc dot gnu.org

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0, 8.2.0, 9.2.0

--- Comment #4 from Martin Sebor  ---
Another test case for the same underlying bug.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (const int*, const int*);

void g (void)
{
  int a = 0, b;
  f (, );
}

void h (void)
{
  int a = 0, b;
  f (, 0);
  f (, 0);
}
z.c: In function ‘g’:
z.c:6:3: warning: ‘b’ may be used uninitialized [-Wmaybe-uninitialized]
6 |   f (, );
  |   ^~
z.c:1:6: note: by argument 2 of type ‘const int *’ to ‘f’ declared here
1 | void f (const int*, const int*);
  |  ^
z.c:5:14: note: ‘b’ declared here
5 |   int a = 0, b;
  |  ^

[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Done.

[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:4358099049cbb8180c5354c6754b04ff0b330835

commit r11-2099-g4358099049cbb8180c5354c6754b04ff0b330835
Author: Marek Polacek 
Date:   Tue Jul 14 17:31:08 2020 -0400

c++: Add new test [PR59978]

Fixed in r224162.  That came without a test so adding this one.
Previously, we issued a bogus "too few arguments to function" error.

gcc/testsuite/ChangeLog:

PR c++/59978
* g++.dg/cpp0x/vt-59978.C: New test.

[Bug middle-end/96200] New: Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported

2020-07-14 Thread carlos at redhat dot com

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

Bug ID: 96200
   Summary: Implement __builtin_thread_pointer() and
__builtin_set_thread_pointer() if TLS is supported
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlos at redhat dot com
  Target Milestone: ---

In glibc we implement the equivalent of __builtin_thread_pointer() and
__builtin_set_thread_pointer() to access data that is at a constant offset from
the thread pointer.

For many of the architectures that have the builtins their tls.h implementation
in glibc is greatly simplified because they can use the builtin.

We have some ABIs that are defined as having data of a certain size and
alignment at a fixed offset from the thread pointer e.g. stack_guard,
pointer_guard, TM ABI, __private_ss (split stack) etc.

In relation to restartable sequences in the linux kernel it was discussed that
it might be interesting to have an ABI that also uses TP + offset, where glibc
provides the "offset" via an API, but the user is left to do the "TP + offset"
calculation on their own.

https://lore.kernel.org/linux-api/2452161.11491.1594732791558.javamail.zim...@efficios.com/
"Is there an arch-agnostic way to get the thread pointer from user-space code ?
That would be needed by all rseq critical section implementations."

We should support these two builtins for all targets that support TLS.

[Bug fortran/89574] [8/9/10/11 Regression] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3792

2020-07-14 Thread anlauf at gcc dot gnu.org

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-July/054744.html

[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

--- Comment #2 from Marek Polacek  ---
We're reaching tsubst_copy/CONST_DECL:

  /* We didn't find the name.  That should never happen; if
 name-lookup found it during preliminary parsing, we
 should find it again here during instantiation.  */
gcc_unreachable ();

[Bug fortran/89574] [8/9/10/11 Regression] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3792

2020-07-14 Thread anlauf at gcc dot gnu.org

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Line 2095 should never return a match for a symbol from a different module.

I have a patch that regtests cleanly.

[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

Summary|internal compiler error: in |[10/11 Regression] internal
   |tsubst_copy with CTAD for   |compiler error: in
   |alias templates |tsubst_copy with CTAD for
   ||alias templates
   Target Milestone|--- |10.2

--- Comment #1 from Marek Polacek  ---
Started with r278786.

[Bug target/95443] cmpstrnqi patterns update string length

2020-07-14 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #5 from H.J. Lu  ---
Fixed.

[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops

2020-07-14 Thread hjl.tools at gmail dot com

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

Bug 95443 Summary: cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/96199] New: internal compiler error: in tsubst_copy with CTAD for alias templates

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Bug ID: 96199
   Summary: internal compiler error: in tsubst_copy with CTAD for
alias templates
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

template class A;
template struct W { };
template class B {
  enum { X };
  B(A) { }
  template  using U = B;
  W u;
};

$ ./cc1plus -quiet q.C
q.C:5:3: internal compiler error: in tsubst_copy, at cp/pt.c:16379
5 |   B(A) { }
  |   ^
0xbf58f3 tsubst_copy
/home/mpolacek/src/gcc/gcc/cp/pt.c:16379
0xc0d363 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:20496
0xc04ffc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:18783
0xbdfd4f tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:12116
0xbe3b45 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:13169
0xbe48d5 tsubst_aggr_type
/home/mpolacek/src/gcc/gcc/cp/pt.c:13372
0xbf1239 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:15267
0xbef7bc tsubst_arg_types
/home/mpolacek/src/gcc/gcc/cp/pt.c:14802
0xbefdce tsubst_function_type
/home/mpolacek/src/gcc/gcc/cp/pt.c:14943
0xbf2f58 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:15720
0xbe7642 tsubst_function_decl
/home/mpolacek/src/gcc/gcc/cp/pt.c:13757
0xbec51f tsubst_decl
/home/mpolacek/src/gcc/gcc/cp/pt.c:14199
0xc2fd83 alias_ctad_tweaks
/home/mpolacek/src/gcc/gcc/cp/pt.c:28562
0xc30867 deduction_guides_for
/home/mpolacek/src/gcc/gcc/cp/pt.c:28703
0xc31104 do_class_deduction
/home/mpolacek/src/gcc/gcc/cp/pt.c:28808
0xc31d4c do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/pt.c:28937
0xce14ca build_functional_cast_1
/home/mpolacek/src/gcc/gcc/cp/typeck2.c:2313
0xce1919 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/typeck2.c:2413
0xb744e9 cp_parser_functional_cast
/home/mpolacek/src/gcc/gcc/cp/parser.c:29671
0xb46a8e cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7212

[Bug target/95443] cmpstrnqi patterns update string length

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-2098-gb2984e5ada65f417e8704d2e1e81ccd0272b5eb3
Author: H.J. Lu 
Date:   Tue Jul 14 14:01:51 2020 -0700

x86: Replace __glibc_unlikely with __builtin_expect

Replace glibc specific __glibc_unlikely with __builtin_expect.

PR target/95443
* gcc.target/i386/pr95443-1.c (simple_strstr): Replace
__glibc_unlikely with __builtin_expect.

[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda

2020-07-14 Thread ppalka at gcc dot gnu.org

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-14
 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Confirmed.  Fails on trunk, too.

[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock

2020-07-14 Thread federico.kircheis at gmail dot com

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

--- Comment #3 from Federico Kircheis  ---
Thank you for the analysis, explanation and references, I did not think about
testing std::lock directly.


I'm still unsure if that means that it is a bug in valgrind, unfortunately I do
not know other 3rd party tool for doing such verifications.

I also noticed that I made an error in my initial report, the second snippet
should have been

-
int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
std::lock_guard lg1{m1};std::lock_guard lg2{m2};
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
std::lock_guard lg2{m2};std::lock_guard lg1{m1};
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}
-

otherwise it does not generate any warning in valgrind as the order is the
same.

> Also, I'm not even sure what the helgrind error really means.

>From helgrind manual: https://www.valgrind.org/docs/manual/hg-manual.html


Helgrind monitors the order in which threads acquire locks. This allows it to
detect potential deadlocks which could arise from the formation of cycles of
locks. Detecting such inconsistencies is useful because, whilst actual
deadlocks are fairly obvious, potential deadlocks may never be discovered
during testing and could later lead to hard-to-diagnose in-service failures.




> Just because they were locked in one order at one time doesn't establish an 
> invariant that they must always be locked in that order elsewhere in the 
> program.

I'm not an expert, I've just made the report because I've tried out valgrind on
a bigger program and then noticed it also complained about this example.

In order to avoid deadlocks, shouldn't mutexes get always locked in the same
order?

Otherwise thread1 locks the first mutex, then thread2 locks the second, and now
both thread are waiting for locking the next.

My guess, without having looked at the implementation of std::lock, is that the
algorithm uses try_lock to eventually lock/unlock the mutexes and see if it
manages to lock both, in order to avoid the deadlock.
And I suppose that somehow this algorithm also manages to avoid livelocks.


But even if std::lock would be correct (and it is a false positive of
valgrind), wouldn't sorting by address be an optimization?

As far as I understand, if the mutexes are always locked in the same order, one
does not need to try_lock. If it does, it would at least avoid the dance of
both threads trying to lock and unlock, as the first one that arrives manages
to lock both.
And if someone else locked them somewhere else in a different order, then the
current algorithm still applies.

I'm therefore not saying the current algorithm should be dismissed, just asking
if ordering before applying the algorithm could have any benefit.
Apart from the fact that helgrind would not complain anymore, which IMHO would
already be a big win.

Maybe there are known drawbacks to sorting by address, but as mutexes cannot be
moved, the output of sorting should always be the same, and I suppose that
sorting should not cost much, especially compared to locking.

[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-2097-g8e64d182850560dbedfabb88aac90d4fc6155067
Author: Marek Polacek 
Date:   Mon Jun 22 21:26:49 2020 -0400

c++: Make convert_like complain about bad ck_ref_bind again [PR95789]

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* call.c (convert_like_real_1): Renamed from convert_like_real.
(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* g++.dg/conversion/ref4.C: New test.
* g++.dg/conversion/ref5.C: New test.
* g++.dg/conversion/ref6.C: New test.

[Bug c++/96179] [10/11 Regression] g++-10.1 silently doesn't push_back the return of a void function

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-2097-g8e64d182850560dbedfabb88aac90d4fc6155067
Author: Marek Polacek 
Date:   Mon Jun 22 21:26:49 2020 -0400

c++: Make convert_like complain about bad ck_ref_bind again [PR95789]

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* call.c (convert_like_real_1): Renamed from convert_like_real.
(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* g++.dg/conversion/ref4.C: New test.
* g++.dg/conversion/ref5.C: New test.
* g++.dg/conversion/ref6.C: New test.

[Bug c++/96104] [10/11 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:681

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-2097-g8e64d182850560dbedfabb88aac90d4fc6155067
Author: Marek Polacek 
Date:   Mon Jun 22 21:26:49 2020 -0400

c++: Make convert_like complain about bad ck_ref_bind again [PR95789]

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* call.c (convert_like_real_1): Renamed from convert_like_real.
(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

PR c++/95789
PR c++/96104
PR c++/96179
* g++.dg/conversion/ref4.C: New test.
* g++.dg/conversion/ref5.C: New test.
* g++.dg/conversion/ref6.C: New test.

[Bug c++/88475] -E -fdirectives-only clashes with raw strings

2020-07-14 Thread ryan.egesdahl at mongodb dot com

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

Ryan Egesdahl  changed:

   What|Removed |Added

 CC||ryan.egesdahl at mongodb dot 
com

--- Comment #6 from Ryan Egesdahl  ---
The actual bug here appears to be the fact that "gcc -E" (which I believe
invokes "cpp"?) has different behavior than the integrated preprocessor. If you
compile the code in the initial report with just "gcc", it works irrespective
of passing "-fdirectives-only" to the compiler.

A different way of demonstrating the problem looks like this:

test.cpp:
#define expand(x) x
#define test(...) \
expand(_test_2(__VA_ARGS__))
#define _test_2(Expression) \
doSomething((Expression))
template 
inline bool doSomething(
const T& testOK) {
if (!testOK) {
return false;
}
return true;
}
int main()
{
bool condition = true;
return test(!condition || condition == condition);
}

The above compiles correctly with this:
$ g++ -Wall test.cpp -o test

However, this fails:
$ g++ -Wall -E test.cpp -o test.ii
$ g++ -fpreprocessed -fdirectives-only -Wall -c test.ii -o test
test.cpp: In function ‘int main()’:
test.cpp:21:49: warning: self-comparison always evaluates to true
[-Wtautological-compare]
 return test(!condition || condition == condition);

As does this:
$ g++ -fdirectives-only -Wall -c test.ii -o test
$ g++ -fpreprocessed -Wall -c test.ii -o test
test.cpp: In function ‘int main()’:
test.cpp:21:41: warning: self-comparison always evaluates to true
[-Wtautological-compare]
 return test(!condition || condition == condition);
   ~~^~~~
test.cpp:21:12: error: ‘test’ was not declared in this scope
 return test(!condition || condition == condition);
^~~~

I understand (from testing) that not passing -fdirectives-only is the actual
cause of the behavior in my test case; however, it is not immediately obvious
why passing -fdirectives-only should be necessary with both the compiler and
preprocessor, nor does the documentation state so. The point is that the
integrated compiler and "gcc -E" (or cpp) behave differently.

Most build wrappers like ccache and icecc (when ICECC_REMOTE_CPP is enabled)
work by taking a gcc command and splitting it into separate preprocessing and
compilation steps, which involves adding -E to the flags for preprocessing and
-c for compiling, then passing the preprocessing results to the compiler.
Because "gcc -E" and the integrated compiler behave differently, some builds
fail with separate preprocessing and compilation steps that otherwise would
have succeeded with a single step. The lack of documentation around
-fdirectives-only and that it must be passed to the compiler (and that it
implies -fpreprocessed to the compiler, for that matter) is making the
confusion worse.

To resolve this report, GCC should not behave differently depending on how you
preprocess source. My personal thought is that "gcc -E" should invoke the
internal preprocessor and just stop before compiling. Also, the documentation
for -fdirectives-only needs to be improved (and maybe added it to the compiler
documentation?) to make clear that the option needs to be passed to the
compiler as well, and that passing it to the compiler with no preprocessed
source is effectively a no-op.

[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed in r11-532-g4b38d56dbac6742b038551a36ec80200313123a1.

[Bug c++/94404] [meta-bug] C++ core issues

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Bug 94415 Summary: Implement DR 2237: Can a template-id name a constructor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415

   What|Removed |Added

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

[Bug target/95443] cmpstrnqi patterns update string length

2020-07-14 Thread ro at gcc dot gnu.org

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

Rainer Orth  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-14
 Status|RESOLVED|REOPENED
 Ever confirmed|0   |1
 CC||ro at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #3 from Rainer Orth  ---
One of the new tests FAILs on Solaris/x86 (and most likely all non-glibc
targets):

+FAIL: gcc.target/i386/pr95443-1.c (test for excess errors)
+UNRESOLVED: gcc.target/i386/pr95443-1.c compilation failed to produce
executable

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr95443-1.c:52:11:
warning: implicit declaration of function '__glibc_unlikely'
[-Wimplicit-function-declaration]
Undefined   first referenced
 symbol in file
__glibc_unlikely/var/tmp//ccMfX1cc.o
ld: fatal: symbol referencing errors

[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops

2020-07-14 Thread ro at gcc dot gnu.org

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

Bug 95443 Summary: cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

2020-07-14 Thread jakub at gcc dot gnu.org

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

--- Comment #2 from Jakub Jelinek  ---
I think
--- gcc/omp-general.c.jj2020-07-14 12:20:01.520110629 +0200
+++ gcc/omp-general.c   2020-07-14 20:54:48.104237522 +0200
@@ -726,7 +726,7 @@ omp_extract_for_data (gomp_for *for_stmt
  if (loop->m1 || loop->m2)
{
  gcc_assert (single_nonrect != -1);
- if (single_nonrect_cond_code == LT_EXPR)
+ if (1 || single_nonrect_cond_code == LT_EXPR)
{
  n1 = n1first;
  n2 = n2first;
@@ -764,7 +764,7 @@ omp_extract_for_data (gomp_for *for_stmt
  m1 = fold_convert (itype, m1);
  m2 = fold_convert (itype, m2);
  tree t2;
- if (single_nonrect_cond_code == LT_EXPR)
+ if (1 || single_nonrect_cond_code == LT_EXPR)
t2 = fold_build2 (MINUS_EXPR, itype, m2, m1);
  else
t2 = fold_build2 (MINUS_EXPR, itype, m1, m2);
should fix that, but need to go back to drawing board and see if that is how we
want to handle those cases.  That said at least for all the testcases in the
testsuite it currently computes the right number of iterations at least.

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-07-14 Thread wilco at gcc dot gnu.org

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
(In reply to Jim Wilson from comment #0)
> Given a simple testcase
> extern int sub (int);
> 
> int
> main (void)
> {
>   sub (10);
>   return 0;
> }
> commpiling with -O -S -fstack-protector-all -mstack-protector-guard=global
> in the epilogue for the canary check I see
>   ldr x1, [sp, 40]
>   ldr x0, [x19, #:lo12:__stack_chk_guard]
>   eor x0, x1, x0
>   cbnzx0, .L4
> Both x0 and x1 have the stack protector canary loaded into them, and the eor
> clobbers x0, but x1 is left alone.  This means the value of the canary is
> leaking from the epilogue.  The canary value is never supposed to survive in
> a register outside the stack protector patterns.
> 
> A powerpc64-linux toolchain build with the same testcase and options
> generates
>   lwz 9,28(1)
>   lwz 10,0(31)
>   xor. 9,9,10
>   li 10,0
>   bne- 0,.L4
> and note that it clears the second register after the xor to prevent the
> canary leak.  The aarch64 stack_protect_test pattern should do the same
> thing.

The canary value is not a secret. What would the purpose of clearing the
register be given the stack slot containing the canary is not cleared as well?
And register could potentially contain the address of the canary or that of a
global nearby, making reading the canary value really easy.

[Bug middle-end/95114] [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

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

https://gcc.gnu.org/g:74d4c8bda2998e32e6c3b397cc61eadb4b208f0b

commit r10-8495-g74d4c8bda2998e32e6c3b397cc61eadb4b208f0b
Author: Richard Sandiford 
Date:   Tue Jul 14 19:24:57 2020 +0100

ipa-devirt: Fix crash in obj_type_ref_class [PR95114]

The testcase has failed since r9-5035, because obj_type_ref_class
tries to look up an ODR type when no ODR type information is
available.  (The information was available earlier in the
compilation, but was freed during pass_ipa_free_lang_data.)
We then crash dereferencing the null get_odr_type result.

The test passes with -O2.  However, it fails again if -fdump-tree-all
is used, since obj_type_ref_class is called indirectly from the
dump routines.

Other code creates ODR type entries on the fly by passing âtrueâ
as the insert parameter.  But obj_type_ref_class can't do that
unconditionally, since it should have no side-effects when used
from the dumping code.

Following a suggestion from Honza, this patch adds parameters
to say whether the routines are being called from dump routines
and uses those to derive the insert parameter.

gcc/
PR middle-end/95114
* tree.h (virtual_method_call_p): Add a default-false parameter
that indicates whether the function is being called from dump
routines.
(obj_type_ref_class): Likewise.
* tree.c (virtual_method_call_p): Likewise.
* ipa-devirt.c (obj_type_ref_class): Likewise.  Lazily add ODR
type information for the type when the parameter is false.
* tree-pretty-print.c (dump_generic_node): Update calls to
virtual_method_call_p and obj_type_ref_class accordingly.

gcc/testsuite/
PR middle-end/95114
* g++.target/aarch64/pr95114.C: New test.

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

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

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

commit r10-8494-gb9475357b5b180c63b3389742452a48026f073a6
Author: Richard Sandiford 
Date:   Tue Jul 14 19:24:56 2020 +0100

value-range: Fix handling of POLY_INT_CST anti-ranges [PR96146]

The range infrastructure has code to decompose POLY_INT_CST ranges
to worst-case integer bounds.  However, it had the fundamental flaw
(obvious in hindsight) that it applied to anti-ranges too, meaning
that a range 2+2X would end up with a range of ~[2, +INF], i.e.
[-INF, 1].  This patch decays to varying in that case instead.

I'm still a bit uneasy about this.  ISTM that in terms of
generality:

  SSA_NAME => POLY_INT_CST => INTEGER_CST
   => ADDR_EXPR

I.e. an SSA_NAME could store a POLY_INT_CST and a POLY_INT_CST
could store an INTEGER_CST (before canonicalisation).  POLY_INT_CST
is also âas constant asâ ADDR_EXPR (well, OK, only some ADDR_EXPRs
are run-time rather than link-time constants, whereas all POLY_INT_CSTs
are, but still).  So it seems like we should at least be able to treat
POLY_INT_CST as symbolic.  On the other hand, I don't have any examples
in which that would be useful.

gcc/
PR tree-optimization/96146
* value-range.cc (value_range::set): Only decompose POLY_INT_CST
bounds to integers for VR_RANGE.  Decay to VR_VARYING for
anti-ranges
involving POLY_INT_CSTs.

gcc/testsuite/
PR tree-optimization/96146
* gcc.target/aarch64/sve/acle/general/pr96146.c: New test.

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

2020-07-14 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #24 from Manuel López-Ibáñez  ---
Great!

(If you login into bugzilla with your @gcc.gnu.org account, you should be able
to admin PRs)

[Bug c++/96193] No ADL for hidden friend in call with explicit template arguments

2020-07-14 Thread johelegp at gmail dot com

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

--- Comment #3 from Johel Ernesto Guerrero Peña  ---
Yes! I left it out expecting it to be backported as an extension like Clang
does.

[Bug demangler/96143] C++ demangler should not add a lambda as a substitution

2020-07-14 Thread ian at airs dot com

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Fixed on trunk.

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug demangler/96143] C++ demangler should not add a lambda as a substitution

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-2093-gbae45b8be57b2a2c22bf45f3eeb1118c328ad028
Author: Ian Lance Taylor 
Date:   Fri Jul 10 09:34:28 2020 -0700

demangler: don't treat lambda as a substitution candidate

libiberty/ChangeLog:

PR demangler/96143
* cp-demangle.c (d_lambda): Don't add substitution candidate.
* testsuite/demangle-expected: Update a few existing test cases
accordingly, and add a new test case.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

2020-07-14 Thread willschm at gcc dot gnu.org

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

Will Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Will Schmidt  ---
Fixed, Closing.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

2020-07-14 Thread willschm at gcc dot gnu.org

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

Will Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Will Schmidt  ---
Should now be fixed in all of the right places.  
closing. 
Thanks

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

2020-07-14 Thread willschm at gcc dot gnu.org

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

--- Comment #16 from Will Schmidt  ---
(In reply to Mikael Pettersson from comment #15)
> (In reply to Will Schmidt from comment #14)
> > (In reply to Will Schmidt from comment #13)
> > > Created attachment 48871 [details]
> > > proposed patch
> > > 
> > > Attached patch appears sufficient to resolve the issue on the 970 based 
> > > box
> > > I have access to.
> > 
> > Mikael, would be appreciated if you could give that a run-through to confirm
> > it fixes the problem on your system.
> > thanks,
> 
> I can confirm that this patch restores gcc-8 bootstrap with the older
> binutils.

Thanks :-) 
Patch posted to list for review.

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

2020-07-14 Thread seurer at linux dot vnet.ibm.com

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

Bill Seurer  changed:

   What|Removed |Added

  Build||powerpc64*-linux-gnu
   Host||powerpc64*-linux-gnu
 Target||powerpc64*-linux-gnu

--- Comment #1 from Bill Seurer  ---
Note: failed on powerpc64 both BE and LE

[Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077

2020-07-14 Thread seurer at linux dot vnet.ibm.com

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

Bug ID: 96198
   Summary: new test case libgomp.c/loop-21.c in r11-2077
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

g:f418bd4b92a03ee0ec0fe4cfcd896e86e11ac2cf, r11-2077 

PASS: libgomp.c/loop-21.c (test for excess errors)
. . .
Execution timeout is: 300
spawn [open ...]
FAIL: libgomp.c/loop-21.c execution test

Running it in gdb shows:

(gdb) where
#0  0x3fffb7c0258c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x3fffb7c04778 in __GI_abort () at abort.c:90
#2  0x10003548 in .main._omp_fn.4 ()
#3  0x3fffb7e36588 in .gomp_thread_start () from
/home/seurer/gcc/install/gcc-7.4.0/lib64/libgomp.so.1
#4  0x3fffb7dccafc in start_thread (arg=0x3fffad21f130) at
pthread_create.c:309
#5  0x3fffb7ce6f4c in .__clone () at
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:104

[Bug other/86904] Column numbers ignore tab characters

2020-07-14 Thread dmalcolm at gcc dot gnu.org

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Thanks; marking as resolved.

[Bug other/86904] Column numbers ignore tab characters

2020-07-14 Thread lhyatt at gmail dot com

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #5 from Lewis Hyatt  ---
Fixed for GCC 11, may I ask someone please to close the PR?

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

2020-07-14 Thread mikpelinux at gmail dot com

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

--- Comment #15 from Mikael Pettersson  ---
(In reply to Will Schmidt from comment #14)
> (In reply to Will Schmidt from comment #13)
> > Created attachment 48871 [details]
> > proposed patch
> > 
> > Attached patch appears sufficient to resolve the issue on the 970 based box
> > I have access to.
> 
> Mikael, would be appreciated if you could give that a run-through to confirm
> it fixes the problem on your system.
> thanks,

I can confirm that this patch restores gcc-8 bootstrap with the older binutils.

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

2020-07-14 Thread lhyatt at gmail dot com

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

--- Comment #23 from Lewis Hyatt  ---
Fixed for GCC 11, may I ask someone please to close the PR?

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread wjwray at gmail dot com

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

--- Comment #9 from Will Wray  ---
An earlier draft had __builtin_tuple_size as the magic behind the P2141
proposed std::tuple_size automagic generalization to Case 3 class types.

There was opposition to that name because it specifically doesn't apply
to tuples so I left the naming open, suggesting __builtin_binding_count
(and, so, requiring consensus on naming for portability...)

[Bug other/86904] Column numbers ignore tab characters

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:004bb936d6d5f177af26ad4905595e843d5665a5

commit r11-2092-g004bb936d6d5f177af26ad4905595e843d5665a5
Author: Lewis Hyatt 
Date:   Tue Jul 14 12:05:56 2020 -0400

diagnostics: Support conversion of tabs to spaces [PR49973] [PR86904]

Supports conversion of tabs to spaces when outputting diagnostics. Also
adds -fdiagnostics-column-unit and -fdiagnostics-column-origin options to
control how the column number is output, thereby resolving the two PRs.

gcc/c-family/ChangeLog:

PR other/86904
* c-indentation.c (should_warn_for_misleading_indentation): Get
global tabstop from the new source.
* c-opts.c (c_common_handle_option): Remove handling of -ftabstop,
which
is now a common option.
* c.opt: Likewise.

gcc/ChangeLog:

PR preprocessor/49973
PR other/86904
* common.opt: Handle -ftabstop here instead of in c-family
options.  Add -fdiagnostics-column-unit= and
-fdiagnostics-column-origin= options.
* opts.c (common_handle_option): Handle the new options.
* diagnostic-format-json.cc (json_from_expanded_location): Add
diagnostic_context argument.  Use it to convert column numbers as
per
the new options.
(json_from_location_range): Likewise.
(json_from_fixit_hint): Likewise.
(json_end_diagnostic): Pass the new context argument to helper
functions above.  Add "column-origin" field to the output.
(test_unknown_location): Add the new context argument to calls to
helper functions.
(test_bad_endpoints): Likewise.
* diagnostic-show-locus.c
(exploc_with_display_col::exploc_with_display_col): Support
tabstop parameter.
(layout_point::layout_point): Make use of class
exploc_with_display_col.
(layout_range::layout_range): Likewise.
(struct line_bounds): Clarify that the units are now always
display columns.  Rename members accordingly.  Add constructor.
(layout::print_source_line): Add support for tab expansion.
(make_range): Adapt to class layout_range changes.
(layout::maybe_add_location_range): Likewise.
(layout::layout): Adapt to class exploc_with_display_col changes.
(layout::calculate_x_offset_display): Support tabstop parameter.
(layout::print_annotation_line): Adapt to struct line_bounds
changes.
(layout::print_line): Likewise.
(line_label::line_label): Add diagnostic_context argument.
(get_affected_range): Likewise.
(get_printed_columns): Likewise.
(layout::print_any_labels): Adapt to struct line_label changes.
(class correction): Add m_tabstop member.
(correction::correction): Add tabstop argument.
(correction::compute_display_cols): Use m_tabstop.
(class line_corrections): Add m_context member.
(line_corrections::line_corrections): Add diagnostic_context
argument.
(line_corrections::add_hint): Use m_context to handle tabstops.
(layout::print_trailing_fixits): Adapt to class line_corrections
changes.
(test_layout_x_offset_display_utf8): Support tabstop parameter.
(test_layout_x_offset_display_tab): New selftest.
(test_one_liner_colorized_utf8): Likewise.
(test_tab_expansion): Likewise.
(test_diagnostic_show_locus_one_liner_utf8): Call the new tests.
(diagnostic_show_locus_c_tests): Likewise.
(test_overlapped_fixit_printing): Adapt to helper class and
function changes.
(test_overlapped_fixit_printing_utf8): Likewise.
(test_overlapped_fixit_printing_2): Likewise.
* diagnostic.h (enum diagnostics_column_unit): New enum.
(struct diagnostic_context): Add members for the new options.
(diagnostic_converted_column): Declare.
(json_from_expanded_location): Add new context argument.
* diagnostic.c (diagnostic_initialize): Initialize new members.
(diagnostic_converted_column): New function.
(maybe_line_and_column): Be willing to output a column of 0.
(diagnostic_get_location_text): Convert column number as per the
new
options.
(diagnostic_report_current_module): Likewise.
(assert_location_text): Add origin and column_unit arguments for
testing the new functionality.
(test_diagnostic_get_location_text): Test the new functionality.
* doc/invoke.texi: Document the new options and

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

https://gcc.gnu.org/g:004bb936d6d5f177af26ad4905595e843d5665a5

commit r11-2092-g004bb936d6d5f177af26ad4905595e843d5665a5
Author: Lewis Hyatt 
Date:   Tue Jul 14 12:05:56 2020 -0400

diagnostics: Support conversion of tabs to spaces [PR49973] [PR86904]

Supports conversion of tabs to spaces when outputting diagnostics. Also
adds -fdiagnostics-column-unit and -fdiagnostics-column-origin options to
control how the column number is output, thereby resolving the two PRs.

gcc/c-family/ChangeLog:

PR other/86904
* c-indentation.c (should_warn_for_misleading_indentation): Get
global tabstop from the new source.
* c-opts.c (c_common_handle_option): Remove handling of -ftabstop,
which
is now a common option.
* c.opt: Likewise.

gcc/ChangeLog:

PR preprocessor/49973
PR other/86904
* common.opt: Handle -ftabstop here instead of in c-family
options.  Add -fdiagnostics-column-unit= and
-fdiagnostics-column-origin= options.
* opts.c (common_handle_option): Handle the new options.
* diagnostic-format-json.cc (json_from_expanded_location): Add
diagnostic_context argument.  Use it to convert column numbers as
per
the new options.
(json_from_location_range): Likewise.
(json_from_fixit_hint): Likewise.
(json_end_diagnostic): Pass the new context argument to helper
functions above.  Add "column-origin" field to the output.
(test_unknown_location): Add the new context argument to calls to
helper functions.
(test_bad_endpoints): Likewise.
* diagnostic-show-locus.c
(exploc_with_display_col::exploc_with_display_col): Support
tabstop parameter.
(layout_point::layout_point): Make use of class
exploc_with_display_col.
(layout_range::layout_range): Likewise.
(struct line_bounds): Clarify that the units are now always
display columns.  Rename members accordingly.  Add constructor.
(layout::print_source_line): Add support for tab expansion.
(make_range): Adapt to class layout_range changes.
(layout::maybe_add_location_range): Likewise.
(layout::layout): Adapt to class exploc_with_display_col changes.
(layout::calculate_x_offset_display): Support tabstop parameter.
(layout::print_annotation_line): Adapt to struct line_bounds
changes.
(layout::print_line): Likewise.
(line_label::line_label): Add diagnostic_context argument.
(get_affected_range): Likewise.
(get_printed_columns): Likewise.
(layout::print_any_labels): Adapt to struct line_label changes.
(class correction): Add m_tabstop member.
(correction::correction): Add tabstop argument.
(correction::compute_display_cols): Use m_tabstop.
(class line_corrections): Add m_context member.
(line_corrections::line_corrections): Add diagnostic_context
argument.
(line_corrections::add_hint): Use m_context to handle tabstops.
(layout::print_trailing_fixits): Adapt to class line_corrections
changes.
(test_layout_x_offset_display_utf8): Support tabstop parameter.
(test_layout_x_offset_display_tab): New selftest.
(test_one_liner_colorized_utf8): Likewise.
(test_tab_expansion): Likewise.
(test_diagnostic_show_locus_one_liner_utf8): Call the new tests.
(diagnostic_show_locus_c_tests): Likewise.
(test_overlapped_fixit_printing): Adapt to helper class and
function changes.
(test_overlapped_fixit_printing_utf8): Likewise.
(test_overlapped_fixit_printing_2): Likewise.
* diagnostic.h (enum diagnostics_column_unit): New enum.
(struct diagnostic_context): Add members for the new options.
(diagnostic_converted_column): Declare.
(json_from_expanded_location): Add new context argument.
* diagnostic.c (diagnostic_initialize): Initialize new members.
(diagnostic_converted_column): New function.
(maybe_line_and_column): Be willing to output a column of 0.
(diagnostic_get_location_text): Convert column number as per the
new
options.
(diagnostic_report_current_module): Likewise.
(assert_location_text): Add origin and column_unit arguments for
testing the new functionality.
(test_diagnostic_get_location_text): Test the new functionality.
* doc/invoke.texi: Document the new options and

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread redi at gcc dot gnu.org

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

--- Comment #8 from Jonathan Wakely  ---
But __builtin_bit_cast is the compiler magic to support std::bit_cast, it's not
just a non-standard extension. PR 93121 is a request for std::bit_cast in GCC.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread wjwray at gmail dot com

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

--- Comment #7 from Will Wray  ---
Oops, __builtin_bit_cast available in MSVC and Clang (when in GCC?)

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread wjwray at gmail dot com

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

--- Comment #6 from Will Wray  ---
Thanks for the comment on approach Jonathan:

I'd noticed some collaboration and agreement around previous builtins
such as __builtin_bit_cast which is now available in both GCC & Clang
(though with some small inevitable divergence of behaviour).

Clearly Richard's suggestion to prioritize P1061, with such illustrious
co-authorship, is the best solution. I can offer to help on the gcc side.
This is the std way to go.

This request was borne of some frustration; I miss this facility in C++20.
By a hack, Clang happens to support SFINAE on structured binding since v5
- lack of any way to do it in GCC prompted this request.
My thinking was that a builtin can see quicker implementation and adoption
than std features. This builtin _is_ in support of a std proposal.

[Bug c++/96197] New: Excess memory consumption, positive correlation with the size of a constexpr array

2020-07-14 Thread hyena at hyena dot net.ee

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

Bug ID: 96197
   Summary: Excess memory consumption, positive correlation with
the size of a constexpr array
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hyena at hyena dot net.ee
  Target Milestone: ---

Created attachment 48876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48876=edit
Contains the problematic constant expression array.

The memory consumption of the compiler seems to have an exponential dependency
on one of the constant expression arrays that I have set up in the header. I
have attached the header file. With an array of just 500 elements the memory
consumption of GCC goes above 5 GiB.

I have tested even with the latest 10.x version and the problem is still there.
Tested also with -O1, -O2 and -O3 and none of these made any difference.

If anyone is aware of any workarounds then I would much appreciate learning
more about them because I need to keep developing the project I have at hand
but because of this bug it has become impossible to continue without changing
the architecture a lot.

This only becomes noticeable at larger array sizes (several hundred elements in
my case).

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #3)
> Not as a DR, absolutely not. There is no defect.
> 
> It could be supported in non-strict modes as an extension, if the syntax
> doesn't conflict with anything a valid program would use.

Yeah, usually it is something with pedwarn, i.e. accepted in
-std=c++2b/-std=gnu++2b mocdx, a warning in -std=gnu++20/-std=gnu++17 etc. and
an error with -std=c++20/-std=c++17.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread redi at gcc dot gnu.org

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Will Wray from comment #0)
> (Submitting simultaneous requests for each of GCC, Clang and MSVC.
>  Coordination between vendors will be beneficial for portability.)

This seems like the wrong approach. If you want something portable that works
in all implementations, propose it for the standard.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread redi at gcc dot gnu.org

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Will Wray from comment #2)
> Would an early-delivered future feature require an opt-in switch?

The relevant -std switch would be the opt-in.

> Can P1061 be default enabled under earlier std flags by DR or otherwise?

Not as a DR, absolutely not. There is no defect.

It could be supported in non-strict modes as an extension, if the syntax
doesn't conflict with anything a valid program would use.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

2020-07-14 Thread skpgkp2 at gmail dot com

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

--- Comment #3 from Sunil Pandey  ---
(In reply to Richard Biener from comment #1)
> Hmm, but there's no local variable to copy here?  Are you refering to the
> result decl from b we materialize in c?  This would be the same case
> as for example switch conversion adding a 'long long' variable, so the
> issue would be more wide-spread as you think - for example IPA SRA might
> choose to pass an aggregate by its components thus with an aggregate with
> two long long members you should see similar issues.

Yes, long long result decl. It's incoming alignment is 4(lowered by target
hook). But copy get default alignment as 8.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

2020-07-14 Thread wjwray at gmail dot com

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

--- Comment #2 from Will Wray  ---
On the Clang ticket, linked above, Richard Smith comments:

  Instead of the proposed direction, I'd suggest we (and other implementers)
  prioritize implementation of https://wg21.link/p1061r1
  (which is on its way to standardization: 
   https://github.com/cplusplus/papers/issues/294).

My follow-on questions:

Would an early-delivered future feature require an opt-in switch?
Can P1061 be default enabled under earlier std flags by DR or otherwise?

[Bug c++/96196] infinite loop removed by optimizer

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jakub Jelinek  ---
This is not a valid C++ program, see https://eel.is/c++draft/intro.progress#1

[Bug c++/96196] infinite loop removed by optimizer

2020-07-14 Thread ktkachov at gcc dot gnu.org

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
This is -ffinite-loops which is on by default and was added in GCC 10.1
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#Optimize-Options

[Bug c++/96196] New: infinite loop removed by optimizer

2020-07-14 Thread ingo at hannover dot ccc.de

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

Bug ID: 96196
   Summary: infinite loop removed by optimizer
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ingo at hannover dot ccc.de
  Target Milestone: ---

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

If compiled with any of -Ofast -Os -O3 or -O2, g++ will optimize the while loop
away and exit immediately, when it should run forever.

#include 
#include 

int main() {
const std::vector a{1};
std::vector b;

std::cout << "before loop: " << b.size() << " < " << a.size() << "\n";

while(b.size() < a.size()) {
// uncommenting this fixes the loop with -O2
//std::cout << ".";
}
std::cout << "after loop: " << b.size() << " < " << a.size() << "\n";
}

This bug occurs at least with g++ from the following debian packages:
* g++-10 (version 1:10.1.0-4)
* g++-10 (version 1:10.1.0-5)
* gcc-snapshot (version 1:20200616-1)
gcc version 9 seems fine, also clang-9 and clang-10.

Output from g++-10 version 1:10.1.0-5:

$ g++-10 -v -save-temps -O2 infloop.cc -o infloop
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.1.0-5'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-pmMab1/gcc-10-10.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-pmMab1/gcc-10-10.1.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.1 20200713 (Debian 10.1.0-5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' 'infloop' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE infloop.cc -mtune=generic -march=x86-64 -O2
-fpch-preprocess -fasynchronous-unwind-tables -o infloop.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/10"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/10
 /usr/include/x86_64-linux-gnu/c++/10
 /usr/include/c++/10/backward
 /usr/lib/gcc/x86_64-linux-gnu/10/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' 'infloop' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -fpreprocessed infloop.ii -quiet
-dumpbase infloop.cc -mtune=generic -march=x86-64 -auxbase infloop -O2 -version
-fasynchronous-unwind-tables -o infloop.s
GNU C++14 (Debian 10.1.0-5) version 10.1.1 20200713 (x86_64-linux-gnu)
compiled by GNU C version 10.1.1 20200713, GMP version 6.2.0, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

warning: MPFR header version 4.0.2 differs from library version 4.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Debian 10.1.0-5) version 10.1.1 20200713 (x86_64-linux-gnu)
compiled by GNU C version 10.1.1 20200713, GMP version 6.2.0, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

warning: MPFR header version 4.0.2 differs from library version 4.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6cd36725701c85e62ce50f8955bd2a9a
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' 'infloop' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o infloop.o infloop.s
GNU

[Bug c++/96162] [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910

2020-07-14 Thread haoxintu at gmail dot com

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

--- Comment #1 from Haoxin Tu  ---
Add a more case.

$cat p.cc
#include 
int a() {  
for (static int & b) {}
}
$g++ p.cc
test.cc: In function ‘int a()’:
test.cc:3:24: error: expected ‘;’ before ‘)’ token
3 | for (static int & b) {}
  |^
  |;
test.cc:3:24: error: expected primary-expression before ‘)’ token
test.cc:3:24: error: expected ‘;’ before ‘)’ token
3 | for (static int & b) {}
  |^
  |;
during GIMPLE pass: *build_cgraph_edges
test.cc:3:23: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1910
3 | for (static int & b) {}
  |   ^
0x63316d discriminator_for_local_entity
../../gcc/cp/mangle.c:1910

This time GCC emits "during GIMPLE pass: *build_cgraph_edges" first and then
triggers the ICE.

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

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

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

commit r10-8493-gde70758207a6b2d8d3d6bbd3fc564ca736ed094f
Author: Jakub Jelinek 
Date:   Tue Jul 14 16:01:11 2020 +0200

expr: Unbreak build of mesa [PR96194]

> > The store to the whole of each volatile object was picked apart
> > like there had been an individual assignment to each of the
> > fields.  Reads were added as part of that; see PR for details.
> > The reads from volatile memory were a clear bug; individual
> > stores questionable.  A separate patch clarifies the docs.

This breaks building of mesa on both the trunk and 10 branch.

The problem is that the middle-end may never create temporaries of non-POD
(TREE_ADDRESSABLE) types, those can be only created when the language says
so and thus only the FE is allowed to create those.

This patch just reverts the behavior to what we used to do before for the
stores to volatile non-PODs.  Perhaps we want to do something else, but
definitely we can't create temporaries of the non-POD type.  It is up to
discussions on what should happen in those cases.

2020-07-14  Jakub Jelinek  

PR middle-end/96194
* expr.c (expand_constructor): Don't create temporary for store to
volatile MEM if exp has an addressable type.

* g++.dg/opt/pr96194.C: New test.

(cherry picked from commit b1d389d60d1929c7528ef984925ea010e3bf2c1a)

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

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

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

commit r11-2086-gb1d389d60d1929c7528ef984925ea010e3bf2c1a
Author: Jakub Jelinek 
Date:   Tue Jul 14 16:01:11 2020 +0200

expr: Unbreak build of mesa [PR96194]

> > The store to the whole of each volatile object was picked apart
> > like there had been an individual assignment to each of the
> > fields.  Reads were added as part of that; see PR for details.
> > The reads from volatile memory were a clear bug; individual
> > stores questionable.  A separate patch clarifies the docs.

This breaks building of mesa on both the trunk and 10 branch.

The problem is that the middle-end may never create temporaries of non-POD
(TREE_ADDRESSABLE) types, those can be only created when the language says
so and thus only the FE is allowed to create those.

This patch just reverts the behavior to what we used to do before for the
stores to volatile non-PODs.  Perhaps we want to do something else, but
definitely we can't create temporaries of the non-POD type.  It is up to
discussions on what should happen in those cases.

2020-07-14  Jakub Jelinek  

PR middle-end/96194
* expr.c (expand_constructor): Don't create temporary for store to
volatile MEM if exp has an addressable type.

* g++.dg/opt/pr96194.C: New test.

[Bug tree-optimization/96195] aarch64: ICE during GIMPLE pass:vect

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Note the testcase is invalid, the loop iterator really shouldn't be changed in
the simd body (well, can change, but only if it has the same value at the end
of loop body as it has at the start of it).
What are the different modes?  vector(4) int and vector(4) int really look the
same to me...

[Bug c++/95820] [10 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

2020-07-14 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |splice_late_return_type, at |splice_late_return_type, at
   |cp/pt.c:29034   |cp/pt.c:29034
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed in GCC 11.

[Bug c++/95820] [10/11 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-2085-g9eb370f19c1198e62d47eae74531e54d0b098bf1
Author: Marek Polacek 
Date:   Wed Jun 24 17:39:21 2020 -0400

c++: Improve checking of decls with trailing return type [PR95820]

This is an ICE-on-invalid but I've been seeing it when reducing
various testcases, so it's more important for me than usually.

splice_late_return_type now checks that if we've seen a late return
type, the function return type was auto.  That's a fair assumption
but grokdeclarator/cdk_function wasn't giving errors for function
pointers and similar.  So we want to perform various checks not only
when funcdecl_p || inner_declarator == NULL.  But only give the
!late_return_type errors when funcdecl_p, to accept e.g.

auto (*fp)() = f;

in C++11.  Here's a diff -w to ease the review:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12102,14 +12102,9 @@ grokdeclarator (const cp_declarator *declarator,

/* Handle a late-specified return type.  */
tree late_return_type =
declarator->u.function.late_return_type;
-   if (funcdecl_p
-   /* This is the case e.g. for
-  using T = auto () -> int.  */
-   || inner_declarator == NULL)
- {
if (tree auto_node = type_uses_auto (type))
  {
-   if (!late_return_type)
+   if (!late_return_type && funcdecl_p)
  {
if (current_class_type
&& LAMBDA_TYPE_P (current_class_type))
@@ -12201,7 +12196,6 @@ grokdeclarator (const cp_declarator *declarator,
"type specifier", name);
return error_mark_node;
  }
- }
type = splice_late_return_type (type, late_return_type);
if (type == error_mark_node)
  return error_mark_node;

gcc/cp/ChangeLog:

PR c++/95820
* decl.c (grokdeclarator) : Check also
pointers/references/... to functions.

gcc/testsuite/ChangeLog:

PR c++/95820
* g++.dg/cpp1y/auto-fn58.C: New test.

[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression

2020-07-14 Thread hyena at hyena dot net.ee

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

--- Comment #4 from Erich Erstu  ---
I also found out that when I try to populate a constexpr array using a trivial
constexpr function that passes on the argument initializer list then I get the
same error.

This does not work any more within the definition of a constexpr array:

constexpr room_desc_part_type make(
ROOM_DESC_PART part, std::initializer_list args
) {
return
#if __cplusplus <= 201703L
__extension__
#endif // __cplusplus
room_desc_part_type{
.index = part,
.arguments = args
};
}

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

2020-07-14 Thread tschwinge at gcc dot gnu.org

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

--- Comment #10 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #4)
> The recent r279626 "OpenACC 2.6 deep copy: middle-end parts" contains
> changes related to this

... some of which have now gotten reverted in recent commit
g:b20097c65d2e74b1901fba1c55c77f0407e542d2 "openacc: Don't strip
TO_PSET/POINTER for enter/exit data".

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

2020-07-14 Thread jvdelisle at charter dot net

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

jvdelisle at charter dot net changed:

   What|Removed |Added

 CC||jvdelisle at charter dot net

--- Comment #1 from jvdelisle at charter dot net ---
I will take this one.

[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy

2020-07-14 Thread hjl.tools at gmail dot com

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

H.J. Lu  changed:

   What|Removed |Added

 CC||elver at google dot com

--- Comment #2 from H.J. Lu  ---
*** Bug 95645 has been marked as a duplicate of this bug. ***

[Bug c/95645] Linux kernel regression "during GIMPLE pass: adjust_alignment"

2020-07-14 Thread hjl.tools at gmail dot com

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

--- Comment #2 from H.J. Lu  ---


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

[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression

2020-07-14 Thread hyena at hyena dot net.ee

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

Erich Erstu  changed:

   What|Removed |Added

 CC||hyena at hyena dot net.ee

--- Comment #3 from Erich Erstu  ---
I started getting the same error after upgrading to GCC 9.3.0.

The problem in my case is either related to the use of std::pair in constexpr
or the fact that I have nested instances of std::initializer_list.

The workaround was to replace std::pair with a custom struct as seen here:

struct zone_name_root_variant_type {
const char *name;
std::initializer_list affixes;
};

struct zone_name_root_type {
ZONE_NAME_ROOT index;
const char *region;
std::initializer_list<
zone_name_root_variant_type
/*
std::pair<
const char*,
std::initializer_list
>
*/
> variants;
};

static constexpr const zone_name_root_type zone_name_root_table[] = {
{
ZONE_NAME_ROOT::UNKNOWN, "Region",
{
{  "", { ZONE_NAME_AFFIX::UNKNOWN } }
}
},
{ ZONE_NAME_ROOT::NONE, "", { } }
};

[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr

2020-07-14 Thread burnus at gcc dot gnu.org

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

--- Comment #9 from Tobias Burnus  ---
(In reply to Nichols A. Romero from comment #0)
> The error for the OpenMP is shown below:
>29 |!$omp target data use_device_ptr(this_bin)
>   | 1
> Error: TARGET DATA must contain at least one MAP clause at (1)

As mentioned, this is OpenMP 5.0 and not yet implemented (for Fortran; it is
already implemented for C/C++).

→ This should be the only remaining issue of the discussion in this PR. 


> For the OpenACC program
>27 |!$acc enter data attach(this_bin)
>   | 1

This one _works now_ with GCC 10 (or the being-developed version GCC 11 alias
mainline/main/trunk).

Additionally, the OpenMP 4.5 (but not OpenMP 5.0) mapping of derived-type
components is now supported in GCC 11 (just committed). (For C/C++, the OpenMP
4.5 struct element mapping is supported since GCC 6.)

[Bug tree-optimization/96195] New: aarch64: ICE during GIMPLE pass:vect

2020-07-14 Thread yangyang305 at huawei dot com

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

Bug ID: 96195
   Summary: aarch64: ICE during GIMPLE pass:vect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyang305 at huawei dot com
  Target Milestone: ---

Hi, gcc-trunk ICEs when compiling the following testcase with -ftree-vectorize
-march=armv8.2-a+sve -O1  -msve-vector-bits=128 -fopenmp-simd

testcase
---
int by;

#pragma omp declare simd
int
zp (int);

void
qh (int oh)
{
#pragma omp simd
  for (by = 0; by < oh; ++by)
by = zp (by);
}
---
GCC version: 11.0.0 20200714 (experimental)

Result:
pr92347.c: In function ‘qh’:
pr92347.c:13:1: error: invalid conversion in gimple call
   13 | qh (int oh)
  | ^~
vector(4) int

vector(4) int

# .MEM_59 = VDEF <.MEM_13>
vect__21.16_58 = zp.simdclone.2 (vect_vec_iv_.15_56);
during GIMPLE pass: vect
pr92347.c:13:1: internal compiler error: verify_gimple failed
0xd1dcd7 verify_gimple_in_cfg(function*, bool)
../.././gcc/tree-cfg.c:5491
0xbe415b execute_function_todo
../.././gcc/passes.c:1992
0xbe505b do_per_function
../.././gcc/passes.c:1640
0xbe505b execute_todo
../.././gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

In the testcase, the following gimple call is generated:

  vect__21.16_58 = zp.simdclone.2 (vect_vec_iv_.15_56);

The TREE_TYPE of vect__21.16_58 has a different mode with the TREE_TYPE of
zp.simdclone.2 (vect_vec_iv_.15_56), leading to the crash.

It seems that a type conversion is needed when the return type of the simd
clone of the function has the same ABI identity but different TYPE_MODEs with
the vectype analyzed.

I have prepared the following patch to fix this problem, the type conversions
of
the arguments are added as well.

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -4108,7 +4108,20 @@ vectorizable_simd_clone_call (vec_info *vinfo,
stmt_vec_info stmt_info,
  vec_oprnd0);
}
  if (k == 1)
-   vargs.safe_push (vec_oprnd0);
+   if (!useless_type_conversion_p (TREE_TYPE (vec_oprnd0),
+  atype))
+ {
+   vec_oprnd0
+ = build1 (VIEW_CONVERT_EXPR, atype, vec_oprnd0);
+   gassign *new_stmt
+ = gimple_build_assign (make_ssa_name (atype),
+  vec_oprnd0);
+   vect_finish_stmt_generation (vinfo, stmt_info,
+new_stmt, gsi);
+   vargs.safe_push (gimple_assign_lhs (new_stmt));
+ }
+   else
+ vargs.safe_push (vec_oprnd0);
  else
{
  vec_oprnd0 = build_constructor (atype, ctor_elts);
@@ -4204,8 +4217,7 @@ vectorizable_simd_clone_call (vec_info *vinfo,
stmt_vec_info stmt_info,
  gcc_assert (ratype || simd_clone_subparts (rtype) == nunits);
  if (ratype)
new_temp = create_tmp_var (ratype);
- else if (simd_clone_subparts (vectype)
-  == simd_clone_subparts (rtype))
+ else if (useless_type_conversion_p (vectype, rtype))
new_temp = make_ssa_name (vec_dest, new_call);
  else
new_temp = make_ssa_name (rtype, new_call);
@@ -4293,6 +4305,12 @@ vectorizable_simd_clone_call (vec_info *vinfo,
stmt_vec_info stmt_info,
  vect_finish_stmt_generation (vinfo, stmt_info, new_stmt, gsi);
  vect_clobber_variable (vinfo, stmt_info, gsi, new_temp);
}
+ else if (!useless_type_conversion_p (vectype, rtype))
+   {
+ vec_oprnd0 = build1 (VIEW_CONVERT_EXPR, vectype, new_temp);
+ new_stmt = gimple_build_assign (make_ssa_name (vec_dest),
vec_oprnd0);
+ vect_finish_stmt_generation (vinfo, stmt_info, new_stmt, gsi);
+   }
}

   if (j == 0)

With this patch, gcc generates:

  _58 = VIEW_CONVERT_EXPR(vect_vec_iv_.15_56);
  _59 = zp.simdclone.2 (_58);
  vect__21.16_61 = VIEW_CONVERT_EXPR(_59);

[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data

2020-07-14 Thread thenlich at gcc dot gnu.org

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

--- Comment #7 from Thomas Henlich  ---
(In reply to Dominique d'Humieres from comment #6)
> > Please explain, what valid code according to Fortran 2008 does -std=f2008 
> > reject?
> 
> FAIL: gfortran.dg/fmt_g0_4.f08   -O  (test for excess errors)

I think there is another bug, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725#c8

[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data

2020-07-14 Thread dominiq at lps dot ens.fr

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

--- Comment #6 from Dominique d'Humieres  ---
> Please explain, what valid code according to Fortran 2008 does -std=f2008 
> reject?

FAIL: gfortran.dg/fmt_g0_4.f08   -O  (test for excess errors)

[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:81072bab8d1e48ee83d9711dcb559ea1e019b351

commit r11-2080-g81072bab8d1e48ee83d9711dcb559ea1e019b351
Author: Mark Eggleston 
Date:   Thu Jun 11 11:05:40 2020 +0100

Fortran  : ICE in gfc_check_pointer_assign PR95612

Output an error if the right hand value is a zero sized array or
does not have a symbol tree otherwise continue checking.

2020-07-14  Steven G. Kargl  

gcc/fortran/

PR fortran/95612
* expr.c (gfc_check_pointer_assigb): Output an error if
rvalue is a zero sized array or output an error if rvalue
doesn't have a symbol tree.

2020-07-14  Mark Eggleston  

gcc/testsuite/

PR fortran/95612
* gfortran.dg/pr95612.f90: New test.

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread manuel.lauss at googlemail dot com

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

--- Comment #6 from Manuel Lauss  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48874 [details]
> gcc11-pr96194.patch
> 
> Untested fix.

It fixes the mesa build, thank you!

[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data

2020-07-14 Thread thenlich at gcc dot gnu.org

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

--- Comment #5 from Thomas Henlich  ---
(In reply to Dominique d'Humieres from comment #4)

> But reject valid too! AFAIU this cannot captured ay the format level.

Please explain, what valid code according to Fortran 2008 does -std=f2008
reject?

[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data

2020-07-14 Thread dominiq at lps dot ens.fr

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

--- Comment #4 from Dominique d'Humieres  ---
> Agreed, that should fix the bug.

But reject valid too! AFAIU this cannot captured ay the format level.

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread jakub at gcc dot gnu.org

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 48874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48874=edit
gcc11-pr96194.patch

Untested fix.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

2020-07-14 Thread burnus at gcc dot gnu.org

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #10 from Tobias Burnus  ---
FIXED on mainline (GCC 10).

Thanks for the bugreport and sorry for taking nearly 5 years to get it fixed.

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #2)
> Started with r11-2045-ga4aca1edaf37d43b2b7e9111825837a7a317b1b0 and its
> r10-2046 backport.

Sorry, meant r10-8468 backport.

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread jakub at gcc dot gnu.org

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

--- Comment #3 from Jakub Jelinek  ---
--- gcc/expr.c.jj   2020-07-13 19:09:33.173872178 +0200
+++ gcc/expr.c  2020-07-14 13:07:26.228801996 +0200
@@ -8382,7 +8382,9 @@ expand_constructor (tree exp, rtx target
   || GET_CODE (target) == PARALLEL || modifier == EXPAND_STACK_PARM
   /* Also make a temporary if the store is to volatile memory, to
 avoid individual accesses to aggregate members.  */
-  || (GET_CODE (target) == MEM && MEM_VOLATILE_P (target)))
+  || (GET_CODE (target) == MEM
+ && MEM_VOLATILE_P (target)
+ && !TREE_ADDRESSABLE (TREE_TYPE (exp
 {
   if (avoid_temp_mem)
return NULL_RTX;
fixes this - even when volatile, for non-POD types the middle-end may not
create temporaries period.

[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|10.1.1: ICE in assign_temp, |[10/11 Regression] ICE in
   |at function.c:984 during|assign_temp, at
   |RTL pass: expand|function.c:984 during RTL
   ||pass: expand
   Priority|P3  |P1
   Target Milestone|--- |10.2

--- Comment #2 from Jakub Jelinek  ---
Started with r11-2045-ga4aca1edaf37d43b2b7e9111825837a7a317b1b0 and its
r10-2046 backport.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

2020-07-14 Thread cvs-commit at gcc dot gnu.org

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:174e79bf73331b41b7a14dffd45ed8293487f0e0

commit r11-2078-g174e79bf73331b41b7a14dffd45ed8293487f0e0
Author: Tobias Burnus 
Date:   Tue Jul 14 12:55:53 2020 +0200

[Fortran, OpenMP] Fix allocatable-components check (PR67311)

gcc/fortran/ChangeLog:

PR fortran/67311
* trans-openmp.c (gfc_has_alloc_comps): Return false also for
pointers to arrays.

libgomp/ChangeLog:

PR fortran/67311
* testsuite/libgomp.fortran/target-map-1.f90: New test.

[Bug middle-end/96194] 10.1.1: ICE in assign_temp, at function.c:984 during RTL pass: expand

2020-07-14 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:

typedef decltype (sizeof 0) size_t;
void *operator new (size_t, void *b) { return b; }
struct A { ~A (); };
struct B : A { float e[64]; };

void *
foo (void *x, bool y)
{
  void *p = y ? x : nullptr;
  return new (p) B ();
}

(the nullptr is from:
static inline void *
os_malloc_aligned(size_t size, size_t alignment)
{
   void *ptr;
   alignment = (alignment + sizeof(void*) - 1) & ~(sizeof(void*) - 1);
   if(posix_memalign(, alignment, size) != 0)
  return NULL;
   return ptr;
}
) and jump threading makes return new (nullptr) B (); out of this.

typedef decltype (sizeof 0) size_t;
void *operator new (size_t, void *b) { return b; }
struct A { ~A (); };
struct B : A { float e[64]; };

void *
foo ()
{
  return new (nullptr) B ();
}

ICEs too.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

2020-07-14 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #48869|0   |1
is obsolete||

--- Comment #9 from Richard Biener  ---
Created attachment 48873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48873=edit
updated alternate patch

(In reply to Richard Biener from comment #8)
> files with growth:
> 
> obj/gcc/calls.c.325t.statistics:320 4958  | 5571
> obj/gcc/prefix.c.325t.statistics:320 115  | 118
> 
> yes, that's all of them.

The prefix.c one is a two-BB natural loop inside an irreducible region.  Since
we do not represent irreducible regions in the loop tree it is falsely
classified as being independent so the scheduling change could make things
worse here.  Not regressing could be easily achieved by keying the thing on no
BB_IRREDUCIBLE_LOOP block in the function but then we need to compute that.
That said, the patch logic assumes that there's no natural loop inside an
irreducible region at outermost loop level.

mark_irreducible_loops uses graphds_scc which in the end would be all we
need (sorting RPO after the SCC component number).

Updated patch taking into account optimized iteration between two outermost
loops w/o a block in the root loop.

[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data

2020-07-14 Thread thenlich at gcc dot gnu.org

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

--- Comment #3 from Thomas Henlich  ---
(In reply to Dominique d'Humieres from comment #2)
> Does it look good?

Agreed, that should fix the bug.

[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data

2020-07-14 Thread dominiq at lps dot ens.fr

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

--- Comment #2 from Dominique d'Humieres  ---
With

--- ../_clean/gcc/fortran/io.c  2020-07-01 18:25:56.0 +0200
+++ gcc/fortran/io.c2020-07-14 11:06:50.0 +0200
@@ -894,7 +894,13 @@ data_desc:
   _locus))
return false;
  u = format_lex ();
- if (u != FMT_PERIOD)
+ if (u == FMT_PERIOD)
+   {
+ if (!gfc_notify_std (GFC_STD_F2018, "% in format at %L", 
+  _locus))
+   return false;
+   }
+ else

I get

g% gfc pr93733.f90 -std=f2008
pr93733.f90:7:12:

7 | write(*, "(g0.2)")  -23
  |1
Error: Fortran 2018: 'G0.d' in format at (1)
pr93733.f90:8:12:

8 | write(*, "(g0.2)")  .true.
  |1
Error: Fortran 2018: 'G0.d' in format at (1)
pr93733.f90:9:12:

9 | write(*, "(g0.2)")  'hello'
  |1
Error: Fortran 2018: 'G0.d' in format at (1)

Does it look good?

[Bug c++/96193] No ADL for hidden friend in call with explicit template arguments

2020-07-14 Thread redi at gcc dot gnu.org

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Johel Ernesto Guerrero Peña from comment #1)
> That actually compiles if I add -std=c++20.

That is correct, isn't it?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0846r0.html is a C++20
feature.

1 2 >

1 - 100 of 117 matches

Mail list logo