[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

2020-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983

--- Comment #9 from Jonathan Wakely  ---
Thanks, Tim. I'd forgotten about that issue and was about to reinvent the
resolution.

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

2020-05-20 Thread luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||luoxhu at gcc dot gnu.org

--- Comment #4 from luoxhu at gcc dot gnu.org ---
Is this just the difference of O3 and O2? Since O3 is OK, maybe this bug is not
effective?

$ /opt/at10.0/bin/gcc -O3 -S pr70053.c
$ cat pr70053.s
.file   "pr70053.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl D256_add_finite
.type   D256_add_finite, @function
D256_add_finite:
dcmpuq 7,4,6
beq 7,.L3
fmr 7,3
fmr 6,2
fmr 3,7
fmr 2,6
blr
.p2align 4,,15
.L3:
fmr 5,7
fmr 4,6
fmr 3,7
fmr 2,6
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   D256_add_finite,.-D256_add_finite
.ident  "GCC: (GNU) 6.4.1 20170720 (Advance-Toolchain-at10.0) IBM AT 10
branch, based on subversion id 250395."
.section.note.GNU-stack,"",@progbits

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

2020-05-20 Thread guojiufu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398

--- Comment #26 from Jiu Fu Guo  ---
Had a test on spec2017 xz_r by changing the specified loop manually, on
ppc64le.

original loop (this loops occur three times in code):
while (++len != len_limit)
if (pb[len] != cur[len])
break;
changed to loop:
typedef long long __attribute__((may_alias)) TYPEE;

  for(++len; len + sizeof(TYPEE) <= len_limit; len += sizeof(TYPEE)) {
long long a = *((TYPEE*)(cur+len));
long long b = *((TYPEE*)(pb+len));
if (a != b) {
  break; //to optimize len can be move forward here.
  }
}
  for (;len != len_limit; ++len)
if (pb[len] != cur[len])
  break;

We can see xz_r runtime improved from 433s to 382s(>12%).
It would be very valuable to do this kind of widening reading/checking.

[Bug target/95251] New: x86 code size expansion inserting field into a union

2020-05-20 Thread michaeljclark at mac dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95251

Bug ID: 95251
   Summary: x86 code size expansion inserting field into a union
   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: ---

Testing code on Godbolt and I came across some pathological code amplification
when SSE is enabled for field insertion into a structure containing a union. 

Here is the Godbolt link: https://godbolt.org/z/z_RpFt

Compiler flags: gcc -Os --save-temps -march=ivybridge -c x7b00.c

The function `x7b00`, inserts into the structure via char fields and it has a
voluminous translation (30 instructions).  The functionally equivalent `xyb87`
inserts into the structure via an 64-bit integer and it translates simply (5
instructions). `x`, `a7x` and `x7bcd` are for comparison.

Not adding  -march=ivybridge improves the code size but it is still nowhere
near optimal. `xyb87` serves as a reference for near optimal translation. It
seemed worthy of filing a bug due to the observed code amplification factor
(6X).

Can the backend choose the non-SSE code generation if it is more efficient?


--- CODE SNIPPET BEGINS ---

typedef unsigned long long u64;
typedef char u8;

typedef struct mr
{
union {
u64 y;
struct {
u8 a,b,c,d;
} i;
} u;
u64 x;
} mr;

u64 x(mr mr) { return mr.x; }
mr a7x(u64 x) { return (mr) { .u = { .i = { 7,0,0,0 } }, .x = x }; }
mr x7bcd(u64 x,u8 b,u8 c,u8 d) { return (mr) {.u={.i={7,b,c,d }}, .x=x }; }
mr xyb87(u64 x, u8 b) { return (mr) {.u={ .y =(u64)b << 8|7},.x=x }; }
mr x7b00(u64 x, u8 b) { return (mr) {.u={ .i ={7,b,0,0}}, .x=x }; }


--- EXPECTED OUTPUT ---

.cfi_startproc
endbr64
movsbq  %sil, %rax
movq%rdi, %rdx
salq$8, %rax
orq $7, %rax
ret
.cfi_endproc


--- OBSERVED OUTPUT ---

.cfi_startproc
endbr64
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rdi, %r8
xorl%eax, %eax
movl$6, %ecx
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
leaq-32(%rsp), %rdi
rep stosb
movq$0, -48(%rsp)
movabsq $281474976710655, %rax
movq$0, -40(%rsp)
movq-48(%rsp), %rdx
andq-32(%rsp), %rax
movzwl  %dx, %edx
salq$16, %rax
orq %rax, %rdx
movq%rdx, -48(%rsp)
movb$7, -48(%rsp)
vmovdqa -48(%rsp), %xmm1
vpinsrb $1, %esi, %xmm1, %xmm0
vmovaps %xmm0, -48(%rsp)
movq-48(%rsp), %rax
movq%r8, -40(%rsp)
movq-40(%rsp), %rdx
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

2020-05-20 Thread rs2740 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983

--- Comment #8 from TC  ---
(really from Tim)

This is https://cplusplus.github.io/LWG/issue3420

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

2020-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983

--- Comment #7 from Jonathan Wakely  ---
(In reply to Lyberta from comment #0)
> #include 
> #include 
> 
> struct Foo
> {
> Foo(const std::filesystem::path& p);
> };
> 
> static_assert(std::copyable);

The problem is that copyable considers the Foo(const path&) constructor to
see if it can be called with a const Foo&. That considers this constructor with
Foo substituted for Source:

filesystem::path(Source const&, format = auto_format);

The constraints for Source involve checking whether Source is a
Cpp17InputIterator, which is done with this:

  template>
using __is_path_iter_src
  = __and_<__is_encoded_char,
   std::is_base_of>;

So we instantiate iterator_traits.

In C++20 finding the matching specialization for std::iterator_traits
checks for concept satisfaction, which includes checking copyable which is
recursive.

An even smaller reproducer is:

#include 

struct X
{
  template::iterator_category>
X(const T&);
};

static_assert( std::copyable );

I can fix filesystem::path to avoid using iterator_traits, but this seems like
it's going to cause problems for plenty of other code too.

[Bug c++/93295] ICE in alias_ctad_tweaks

2020-05-20 Thread arthur.j.odwyer at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #6 from Arthur O'Dwyer  ---
Another test case from Peter O'Rourke on cpplang Slack:
https://godbolt.org/z/YEw4v9

template struct A {};
template A() -> A<1>;
template using B = A<2>;
B bar;

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:7797f5ec58078523a452e5cf239596e13d77d885

commit r11-535-g7797f5ec58078523a452e5cf239596e13d77d885
Author: Uros Bizjak 
Date:   Thu May 21 01:53:09 2020 +0200

i386: Do not use commutative operands with (use) RTX [PR95238]

2020-05-21  Uroš Bizjak  

gcc/ChangeLog:
PR target/95218

* config/i386/mmx.md (*mmx_v2sf): Do not mark
operands 1 and 2 commutative.  Manually swap operands.
(*mmx_nabsv2sf2): Ditto.

Partially revert:

* config/i386/i386.md (*tf2_1):
Mark operands 1 and 2 commutative.
(*nabstf2_1): Ditto.
* config/i386/sse.md (*2): Mark operands 1 and 2
commutative.  Do not swap operands.
(*nabs2): Ditto.

[Bug d/95250] New: [D] ICE instead of error when trying to use bad template type inside template

2020-05-20 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250

Bug ID: 95250
   Summary: [D] ICE instead of error when trying to use bad
template type inside template
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: witold.baryluk+gcc at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/xWrXP5

Minimized version

```
module m;

import std.traits : Unsigned;

void* f(T)(T a, T b) {
alias UnsignedVoid = Unsigned!(T);
return cast(T)(cast(T)(cast(UnsignedVoid)(a-b) / 2));
}
//static assert(is(typeof(f(null, null)) == void*));   // ICE
static assert(is(typeof(f!(void*)(null, null)) == void*));  // ICE
```

The code is not correct, but on DMD v2.092.0 and LDC 1.20.1 (LLVM 9.0.1) it
does say static assert is false (which is also incorrect), and doesn't crash.

Instead it should say, something like this:

/usr/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/std/traits.d:7163:13: error:
static assert  "Type void* does not have an Unsigned counterpart"

 7163 | static assert(false, "Type " ~ T.stringof ~

  | ^


Here is a local run, on Linux, amd64.

$ gdc gdc_ice.d
d21: internal compiler error: Segmentation fault
0xbd63ef crash_signal
../../src/gcc/toplev.c:328
0x7f31b746c7ff ???
./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x71ed1e isAggregate(Type*)
../../src/gcc/d/dmd/opover.c:161
0x71ed1e visit
../../src/gcc/d/dmd/opover.c:586
0x71e935 op_overload(Expression*, Scope*)
../../src/gcc/d/dmd/opover.c:1385
0x6d0b88 Expression::op_overload(Scope*)
../../src/gcc/d/dmd/expression.h:213
0x6d0b88 ExpressionSemanticVisitor::visit(DivExp*)
../../src/gcc/d/dmd/expressionsem.c:6891
0x6cd7b4 semantic(Expression*, Scope*)
../../src/gcc/d/dmd/expressionsem.c:8214
0x6cd7b4 unaSemantic(UnaExp*, Scope*)
../../src/gcc/d/dmd/expressionsem.c:8164
0x6cd7b4 ExpressionSemanticVisitor::visit(CastExp*)
../../src/gcc/d/dmd/expressionsem.c:4203
0x6cd7b4 semantic(Expression*, Scope*)
../../src/gcc/d/dmd/expressionsem.c:8214
0x6cd7b4 unaSemantic(UnaExp*, Scope*)
../../src/gcc/d/dmd/expressionsem.c:8164
0x6cd7b4 ExpressionSemanticVisitor::visit(CastExp*)
../../src/gcc/d/dmd/expressionsem.c:4203
0x6c5a45 semantic(Expression*, Scope*)
../../src/gcc/d/dmd/expressionsem.c:8214
0x74795f StatementSemanticVisitor::visit(ReturnStatement*)
../../src/gcc/d/dmd/statementsem.c:2757
0x74a949 semantic(Statement*, Scope*)
../../src/gcc/d/dmd/statementsem.c:3782
0x74a949 StatementSemanticVisitor::visit(CompoundStatement*)
../../src/gcc/d/dmd/statementsem.c:142
0x743755 semantic(Statement*, Scope*)
../../src/gcc/d/dmd/statementsem.c:3782
0x6e8ba9 FuncDeclaration::semantic3(Scope*)
../../src/gcc/d/dmd/func.c:1711
0x6e8ba9 FuncDeclaration::semantic3(Scope*)
../../src/gcc/d/dmd/func.c:1354
$

$ gdc -v
Using built-in specs.
COLLECT_GCC=gdc
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-1'
--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,amdgcn-amdhsa,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.0 (Debian 10.1.0-1) 
$

[Bug c/95213] GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)

2020-05-20 Thread in-gcc at baka dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95213

Seth Robertson  changed:

   What|Removed |Added

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

--- Comment #3 from Seth Robertson  ---
I disagree that this the same bug as 39170.  I know how to disable these
warning entirely.  I know how to disable them just for the instance it is
wrong.  However, in this bug, under some circumstances gcc is incorrectly
claiming that there is a conversion error where essentially isomorphic code is
thought just fine.

Thank you for your consideration.

[Bug tree-optimization/95246] Failure to optimize comparison between differently signed chars

2020-05-20 Thread gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246

Gabriel Ravier  changed:

   What|Removed |Added

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

--- Comment #3 from Gabriel Ravier  ---
Welp I actually found the option for it, so I'll close it as RESOLVED INVALID
(I guess I really shouldn't be trying to close bug reports at 5 am )

[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute

2020-05-20 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198

--- Comment #3 from Witold Baryluk  ---
> The main example to demonstrate the current behaviour is correct would be the 
> following:

```
extern(C)
private final int f() {
  return 5;
}

auto pubf()() {
  return f();
}
```

I see, I guess you are right. I don't know how would one go to fix this to work
correctly with existing linkers and not break other code.

Thanks for clarifications.

[Bug tree-optimization/95246] Failure to optimize comparison between differently signed chars

2020-05-20 Thread gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246

--- Comment #2 from Gabriel Ravier  ---
Looks like I misread it, LLVM compares `dil` and `sil` with that
transformation, not `edi` and `esi` as it does without it. I should stop making
bug reports at 1 am... I suppose I should mark thtis as INVALID, but I haven't
been able to find how to do it, I can only seem to mark it as RESOLVED (maybe I
shouldn't try to close bug reports at 5 am)

[Bug middle-end/95249] Stack protector runtime has to waste one byte on null terminator

2020-05-20 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249

--- Comment #2 from Rich Felker  ---
Indeed, using an extra zero pad byte could bump the stack frame size by 4 or 8
or 16 bytes, or could leave it unchanged, depending on alignment prior to
adding the byte and the alignment requirements of the target.

[Bug middle-end/95249] Stack protector runtime has to waste one byte on null terminator

2020-05-20 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249

--- Comment #1 from Andrew Pinski  ---
I doubt you could skip one byte as the protector location has to be aligned. 
So the trade off is adding at least 4 or 8 bytes (depending on which ABI is
used) or 8bits less of the randomness.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #18 from Uroš Bizjak  ---
Created attachment 48575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48575=edit
Patch in testing.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #17 from Uroš Bizjak  ---
The problem is with commutative operands, these somehow confuse postreload
pass.

I'll commit partial revert that basically puts back:

 (define_insn_and_split "*2"
-  [(set (match_operand:VF 0 "register_operand" "=x,v")
+  [(set (match_operand:VF 0 "register_operand" "=x,x,v,v")
(absneg:VF
- (match_operand:VF 1 "vector_operand" "%0,v")))
-   (use (match_operand:VF 2 "vector_operand" "xBm,vm"))]
+ (match_operand:VF 1 "vector_operand" "0,xBm,v,m")))
+   (use (match_operand:VF 2 "vector_operand" "xBm,0,vm,v"))]

with manual swapping of operands.

[Bug c++/93083] copy deduction rejected when doing CTAD for NTTP

2020-05-20 Thread hanicka at hanicka dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083

--- Comment #2 from Hana Dusíková  ---
Same error is also triggered by template partial specialization:

```
template  struct literal {
constexpr literal(const char ()[N]) noexcept { }
constexpr literal(const literal &) noexcept { }
};

template  struct field { };

template  struct field { };
```

[Bug middle-end/95249] New: Stack protector runtime has to waste one byte on null terminator

2020-05-20 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95249

Bug ID: 95249
   Summary: Stack protector runtime has to waste one byte on null
terminator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

At least glibc presently stores a null byte in the first byte of the stack
protector canary value, so that string-based read overflows can't leak the
canary value. On 32-bit targets, this wastes a significant portion of the
randomness, making it possible that massive-scale attacks (e.g. against
millions of mobile or IoT devices) will have a decent chance of some success
bypassing stack protector. musl presently does not zero the first byte, but I
received a suggestion that we should do so, and got to thinking about the
tradeoffs involved.

If GCC would skip one byte below the canary, the full range of values could be
used by the stack protector runtime without the risk of string-read-based
disclosure. This should be inexpensive in terms of space and time to store a
single 0 byte on the stack.

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

2020-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/546
   ||179.html
   Keywords||patch

--- Comment #8 from Eric Gallager  ---
(In reply to Michael Kuhn from comment #7)
> Took me a while, sorry. I have just sent the patch to the list.

for reference, that patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546179.html

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #16 from Jeffrey A. Law  ---
A "naked" use as an INSN should only occur inside the pattern of an insn (there
are exceptins that exist internally within reload and delay slot scheduling).


It's only supposed to be used to mark that a particular object is live and used
by the insn.  I'll note the following:

...
This means that @code{use} can @emph{only} be used to describe
that the register is live.  You should think twice before adding
@code{use} statements, more often you will want to use @code{unspec}
instead.  The @code{use} RTX is most commonly useful to describe that
a fixed register is implicitly used in an insn.  It is also safe to use
in patterns where the compiler knows for other reasons that the result
of the whole pattern is variable, such as @samp{cpymem@var{m}} or
@samp{call} patterns.

I think one could reasonably think that we should support  (use (mem)) with the
same semantics -- it means that the value in memory is used which is helpful in
dependency tracking.

[Bug c/95213] GCC -Werror=conversion error when assigning to a bitfield (when mixing constants and variables)

2020-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95213

Eric Gallager  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
dup of bug 39170

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

[Bug tree-optimization/95246] Failure to optimize comparison between differently signed chars

2020-05-20 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246

--- Comment #1 from Marc Glisse  ---
On which version of LLVM did you see that? For me, gcc produces

movzbl  %dil, %edi
movsbl  %sil, %esi
cmpl%esi, %edi
setg%al

while clang skips the first 2 lines (but still emits movl), assuming that the
input is already signed/zero extended, which points at ABI conventions. The
transformation you suggest doesn't seem right to me.

[Bug c/39170] provide an option to silence -Wconversion warnings for bit-fields

2020-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170

Eric Gallager  changed:

   What|Removed |Added

 CC||in-gcc at baka dot org

--- Comment #22 from Eric Gallager  ---
*** Bug 95213 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/95248] New: GCC produces incorrect code with -O3 for loops

2020-05-20 Thread vsevolod.livinskij at frtk dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95248

Bug ID: 95248
   Summary: GCC produces incorrect code with -O3 for loops
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC produces incorrect code with -O3 for loops

Error:
>$ gcc -O0 driver.cpp func.cpp && ./a.out
1
>$ gcc -O3 driver.cpp func.cpp && ./a.out
0

Reproducer:
>$ cat driver.cpp
#include 

int var_2 = -2013646301;
int var_3 = -1126567434;
unsigned int var_12 = 1;
unsigned int var_19;
unsigned int arr_25 [24] [21] [15] [17] [15] ;

void test();

int main() {
test();
printf("%u\n", var_19);
}

>$ cat func.cpp
extern int var_2;
extern int var_3;
extern unsigned int var_12;
extern unsigned int var_19;
extern unsigned int arr_25 [24] [21] [15] [17] [15] ;

void test() {
  for (int a = 0; a < 3; a = 42)
for (int b = 0; b < 20; b++)
  for (int c = 0; c < 4; c = 4)
for (int d = 0; d < 6; d += 4)
  for (int e = 0; e < 4; e += 2) {
arr_25[a][b][c][d][e] = var_2 || var_3;
var_19 = var_12;
  }
}

GCC version:
gcc version 11.0.0 (ed63c387aa0bc1846082524455a6ff1fcec40f9d)

[Bug target/95247] Backport the DRIVER_SELF_SPECS implementation of -mdejagnu-cpu= to GCC 9

2020-05-20 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95247

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-20
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/95247] New: Backport the DRIVER_SELF_SPECS implementation of -mdejagnu-cpu= to GCC 9

2020-05-20 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95247

Bug ID: 95247
   Summary: Backport the DRIVER_SELF_SPECS implementation of
-mdejagnu-cpu= to GCC 9
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Doug Rupp says that it fixes his problems:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546176.html
(thread starts at
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546072.html ).  It should be
perfectly safe to backport, so I'll do that tomorrow.

[Bug libstdc++/95245] std::sort copies custom comparator

2020-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-20
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #2 from Jonathan Wakely  ---
I think other implementations automatically wrap the function in a
reference-like type.

See PR 51965 for similar issues with other recursively-defined algorithms.

N.B. GCC 7 is no longer supported or maintained, so bug reports should be for
currently-supported versions.

[Bug tree-optimization/95246] New: Failure to optimize comparison between differently signed chars

2020-05-20 Thread gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246

Bug ID: 95246
   Summary: Failure to optimize comparison between differently
signed chars
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(unsigned char a, signed char b)
{
return a > b;
}

This can be optimized to `return (signed char)a > b;`. This transformation is
done by LLVM, but not by GCC.

[Bug libstdc++/95245] std::sort copies custom comparator

2020-05-20 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245

--- Comment #1 from Jonathan Wakely  ---
[algorithms.requirements] paragraph 10 says:

[Note: Unless otherwise specified, algorithms that take function objects as
arguments are permitted to copy those function objects freely. Programmers for
whom object identity is important should consider using a wrapper class that
points to a noncopied implementation object such as reference_wrapper 
20.14.5), or some equivalent solution. — end note]

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

2020-05-20 Thread rafael at espindo dot la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #18 from Rafael Avila de Espindola  ---
(In reply to Avi Kivity from comment #17)
> Is that the test were a lambda coroutine is called from future::then()? In
> that case it's a real use-after-free.

It was reduced from that to just

#include 
#include 
using namespace seastar;
int main(int argc, char** argv) {
seastar::app_template app;
app.run(argc, argv, [] () -> future<> {
future<> xyz = make_ready_future<>().then([] {});
co_await std::move(xyz);
});
return 0;
}

Which doesn't have a user after free.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

2020-05-20 Thread a...@cloudius-systems.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #17 from Avi Kivity  ---
Is that the test were a lambda coroutine is called from future::then()? In that
case it's a real use-after-free.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

2020-05-20 Thread rafael at espindo dot la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #16 from Rafael Avila de Espindola  ---
> @Rafael: Can you please append output with:
> export UBSAN_OPTIONS="print_stacktrace=1"

I also added halt_on_error=1:abort_on_error=1:

It is

../tests/unit/coroutines_test.cc:11:5: runtime error: member call on misaligned
address 0x41b58ab3 for type 'struct awaiter', which requires 8 byte
alignment
0x41b58ab3: note: pointer points here

Reactor stalled for 261 ms on shard 0.
Backtrace:
  /lib64/libasan.so.6+0x00045bad
...
#0 0xf3605a in main::{lambda()#1}::operator()() const [clone .actor]
../tests/unit/coroutines_test.cc:11
#1 0xf3b20b in std::__n4861::coroutine_handle::resume() const
/usr/include/c++/10/coroutine:126
#2 0xf3b5ed in
seastar::internal::coroutine_traits_base<>::promise_type::run_and_dispose()
../include/seastar/core/coroutine.hh:104
#3 0x11c8892 in seastar::reactor::run_tasks(seastar::reactor::task_queue&)
../src/core/reactor.cc:2151
#4 0x11cc8db in seastar::reactor::run_some_tasks()
../src/core/reactor.cc:2566
#5 0x11d1aa0 in seastar::reactor::run() ../src/core/reactor.cc:2721
#6 0xf4ef5e in seastar::app_template::run_deprecated(int, char**,
std::function&&) ../src/core/app-template.cc:202
#7 0xf4cf00 in seastar::app_template::run(int, char**,
std::function ()>&&) ../src/core/app-template.cc:115
#8 0xf4d3fa in seastar::app_template::run(int, char**,
std::function ()>&&) ../src/core/app-template.cc:130
#9 0xf36a70 in main ../tests/unit/coroutines_test.cc:8
#10 0x7fac0533d041 in __libc_start_main (/lib64/libc.so.6+0x27041)
#11 0xf3466d in _start
(/home/espindola/scylla/scylla/seastar/build-dbg/tests/unit/coroutines_test+0xf3466d)

I will try to reduce the test to not need seastar.

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

2020-05-20 Thread gcc at ikkoku dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005

--- Comment #7 from Michael Kuhn  ---
Took me a while, sorry. I have just sent the patch to the list.

[Bug libstdc++/95245] New: std::sort copies custom comparator

2020-05-20 Thread andrew.bell.ia at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245

Bug ID: 95245
   Summary: std::sort copies custom comparator
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.bell.ia at gmail dot com
  Target Milestone: ---

std::sort copies a custom comparator numerous times.  If the comparator copy is
expensive, it makes the sort very slow.  Of course, making the comparator cheap
to copy is an easy fix, but it took me by surprise that the algorithm copied my
comparator at all.  Other c++ library implementations don't have this
limitation.  I found this on version 7.5, but I believe the same behavior is in
GCC 10.1.  The following program exhibits the issue:

#include 
#include 
#include 
#include 

int main()
{
struct comp
{
comp(int i)
{
v.resize(i);
std::iota(v.begin(), v.end(), 0);
}

comp(const comp& c) : v(c.v)
{
std::cerr << "Copy ctor!\n";
}

comp(comp&& c) : v(std::move(c.v))
{
std::cerr << "Move ctor!\n";
}

bool operator()(size_t p1, size_t p2)
{
return p1 < p2;
}

// Vector is just here to cause an expensive copy and slow the sort,
// but it could,
// for example, be a cache that is used in the comparison.
std::vector v;
};

std::vector s(500);
std::iota(s.begin(), s.end(), 0);
std::random_shuffle(s.begin(), s.end());
std::sort(s.begin(), s.end(), comp(200));

return 0;
}

[Bug bootstrap/95244] New: GCC 10 no longer builds on RHEL5 [trivial patch]

2020-05-20 Thread lopresti at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95244

Bug ID: 95244
   Summary: GCC 10 no longer builds on RHEL5 [trivial patch]
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lopresti at gmail dot com
  Target Milestone: ---

I still compile GCC on Red Hat Enterprise Linux 5. It is an EoL platform, so
maybe you do not care... But the only problem (introduced with GCC 10) is the
lack of O_CLOEXEC. The following patch fixes my build:

diff --git a/libsanitizer/sanitizer_common/sanitizer_posix.cpp
b/libsanitizer/sanitizer_common/sanitizer_posix.cpp
index d890a3a3177..6ba525d1811 100644
--- a/libsanitizer/sanitizer_common/sanitizer_posix.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_posix.cpp
@@ -347,8 +347,14 @@ int GetNamedMappingFd(const char *name, uptr size, int
*flags) {
   CHECK(internal_strlen(name) < sizeof(shmname) - 10);
   internal_snprintf(shmname, sizeof(shmname), "/dev/shm/%zu [%s]",
 internal_getpid(), name);
+#if defined O_CLOEXEC
   int fd = ReserveStandardFds(
   internal_open(shmname, O_RDWR | O_CREAT | O_TRUNC | O_CLOEXEC,
S_IRWXU));
+#else
+  int fd = ReserveStandardFds(
+  internal_open(shmname, O_RDWR | O_CREAT | O_TRUNC, S_IRWXU));
+  fcntl(fd, F_SETFD, FD_CLOEXEC);
+#endif

I would be happy to make this a pull request if there is any chance it would
get accepted. Thanks.

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

2020-05-20 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223

--- Comment #10 from Bill Seurer  ---
It works for me, too, now.  Thanks!

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

2020-05-20 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223

--- Comment #9 from Dmitry G. Dyachenko  ---
(In reply to Patrick Palka from comment #8)
> Thanks for the reports.  This should now hopefully be fixed with r11-522.

r11-526 PASS for me.
Thanks

[Bug libgomp/95243] New: libgomp documentation should specify GCC Runtime Library Exception license as applicable

2020-05-20 Thread brentd42 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95243

Bug ID: 95243
   Summary: libgomp documentation should specify GCC Runtime
Library Exception license as applicable
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brentd42 at hotmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

>From an inspection of the code base, it appears that libgomp uses the GPL v3
license with the GCC Runtime Library exception. However, the libgomp
documentation page
(https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libgomp/Copying.html#Copying) lists
only GPL v3 and not the exception.

Conversely, libstc++ specifies the GCC Runtime Library exception license
(https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libstdc++/manual/manual/license.html#manual.intro.status.license.gpl)
as expected.

Similarly to libstc++, could the libgomp documentation be updated to specify
the GCC Runtime Library exception license as applicable?

[Bug c++/95242] New: [10 Regression] spurious "warning: zero as null pointer constant [-Wzero-as-null-pointer-constant]" on comparisons with -std=c++2a

2020-05-20 Thread gcc at mattwhitlock dot name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242

Bug ID: 95242
   Summary: [10 Regression] spurious "warning: zero as null
pointer constant [-Wzero-as-null-pointer-constant]" on
comparisons with -std=c++2a
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mattwhitlock dot name
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

/* BEGIN bug.cpp */

#include 
#include 

bool bug(std::chrono::milliseconds lhs, std::chrono::milliseconds rhs) {
return lhs < rhs; // spurious "warning: zero as null pointer constant"
}

bool bug(std::string::const_iterator lhs, std::string::const_iterator rhs) {
return lhs < rhs; // spurious "warning: zero as null pointer constant"
}

/* END bug.cpp */


$ g++ -std=c++2a -Wzero-as-null-pointer-constant -c bug.cpp
bug.cpp: In function 'bool bug(std::chrono::milliseconds,
std::chrono::milliseconds)':
bug.cpp:5:15: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
5 |  return lhs < rhs; // spurious "warning: zero as null pointer constant"
  |   ^~~
bug.cpp: In function 'bool
bug(std::__cxx11::basic_string::const_iterator,
std::__cxx11::basic_string::const_iterator)':
bug.cpp:9:15: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
9 |  return lhs < rhs; // spurious "warning: zero as null pointer constant"
  |   ^~~


$ g++ --version | head -n1
g++ (Gentoo 10.1.0 p1) 10.1.0


The bug is not present in G++ 9.3, and it also is not present in G++ 10.1 in
-std=c++17 (or earlier) mode. This leads me to believe it may be related to the
new three-way comparison operator functionality.

[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900

2020-05-20 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/94553] Revise [basic.scope.declarative]/4.2

2020-05-20 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553

--- Comment #5 from Marek Polacek  ---
The structured binding part is now fixed, but the variable template part isn't
yet, so not closing.

[Bug c++/94553] Revise [basic.scope.declarative]/4.2

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553

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

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

commit r11-529-g2a8565fa1182ed326721a50c700f9f5275355d40
Author: Marek Polacek 
Date:   Tue May 19 23:53:28 2020 -0400

c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

DR 2289 clarified that since structured bindings have no C compatibility
implications, they should be unique in their declarative region, see
[basic.scope.declarative]/4.2.

The duplicate_decls hunk is the gist of the patch, but that alone would
not be enough to detect the 'A' case: cp_parser_decomposition_declaration
uses

13968   tree decl2 = start_decl (declarator, _specs,
SD_INITIALIZED,
13969NULL_TREE, NULL_TREE,
_pushed_scope);

to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
don't do fit_decomposition_lang_decl because the declarator kind is not
cdk_decomp, so then when start_decl calls maybe_push_decl, the decl 'A'
isn't DECL_DECOMPOSITION_P and we don't detect this case.  So I needed a
way to signal to start_decl that it should fit_decomposition_lang_decl.
In this patch, I'm adding SD_DECOMPOSITION flag to say that the variable
is initialized and it should also be marked as DECL_DECOMPOSITION_P.

DR 2289
PR c++/94553
* cp-tree.h (SD_DECOMPOSITION): New flag.
* decl.c (duplicate_decls): Make sure a structured binding is
unique
in its declarative region.
(start_decl): If INITIALIZED is SD_DECOMPOSITION, call
fit_decomposition_lang_decl.
(grokdeclarator): Compare INITIALIZED directly to SD_* flags.
* parser.c (cp_parser_decomposition_declaration): Pass
SD_DECOMPOSITION
to start_decl.

* g++.dg/cpp1z/decomp52.C: New test.

[Bug c++/95241] [10/11 Regression] internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900

2020-05-20 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |10.2
Summary|internal compiler error:|[10/11 Regression] internal
   |tree check: expected|compiler error: tree check:
   |integer_cst, have   |expected integer_cst, have
   |range_expr in to_wide, at   |range_expr in to_wide, at
   |tree.h:5900 |tree.h:5900
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-20
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords||ice-on-valid-code

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r10-7556-g37244b217a7329792f4ec48027f63cf5010b0ea8

[Bug c++/95241] New: internal compiler error: tree check: expected integer_cst, have range_expr in to_wide, at tree.h:5900

2020-05-20 Thread tab.debugteam at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95241

Bug ID: 95241
   Summary: internal compiler error: tree check: expected
integer_cst, have range_expr in to_wide, at
tree.h:5900
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tab.debugteam at gmail dot com
  Target Milestone: ---

Following c++ code:

```
struct Fragment
{
int offset;
int length;

constexpr Fragment(
int _offset,
int _length)
: offset(_offset), length(_length)
{
}
constexpr Fragment() :
Fragment(0, 1) { }
};

struct Field {
Fragment fragments[3];

constexpr
Field(int offset, int length)
  : fragments{Fragment(offset, length)}
{
}
};

int main()
{
auto field = Field(0, 1);
return 0;
}
```

fails to compile with gcc 10.1 (https://godbolt.org/z/tyPB6V) and later with
error message:

```
: In function 'int main()':

:28:28:   in 'constexpr' expansion of 'Field(0, 1)'

:28:28: internal compiler error: tree check: expected integer_cst, have
range_expr in to_wide, at tree.h:5900

   28 | auto field = Field(0, 1);

  |^
```

First spotted on gcc 10.1: https://godbolt.org/z/tyPB6V, but it's also
reproducible on latest gcc available on compiler explorer (version 11.0.0
20200511): https://godbolt.org/z/qWivJC.
I'm unable to reproduce it on gcc 9.3: https://godbolt.org/z/C2QqxA.

[Bug target/95229] [11 Regression] in mark_jump_label_1

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:3872a519c8fa65318efa1b481d331ef91b3ff044

commit r11-528-g3872a519c8fa65318efa1b481d331ef91b3ff044
Author: Uros Bizjak 
Date:   Wed May 20 19:00:39 2020 +0200

i386: Fix zero/sign extend expanders [PR95229]

2020-05-20  Uroš Bizjak  

gcc/ChangeLog:
PR target/95229
* config/i386/sse.md (v8qiv8hi2): Use
simplify_gen_subreg instead of simplify_subreg.
(v8qiv8si2): Ditto.
(v4qiv4si2): Ditto.
(v4hiv4si2): Ditto.
(v8qiv8di2): Ditto.
(v4qiv4di2): Ditto.
(v2qiv2di2): Ditto.
(v4hiv4di2): Ditto.
(v2hiv2di2): Ditto.
(v2siv2di2): Ditto.

gcc/testsuite/ChangeLog:
PR target/95229
* g++.target/i386/pr95229.C: New test.

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r11-527-g2cf6f31527c6d8dd2cc96f4efe8ff70d60d5fb44
Author: Uros Bizjak 
Date:   Wed May 20 18:57:32 2020 +0200

i386: Fix *pushsi2_rex64 constraints [PR95238]

2020-05-20  Uroš Bizjak  

gcc/ChangeLog:
PR target/95238
* config/i386/i386.md (*pushsi2_rex64):
Use "e" constraint instead of "i".

[Bug analyzer/95240] New: calloc() false positives

2020-05-20 Thread gcc.gnu.org at andred dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95240

Bug ID: 95240
   Summary: calloc() false positives
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: gcc.gnu.org at andred dot net
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

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

Test with: gcc-10 (Debian 10.1.0-2) 10.1.0
(same behaviour with gcc 10.0)

With the attached, I get a false positive:

gcc-10 -Os -fanalyzer -fdiagnostics-path-format=separate-events t.c -o t
t.c: In function ‘initActiveTroubleArray’:
t.c:13:35: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-leak]
   13 | return activeTroubleArray ? 0 : 1;
  |~~~^~~
t.c:12:26: note: (1) allocated here
   12 | activeTroubleArray = calloc (1, 1);
  |  ^
t.c:13:35: note: (2) ‘’ leaks here; was allocated at (1)
   13 | return activeTroubleArray ? 0 : 1;
  |~~~^~~


The warning goes away in either of the following cases:
* use malloc() instead of calloc() and change nothing else
* remove the test in initActiveTroubleArray() and change nothing else
* declare activeTroubleArray as void * and change nothing else (note that the
warning is triggered when using anything but void * - standard types like char,
long, etc, but also when using struct, enum etc.)

[Bug c/95239] New: Unable to ignore -Wattribute-warning in macro

2020-05-20 Thread e...@coeus-group.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95239

Bug ID: 95239
   Summary: Unable to ignore -Wattribute-warning in macro
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 48573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48573=edit
Test case

I'm trying to create a macro which evaluates an expression while ignoring
warnings generated by the warning attribute.  Basically, a slightly simplified
version of what I want is:

  #define IGNORE_WARNING_ATTR(expr) (__extension__({ \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wattribute-warning\"") \
int tmp = expr; \
_Pragma("GCC diagnostic pop") \
tmp; \
  }))

However, when I use it I still see the warning.

If I don't use a macro, but instead just do 

int c = (__extension__({
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wattribute-warning\"")
int tmp = foo(argc);
_Pragma("GCC diagnostic pop")
tmp;
  }));

