[Bug target/90552] attribute((optimize(3))) not overriding -Os

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #3 from Uroš Bizjak  ---
This happens due to the following TODO from i386-options.c:

  /* TODO: ix86_cost should be chosen at instruction or function granuality
 so for cold code we use size_cost even in !optimize_size compilation.  */
  if (opts->x_optimize_size)
ix86_cost = _size_cost;
  else
ix86_cost = ix86_tune_cost;

ix86_rtx_costs in i386.c is correctly called with speed=1, even when -Os is
used. However, -Os switches ix86_cost to ix86_size_cost so the following line
still returns ix86_size_cost:

  const struct processor_costs *cost = speed ? ix86_cost : _size_cost;

So, someone should comb through i386*.c files and fix up ix86_cost usage to
finally implement switching at insn/function "granuality" [sic]. Luckily, there
are not that many instances in the code.

[Bug c++/90592] New: Documentation: Missing word (or wrong parenthesization) in "Function Names as Strings"

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90592
   Summary: Documentation: Missing word (or wrong
parenthesization) in "Function Names as Strings"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

In "Function Names as Strings" (par. 6.50 in
) there's the following
text:

  As an extension, at file (or, in C++, namespace scope), __func__
  evaluates to the empty string.

Here, "at file" should be followed by the word "scope", so I suggest changing
the text to either

  - As an extension, at file (or, in C++, namespace) scope, __func__
evaluates to the empty string.

or

  - As an extension, at file scope (or, in C++, namespace scope), __func__
evaluates to the empty string.

[Bug tree-optimization/90591] New: Avoid unnecessary data transfer out of OMP construct

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90591
   Summary: Avoid unnecessary data transfer out of OMP construct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The reverse side of PR90573.  For (all too common!) code like:

int i;
#pragma acc kernels // implicit 'copy(i)', or 'copyout(i)' with PR90573
  {
for (i = 0; i < N; ++i)
  [...]
  }
#pragma acc kernels // implicit 'copy(i)', or 'copyout(i)' with PR90573
  {
for (i = N - 1; i >= 0; --i)
  [...]
  }
['i' never read here]

In addition that we can avoid unnecessary data transfer into each OMP construct
(PR90573), we also don't need to copy 'i' out in such scenarios, so can
optimize 'copy' to 'copyin', or 'copyout' to 'create'.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu.org]

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

--- Comment #40 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #39)
> (In reply to Richard Biener from comment #36)
> > Created attachment 46396 [details]
> > poor mans solution^Whack



> How does this work if op is a SSA_NAME?

it doens't, the patch has to be fixed to create a new def and adjust
all uses which isn't possible here (no immediate uses).

It's a proof-of-concept hack - the SSA name issue means we have to
find a better place for such hack.  Note I don't think we should
go with this kind of hack, iff, then we should at least not use
an ASM but some special __IFN and a more appropriate construct on
the RTL side (not sure what that would be).

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #40 from Jakub Jelinek  ---
I must say I don't like -fbroken-callers option name too much, can we use
instead something like -ftail-call-workaround={0,1,2} /
-f{,no-}tail-call-workaround
where -ftail-call-workaround == -ftail-call-workaround=1 would be the default
(for now) and enabled only if resolve_symbol finds FL_PROCEDURE if_source ==
IFSRC_UNKNOWN symbols (remembered in some gfc_ns member and set on containing
procedure, not say containing BLOCK), -fno-tail-call-workaround ==
-ftail-call-workaround=0 would disable this and -ftail-call-workaround=2 would
be enabled no matter whether there are any FL_PROCEDURE IFSRC_UNKNOWN symbols
or not?

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||9.1.0

--- Comment #22 from Richard Biener  ---
So this was fixed for GCC 9.  Both the GCC 8 and GCC 7 branches are still open
for wrong-code fixes, I'd appreciate at least providing "official" backports of
the fix even if we end up not committing them because for the fear of breakage.
You probably know best - was there any fallout of the two revs committed here
that needed to be fixed?

Thanks.

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[yangyibiao at nju dot edu.cn]

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

--- Comment #4 from Yibiao Yang  ---
(In reply to Jonathan Wakely from comment #3)
> Putting "[gdb]" in the bug summary suggests you're trying to report a GDB
> bug, which doesn't belong here.
> 
> You're trying to put a breakpoint on a line with no code, which won't work.
> Try breaking on line 12.

Thanks. 
Indeed, as you said, I would probably agree that this is a bug in gdb. In fact,
we can set breakpoint at the label statement (Line 13) as follows. The behavior
of gdb is correct in this case. Thus, this problem should not be caused by "a
line with no code".

$ cat small.c
#include 
int main()
{
  int i = 0;
  int j = 0;
  for (; i<=1; i++) {
for (; j<=1; j++) {
  goto lbl;
}
  }

  printf("hello\n");
lbl:  // line 13
  return 0;
}

[Bug target/85539] x86_64: loads are not always narrowed

[navyadeepika.garakapati at gmail dot com]

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

Navya  changed:

   What|Removed |Added

 CC||navyadeepika.garakapati@gma
   ||il.com

--- Comment #2 from Navya  ---
Testcase:
$cat test.c
int foo(long *p)
{
return *p;
}

$cat test.s
foo:
movq(%rdi), %rax
retq

While analysing it found that, in gcc trunck with -O0 optimization,

In ira pass, there is a conversion information from 64bit to 32bit 
subreg:SI (reg:DI 82 [ _1 ]) 0)): 

