[Bug libstdc++/71090] #include cannot locate math.h

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
If you mess with the order of system header directories then you mess up how
headers are found. So don't do that.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to Oleg Endo from comment #5)
> PR 67731 maybe related or dup?

Related but not a dup. This bug is caused by frontend folding two bitfield
accesses to a single comparison which prevented generation of bit test later in
tree-opt.

[Bug libstdc++/71090] #include cannot locate math.h

[sebastian.bw at freenet dot de]

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

bastl73  changed:

   What|Removed |Added

 CC||sebastian.bw at freenet dot de

--- Comment #5 from bastl73  ---
I had the same error with gcc-6.3 and it seems to be

#include_nextfails

#includeworks

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Bill Schmidt from comment #4)
> Created attachment 40568 [details]
> Proposed patch
> 
> Attaching proposed patch.  Iain, would you be able to test this on Darwin
> 32- and 64-bit and see whether it makes sense?

On darwin (powerpc-darwin9, trunk 244915) the patch flips the fail from m32 ->
m64.  I.E. without the patch m64 passes and m32 fails; with the patch, the
inverse.

I haven't built powerpc64-darwin9 in quite a while, so no comment there.

Apologies, but will have defer analysis for a while.

[Bug c/79266] excessive compile time for large static array (-O1)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
There might be a dup of this bug just filed a few days ago and that was marked
as a dup too.

[Bug c/79266] excessive compile time for large static array (-O1)

[josh at joshtriplett dot org]

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

--- Comment #1 from Josh Triplett  ---
Following up: it looks like gcc -O1 does eventually complete, after several
minutes.  -O3 is still running.

[Bug c/79266] New: excessive compile time for large static array (-O1)

[josh at joshtriplett dot org]

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

Bug ID: 79266
   Summary: excessive compile time for large static array (-O1)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josh at joshtriplett dot org
  Target Milestone: ---

Consider the following test case:

int main(int argc, char *argv[]) {
char *array[] = {
#include "num_array.h"
argv[0],
};
int sum = 0;
for (int i = 0; i < sizeof(array)/sizeof(*array); i++) {
sum += __builtin_strlen(array[i]);
}
return sum;
}

Where num_array.h gets generated as follows:

seq 1 25 | sed 's/.*/"&",/' > num_array.h

When compiled without optimization, it compiles without issue:

/tmp$ time gcc test.c -o test

real0m6.563s
user0m6.288s
sys 0m0.264s
/tmp$ ./test

However, turning on even -O1 causes gcc to run for a long time with no signs of
stopping.

[Bug sanitizer/79265] New: -fsanitize=undefined inserts unnecessary null pointer tests

[msebor at gcc dot gnu.org]

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

Bug ID: 79265
   Summary: -fsanitize=undefined inserts unnecessary null pointer
tests
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
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
  Target Milestone: ---

UBSan inserts a null pointer test for each pointer argument to a function whose
corresponding formal argument is declared attribute nonnull.  That makes sense
except for expressions that are known/guaranteed no to be null, such as arrays,
VLAs, or pointers obtained from calls to GCC built-in functions
known/guaranteed not to return null such as alloca.  I'm inclined to suggest
it's also unnecessary for ordinary (non-builtin) functions declared with
attribute returns_nonnull since those, too, guarantee not to return a null
pointer, but since possible for such a function to break that guarantee there
may be some value in UBSan emitting tests for those (unless those tests are or
can be defeated by subsequent optimization passes).  While some of these
redundant test are removed by subsequent optimizations they tend to interfere
with them and lead to suboptimal code (as discussed in bug 79257), and can
trigger warnings.

The following test case shows the unnecessary tests. 

$ cat b.c && gcc -O2 -c -Wall -fdump-tree-ubsan=/dev/stdout
-fsanitize=undefined b.c
void* __attribute__ ((alloc_size (1), returns_nonnull))
myalloc (unsigned);

void sink (void*);

void f0 (void)
{
  char a[4];
  __builtin_sprintf (a, "%%");
  sink (a);
}

void f1 (unsigned n)
{
  char a[n];
  __builtin_sprintf (a, "%%");
  sink (a);
}

void f2 (unsigned n)
{
  void *p = __builtin_alloca (n);
  __builtin_sprintf (p, "%%");
  sink (p);
}

void f3 (unsigned n)
{
  void *p = myalloc(n);
  __builtin_sprintf (p, "%%");
  sink (p);
}


;; Function f0 (f0, funcdef_no=0, decl_uid=2121, cgraph_uid=0, symbol_order=0)