It works as intended; no warning.

If I use the macro version and preprocess the source file first, then compile
the preprocessed file separately, it works.

If I compile with g++ it works.

Using the attached test case, I get:

$ gcc -E -o warn-pp.c warn.c && gcc -o warn warn-pp.c
$ g++ -o warn warn.c
$ gcc -o warn warn.c
warn.c: In function ‘main’:
warn.c:23:31: warning: call to ‘foo’ declared with attribute warning: Calling
foo [-Wattribute-warning]
   23 |   int b = IGNORE_WARNING_ATTR(foo(argc));
  |   ^
warn.c:4:15: note: in definition of macro ‘IGNORE_WARNING_ATTR’
4 | int tmp = expr; \
  |   ^~~~

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

2020-05-20 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-20

--- Comment #1 from H.J. Lu  ---
FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error)
FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error)
FAIL: c-c++-common/gomp/declare-variant-5.c (internal compiler error)
FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors)
FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors)
FAIL: c-c++-common/gomp/declare-variant-5.c (test for excess errors)
FAIL: gcc.target/i386/pr69454-2.c (internal compiler error)
FAIL: gcc.target/i386/pr69454-2.c (test for excess errors)
FAIL: gcc.target/i386/stackalign/longlong-1.c -mno-stackrealign (internal
compiler error)
FAIL: gcc.target/i386/stackalign/longlong-1.c -mno-stackrealign (test for
excess errors)
FAIL: gcc.target/i386/stackalign/longlong-1.c -mstackrealign (internal compiler
error)
FAIL: gcc.target/i386/stackalign/longlong-1.c -mstackrealign (test for excess
errors)

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-20
 Status|UNCONFIRMED |NEW