ira pass:

(insn 8 7 11 2 (set (reg:SI 83 [ _4 ])
(subreg:SI (reg:DI 82 [ _1 ]) 0)) "t.c":3:8 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg:DI 82 [ _1 ])
(nil)))

while reload pass is deleting this information and assigning 32bit to 32bit
i.e; SI to SI which results this as a dead code for the next pass and as a
result this insn 8 is getting deleted in next pass which is split2 pass.

reload pass:

(insn 8 7 15 2 (set (reg:SI 0 ax [orig:83 _4 ] [83])
(reg:SI 0 ax [orig:82 _1 ] [82])) "t.c":3:8 67 {*movsi_internal}
 (nil))

please let us know if there is any target hook being used, because of which the
conversion information from DI to SI is converted to SI to SI in reload pass.

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe  ---
Author: iains
Date: Thu May 23 09:23:47 2019
New Revision: 271544

URL: https://gcc.gnu.org/viewcvs?rev=271544=gcc=rev
Log:
x86, testsuite - update fuse-caller-save tests.

These tests had started to XPASS on pic targets where
the codegen is now as expected.

gcc/testsuite/

2019-05-23  Iain Sandoe  

PR rtl-optimisation/64895
* gcc.target/i386/fuse-caller-save-rec.c: Remove XFAILs.
* gcc.target/i386/fuse-caller-save.c: Likewise.
* gcc.target/i386/fuse-caller-save-xmm.c: Adjust tests for
PIC cases, remove XFAILs.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-rec.c
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save-xmm.c
trunk/gcc/testsuite/gcc.target/i386/fuse-caller-save.c