Introduced new external node (__builtin___ubsan_handle_nonnull_arg/15).

Symbols to be put in SSA form
{ D.2162 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 7
Number of blocks to update: 6 ( 86%)


f0 ()
{
  char a[4];

   [0.00%]:
  if ( == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data1);

   [0.00%]:
  if ("%%" == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);

   [0.00%]:
  __builtin_sprintf (, "%%");
  sink ();
  a ={v} {CLOBBER};
  return;

}



;; Function f1 (f1, funcdef_no=1, decl_uid=2125, cgraph_uid=1, symbol_order=3)


Symbols to be put in SSA form
{ D.2173 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 9
Number of blocks to update: 8 ( 89%)


f1 (unsigned int n)
{
  char[0:D.2155] * a.2;
  sizetype D.2155;
  unsigned long _1;
  long int _2;
  long int _3;
  bitsizetype _5;
  void * saved_stack.5_6;
  bitsizetype _8;
  char[0:D.2155] * a.3_11;
  char[0:D.2155] * a.4_12;
  unsigned int n.0_13;
  unsigned int n.1_15;
  bitsizetype _17;
  sizetype _18;
  bitsizetype _19;
  sizetype _20;

   [0.00%]:
  saved_stack.5_6 = __builtin_stack_save ();
  n.0_13 = n_4(D);
  if (n.0_13 == 0)
goto ; [0.00%]
  else
goto ; [0.00%]

   [0.00%]:
  _1 = (unsigned long) n.0_13;
  __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, _1);

   [0.00%]:
  n.1_15 = n.0_13;
  _2 = (long int) n.1_15;
  _3 = UBSAN_CHECK_SUB (_2, 1);
  _16 = (sizetype) _3;
  _5 = (bitsizetype) n.1_15;
  _17 = _5 * 8;
  _18 = (sizetype) n.1_15;
  _8 = (bitsizetype) n.1_15;
  _19 = _8 * 8;
  _20 = (sizetype) n.1_15;
  a.2_22 = __builtin_alloca_with_align (_20, 8);
  a.3_11 = a.2_22;
  if (a.3_11 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data3);

   [0.00%]:
  if ("%%" == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data4);

   [0.00%]:
  __builtin_sprintf (a.3_11, "%%");
  a.4_12 = a.2_22;
  sink (a.4_12);
  __builtin_stack_restore (saved_stack.5_6);
  return;

}



;; Function f2 (f2, funcdef_no=2, decl_uid=2142, cgraph_uid=2, symbol_order=4)


Symbols to be put in SSA form
{ D.2184 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 7
Number of blocks to update: 6 ( 86%)


f2 (unsigned int n)
{
  void * p;
  long unsigned int _1;

   [0.00%]:
  _1 = (long unsigned int) n_2(D);
  p_5 = __builtin_alloca (_1);
  if (p_5 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data5);

   [0.00%]:
  if ("%%" == 0B)
goto ; [0.04%]
  else
goto ; 

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
One thing I noticed that suggests another possible (and, IMO, the ideal for
this specific case) solution: the warning goes away and GCC emits far better
code when the controlling expression of the loop is (i != 2) as opposed to (i <
2).  Contrast the optimal code emitted for foo() below to that for bar():

$ cat c.c && gcc -O2 -c -Wall -fdump-tree-optimized=/dev/stdout
-fsanitize=undefined c.c

void a (void);

char buffer[2];

void foo (void)
{
  for (int i = 0; i != 2; i++)
{
  if (i == 0)
a ();
  __builtin_sprintf (buffer, "%d", i);
}
}

void bar (void)
{
  for (int i = 0; i < 2; i++)
{
  if (i == 0)
a ();
  __builtin_sprintf (buffer, "%d", i);
}
}


;; Function foo (foo, funcdef_no=0, decl_uid=2120, cgraph_uid=0,
symbol_order=1)

foo ()
{
   [28.07%]:
  a ();
  __builtin_sprintf (, "%d", 0);
  __builtin_sprintf (, "%d", 1); [tail call]
  return;

}


c.c: In function ‘bar’:
c.c:21:35: warning: ‘%d’ directive writing between 1 and 10 bytes into a region
of size 2 [-Wformat-overflow=]
   __builtin_sprintf (buffer, "%d", i);
   ^~
c.c:21:34: note: directive argument in the range [0, 2147483646]
   __builtin_sprintf (buffer, "%d", i);
  ^~~~
c.c:21:7: note: ‘__builtin_sprintf’ output between 2 and 11 bytes into a
destination of size 2
   __builtin_sprintf (buffer, "%d", i);
   ^~~

;; Function bar (bar, funcdef_no=1, decl_uid=2127, cgraph_uid=1,
symbol_order=2)

Removing basic block 8
bar ()
{
  unsigned long ivtmp.7;
  int i;
  unsigned int _1;
  int _8;
  unsigned int _10;

   [15.00%]:
  goto ; [100.00%]

   [70.00%]:
  ivtmp.7_7 = ivtmp.7_3 + 1;

   [85.00%]:
  # ivtmp.7_3 = PHI 
  i_13 = (int) ivtmp.7_3;
  if (i_13 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [28.05%]:
  a ();
  __builtin_sprintf (, "%d", 0);
  goto ; [100.00%]

   [56.95%]:
  __builtin_sprintf (, "%d", i_13);
  _1 = (unsigned int) ivtmp.7_3;
  _10 = _1 + 1;
  _8 = (int) _10;
  if (_8 <= 1)
goto ; [73.66%]
  else
goto ; [26.34%]

   [15.00%]:
  return;
}

[Bug c++/79264] New: ICE verify_type failed

[guille at berkeley dot edu]

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

Bug ID: 79264
   Summary: ICE verify_type failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at berkeley dot edu
  Target Milestone: ---

The following code ICEs on:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/7.0.1/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 7.0.1 20170122 (experimental) (GCC)

Compiled with:
c++ test.c  -std=c++1z -fconcepts -g3

*NOTE*: when removing '-g3' it no longer ICEs. 


Code has been simplified as much as possible. Note: removing the 'std::decay_t'
gives a "silent" ICE notification ("t.c:48:1: internal compiler error:
Segmentation fault: 11").



#include 


template  struct Wrapper
{
C c_;

template  struct signature_imp
{};

template  struct signature_imp
{
template  using arg_t = std::tuple_element_t;
};

template  struct signature : public
signature_imp
{};

template  requires std::is_same_v> auto call(const F& f)
{
return f(c_);
}
};


struct A
{
Wrapper w_;

template  void g(auto)
{
}

public:
void f()
{
w_.call([&] (auto&)
{
g ([] (auto) {});
});
}
};


int main()
{
return 0;
}


Output:
---

$ c++ t.c  -std=c++1z -fconcepts -g3
t.c:48:1: error: type variant has different TYPE_FIELDS
 }
 ^
 
constant 8>
unit size 
constant 1>
align 8 symtab 51474176 alias set -1 canonical type 0x10328ef18
fields 
readonly unsigned type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x10328e9d8>
used decl_7 VOID file t.c line 39 col 4
align 1 offset_align 1 context 
chain 
nonlocal decl_4 VOID file t.c line 37 col 13
align 1 context  result

   >> context 
full-name "struct A::f()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
t.c:48:1: error: first mismatch is field
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x10328ef18 fields
 context 
full-name "struct A::f()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
chain >
nonlocal decl_4 VOID file t.c line 37 col 13
align 1 context 
result  unit size 
align 8 symtab 51474176 alias set -1 canonical type 0x10328ef18
fields 
used decl_7 VOID file t.c line 39 col 4
align 1 offset_align 1 context 
chain > context 
full-name "struct A::f()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
   >
t.c:48:1: error: and field
 
unit size 
align 32 symtab 51473376 alias set -1 canonical type 0x103289e70
fields  context 
full-name "struct A"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  chain >
readonly unsigned type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x10328e9d8>
used decl_7 VOID file t.c line 39 col 4
align 1 offset_align 1 context  chain
>
 
constant 8>
unit size 
constant 1>
align 8 symtab 56696416 alias set -1 canonical type 0x103292150
fields  unit size 
align 8 symtab 0 alias set -1 canonical type 0x10328ef18 fields
 context 
full-name "struct A::f()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
chain >
nonlocal decl_4 VOID file t.c line 37 col 13
align 1 context 
result  unit size 
align 8 symtab 51474176 alias set -1 canonical type 0x10328ef18
fields  context 
full-name "struct A::f()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  chain >
   > context 
full-name "const struct A::f()::"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this  reference_to_this
>
t.c:48:1: internal compiler error: verify_type failed

t.c:48:1: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[vehre at gcc dot gnu.org]

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

--- Comment #18 from vehre at gcc dot gnu.org ---
Correct me when I am wrong, but should the pointer component really be
finalized automatically? I am in the opinion that pointer components are not
finalized automatically. That is one of the significant differences to
allocatable components. I am thinking about a single linked list, where one
does:

type link
  type(link), pointer :: next
  class(*) :: data
end type

Grant me the above to be pseudo-fortran to just explain the concept.

Now, when I want to delete only the first item of the list and have:

type (link), pointer :: head
type (link), pointer :: newhead => head%next

deallocate(head) ! This one would deallocate the whole list, when finalization
is done!

So I first need to do: 

head%next => NULL
deallocate(head)

which for a pointer is IMHO not the intention of the standard. When I like to
have managed memory with full automatic free, then one should have chosen
allocatable, or am I totally misunderstanding Fortran?

[Bug testsuite/70583] [6/7 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #12 from John David Anglin  ---
Fixed.

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-28
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
A few more comments:

1) moving the gimple-ssa-sprintf pass after vrp2 suppresses just one of the two
warnings (the argument in the second call to sprintf is still in the same
range)
2) it's not the null pointer sanitizer that's causing the warnings but rather
the integer overflow sanitizer
3) the warnings don't seem related to r244974 (i.e., the range of the argument
is the same and the same warnings are still issued)
4) similar warnings are issued prior to the recent changes committed to resolve
bug 78703 so it's not a recent change or regression
5) the warning is issued on the basis that the range of the argument values is
a subrange of its type (as opposed to one whose value is completely unbounded,
such a function argument); i.e., an attempt has been made to constrain the
argument, presumably to make it fit in the buffer, but the attempt doesn't go
far enough