--- Comment #5 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #4)
> 
> (define_insn "*pushsi2"
>   [(set (match_operand:SI 0 "push_operand" "=<,<")
>   (match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))]
> 
> This was "i" before my patch.

This may generate DT_TEXTREL for "push $symbol" when generating shared object

[Bug tree-optimization/94335] [10/11 Regression] False positive -Wstringop-overflow warning with -O2

2020-05-20 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0
 Blocks||88443
Summary|False positive  |[10/11 Regression] False
   |-Wstringop-overflow warning |positive
   |with -O2|-Wstringop-overflow warning
   ||with -O2

--- Comment #7 from Martin Sebor  ---
Thanks for the small test case!  The warning for reference is:

pr94335-c6.C: In function ‘int main()’:
pr94335-c6.C:8:20: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
8 | outputs.back() = 1;
  | ~~~^~~
In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:64,
 from pr94335-c6.C:3:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:115:41:
note: at offset 0 to an object with size 0 allocated by ‘operator new’ here
  115 |  return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
  |   ~~^~~

The warning in this case is actually due to a different problem, this one in
the warning infrastructure itself.  The relevant IL the warning works with
(-fdump-tree-strlen) is below:

main ()
{
  ...
  unsigned char * _48;
  ...
  unsigned char * _59;
  ...
   [local count: 1073741825]:
  ...
  _59 = operator new (2);

   [local count: 1073007519]:
  outputs.D.19139._M_impl.D.18482._M_start = _59;
  _48 = _59 + 2;
  ...
  MEM[(value_type &)_48 + 18446744073709551615] = 1;   <<< warning here
(18446744073709551615 == -2)
  ...
}

To determine the size of what _48 points to the warning code calls the
compute_objsize() function.  It returns zero because of a design limitation: it
returns the size of the remaining space in the object (i.e., the full size of
the pointed-to object minus the offset, which is 2 in this case).  The caller
has no way to increase the size it gets back by its negative offset (the large
number which is -2).

I have a rewritten the function to avoid this (and other problems with it) and
expect to have a fix for GCC 11, and possibly even for GCC 10.2.

Since this is a different problem than the originally reported bug I don't want
to use it to track it.  Feel free to open a separate bug for it.


Referenced Bugs:

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

[Bug fortran/20585] [meta-bug] Fortran 2003 support

2020-05-20 Thread markeggleston at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 39695, which changed state.

Bug 39695 Summary: [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

   What|Removed |Added

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

[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message

2020-05-20 Thread markeggleston at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from markeggleston at gcc dot gnu.org ---
Committed to master and backported.

[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

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

https://gcc.gnu.org/g:15e518600a9ef82b55d2ec75d8d41d767132f475

commit r8-10261-g15e518600a9ef82b55d2ec75d8d41d767132f475
Author: Mark Eggleston 
Date:   Thu May 7 08:02:02 2020 +0100

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

Backport from master.

2020-05-20  Mark Eggleston  

gcc/fortran/

PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set.  For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.

2020-05-20  Mark Eggleston  

gcc/testsuite/

PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.

(cherry picked from commit
eb069ae8819c3a84d7f78becc5501e21ee3a9554)

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

--- Comment #4 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > The "i" constraint shouldn't be used for flag_pic since symbolic constant
> > > leads to writable text in 32-bit mode and invalid in 64-bit mode.
> > 
> > Just a typo. "i" should be changed back to "e".
> 
> There are other "ri" in push patterns.  The 32 bit linker won't complain
> but will add DT_TEXTREL for "push $symbol" when generating shared object.

(define_insn "*push2"
  [(set (match_operand:DWI 0 "push_operand" "=<,<")
(match_operand:DWI 1 "general_no_elim_operand" "riF*o,*v"))]

This will never match symbol, so "i" can be "n" as well.

;; For TARGET_64BIT we always round up to 8 bytes.
(define_insn "*pushsi2_rex64"
  [(set (match_operand:SI 0 "push_operand" "=X,X")
(match_operand:SI 1 "nonmemory_no_elim_operand" "re,*v"))]

This is changed to "e", as was before.

(define_insn "*pushsi2"
  [(set (match_operand:SI 0 "push_operand" "=<,<")
(match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))]

This was "i" before my patch.

(define_insn "*push2_prologue"
  [(set (match_operand:W 0 "push_operand" "=<")
(match_operand:W 1 "general_no_elim_operand" "r*m"))

This one is in effect "e".

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #15 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #13)
> So perhaps pre-reload splitter of that into the UNSPEC form?

Vector insns should be able to use pre-reload splitter, but scalar instructions
depend on post-reload splitter, because they are split in a different way,
depending on a register set of allocated register (FP, XMM or even integer).

So, it really needs to be a post-reload splitter.

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

--- Comment #3 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to H.J. Lu from comment #1)
> > The "i" constraint shouldn't be used for flag_pic since symbolic constant
> > leads to writable text in 32-bit mode and invalid in 64-bit mode.
> 
> Just a typo. "i" should be changed back to "e".

There are other "ri" in push patterns.  The 32 bit linker won't complain
but will add DT_TEXTREL for "push $symbol" when generating shared object.

[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:7c9bfd404691e5dac7e32830ae6d9726ccf59683

commit r9-8608-g7c9bfd404691e5dac7e32830ae6d9726ccf59683
Author: Mark Eggleston 
Date:   Thu May 7 08:02:02 2020 +0100

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

Backported from master.

2020-05-20  Mark Eggleston  

gcc/fortran/

PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set.  For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.

2020-05-20  Mark Eggleston  

gcc/testsuite/

PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.

(cherry picked from commit
eb069ae8819c3a84d7f78becc5501e21ee3a9554)

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

Uroš Bizjak  changed:

   What|Removed |Added

 CC|uros at gcc dot gnu.org|

--- Comment #14 from Uroš Bizjak  ---
Its interesting to note, that only *some* of insns with memory uses get
removed.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
So perhaps pre-reload splitter of that into the UNSPEC form?

[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

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

https://gcc.gnu.org/g:8358ac9bbc57d6986c9bd5dd17c0331a60114f45

commit r10-8160-g8358ac9bbc57d6986c9bd5dd17c0331a60114f45
Author: Mark Eggleston 
Date:   Thu May 7 08:02:02 2020 +0100

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

Backported from master.

2020-05-20  Mark Eggleston  

gcc/fortran/

PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set.  For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.

2020-05-20  Mark Eggleston  

gcc/testsuite/

PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.

(cherry picked from commit
eb069ae8819c3a84d7f78becc5501e21ee3a9554)

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #12 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #11)
> Note a 'use' is not something that needs to be preserved, so
> 
> (define_insn_and_split "*2"
>   [(set (match_operand:VF 0 "register_operand" "=x,v")
> (absneg:VF
>   (match_operand:VF 1 "vector_operand" "%0,v")))
>(use (match_operand:VF 2 "vector_operand" "xBm,vm"))]
>   "TARGET_SSE"
>   "#"
>   "&& reload_completed"
>   [(set (match_dup 0)
> (:VF (match_dup 1) (match_dup 2)))]
>   ""
>   [(set_attr "isa" "noavx,avx")])
> 
> doesn't make much sense (before reload).  To me, that is.  Why do
> we go that obfuscated way at all?  I think a clean solution is to
> use an UNSPEC here (well, "clean"...).

The reason for this approach was, that combine still processes the pattern as
abs/nop. Please see how *nabstf2_1 is defined.

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

--- Comment #2 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #1)
> The "i" constraint shouldn't be used for flag_pic since symbolic constant
> leads to writable text in 32-bit mode and invalid in 64-bit mode.

Just a typo. "i" should be changed back to "e".

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

2020-05-20 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Thanks for the reports.  This should now hopefully be fixed with r11-522.

[Bug target/95229] [11 Regression] in mark_jump_label_1

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229

--- Comment #7 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #6)

> That fixes the testcase.  But simplify_subreg is used in a lot more places
> so leaving to Uros to match up with expectations.

Oh, yes... We don't have hard regs here, so all should be changed to
simplify_gen_subregs. I have a patch.

[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

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

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

commit r11-524-geb069ae8819c3a84d7f78becc5501e21ee3a9554
Author: Mark Eggleston 
Date:   Thu May 7 08:02:02 2020 +0100

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

2020-05-20  Mark Eggleston  

gcc/fortran/

PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set.  For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.

2020-05-20  Mark Eggleston  

gcc/testsuite/

PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223

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

https://gcc.gnu.org/g:610ae2dbbf98a291782cb05c0fb31e056193e5e2

commit r11-522-g610ae2dbbf98a291782cb05c0fb31e056193e5e2
Author: Patrick Palka 
Date:   Wed May 20 09:15:48 2020 -0400

c++: spec_hasher and TYPENAME_TYPE resolution [PR95223]

After enabling sanitization of the specialization tables, we are
triggering one of the hash table sanity checks in the below testcase.

The reason is that when looking up the specialization j in the
type_specializations table, the sanity check finds that the existing
entry j::m> compares equal to j but hashes differently.

The discrepancy is due to structural_comptypes looking through
TYPENAME_TYPEs (via resolve_typename_type), something which
iterative_hash_template_arg doesn't do.  So the TYPENAME_TYPE n::m is
considered equal to int, but the hashes of these two template arguments
are different.

It seems wrong for the result of a specialization table lookup to depend
on the current scope, so this patch makes structural_comptypes avoid
calling resolve_typename_type when comparing_specializations.

In order for the below testcase to deterministically trigger the
sanitization error without this patch, we also need to fix the location
of the call to hash_table::verify within hash_table::find_with_hash.

gcc/ChangeLog:

PR c++/95223
* hash-table.h (hash_table::find_with_hash): Move up the call to
hash_table::verify.

gcc/cp/ChangeLog:

PR c++/95223
* typeck.c (structural_comptypes): Don't perform
context-dependent resolution of TYPENAME_TYPEs when
comparing_specializations.

gcc/testsuite/ChangeLog:

PR c++/95223
* g++.dg/template/typename23.C: New test.

[Bug target/95238] [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

--- Comment #1 from H.J. Lu  ---
The "i" constraint shouldn't be used for flag_pic since symbolic constant
leads to writable text in 32-bit mode and invalid in 64-bit mode.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #11 from Richard Biener  ---
Note a 'use' is not something that needs to be preserved, so

(define_insn_and_split "*2"
  [(set (match_operand:VF 0 "register_operand" "=x,v")
(absneg:VF
  (match_operand:VF 1 "vector_operand" "%0,v")))
   (use (match_operand:VF 2 "vector_operand" "xBm,vm"))]
  "TARGET_SSE"
  "#"
  "&& reload_completed"
  [(set (match_dup 0)
(:VF (match_dup 1) (match_dup 2)))]
  ""
  [(set_attr "isa" "noavx,avx")])

doesn't make much sense (before reload).  To me, that is.  Why do
we go that obfuscated way at all?  I think a clean solution is to
use an UNSPEC here (well, "clean"...).

[Bug target/95238] New: [11 Regression] Invalid *pushsi2_rex64

2020-05-20 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95238

Bug ID: 95238
   Summary: [11 Regression] Invalid *pushsi2_rex64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64

In 64-bit mode, we can only push 16-bit or 64-bit memory/register.

commit 75514d157e9e28616c6de4e8c2740d8c87b6857d
Author: Uros Bizjak 
Date:   Fri May 15 16:22:19 2020 +0200

i386: Allow SI, DI and TImode pushes from XMM registers

Also change XMM register constraint from "x" to "v" in FP push insns.

added

+;; For TARGET_64BIT we always round up to 8 bytes.
+(define_insn "*pushsi2_rex64"
+  [(set (match_operand:SI 0 "push_operand" "=X,X")
+   (match_operand:SI 1 "nonmemory_no_elim_operand" "ri,*v"))]
+  "TARGET_64BIT"
+  "@
+   push{q}\t%q1
+   #"
+  [(set_attr "type" "push,multi")
+   (set_attr "mode" "DI")])

The "i" constraint should be "n" since symbolic constant is invalid for PIC
or PIE.

[Bug tree-optimization/94335] False positive -Wstringop-overflow warning with -O2

2020-05-20 Thread kal.conley at dectris dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335

kal.conley at dectris dot com changed:

   What|Removed |Added

 CC||kal.conley at dectris dot com

--- Comment #6 from kal.conley at dectris dot com ---
We are hitting this warning too with:

#include 
#include 

int main() {
std::vector inputs(2);
std::vector outputs{inputs.begin(), inputs.end()};
outputs.back() = 1;
return 0;
}

Regards,
Kal

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 20 May 2020, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218
> 
> Uroš Bizjak  changed:
> 
>What|Removed |Added
> 
>  CC||law at gcc dot gnu.org,
>||rsandifo at gcc dot gnu.org
> 
> --- Comment #9 from Uroš Bizjak  ---
> (In reply to Uroš Bizjak from comment #7)
> > Ooh, yes :(
> > 
> > '(use X)'
> >  Represents the use of the value of X.  It indicates that the value
> >  in X at this point in the program is needed, even though it may not
> >  be apparent why this is so.  Therefore, the compiler will not
> >  attempt to delete previous instructions whose only effect is to
> >  store a value in X.  X must be a 'reg' expression.
> > 
> > Partial revert is in works.
> 
> Actually, no. The above applies to single (use ...) RTX, not (use ...) as part
> of a parallel. There are plenty of uses of memory_operands in i386.md:
> 
> (define_insn "fix_truncdi_i387"
>   [(set (match_operand:DI 0 "nonimmediate_operand" "=m")
> (fix:DI (match_operand 1 "register_operand" "f")))
>(use (match_operand:HI 2 "memory_operand" "m"))
>(use (match_operand:HI 3 "memory_operand" "m"))
>(clobber (match_scratch:XF 4 "="))]
> 
> Let's ask experts.

The question is what should the (use ...) do?  Allow the splitter
to use its contents?  I guess that's reasonable interpretation
though I thought (use ...) apply only to register liveness computation
and not to memory.  But what do I know about RTL ;)

[Bug target/95237] New: LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237

Bug ID: 95237
   Summary: LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL
gcc.target/i386/pr69454-2.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The testcase and a few others now ICEs on x86_64 with -m32 since
LOCAL_DECL_ALIGNMENT with -mpreferred-stack-boundary=2 shrinks alignment
of 'long long' from 8 to 4.

/home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c: In
function 'fn1':^M
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr69454-2.c:7:6:
internal compiler error: in execute, at adjust-alignment.c:73^M
0x216245b execute^M
../../src/trunk/gcc/adjust-alignment.c:73^M
Please submit a full bug report,^M

this was a latent wrong-code bug before if you consider

typedef __UINTPTR_TYPE__ uintptr_t;
void __attribute__((noipa)) foo (long long *p, uintptr_t a)
{
  if ((uintptr_t)p & (a-1))
__builtin_abort ();
}
int main()
{
  long long x;
  uintptr_t a = __alignof__(x);
  foo(, a);
  return 0;
}

and the frame of main not being aligned to 8 bytes.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #7)
> Ooh, yes :(
> 
> '(use X)'
>  Represents the use of the value of X.  It indicates that the value
>  in X at this point in the program is needed, even though it may not
>  be apparent why this is so.  Therefore, the compiler will not
>  attempt to delete previous instructions whose only effect is to
>  store a value in X.  X must be a 'reg' expression.
> 
> Partial revert is in works.

Actually, no. The above applies to single (use ...) RTX, not (use ...) as part
of a parallel. There are plenty of uses of memory_operands in i386.md:

(define_insn "fix_truncdi_i387"
  [(set (match_operand:DI 0 "nonimmediate_operand" "=m")
(fix:DI (match_operand 1 "register_operand" "f")))
   (use (match_operand:HI 2 "memory_operand" "m"))
   (use (match_operand:HI 3 "memory_operand" "m"))
   (clobber (match_scratch:XF 4 "="))]

Let's ask experts.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #8 from Martin Liška  ---
There's partially reduced test-case:

$ cat fma.i

double res_test0101[] = {
-3,1, 17,51,109,   197,   321,   487,   701,   969,  1297,
1691,  2157,  2701,  3329,  4047,  4861,  5777,  6801,  7939,  9197, 10581,
12097, 13751, 15549, 17497, 19601, 21867, 24301, 26909, 29697, 32671};
double res_test0110[] = {3,  -1, -17,-51,-109,   -197,   -321,
 -487,   -701,   -969,   -1297,  -1691,  -2157,  -2701,
 -3329,  -4047,  -4861,  -5777,  -6801,  -7939,  -9197,
 -10581, -12097, -13751, -15549, -17497, -19601,
-21867,
 -24301, -26909, -29697, -32671};
extern void abort() __attribute__(()) __attribute__(());
static __inline int __get_cpuid(unsigned int __leaf, unsigned int *__eax,
unsigned int *__ebx, unsigned int *__ecx,
unsigned int *__edx) {
  __asm__("cpuid\n\t"
  : "=a"(*__eax), "=b"(*__ebx), "=c"(*__ecx), "=d"(*__edx)
  : "0"(__leaf));
}
static void fma_test();
int main() {
  unsigned int eax, ebx, ecx, edx;
  if (!__get_cpuid(1, , , , )) 0;
  if (ecx & (1 << 12)) fma_test();

  return 0;
}
double m1[] = {1,  2,  3,  4,  5,  6,  7,  8,  9,  10, 11, 12, 13, 14, 15, 16,
   17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32};
double m2[] = {2,  3,  4,  5,  6,  7,  8,  9,  10, 11, 12, 13, 14, 15, 16, 17,
   18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33};
double m3[] = {3,  4,  5,  6,  7,  8,  9,  10, 11, 12, 13, 14, 15, 16, 17, 18,
   19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34};
double m4[32];
int test_fails = 0;
void compare_result(double *res) {
  int i;
  int good = 1;
  i = 0;
  for (i; i < 32; i++)
if (m4[i] != res[i])
  if (good) good = 0;
  if (!good) test_fails = 1;
}
static void fma_test() {
  double __trans_tmp_3;
  double __trans_tmp_2;
  double __trans_tmp_1;
  int i;
  for (i = 0; i < 32; i++) m4[i] = 0;
  i = 0;
  for (i; i < 32; i++) {
double a = m1[i];
double b = m2[i];
double c = m3[i];
__trans_tmp_1 = ((a * b) - c) * a - b;

m4[i] = __trans_tmp_1;
  }
  compare_result(res_test0101);
  i = 0;
  for (i; i < 32; i++) {
{
  double a = m1[i];
  double b = m2[i];
  double c = m3[i];

  __trans_tmp_3 = -((a * b) - c) * a + b;
}

m4[i] = __trans_tmp_3;
  }
  compare_result(res_test0110);
  i = 0;
  for (i; i < 32; i++) {
double a = m1[i];
double b = m2[i];
double c = m3[i];
__trans_tmp_2 = -((a * b) - c) * a - b;

m4[i] = __trans_tmp_2;
  }
  if (test_fails) abort();
}

$ gcc -O3 -Wno-attributes -mfpmath=sse -mfma fma.i  && ./a.out 
Aborted (core dumped)

[Bug target/95229] [11 Regression] in mark_jump_label_1

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> Built by
> 
> #5  0x020c4504 in gen_rtx_fmt_ee_stat (code=VEC_SELECT, 
> mode=E_V2SImode, arg0=0x0, arg1=0x76ad92e0) at ./genrtl.h:49
> #6  0x0211e242 in gen_sse4_1_zero_extendv2siv2di2 (
> operand0=0x76ada4f8, operand1=0x0) at insn-emit.c:40857
> #7  0x02207aa7 in gen_zero_extendv2siv2di2 (operand0=0x76ada4f8, 
> operand1=0x76ada4c8) at ../../src/trunk/gcc/config/i386/sse.md:18012
> #8  0x010cfe31 in insn_gen_fn::operator() (
> this=0x3230928 , a0=0x76ada4f8, a1=0x76ada4c8)
> at ../../src/trunk/gcc/recog.h:317
> #9  0x014aed21 in maybe_gen_insn
> (icode=CODE_FOR_zero_extendv2siv2di2, 
> nops=2, ops=0x7fffa8d0) at ../../src/trunk/gcc/optabs.c:7444
> #10 0x014a3c7d in maybe_emit_unop_insn (
> icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8, 
> --Type  for more, q to quit, c to continue without paging--
> op0=0x76ada4c8, code=ZERO_EXTEND) at
> ../../src/trunk/gcc/optabs.c:3597
> #11 0x014a3d7f in emit_unop_insn
> (icode=CODE_FOR_zero_extendv2siv2di2, 
> target=0x76ada4f8, op0=0x76ada4c8, code=ZERO_EXTEND)
> at ../../src/trunk/gcc/optabs.c:3621
> #12 0x01098d45 in convert_move (to=0x76ada4f8, 
> from=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:260
> #13 0x0109bc1e in convert_modes (mode=E_V2DImode,
> oldmode=E_V2SImode, 
> x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:737
> #14 0x0109b220 in convert_to_mode (mode=E_V2DImode,
> x=0x76ada4c8, 
> unsignedp=1) at ../../src/trunk/gcc/expr.c:662
> #15 0x010bae75 in expand_expr_real_2 (ops=0x7fffb600,
> target=0x0, 
> tmode=E_VOIDmode, modifier=EXPAND_NORMAL)
> at ../../src/trunk/gcc/expr.c:8665
> 
> frame #7 looks OK while #6 is bogus.  Context:
> 
> 18009 if (!MEM_P (operands[1]))
> 18010   {
> 18011 operands[1] = simplify_subreg (V4SImode, operands[1],
> V2SImode, 0);
> 18012 emit_insn (gen_sse4_1_v2siv2di2 (operands[0],
> operands[1]));
> 18013 DONE;
> 
> simplify_subreg returns NULL.  It is originally (reg:V2SI 90 [ vect__2.8 ]).
> Should that be simplify_gen_subreg?

That fixes the testcase.  But simplify_subreg is used in a lot more places
so leaving to Uros to match up with expectations.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
Ooh, yes :(

'(use X)'
 Represents the use of the value of X.  It indicates that the value
 in X at this point in the program is needed, even though it may not
 be apparent why this is so.  Therefore, the compiler will not
 attempt to delete previous instructions whose only effect is to
 store a value in X.  X must be a 'reg' expression.

Partial revert is in works.

[Bug target/95229] [11 Regression] in mark_jump_label_1

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229

--- Comment #5 from Richard Biener  ---
Built by

#5  0x020c4504 in gen_rtx_fmt_ee_stat (code=VEC_SELECT, 
mode=E_V2SImode, arg0=0x0, arg1=0x76ad92e0) at ./genrtl.h:49
#6  0x0211e242 in gen_sse4_1_zero_extendv2siv2di2 (
operand0=0x76ada4f8, operand1=0x0) at insn-emit.c:40857
#7  0x02207aa7 in gen_zero_extendv2siv2di2 (operand0=0x76ada4f8, 
operand1=0x76ada4c8) at ../../src/trunk/gcc/config/i386/sse.md:18012
#8  0x010cfe31 in insn_gen_fn::operator() (
this=0x3230928 , a0=0x76ada4f8, a1=0x76ada4c8)
at ../../src/trunk/gcc/recog.h:317
#9  0x014aed21 in maybe_gen_insn (icode=CODE_FOR_zero_extendv2siv2di2, 
nops=2, ops=0x7fffa8d0) at ../../src/trunk/gcc/optabs.c:7444
#10 0x014a3c7d in maybe_emit_unop_insn (
icode=CODE_FOR_zero_extendv2siv2di2, target=0x76ada4f8, 
--Type  for more, q to quit, c to continue without paging--
op0=0x76ada4c8, code=ZERO_EXTEND) at ../../src/trunk/gcc/optabs.c:3597
#11 0x014a3d7f in emit_unop_insn (icode=CODE_FOR_zero_extendv2siv2di2, 
target=0x76ada4f8, op0=0x76ada4c8, code=ZERO_EXTEND)
at ../../src/trunk/gcc/optabs.c:3621
#12 0x01098d45 in convert_move (to=0x76ada4f8, 
from=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:260
#13 0x0109bc1e in convert_modes (mode=E_V2DImode, oldmode=E_V2SImode, 
x=0x76ada4c8, unsignedp=1) at ../../src/trunk/gcc/expr.c:737
#14 0x0109b220 in convert_to_mode (mode=E_V2DImode, x=0x76ada4c8, 
unsignedp=1) at ../../src/trunk/gcc/expr.c:662
#15 0x010bae75 in expand_expr_real_2 (ops=0x7fffb600, target=0x0, 
tmode=E_VOIDmode, modifier=EXPAND_NORMAL)
at ../../src/trunk/gcc/expr.c:8665

frame #7 looks OK while #6 is bogus.  Context:

18009 if (!MEM_P (operands[1]))
18010   {
18011 operands[1] = simplify_subreg (V4SImode, operands[1], V2SImode,
0);
18012 emit_insn (gen_sse4_1_v2siv2di2 (operands[0],
operands[1]));
18013 DONE;

simplify_subreg returns NULL.  It is originally (reg:V2SI 90 [ vect__2.8 ]).
Should that be simplify_gen_subreg?

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #6 from Uroš Bizjak  ---
I think I found the issue.

Before the patch, we had:

(insn 375 373 2574 7 (parallel [
(set (reg:V4DF 21 xmm1 [orig:1681 vect__45.441 ] [1681])
(neg:V4DF (mem/c:V4DF (plus:DI (reg/f:DI 7 sp)
(const_int 160 [0xa0])) [3 %sfp+-1184 S32 A256])))
(use (reg:V4DF 20 xmm0 [3332]))
]) "fma_1.h":20:10 1487 {*negv4df2}
 (nil))

after the patch, reload is free to create:

(insn 375 3216 2578 7 (parallel [
(set (reg:V4DF 21 xmm1 [orig:1681 vect__45.441 ] [1681])
(neg:V4DF (reg:V4DF 20 xmm0 [3332])))
(use (mem/c:V4DF (plus:DI (reg/f:DI 7 sp)
(const_int 160 [0xa0])) [3 %sfp+-1184 S32 A256]))
]) "fma_1.h":20:10 1487 {*negv4df2}
 (nil))

which postreload pass does not like, and simply deletes it:

deleting insn with uid = 375.

Just like that. No substitution whatsoever.

So, is there some limitation with (use) RTX, so we can't have memory here?

[Bug target/95229] [11 Regression] in mark_jump_label_1

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95229

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*
 CC||uros at gcc dot gnu.org
  Component|middle-end  |target

--- Comment #4 from Richard Biener  ---
Program received signal SIGSEGV, Segmentation fault.
0x013747bd in mark_jump_label_1 (x=0x0, insn=0x76ac8b80, 
in_mem=false, is_target=false) at ../../src/trunk/gcc/jump.c:1087
1087  RTX_CODE code = GET_CODE (x);
(gdb) p debug_rtx (insn)
(insn 9 8 10 2 (set (reg:V2DI 91 [ vect__3.9 ])
(zero_extend:V2DI (vec_select:V2SI (nil)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
] "z.c":15:12 -1
 (nil))


the vec_select has a NULL operand somehow.  We're expanding from

  vect__3.9_16 = (vector(2) long unsigned int) vect__2.8_15;

so likely Uros change or it triggers a bogus expand helper or forwprop
does not properly constrain itself.  I'll debug a bit.

[Bug target/95219] [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95219

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

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

commit r11-519-gb2f26af32b5b031fce761aa090de9476a53e6e5a
Author: Richard Biener 
Date:   Wed May 20 09:22:58 2020 +0200

tree-optimization/95219 - improve IV selection for induction

This improves code generation with SSE2 for the testcase by
making sure to only generate a single IV when the group size
is a multiple of the vector size.  It also adjusts the testcase
which was passing before.

2020-05-20  Richard Biener  

PR tree-optimization/95219
* tree-vect-loop.c (vectorizable_induction): Reduce
group_size before computing the number of required IVs.

* gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c: Adjust.

[Bug target/95219] [11 Regression] FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-pr30843.c

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95219

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug demangler/85304] Segmentation fault

2020-05-20 Thread trupti_pardeshi at persistent dot co.in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304

Trupti Pardeshi  changed:

   What|Removed |Added

 CC||trupti_pardeshi@persistent.
   ||co.in

--- Comment #3 from Trupti Pardeshi  
---
Hi,

May I know whether this bug is fixed? And if fixed, in which version of
binutils this fix has gone?

Any heads up will be appreciated.

Thanks in advance.

Best Regards,

[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231

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

https://gcc.gnu.org/g:130bb4c79295487c5fc203103d80e3b754640eb4

commit r11-518-g130bb4c79295487c5fc203103d80e3b754640eb4
Author: Richard Biener 
Date:   Wed May 20 11:00:57 2020 +0200

middle-end/95231 - revert parts of PR95171

I mistook the opportunity to also "fix" the [VEC_]COND_EXPR case
for PR95171 but I was wrong in that it doesn't need the fix and
in the actual fix as well.  The following just reverts that part.

2020-05-20  Richard Biener  

PR middle-end/95231
* tree-inline.c (remap_gimple_stmt): Revert adjusting
COND_EXPR and VEC_COND_EXPR for a -fnon-call-exception boundary.

* g++.dg/other/pr95231.C: New testcase.

[Bug tree-optimization/95231] [11 Regression] error: the first argument of a ‘vec_cond_expr’ must be of a boolean vector type of the since r11-451-gfe168751c5c1c517

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171
Bug 95171 depends on bug 95231, which changed state.

Bug 95231 Summary: [11 Regression] error: the first argument of a 
‘vec_cond_expr’ must be of a boolean vector type of the since 
r11-451-gfe168751c5c1c517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95231

   What|Removed |Added

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

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

2020-05-20 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #15 from Iain Sandoe  ---
(In reply to Martin Liška from comment #14)
> The original problem:
> 
> test.cc:3749:5: runtime error: member call on misaligned address
> 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment
> 0x41b58ab3: note: pointer points here
> 
> 
> @Iain: How do you allocate the awaiter object?

The coro frame is laid out according to the types determined for the objects it
contains (the awaiter types are known at the point it's laid out).

It just uses the 'normal' struct building rules.

Awaiters are most often initialised from return values from some promise
method, but they can also be local vars or parms - perhaps I slipped up there.

I have a thought that I might be failing to copy across excess alignment
applied (which I will look at later).

^^^ these are things on my TO-LOOK-AT list.

> 
> @Rafael: Can you please append output with:
> export UBSAN_OPTIONS="print_stacktrace=1"

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #5 from Martin Liška  ---
Sure, doing that.

[Bug libgcc/91695] [X86] get_available_features only sets FEATURE_GFNI and FEATURE_VPCLMULQDQ when avx512_usable is true

2020-05-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91695

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

https://gcc.gnu.org/g:1e46a443f25d26816536c0c480211714b123a1d5

commit r11-516-g1e46a443f25d26816536c0c480211714b123a1d5
Author: H.J. Lu 
Date:   Tue May 19 18:55:08 2020 -0700

x86: Update VPCLMULQDQ check

Update VPCLMULQDQ check to support processors with AVX version of
VPCLMULQDQ.

PR target/91695
* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
check.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

--- Comment #4 from Uroš Bizjak  ---
(In reply to Martin Liška from comment #3)
> Started with r11-455-g94f687bd9ae37ece.

It is not obvious from the referred patch what is going wrong here.

Unfortunately, I have no FMA capable machine, can someone please isolate one
small test that fails?

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

2020-05-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #14 from Martin Liška  ---
The original problem:

test.cc:3749:5: runtime error: member call on misaligned address 0x41b58ab3
for type 'struct awaiter', which requires 8 byte alignment
0x41b58ab3: note: pointer points here


@Iain: How do you allocate the awaiter object?

@Rafael: Can you please append output with:
export UBSAN_OPTIONS="print_stacktrace=1"

[Bug middle-end/95208] missed switch optimization as bit test

2020-05-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95208

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Looking at the dump files, we select a jump table:

switch (c_2(D))  [67.00%], case 33 ... 35:  [33.00%], case
37 ... 39:  [33.00%], case 42 ... 63:  [33.00%], case 65 ... 91: 
[33.00%], case 93 ... 95:  [33.00%], case 97 ... 126:  [33.00%]>

;; GIMPLE switch case clusters: JT(values:88 comparisons:12 range:94 density:
12.77%):33-126 

We prefer a smaller number of clusters (in this case) one because we don't have
to build a decision tree on top of them. In this case one can't handle all in
of bit test as the range of values is >= 64.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

2020-05-20 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #13 from Iain Sandoe  ---
Created attachment 48572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48572=edit
fix for most of the UBSAN fails

Most of the UBSAN fails are from a single cause; I reused the built DTOR tree
on both resume and destroy edges from the await.

There is a single remaining UBSAN fail (which is unrelated).

I don't expect this to make any difference to the initial reported fail.

[Bug middle-end/95236] New: OMP 'GOMP_MAP_STRUCT': a structure is more than the sum of all its fields?

2020-05-20 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95236

Bug ID: 95236
   Summary: OMP 'GOMP_MAP_STRUCT': a structure is more than the
sum of all its fields?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48571=edit
'itu_.c'

..., and the answer (technically) may easily be "yes", considering ABI-mandated
padding, for example.

But: is that user friendly?  Consider the test case I'm attaching, where
'struct s' consists of fields 'a', 'b', which both get mapped -- yet, 's'
itself isn't considered to be.  At the user level, should a structure equal the
sum of all its fields, or "do we have to be complicated"?

I have not fully thought that through, just noticed this when looking into
something else.  I also have not verified OpenMP behavior.

[Bug fortran/95214] ICE on assumed-rank character array with select rank

2020-05-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95214

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-20
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r10-2912-g70570ec192745095, it was rejected before the revision.

[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece

2020-05-20 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
Summary|[11 Regression] FAIL:   |[11 Regression] FAIL:
   |gcc.target/i386/fma_run_dou |gcc.target/i386/fma_run_dou
   |ble_1.c execution test  |ble_1.c execution test
   ||since
   ||r11-455-g94f687bd9ae37ece

--- Comment #3 from Martin Liška  ---
Started with r11-455-g94f687bd9ae37ece.

[Bug target/95234] [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95234

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #2 from Richard Biener  ---
Maybe related to the recent avx_fma testsuite fails?  (anyone bisected those?)

[Bug target/95235] Failure to properly optimize out register use in bit-twiddling code

2020-05-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95235

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
That's indeed odd.

  1   2   >