[Bug middle-end/88784] Middle end is missing some optimizations about unsigned

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Qi Feng from comment #9)
> And there's another problem. Take `x >  y  &&  x != 0   -->   x > y' for
> example, I would also like to do
> 
>x <  y  &&  y != 0  -->  x < y
>x != 0  &&  x >  y  -->  x > y
>y != 0  &&  x <  y  -->  x < y
> 
> If the constant always comes in as the second operand is incorrect, these
> would have to be doubled.
> 
> I tried to add :c to truth_andif, but got the `operation is not commutative'
> error.  I also tried to make truth_andif commutative by modifying
> genmatch.c, but again, I don't know it well, afraid that I would break
> something.
> 
> The patterns I wrote looks like:
> 
> /* x >  y  &&  x != 0 --> x > y
>Only for unsigned x and y.  */
> (simplify
>  (truth_andif:c (gt@2 @0 @1) (ne @0 integer_zerop))
>  (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@0))
>   && INTEGRAL_TYPE_P (TREE_TYPE(@1)) && TYPE_UNSIGNED
> (TREE_TYPE(@1)))
>@2))
> 
> I have to wrote 4 of this with minor modification for a single
> transformation. If there's better way to do it, please do leave a comment.

I think first of all you do _not_ want to use truth_andif since that
will only prevail iff x or y have side-effects.  To match on GIMPLE
you want bit_and instead/as well since all truth_ stuff doesn't prevail there.

And obviously truth_andif is _not_ commutative.  You can use :C if you
want to force it though.  Both truth_and and bit_and are commutative.
So sth like

(for and (truth_and bit_and)
 (for ltgtop (lt le)
  (simplify
   (and:c (ltgtop:c@2 @0 @1) (ne @0 integer_zerop))
   (if (...)
@2)))

should cover all of

   x <  y  &&  y != 0  -->  x < y
   x != 0  &&  x >  y  -->  x > y
   y != 0  &&  x <  y  -->  x < y
   x <  y  &&  y != 0  -->  x < y

note that from

(and (lt:c@2 @0 @1) (ne @0 integer_zerop))

we generate

(and (lt@2 @0 @1) (ne @0 integer_zerop))
(and (gt@2 @1 @0) (ne @0 integer_zerop))

so :c will ensure the semantically same operation will be present with
swapped operands.  As opposed to :C which would do lt@2 @1 @0.

[Bug c++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-23
  Component|libstdc++   |c++
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
In theory we could do this to avoid the warning:

--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -189,13 +189,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   operator^=(_Ios_Iostate& __a, _Ios_Iostate __b)
   { return __a = __a ^ __b; }

+  enum _Ios_Seekdir_range
+{
+  _S_ios_seekdir_beg_ = 0,
+  _S_ios_seekdir_end = 1L << 16
+};

-  enum _Ios_Seekdir 
+  enum _Ios_Seekdir : __underlying_type(_Ios_Seekdir_range)
 { 
   _S_beg = 0,
   _S_cur = _GLIBCXX_STDIO_SEEK_CUR,
-  _S_end = _GLIBCXX_STDIO_SEEK_END,
-  _S_ios_seekdir_end = 1L << 16 
+  _S_end = _GLIBCXX_STDIO_SEEK_END
 };


But giving the enum a fixed underlying type changes its semantics, as now any
value of the underlying type is a valid value of the enumeration type.

As I said in the Clang bug, I think a better approach would be to suppress the
warning for enumerators that are defined in system headers and that use
reserved names.

So I'm changing this to a compiler enhancement request, to suppress this
warning for cases like this.

[Bug libstdc++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a libstdc++ bug, we're allowed to define whatever enumerators we
> want as long as they use reserved names.

Which is almost exactly what I said in the Clang bug you linked to. Nice to
know I'm consistent.

[Bug libstdc++/90590] enumeration value not handled in switch warning for std::ios_base::seek_dir

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is not a libstdc++ bug, we're allowed to define whatever enumerators we
want as long as they use reserved names.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

--- Comment #4 from mccannd at uk dot ibm.com ---
I've not yet tried outside of a container.

I have a script that sets LD_PRELOAD so that I can detect problems in code I do
care about. It just so happens that this code calls ps, which then hung. I'm
concerned that it indicates a problem that will affect more than ps.

[Bug c++/90587] [10 Regression] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||vlad at ispras dot ru
  Known to work||9.1.0
Version|9.0 |10.0
   Target Milestone|--- |10.0
Summary|asan: stack-use-after-scope |[10 Regression] asan:
   |with -O3 and -Wall  |stack-use-after-scope with
   ||-O3 and -Wall
  Known to fail||10.0

--- Comment #5 from Martin Liška  ---
Started with r271460.

[Bug libstdc++/90590] New: enumeration value not handled in switch warning for std::ios_base::seek_dir

[alan at birtles dot org.uk]

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

Bug ID: 90590
   Summary: enumeration value not handled in switch warning for
std::ios_base::seek_dir
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alan at birtles dot org.uk
  Target Milestone: ---

GCC (and clang bug 67996) raises a warning when declaring a switch statement
which uses std::ios_base::seek_dir.

The following:

#include 

int main()
{
std::ios_base::seekdir dir = std::ios_base::end;
switch ( dir )
{
case std::ios_base::end:
case std::ios_base::beg:
case std::ios_base::cur:
break;
}
}

produces:
test.cpp: In function 'int main()':
test.cpp:6:12: warning: enumeration value '_S_ios_seekdir_end' not handled in
switch [-Wswitch]

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Do you have the same problem not in a container?
How useful is to use the LD_PRELOAD for the ps?

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

--- Comment #2 from mccannd at uk dot ibm.com ---
No, I've just installed the procps and libasan packages within my Fedora 30
container.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-23
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce on openSUSE Tumbleweed:

marxin@marxinbox:/tmp> LD_PRELOAD=/usr/lib64/libasan.so.5.0.0 ps
  PID TTY  TIME CMD
20622 pts/17   00:00:00 bash
26138 pts/17   00:00:00 ps
marxin@marxinbox:/tmp> LD_PRELOAD=/usr/lib64/libasan.so.4.0.0 ps
  PID TTY  TIME CMD
20622 pts/17   00:00:00 bash
26903 pts/17   00:00:00 ps

Do you have the 'ps' instrumented with ASAN?

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 Blocks||86656

--- Comment #4 from Martin Liška  ---
> 
> There's missing main function that will call the reduced test-case.

Ah, sorry, compiler should be executed. Let me take a look then..


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
[Bug 86656] Issues found with -fsanitize=address

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to David Binderman from comment #2)
> Here is the reduced C++ code:
> 
> typedef unsigned a;
> typedef char b;
> typedef struct {
>   a *c;
> } d;
> int e(d *f) {
>   if (f)
> return *f->c;
> }
> a g(d *f) { return e(f); }
> typedef struct {
>   b channel;
> } h;
> b *j(d *f, int channel, b *dest) {
>   int k = 80, i;
>   for (i = 0; i < 4; ++i, k = 1)
> if (channel & k)
>   dest[i] = g(f);
>   return dest;
> }
> void l(int, b *dest, b *m) {
>   int i;
>   for (i = 0; i < 4; ++i)
> dest[i] = m[i];
> }
> b n(d *f) {
>   for (;;) {
> h *o;
> b *dest;
> b p[4];
> if (j(f, o->channel, p))
>   l(o->channel, dest, p);
>   }
> }

There's missing main function that will call the reduced test-case.

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
So the problem can be reproduced when only factor.cc is compiled with -flto
-Os.
Problematic comparison is:


 for (pivot = temp.pivots.next; pivot != 
  pivot = pivot->next)
 {
eliminatePivot(pivot->idx, pivot->pos, eps );
 }
  }

I reduced that to problematic call to:
#0  aliasing_component_refs_p (ref1=0x773cd480, ref1_alias_set=15,
base1_alias_set=6, offset1=..., max_size1=..., ref2=0x77441030,
ref2_alias_set=15, base2_alias_set=13, offset2=..., max_size2=...,
ref2_is_decl=false)

true is returned for:

(gdb) p print_generic_expr (stderr, ref1, 0)
this_16(D)->temp.pivots.next$8 = void
(gdb) p print_generic_expr (stderr, ref2, 0)
_1090->next$9 = void

(gdb) p debug_tree(ref1)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 13 canonical-type
0x7758e888 fields  context 
pointer_to_this >
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 15 structural-equality
pointer_to_this  reference_to_this
>

arg:0 

arg:0 

arg:0 

arg:0 
visited var 
def_stmt GIMPLE_NOP
version:16
ptr-info 0x776c0eb8>
arg:1 > arg:1

factor.cc:1369:23 start: factor.cc:1369:23 finish:
factor.cc:1369:23>
arg:1 
nonlocal BLK clufactor.h:75:15 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset 
bit-offset  context
 chain >
factor.cc:1369:28 start: factor.cc:1369:28 finish: factor.cc:1369:28>
arg:1 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality reference_to_this >
unsigned nonlocal DI clufactor.h:53:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset  bit-offset  context 
chain 
unsigned nonlocal DI clufactor.h:54:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
factor.cc:1369:35 start: factor.cc:1369:35 finish: factor.cc:1369:35>

(gdb) p debug_tree(ref2)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 13 canonical-type
0x7758e888 fields  context 
pointer_to_this >
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 15 structural-equality
pointer_to_this  reference_to_this
>

arg:0 

arg:0 
visited
def_stmt _1090 = _1088->prev;
version:1090
ptr-info 0x775e6228>
arg:1 >
arg:1 
unsigned DI size  unit-size

align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality reference_to_this >
unsigned nonlocal DI clufactor.h:53:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
unsigned nonlocal DI clufactor.h:54:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset  bit-offset  context
 chain >>
factor.cc:1079:7 start: factor.cc:1079:7 finish: factor.cc:1079:7>

(gdb) p offset1
$12 = {
  > = {
coeffs = {3392}
  }, }
(gdb) p offset2
$13 = {
  > = {
coeffs = {0}
  }, }

(gdb) p max_size1
$14 = {
  > = {
coeffs = {64}
  }, }
(gdb) p max_size2
$15 = {
  > = {
coeffs = {64}
  }, }

I hope it will be enough information.
Honza?

[Bug sanitizer/90589] New: In Fedora 30 ps hangs using address sanitizer

[mccannd at uk dot ibm.com]

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

Bug ID: 90589
   Summary: In Fedora 30 ps hangs using address sanitizer
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mccannd at uk dot ibm.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I'm using Fedora 30 in a docker container running on a Ubuntu 16.04 or 18.04
host. The following command hangs:
LD_PRELOAD=/lib64/libasan.so.5.0.0 ps

The same commands works using Fedora 29.

If I take off the LD_PRELOAD, then the command completes successfully.

An strace always shows it in the following:
futex(0x7f19408a0be8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 2, NULL,
FUTEX_BITSET_MATCH_ANY

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|MOVED   |INVALID

--- Comment #3 from Jonathan Wakely  ---
Putting "[gdb]" in the bug summary suggests you're trying to report a GDB bug,
which doesn't belong here.

You're trying to put a breakpoint on a line with no code, which won't work. Try
breaking on line 12.

[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation

[tschwinge at gcc dot gnu.org]

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

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Thu May 23 08:22:56 2019
New Revision: 271540

URL: https://gcc.gnu.org/viewcvs?rev=271540=gcc=rev
Log:
[PR90510] Adjust 'brig.dg/test/gimple/packed.hsail'

... for r271463 "Fix PR90510, VEC_PERM -> BIT_INSERT folding".

gcc/testsuite/
PR middle-end/90510
* brig.dg/test/gimple/packed.hsail: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/brig.dg/test/gimple/packed.hsail

[Bug libgomp/90585] libgomp hsa plugin ftbfs in the x32 multilib variant

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 46400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46400=edit
gcc10-pr90585.patch

Untested fix.  Note, the rest of libgomp uses PRIu64 only conditionally on
HAVE_INTTYPES_H, so this patch does that too, but as it is in many spots, using
a typedef.

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Here is the reduced C++ code:

typedef unsigned a;
typedef char b;
typedef struct {
  a *c;
} d;
int e(d *f) {
  if (f)
return *f->c;
}
a g(d *f) { return e(f); }
typedef struct {
  b channel;
} h;
b *j(d *f, int channel, b *dest) {
  int k = 80, i;
  for (i = 0; i < 4; ++i, k = 1)
if (channel & k)
  dest[i] = g(f);
  return dest;
}
void l(int, b *dest, b *m) {
  int i;
  for (i = 0; i < 4; ++i)
dest[i] = m[i];
}
b n(d *f) {
  for (;;) {
h *o;
b *dest;
b p[4];
if (j(f, o->channel, p))
  l(o->channel, dest, p);
  }
}

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[yangyibiao at nju dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
(In reply to Jonathan Wakely from comment #1)
> GDB is a separate project with its own bugzilla, see
> https://sourceware.org/bugzilla

Thanks. 
I am not quite sure whether this is a bug of gdb or gcc. 
I am wondering that the problem is caused by wrong code generated by gcc.

[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The glibc change was https://sourceware.org/bugzilla/show_bug.cgi?id=21120 and
is present from version 2.26

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Jonathan Wakely  ---
GDB is a separate project with its own bugzilla, see
https://sourceware.org/bugzilla

[Bug c++/90415] [10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.3.0, 9.1.1
   Keywords||rejects-valid
   Last reconfirmed||2019-05-23
  Component|libstdc++   |c++
 CC|jason at redhat dot com|jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|std::is_copy_constructible< |[10 Regression]
   |std::tuple> is|std::is_copy_constructible<
   |incomplete  |std::tuple> is
   ||incomplete
  Known to fail||10.0

--- Comment #4 from Jonathan Wakely  ---
Thanks for the bisection.

Changing component to c++ for now, although it's possible a fix is needed in
the library.

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-23
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can confirm it. I'll reduce it down..

[Bug c++/90587] asan: stack-use-after-scope with -O3 and -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-23
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please test it with:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01559.html
?

[Bug sanitizer/90570] [9/10 Regression] AddressSanitizer: stack-use-after-scope

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01559.html

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
(In reply to Thomas Koenig from comment #22)
> I've been trying out some things, and I cannot construct a failing
> test case.
> 
> A sane way to build such an interface would be
> 
>  cat tst.f90
> module x
>   use, intrinsic :: iso_c_binding, only : c_double
>   implicit none
>   interface
>  subroutine foo(a) bind(c)
>import
>real(kind=c_double) :: a(*)
>  end subroutine foo
>   end interface
>   private
>   public :: bar
> 
> contains
>   subroutine bar(a)
> real(kind=c_double), dimension(:) :: a
> a = 42._c_double
> call foo(a)
>   end subroutine bar
> end module x
> 
> program main
>   use, intrinsic :: iso_c_binding, only : c_double
>   use x
>   implicit none
>   real(kind=c_double), dimension(1) :: a
>   call bar(a)
> end program main
> $ cat foo.c
> #include 
> 
> void foo (double *a)
> {
>   printf("%f\n", *a);
> }
> $ gfortran -flto -O tst.f90 foo.c
> $ ./a.out
> 42.00
> 
> This works as expected.
> 
> What I do not understand is (comment #17)
> 
> (gdb) p debug(fsym)
> || symbol: '_formal_107'  
>   type spec : (REAL 8)
>   attributes: (VARIABLE  DIMENSION DUMMY)
>   Array spec:(0 [0])
> 
> 
> This means that the dummy parameter has rank zero. How, then,
> is it possible to pass a rank-1 argument to it?
> 
> (gdb) p debug(expr)
> nf90_put_var_1d_eightbytereal:values(FULL) (REAL 8)
> 
> (gdb) p *expr->ref
> $8 = {
>   type = REF_ARRAY, 
>   u = {
> ar = {
>   type = AR_FULL, 
>   dimen = 1, 
>   codimen = 0, 
> 
> Something very fishy going on here.
> 
> Please look up the Fortran interface to the C function that is called,
> nc_put_vara_double.
> 
> Also, please break on gfc_conv_procedure_call for the call
> in question and do
> 
> $ call debug(sym)
> $ p args
> $ call debug(args->expr)
> $ p args->next
> $ call debug(args->next->expr)

(gdb) call debug(sym)
|| symbol: 'nf_put_vara_double' 
  type spec : (INTEGER 4)
  attributes: (PROCEDURE EXTERNAL-PROC IMPLICIT-SAVE EXTERNAL FUNCTION)
  result: nf_put_vara_double
  Formal arglist: _formal_103 _formal_104 _formal_105 _formal_106 _formal_107
(gdb) p args
$4 = (gfc_actual_arglist *) 0x2a766f0
(gdb) call debug(args->expr)
nf90_put_var_1d_eightbytereal:ncid (INTEGER 4)
(gdb) p args->next
$5 = (gfc_actual_arglist *) 0x2a72150
(gdb) call debug(args->next->expr)
nf90_put_var_1d_eightbytereal:varid (INTEGER 4)
(gdb) call debug(args->next->next->expr)
nf90_put_var_1d_eightbytereal:localstart(FULL) (INTEGER 4)
(gdb) call debug(args->next->next->next->expr)
nf90_put_var_1d_eightbytereal:localcount(FULL) (INTEGER 4)
(gdb) call debug(args->next->next->next->next->expr)
nf90_put_var_1d_eightbytereal:values(FULL) (REAL 8)

> 
> ... and so on, until args->...->next becomes a null pointer.
> 
> I am starting do suspect that this is, in fact, another piece of SPEC
> bugware where they made some sort of broken interface between C
> and Fortran, which is exposed by my patch.

That's likely :) Hope my remove gdb session helped.

> 
> Hmpf...

[Bug target/90588] New: [AArch64] SVE2 flag patch omits aarch64-protos.h

[p...@gcc-bugzilla.mail.kapsi.fi]

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

Bug ID: 90588
   Summary: [AArch64] SVE2 flag patch omits aarch64-protos.h
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

AArch64 SVE2 flag patch (commit 33af5a3270d6c9abaf5c05040a89e41130cbd5ca) does
not update `gcc/config/aarch64/aarch64-protos.h' (still uses unsigned long, not
uint64_t), leading to compile errors.  Maybe these changes are already done,
but weren't included in the commit by a mistake?

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
One another note is that the problematic code lives in src/netcdf/* and the
same code contain:
benchspec/CPU/521.wrf_r/src/netcdf/
and
benchspec/CPU/628.pop2_s/src/netcdf/

So that would explain also the segfault of the wrf benchmark.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Thomas Koenig from comment #21)
> OK, if the callee is a C function... what is its declaration
> on the Fortran side?  Is there any interface, bind(c) or otherwise?
> 
> I suppose there must be something, otherwise nf_put_vara_double would
> have a trailing underscore.
> 
> On the caller side, I see that an array is passed, but the fsym
> has rank=0.  I think this would be flagged otherwise.

So ncfortran.h contains:
#define nf_put_vara_double  nf_put_vara_double_

And Fortran interface is defined in netcdf/include/netcdf.inc:

  integer nf_put_vara_double
! (integer ncid,
!  integer varid,
!  integer start(1),
!  integer count(1),
!  doubleprecision dvals(1))
  externalnf_put_vara_double

[Bug c++/90587] New: asan: stack-use-after-scope with -O3 and -Wall

[dcb314 at hotmail dot com]

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

Bug ID: 90587
   Summary: asan: stack-use-after-scope with -O3 and -Wall
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 46399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46399=edit
C++ source code

The attached C++ code does this:

==7322==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffebf37620 at pc 0x0390b2ba bp 0x7fffebf373e0 sp 0x7fffebf373d8

when compiled like this:

$ /home/dcb/gcc/results.271500.asan/bin/gcc -O3 -Wall -std=c++11 bug522.cc

The bug seems to start sometime between revision 271200 and 271500.
I will post reduced C++ code when I get it.

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> for our kernel module we always pass option "-mlongcall" and  we believe
> that ,the asm thunk should generate the long call  here (through call r12 in
> this case)  and we can fix the compiler here to do so (more conservative and
> un-optimial for now).

There is no point in emitting an asm thunk if you use a long call though.

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[umesh.kalappa0 at gmail dot com]

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

--- Comment #11 from Umesh Kalappa  ---
Segher and Alan ,
for our kernel module we always pass option "-mlongcall" and  we believe that
,the asm thunk should generate the long call  here (through call r12 in this
case)  and we can fix the compiler here to do so (more conservative and
un-optimial for now).