It's worth noting that this problem isn't specific to the -Wformat-overflow
warning.  It affects all get_range_info clients outside VRP that use the upper
bound of the range (I think that's just -Walloca-larger-than in GCC 7, but the
list is likely to grow in the future).

Ideally, the range info would be as accurate outside VRP as within it.  Barring
that, the range info consumers might need to be more closely integrated with
the VRP pass in some way as Richard suggests.

I'm not sure what's the appropriate solution for GCC 7.  Relaxing the logic in
the -Wformat-{overflow,truncation} checker to avoid this instance of the
warning will cause false negatives and won't do anything for the other
warning(s).  Disabling the warning altogether when -fsanitize=undefined is
specified also doesn't seem like a good fix.

I would tend to defer the decision until more code has been exposed to the
warning (the Fedora mass rebuild).  If this turns out to be a pervasive problem
it's easy to implement one of the changes above.  It it's rare living with it
would seem like an acceptable tradeoff.  In GCC 8 I'd like to look into
improving the warning to avoid this case as well as a number of others we know
about.

[Bug testsuite/70583] [6/7 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #11 from John David Anglin  ---
Author: danglin
Date: Sat Jan 28 18:08:22 2017
New Revision: 245008

URL: https://gcc.gnu.org/viewcvs?rev=245008=gcc=rev
Log:
PR testsuite/70583
* g++.old-deja/g++.abi/vtable2.C: Adjust CMP_VPTR define on hppa.


Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[vehre at gcc dot gnu.org]

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

--- Comment #17 from vehre at gcc dot gnu.org ---
Ok, being the offender I tried to have a look into as soon as possible.

[Bug testsuite/70583] [6/7 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
Author: danglin
Date: Sat Jan 28 18:01:22 2017
New Revision: 245007

URL: https://gcc.gnu.org/viewcvs?rev=245007=gcc=rev
Log:
PR testsuite/70583
* g++.old-deja/g++.abi/vtable2.C: Adjust CMP_VPTR define on hppa.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C

[Bug rtl-optimization/79263] New: Several tests introduced in r244878 fail with -m32

[dominiq at lps dot ens.fr]

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

Bug ID: 79263
   Summary: Several tests introduced in r244878 fail with -m32
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The following tests introduced in r244878 fail with -m32 (see also
https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02413.html)

FAIL: gcc.dg/rtl/x86_64/dfinit.c execution test
FAIL: gcc.dg/rtl/x86_64/final.c (internal compiler error)
FAIL: gcc.dg/rtl/x86_64/final.c (test for excess errors)
FAIL: gcc.dg/rtl/x86_64/final.c 1 blank line(s) in output
FAIL: gcc.dg/rtl/x86_64/final.c scan-assembler .cfi_endproc
FAIL: gcc.dg/rtl/x86_64/final.c scan-assembler .cfi_startproc
FAIL: gcc.dg/rtl/x86_64/final.c scan-assembler ret
FAIL: gcc.dg/rtl/x86_64/into-cfglayout.c execution test
FAIL: gcc.dg/rtl/x86_64/ira.c execution test
FAIL: gcc.dg/rtl/x86_64/times-two.c.after-expand.c execution test
FAIL: gcc.dg/rtl/x86_64/vregs.c execution test

The ICE is

/opt/gcc/work/gcc/testsuite/gcc.dg/rtl/x86_64/final.c:124:1: error:
unrecognizable insn:
(insn/f 32 6 33 2 (set (mem:DI (pre_dec:DI (reg/f:SI 7 sp)) [0  S8 A8])
(reg/f:SI 6 bp)) -1
 (nil))
/opt/gcc/work/gcc/testsuite/gcc.dg/rtl/x86_64/final.c:124:1: internal compiler
error: in extract_insn, at recog.c:2311

On x86_64-apple-darwin16 I also see the following ICE with -m64

FAIL: gcc.dg/rtl/x86_64/final.c (internal compiler error)
FAIL: gcc.dg/rtl/x86_64/final.c (test for excess errors)
FAIL: gcc.dg/rtl/x86_64/final.c 1 blank line(s) in output
FAIL: gcc.dg/rtl/x86_64/final.c scan-assembler .cfi_endproc
FAIL: gcc.dg/rtl/x86_64/final.c scan-assembler .cfi_startproc

/opt/gcc/work/gcc/testsuite/gcc.dg/rtl/x86_64/final.c:124:1: internal compiler
error: Segmentation fault: 11

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

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Between revisions r244915 and r244957 I got the following XPASS

I have forgotten to say that it is on x86_64-apple-darwin16.

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

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
Between revisions r244915 and r244957 I got the following XPASS

XPASS: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not pop
XPASS: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not push
XPASS: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-times
addl\\t%[re]?dx, %[re]?ax 1
XPASS: gcc.target/i386/fuse-caller-save.c scan-assembler-not pop
XPASS: gcc.target/i386/fuse-caller-save.c scan-assembler-not push
XPASS: gcc.target/i386/fuse-caller-save.c scan-assembler-times
addl\\t%[re]?d[ix], %[re]?ax 1

[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #3)
> Have you raised this with compiler-rt upstream already?

I don't believe that upstream supports the sanitisers for Darwin < 11.

However, as seen, they are quite capable of function with a little TLC.  I
don't have a chance to progress this until at least mid-Feb, if it's more
urgent, then (a) please adopt some version of the patch locally, or (b) disable
for Darwin < 11.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
> r243479 shows no runtime error, r243480 does.

The dump with r243479 is identical to 6.2. So r243480 does actually improve the
situation, but fails to handle class components properly.

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[aldyh at gcc dot gnu.org]

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

--- Comment #9 from Aldy Hernandez  ---
Created attachment 40613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40613=edit
preprocessed testcase for reproducing on ppc64 and aarch64

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez  ---
FYI, on aarch64, the problem can be reproduced with:

./cc1 -quiet -I./ a.c -O3 -ffast-math -mcpu=cortex-a53

on ppc64 with:

./cc1 -quiet -I./ a.c -O3 -ffast-math

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #7 from Aldy Hernandez  ---
On both aarch64 and ppc64, this starts happening after scheduling changes:

commit 08993ad1c669cab64baf352f79cd7f8584dd8e0c
Author: jgreenhalgh 
Date:   Thu Oct 1 09:33:40 2015 +

[Patch 2/2 ARM/AArch64] Add a new Cortex-A53 scheduling model

* config/arm/aarch-common-protos.h
(aarch_accumulator_forwarding): New.
(aarch_forward_to_shift_is_not_shifted_reg): Likewise.
* config/arm/aarch-common.c (aarch_accumulator_forwarding): New.
(aarch_forward_to_shift_is_not_shifted_reg): Liekwise.
* config/arm/cortex-a53.md: Rewrite.

and

commit 5379d8d457b300219d3d8eda38caaa9916f98078   
Author: dje 
Date:   Mon Jan 19 18:33:24 2015 + 
   
  * config/rs6000/default64.h: Include rs6000-cpus.def.
 (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8).   
(TARGET_DEFAULT) [BIG_ENDIAN]: Use POWER4. 
   * config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7  
  and POWER8.  
 * config/rs6000/linux64.h (PROCESSOR_DEFAULT64): Always default to
POWER8.
   * config/rs6000/rs6000.c (rs6000_file_start): Emit .machine 
  pseudo-op to specify assembler dialect.

There is further analysis by James on bz#77468.

On arm-eabi -mhard-float I was not able to reproduce, so perhaps we could
remove the arm-*-* target, and just leave aarch64.

Note, the speculative execution of sqrt on both aarch64 and ppc64 happens in
the sched1 rtl pass.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to janus from comment #14)
> > r243480:
> > 2016-12-09  Andre Vehreschild  
> > 
> > * trans-array.c (gfc_array_deallocate): Remove wrapper.
> > (gfc_trans_dealloc_allocated): Same.
> > (structure_alloc_comps): Restructure deallocation of (nested)
> > allocatable components.  Insert dealloc of sub-component into the block
> > guarded by the if != NULL for the component.
> > (gfc_trans_deferred_array): Use the almightly deallocate_with_status.
> > * trans-array.h: Remove prototypes.
> > * trans-expr.c (gfc_conv_procedure_call): Use the almighty deallocate_
> > with_status.
> > * trans-openmp.c (gfc_walk_alloc_comps): Likewise.
> > (gfc_omp_clause_assign_op): Likewise.
> > (gfc_omp_clause_dtor): Likewise.
> > * trans-stmt.c (gfc_trans_deallocate): Likewise.
> > * trans.c (gfc_deallocate_with_status): Allow deallocation of scalar
> > and arrays as well as coarrays.
> > (gfc_deallocate_scalar_with_status): Get the data member for coarrays
> > only when freeing an array with descriptor.  And set correct caf_mode
> > when freeing components of coarrays.
> > * trans.h: Change prototype of gfc_deallocate_with_status to allow
> > adding statements into the block guarded by the if (pointer != 0) and
> > supply a coarray handle.
> 
> Unfortunately this patch does not reverse-apply cleanly any more.

... so I quickly went back to the old versions of the repo and found:

r243479 shows no runtime error, r243480 does.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to janus from comment #12)
> r243483:
> 2016-12-09  Janus Weil  
> 
>   PR fortran/61767
>   * class.c (has_finalizer_component): Fix this function to detect only
>   non-pointer non-allocatable components which have a finalizer.

I just tried reverting this commit, which did not help.


> r243480:
> 2016-12-09  Andre Vehreschild  
> 
>   * trans-array.c (gfc_array_deallocate): Remove wrapper.
>   (gfc_trans_dealloc_allocated): Same.
>   (structure_alloc_comps): Restructure deallocation of (nested)
>   allocatable components.  Insert dealloc of sub-component into the block
>   guarded by the if != NULL for the component.
>   (gfc_trans_deferred_array): Use the almightly deallocate_with_status.
>   * trans-array.h: Remove prototypes.
>   * trans-expr.c (gfc_conv_procedure_call): Use the almighty deallocate_
>   with_status.
>   * trans-openmp.c (gfc_walk_alloc_comps): Likewise.
>   (gfc_omp_clause_assign_op): Likewise.
>   (gfc_omp_clause_dtor): Likewise.
>   * trans-stmt.c (gfc_trans_deallocate): Likewise.
>   * trans.c (gfc_deallocate_with_status): Allow deallocation of scalar
>   and arrays as well as coarrays.
>   (gfc_deallocate_scalar_with_status): Get the data member for coarrays
>   only when freeing an array with descriptor.  And set correct caf_mode
>   when freeing components of coarrays.
>   * trans.h: Change prototype of gfc_deallocate_with_status to allow
>   adding statements into the block guarded by the if (pointer != 0) and
>   supply a coarray handle.

Unfortunately this patch does not reverse-apply cleanly any more.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> The problem seems located to the file evaluators_uti.f90 and occurred
> between revisions  r243430 (2016-12-08, OK) and r243621 (2016-12-13, 
> segfault).

Could it be r243483 (pr61767)?

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> The problem seems located to the file evaluators_uti.f90 and occurred
> between revisions  r243430 (2016-12-08, OK) and r243621 (2016-12-13,
> segfault).

Looking at the ChangeLog, I see two entries in this range that sound like they
could be related:


r243483:
2016-12-09  Janus Weil  

PR fortran/61767
* class.c (has_finalizer_component): Fix this function to detect only
non-pointer non-allocatable components which have a finalizer.


r243480:
2016-12-09  Andre Vehreschild  

* trans-array.c (gfc_array_deallocate): Remove wrapper.
(gfc_trans_dealloc_allocated): Same.
(structure_alloc_comps): Restructure deallocation of (nested)
allocatable components.  Insert dealloc of sub-component into the block
guarded by the if != NULL for the component.
(gfc_trans_deferred_array): Use the almightly deallocate_with_status.
* trans-array.h: Remove prototypes.
* trans-expr.c (gfc_conv_procedure_call): Use the almighty deallocate_
with_status.
* trans-openmp.c (gfc_walk_alloc_comps): Likewise.
(gfc_omp_clause_assign_op): Likewise.
(gfc_omp_clause_dtor): Likewise.
* trans-stmt.c (gfc_trans_deallocate): Likewise.
* trans.c (gfc_deallocate_with_status): Allow deallocation of scalar
and arrays as well as coarrays.
(gfc_deallocate_scalar_with_status): Get the data member for coarrays
only when freeing an array with descriptor.  And set correct caf_mode
when freeing components of coarrays.
* trans.h: Change prototype of gfc_deallocate_with_status to allow
adding statements into the block guarded by the if (pointer != 0) and
supply a coarray handle.


I need to take a closer look to see which of those two (if any) is the culprit.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter  ---
(In reply to janus from comment #7)
> (In reply to Jürgen Reuter from comment #5)
> > Here is the promised reduced test case, 80 lines, and I do believe that this
> > is most likely causing the issues of all our 250 failing tests (hopefully).
> > Attached and plain:
> 
> I'm afraid this example is invalid, because it accesses element 7 of an
> array with size 1, so the runtime error ("free(): invalid pointer") is
> probably correct, even though it does not appear with gfortran 6.2.
> 

Sorry for screwing up the reduced case. Glad that you were able to fix that one
into a sensible test case. I think Dominique d'Humieres already managed to
narrow down when this regression was introduced, see Comment#3.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Another variant, which removes the naming collision (and dimension
> attribute) in the character components, in order to make things clearer:
> 
> 
> program main_ut
>   implicit none
> 
>   type :: data_t
>  character, allocatable :: c1
>   end type
> 
>   type :: t1_t
>  character, allocatable :: c2
>  class(data_t), pointer :: width_data
>   end type
> 
>   call evaluator
> 
> contains
> 
>   subroutine evaluator
> type(data_t), target :: par_real
> type(t1_t) :: field
> field%width_data => par_real
>   end subroutine
> 
> end


With version 6.2, the dump for this case looks like:

evaluator ()
{
  struct t1_t field;
  struct data_t par_real;

  try
{
  field.c2 = 0B;
  par_real.c1 = 0B;
  (struct __vtype_main_ut_Data_t *) field.width_data._vptr =
&__vtab_main_ut_Data_t;
  field.width_data._data = _real;
}
  finally
{
  if (par_real.c1 != 0B)
{
  __builtin_free ((void *) par_real.c1);
}
  par_real.c1 = 0B;
  if (field.c2 != 0B)
{
  __builtin_free ((void *) field.c2);
}
  field.c2 = 0B;
}
}


I.e. any deallocation/finalization code for the width_data case is missing,
which is a potential memory leak.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Or maybe we should rather call the finalization wrapper for the type
> 'data_t'

That's also what's happening to 'par_real' in the following case:


  subroutine evaluator
class(data_t), allocatable, target :: par_real
type(t1_t) :: field
field%width_data => par_real
  end subroutine


as seen in the dump:

  if (par_real._data != 0B)
{
  if (par_real._vptr->_final != 0B)
{
  {
struct array0_data_t desc.6;

desc.6.dtype = 552;
desc.6.data = (void * restrict) par_real._data;
par_real._vptr->_final (, par_real._vptr->_size, 0);
  }
}
  __builtin_free ((void *) par_real._data);
}

So, yes, that's the way to go also for the 'width_data' component.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Another variant, which removes the naming collision (and dimension attribute)
in the character components, in order to make things clearer:


program main_ut
  implicit none

  type :: data_t
 character, allocatable :: c1
  end type

  type :: t1_t
 character, allocatable :: c2
 class(data_t), pointer :: width_data
  end type

  call evaluator

contains

  subroutine evaluator
type(data_t), target :: par_real
type(t1_t) :: field
field%width_data => par_real
  end subroutine

end


The dump of the 'evaluator' function looks like this:


evaluator ()
{
  struct t1_t field;
  struct data_t par_real;

  try
{
  field.c2 = 0B;
  par_real.c1 = 0B;
  field.width_data._vptr = (struct __vtype_main_ut_Data_t * {ref-all})
&__vtab_main_ut_Data_t;
  field.width_data._data = _real;
}
  finally
{
  if (par_real.c1 != 0B)
{
  __builtin_free ((void *) par_real.c1);
  par_real.c1 = 0B;
}
  if (field.c2 != 0B)
{
  __builtin_free ((void *) field.c2);
  field.c2 = 0B;
}
  if (field.width_data.c1 != 0B)
{
  __builtin_free ((void *) field.width_data.c1);
  field.width_data.c1 = 0B;
}
}
}


What is wrong here is the very last part, I think:

  if (field.width_data.c1 != 0B)
{
  __builtin_free ((void *) field.width_data.c1);
  field.width_data.c1 = 0B;
}

It seems that 'width_data' is missing a _data reference in all three cases.
Also the 'if'-condition is missing a check for that '_data' component being
non-null, I guess.

Or maybe we should rather call the finalization wrapper for the type 'data_t',
which is being built here anyway and would also take care of freeing up 'c1'.

[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||6.2.0
Summary|[7 Regression] Run time |[7 Regression] [OOP] Run
   |error: malloc on valid code |time error: double free or
   ||corruption
  Known to fail||7.0

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #5)
> Here is the promised reduced test case, 80 lines, and I do believe that this
> is most likely causing the issues of all our 250 failing tests (hopefully).
> Attached and plain:

I'm afraid this example is invalid, because it accesses element 7 of an array
with size 1, so the runtime error ("free(): invalid pointer") is probably
correct, even though it does not appear with gfortran 6.2.

However, when fixing that (i.e. turning the '7' into a '1'), the runtime error
turns into:

Error in `./a.out': double free or corruption (fasttop): 0x02168ff0 ***


Here is a further reduced test case for that error:

program main_ut
  implicit none

  type :: data_t
 character, dimension(:), allocatable :: name
  end type

  type :: t1_t
 character, dimension(:), allocatable :: name
 class(data_t), pointer :: width_data
  end type

  call evaluator

contains

  subroutine evaluator
type(data_t), target :: par_real
type(t1_t) :: field
field%width_data => par_real
  end subroutine

end


As with the previous case, there is no runtime error with gfortran 6.2, so it's
a regression.

[Bug tree-optimization/79262] [6/7 Regression] load gap with store gap causing performance regression in 462.libquantum

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 40612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40612=edit
The vector cost model improvement for ThunderX2 CN99xx

This changes the vector cost model to be more correct for thunderx2t99.  I did
not touch other cores, but a similar cost model should be done for at least
thunderx, a53 and a72 (and maybe others too; those are the ones I know of
currently; generic most likely should be changed because all of the current set
of cores I know of have different ratios [the only one which I did not look
into is the qualcomm core]).  Mainly because scalar/vect cost ratio is
different for int and fp.
Note I also improved one case in the vector code so it would pass the stmt_info
that it had for that statement.

[Bug tree-optimization/18438] vectorizer failed for vector matrix multiplication

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski  ---
(In reply to Maxim Kuvyrkov from comment #12) 
> You are making an orthogonal point to this bug report: whether or not to
> vectorize such a loop.  But if loop is vectorized, then on any
> microarchitecture it is better to have "st2" vs "umov; st1; str".

Yes but thinking about the problem some more I do think there are some vector
cost model issue in the aarch64 backend where we don't model int vs floating
point cost differences.  For an example ^ for scalar int might be one cycle but
vector it is 4 cycles but for floating point scalar addition, it is 4 cycles
while the floating point vector addition is just 4 cycles.
struct cpu_vector_cost
{
  const int scalar_stmt_cost;/* Cost of any scalar operation,
excluding load and store.  */
...

  const int vec_stmt_cost;   /* Cost of any vector operation,
excluding load, store, permute,
vector-to-scalar and
scalar-to-vector operation.  */


Anyways I filed PR 79262 for the regression.

[Bug tree-optimization/79262] [6/7 Regression] load gap with store gap causing performance regression in 462.libquantum

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.4

[Bug tree-optimization/79262] New: [6/7 Regression] load gap with store gap causing performance regression in 462.libquantum

[pinskia at gcc dot gnu.org]

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

Bug ID: 79262
   Summary: [6/7 Regression] load gap with store gap causing
performance regression in 462.libquantum
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---
Target: aarch64

As reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438#c9 but what
is not mentioned is that this is a regression from GCC 5.  I noticed this again
when I was working on improving ThunderX 2 CN99xx performance difference
between -O2 and -Ofast and GCC 5.4.0 and the trunk.

Take:
struct node_struct
{
  float _Complex gap;
  unsigned long long state;
};

struct reg_struct
{
  int size;
  struct node_struct *node;
};

void
func(int target, struct reg_struct *reg)
{
  int i;

  for(i=0; isize; i++)
reg->node[i].state ^= ((unsigned long long) 1 << target);
}
 CUT ---
Currently this is vectorized on the trunk using load gaps but then the store is
using scalars.  This is much slower and also it is only doing 2 at a time. 
There are some cost model issues in the aarch64 backend dealing with scalar for
int vs floating point too.  I might just go fix those first.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations