[Bug middle-end/88273] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
The creduced file definitely does not represent at all the original file.

It is the second call to user_regset_copyin which is complaining.  Without
looking into the gimple dump, I think there is jump threading going on which
might cause this warning.

[Bug libgcc/88267] A new flag in GCC causes a divergence in crtbegin.o file

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
But it's hidden, so I'm not sure we care.  OTOH not sure why options.h is being
pulled in.

[Bug tree-optimization/88272] warning: iteration 9223372036854775807 invokes undefined behavior

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
Where do we set the cut-off? ;)

Btw, it's warning from do_warn_aggressive_loop_optimizations and:

  /* Only warn if undefined behavior gives us lower estimate than the
 known constant bound.  */
  || wi::cmpu (i_bound, wi::to_widest (loop->nb_iterations)) >= 0

that looks backwards?

[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|warning: 'memcpy' offset|[8/9 Regression] warning:
   |[-527, -529] is out of the  |'memcpy' offset [-527,
   |bounds [0, 16] of object|-529] is out of the bounds
   |'vrsave' with type 'union   |[0, 16] of object 'vrsave'
   |'|with type 'union
   |[-Warray-bounds]|'
   ||[-Warray-bounds]

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
-fstrict-enums.  By inspection ranges_from_anti_range falls foul of our
incomplete honoring of TYPE_MIN/MAX_VALUE.  Don't have a cross ready
to test the following patch but it looks "obvious" ...

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 266657)
+++ gcc/tree-vrp.c  (working copy)
@@ -1249,14 +1249,14 @@ ranges_from_anti_range (const value_rang
   || !vrp_val_max (type))
 return false;

-  if (!vrp_val_is_min (ar->min ()))
-*vr0 = value_range (VR_RANGE,
-   vrp_val_min (type),
-   wide_int_to_tree (type, wi::to_wide (ar->min ()) - 1));
-  if (!vrp_val_is_max (ar->max ()))
-*vr1 = value_range (VR_RANGE,
-   wide_int_to_tree (type, wi::to_wide (ar->max ()) + 1),
-   vrp_val_max (type));
+  if (tree_int_cst_lt (vrp_val_min (type), ar->min ()))
+vr0->set (VR_RANGE,
+ vrp_val_min (type),
+ wide_int_to_tree (type, wi::to_wide (ar->min ()) - 1));
+  if (tree_int_cst_lt (ar->max (), vrp_val_max (type)))
+vr1->set (VR_RANGE,
+ wide_int_to_tree (type, wi::to_wide (ar->max ()) + 1),
+ vrp_val_max (type));
   if (vr0->undefined_p ())
 {
   *vr0 = *vr1;

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
Indeed it fixes the issue at hand. I won't be able to perform full regtest
until the beginning of next week, though.

[Bug rtl-optimization/88275] New: Memory hog in selective scheduler

[asolokha at gmx dot com]

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

Bug ID: 88275
   Summary: Memory hog in selective scheduler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: memory-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu

gcc-9.0.0-alpha20181125 snapshot (r266441) exhibits high memory consumption
compiling gcc/testsuite/gcc.c-torture/compile/20001226-1.c w/ -O2
-fselective-scheduling -fno-code-hoisting -fno-sched-interblock
-fno-tree-dominator-opts -fno-tree-fre -fno-tree-pre.

 scheduling : 135.46 ( 93%)   3.52 ( 87%) 277.00 ( 93%)
1597632 kB ( 90%)

perf top:

  27.72%  cc1   [.] concat_INSN_LIST
  23.20%  cc1   [.] free_INSN_LIST_list
  13.51%  cc1   [.] alloc_INSN_LIST
  11.78%  cc1   [.] deps_join
  10.76%  cc1   [.] ggc_internal_alloc
   3.19%  cc1   [.] free_deps
   2.35%  libc-2.27.so  [.] memset
   2.31%  cc1   [.] gen_rtx_INSN_LIST
   1.84%  cc1   [.] rtx_alloc_stat_v
   0.70%  cc1   [.] rtx_alloc
   0.40%  cc1   [.] sd_find_dep_between_no_cache
   0.37%  cc1   [.] memset@plt
   0.22%  cc1   [.] sched_rgn_compute_dependencies
   0.18%  cc1   [.] sd_next_list
   0.15%  libc-2.27.so  [.] __libc_calloc
   0.11%  cc1   [.] check_dep
   0.11%  cc1   [.] bitmap_ior_into

The testcase takes much less memory when compiling for other targets or when
not using selective scheduling for the first scheduling pass.

[Bug c/88276] New: AVX512: reorder bit ops to get free and operation

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 88276
   Summary: AVX512: reorder bit ops to get free and operation
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

[code]
#include 
#include 

int test1(const __m128i* src, int mask)
{
__m128i v = _mm_load_si128(src);
int cmp = _mm_cmpeq_epi16_mask(v, _mm_setzero_si128());
return (cmp << 1) & mask;
}

int test2(const __m128i* src, int mask)
{
__m128i v = _mm_load_si128(src);
int cmp = _mm_cmpeq_epi16_mask(v, _mm_setzero_si128());
return (cmp & (mask >> 1)) << 1;
}
[/code]

test1() shifts result of _mm_cmpeq_epi16_mask() first, then and it with mask.
In test2() mask is shifted first, then and-ed with cmp result, and then shifted
again. In this case result of _mm_cmpeq_epi16_mask uses 8 bits only, so both
code versions are equivalent.

This compiles to following asm code, using gcc 8.2 with -O3
-march=skylake-avx512:

[asm]
test1(long long __vector(2) const*, int):
vpxor   xmm0, xmm0, xmm0
vpcmpeqwk1, xmm0, XMMWORD PTR [rdi]
kmovb   edx, k1
lea eax, [rdx+rdx]
and eax, esi
ret
test2(long long __vector(2) const*, int):
mov eax, esi
sar eax
vpxor   xmm0, xmm0, xmm0
kmovb   k2, eax
vpcmpeqwk1{k2}, xmm0, XMMWORD PTR [rdi]
kmovb   eax, k1
add eax, eax
ret
[/asm]

Such change may lead to more effective code, as with AVX512 this and op can be
merged into vpcmpeqw instruction. In my case this was part of bigger function
which was performing series of such calculations on array, and after this
change it started working faster.

[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector

[noloader at gmail dot com]

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

--- Comment #12 from Jeffrey Walton  ---
(In reply to Jakub Jelinek from comment #10)
> Author: jakub
> Date: Thu Nov 29 14:23:21 2018
> New Revision: 266619
> 
> URL: https://gcc.gnu.org/viewcvs?rev=266619&root=gcc&view=rev
> Log:
>   PR target/88234
>   * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): For
>   vec_add and vec_sub builtins, perform PLUS_EXPR or MINUS_EXPR
>   in unsigned_type_for instead of vector integral type where overflow
>   doesn't wrap.
> 
>   * gcc.dg/ubsan/pr88234.c: New test.
> ...

In case it is useful, here are some additional datapoints from the exyernal bug
report. It could help provide a little more coverage for the test case.

signed integer overflow: 127 + 1 cannot be represented in type 'signed char'

signed integer overflow: 7640891576939301132 + 5840696475078001361 cannot be
represented in type 'long int'
signed integer overflow: -4942790177534073029 + -7262195936335986787 cannot be
represented in type 'long int'
signed integer overflow: 6625583534739731862 + 7088136013498015297 cannot be
represented in type 'long int'
signed integer overflow: -5587509538033248007 + -3814479935187347353 cannot be
represented in type 'long int'
p

[Bug sanitizer/88277] New: ASAN stack poisoning is using unaligned stores on e.g. x86_64

[marxin at gcc dot gnu.org]

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

Bug ID: 88277
   Summary: ASAN stack poisoning is using unaligned stores on e.g.
x86_64
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin 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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Considering x86_64 and following example:

$ cat asan.c
void bar (void *a)
{
  int *p = a;
  *(p-1) = 123;
}


int
baz (void)
{
  char e2[56];
  bar (&e2[0]);
  return 0;
}

int *p;

int main()
{
  int a;
  p = &a;
  baz();
}

I see:

$ gcc asan.c  -fsanitize=address &&
ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out 
=
==21996==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x72d0009c at pc 0x00401195 bp 0x7fffda80 sp 0x7fffda78
WRITE of size 4 at 0x72d0009c thread T0
#0 0x401194 in bar (/home/marxin/Programming/testcases/a.out+0x401194)
#1 0x401227 in baz (/home/marxin/Programming/testcases/a.out+0x401227)
#2 0x401309 in main (/home/marxin/Programming/testcases/a.out+0x401309)
#3 0x76c71fea in __libc_start_main ../csu/libc-start.c:308
#4 0x401099 in _start (/home/marxin/Programming/testcases/a.out+0x401099)

Address 0x72d0009c is located in stack of thread T0 at offset 28 in frame
#0 0x4011ad in baz (/home/marxin/Programming/testcases/a.out+0x4011ad)

  This frame has 1 object(s):
[32, 88) 'e2' <== Memory access at offset 28 underflows this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
(/home/marxin/Programming/testcases/a.out+0x401194) in bar
Shadow bytes around the buggy address:
  0x10007e597fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e597fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e597fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e597ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e598000: f1 f1 f1 f1 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00
=>0x10007e598010: f1 f1 f1[f1]00 00 00 00 00 00 00 f2 f3 f3 f3 f3
  0x10007e598020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e598030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e598040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e598050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e598060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This is fine starting f3 at 0x10007e598010 line is aligned to 32B.

However:
$ gcc asan.c  -fsanitize=address &&
ASAN_OPTIONS=detect_stack_use_after_return=0 ./a.out 
=
==22038==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fffdadc at pc 0x00401195 bp 0x7fffda80 sp 0x7fffda78
WRITE of size 4 at 0x7fffdadc thread T0
#0 0x401194 in bar (/home/marxin/Programming/testcases/a.out+0x401194)
#1 0x401227 in baz (/home/marxin/Programming/testcases/a.out+0x401227)
#2 0x401309 in main (/home/marxin/Programming/testcases/a.out+0x401309)
#3 0x76c71fea in __libc_start_main ../csu/libc-start.c:308
#4 0x401099 in _start (/home/marxin/Programming/testcases/a.out+0x401099)

Address 0x7fffdadc is located in stack of thread T0 at offset 28 in frame
#0 0x4011ad in baz (/home/marxin/Programming/testcases/a.out+0x4011ad)

  This frame has 1 object(s):
[32, 88) 'e2' <== Memory access at offset 28 underflows this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
(/home/marxin/Programming/testcases/a.out+0x401194) in bar
Shadow bytes around the buggy address:
  0x10007fff7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7b50: 00 00 00 00 00 00 00 00 f1 f1 f1[f1]00 00 00 00
  0x10007fff7b60: 00 00 00 f2 f3 f3 f3 f3 00 00 00 00 00 00 f1 f1
  0x10007fff7b70: f1 f1 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00
  0x10007fff7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The first f3 byte is only aligned to 2B in shadow m

[Bug testsuite/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails when using --with-arch=...

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Instead of adding -march= please add instead say -mavx2 -mno-avx512f or
> whatever ISA set you want to pick, and probably also
> -mprefer-vector-width=256 or what you want.

I guess it might be a good idea to have different variants of the test case
that check the correct vector widths for AVX, AVX2, AVX512, etc. Of course one
would need to make sure that e.g. the AVX512 variant is only executed on AVX512
hardware (e.g. skylake CPU).

[Bug sanitizer/88277] ASAN stack poisoning is using unaligned stores on e.g. x86_64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Let me take it for next stage1.

[Bug target/87807] passing float/double vectors as variadic args fails on-64bit SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Eric Botcazou  ---
> Thanks for reporting the problem.

Great, thanks for the quick fix.

Rainer

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 30 10:37:39 2018
New Revision: 266659

URL: https://gcc.gnu.org/viewcvs?rev=266659&root=gcc&view=rev
Log:
2018-11-30  Richard Biener  

PR tree-optimization/88274
* tree-vrp.c (ranges_from_anti_range): Fix handling of
TYPE_MIN/MAX_VALUE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
With additional -mbranch-cost=1 the gimple dumps are identical on x86_64 with
-m32 until reassoc1, which decides differently for some reason - diff from
powerpc64 to x86_64:
-Optimizing range tests _7 -[3, 3] and -[5, 5]
- into (_7 + 4294967293 & 4294967293) != 0
-Rank for _38 is 458754
-Width = 1 was chosen for reassociation
-Width = 1 was chosen for reassociation
-Removing basic block 7
...

I guess one bug here is in reassoc pass, if we have these weird types that
don't have precision of the corresponding mode, we should have probably cast it
to some normal integral type before doing the + 429467293 etc. on it, that is
probably UB on such an IL.

The other issue is that the vrp code shouldn't ICE on code like:
  reload_type _7;
  reload_type _38;
  reload_type _39;

  _7 = MEM[base: _42, offset: 16B];
  _38 = _7 + 4294967293;
  _39 = _38 & 4294967293;
where reload_type is unsigned type with range [0, 15] and precision 4.
I haven't managed to create a testcase where it would trigger through invalid
code though so far.

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 30 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88274
> 
> --- Comment #5 from Jakub Jelinek  ---
> With additional -mbranch-cost=1 the gimple dumps are identical on x86_64 with
> -m32 until reassoc1, which decides differently for some reason - diff from
> powerpc64 to x86_64:
> -Optimizing range tests _7 -[3, 3] and -[5, 5]
> - into (_7 + 4294967293 & 4294967293) != 0
> -Rank for _38 is 458754
> -Width = 1 was chosen for reassociation
> -Width = 1 was chosen for reassociation
> -Removing basic block 7
> ...
> 
> I guess one bug here is in reassoc pass, if we have these weird types that
> don't have precision of the corresponding mode, we should have probably cast 
> it
> to some normal integral type before doing the + 429467293 etc. on it, that is
> probably UB on such an IL.
> 
> The other issue is that the vrp code shouldn't ICE on code like:
>   reload_type _7;
>   reload_type _38;
>   reload_type _39;
> 
>   _7 = MEM[base: _42, offset: 16B];
>   _38 = _7 + 4294967293;
>   _39 = _38 & 4294967293;
> where reload_type is unsigned type with range [0, 15] and precision 4.
> I haven't managed to create a testcase where it would trigger through invalid
> code though so far.

I think those min/max values not matching the precision are only an
optimization hint.  But yes, if a pass creates out-of-range values
then it has to use a different type for those.

Or we simply go away with honoring those hints in VRP at all...

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The regression started with r265241 BTW.

Here is a reassoc patch I wrote that also fixes this ICE:
--- gcc/tree-ssa-reassoc.c.jj   2018-10-23 10:13:25.278875175 +0200
+++ gcc/tree-ssa-reassoc.c  2018-11-30 11:13:37.232393154 +0100
@@ -2537,8 +2537,23 @@ optimize_range_tests_xor (enum tree_code
   if (!tree_int_cst_equal (lowxor, highxor))
 return false;

+  exp = rangei->exp;
+  scalar_int_mode mode = as_a  (TYPE_MODE (type));
+  int prec = GET_MODE_PRECISION (mode);
+  if (TYPE_PRECISION (type) < prec
+  || (wi::to_wide (TYPE_MIN_VALUE (type))
+ != wi::min_value (prec, TYPE_SIGN (type)))
+  || (wi::to_wide (TYPE_MAX_VALUE (type))
+ != wi::max_value (prec, TYPE_SIGN (type
+{
+  type = build_nonstandard_integer_type (prec, TYPE_UNSIGNED (type));
+  exp = fold_convert (type, exp);
+  lowxor = fold_convert (type, lowxor);
+  lowi = fold_convert (type, lowi);
+  highi = fold_convert (type, highi);
+}
   tem = fold_build1 (BIT_NOT_EXPR, type, lowxor);
-  exp = fold_build2 (BIT_AND_EXPR, type, rangei->exp, tem);
+  exp = fold_build2 (BIT_AND_EXPR, type, exp, tem);
   lowj = fold_build2 (BIT_AND_EXPR, type, lowi, tem);
   highj = fold_build2 (BIT_AND_EXPR, type, highi, tem);
   if (update_range_test (rangei, rangej, NULL, 1, opcode, ops, exp,
@@ -2581,7 +2596,16 @@ optimize_range_tests_diff (enum tree_cod
   if (!integer_pow2p (tem1))
 return false;

-  type = unsigned_type_for (type);
+  scalar_int_mode mode = as_a  (TYPE_MODE (type));
+  int prec = GET_MODE_PRECISION (mode);
+  if (TYPE_PRECISION (type) < prec
+  || (wi::to_wide (TYPE_MIN_VALUE (type))
+ != wi::min_value (prec, TYPE_SIGN (type)))
+  || (wi::to_wide (TYPE_MAX_VALUE (type))
+ != wi::max_value (prec, TYPE_SIGN (type
+type = build_nonstandard_integer_type (prec, 1);
+  else
+type = unsigned_type_for (type);
   tem1 = fold_convert (type, tem1);
   tem2 = fold_convert (type, tem2);
   lowi = fold_convert (type, lowi);

Do we want that too, or is the exact type in which we compute these
uninteresting?  Note, unfortunately in this case the enum type has
TYPE_PRECISION 32, just TYPE_MAX_VALUE of 15, and we consider such conversions
useless, so not really sure how can vrp work reliably with that.

[Bug testsuite/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails when using --with-arch=...

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed.

[Bug testsuite/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails when using --with-arch=...

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Nov 30 10:48:51 2018
New Revision: 20

URL: https://gcc.gnu.org/viewcvs?rev=20&root=gcc&view=rev
Log:
Restrict vector extension to use 128bit vectors (PR testsuite/88265).

2018-11-30  Martin Liska  

PR testsuite/88265
* gfortran.dg/simd-builtins-1.f90: Restrict to 128b vectors.
* gfortran.dg/simd-builtins-6.f90: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/simd-builtins-1.f90
trunk/gcc/testsuite/gfortran.dg/simd-builtins-6.f90

[Bug target/88278] New: Fails to elide zeroing of upper vector register

[rguenth at gcc dot gnu.org]

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

Bug ID: 88278
   Summary: Fails to elide zeroing of upper vector register
   Product: gcc
   Version: 9.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: ---

typedef unsigned char v16qi __attribute__((vector_size(16)));
typedef unsigned char v8qi __attribute__((vector_size(8)));

v16qi __GIMPLE foo (unsigned char *p)
{
  v8qi _2;
  v16qi _3;

bb_2:
  _2 = __MEM  (p_1(D));
  _3 = _Literal (v16qi) { _2, _Literal (v8qi) { _Literal (unsigned char) 0,
_Literal (unsigned char) 0, _Literal (unsigned char) 0, _Literal (unsigned
char) 0, _Literal (unsigned char) 0, _Literal (unsigned char) 0, _Literal
(unsigned char) 0 } };
  return _3;
}

and

typedef unsigned int v4si __attribute__((vector_size(16)));
typedef unsigned int v2si __attribute__((vector_size(8)));

v4si __GIMPLE bar (unsigned int *p)
{
  v2si _2;
  v4si _3;

bb_2:
  _2 = __MEM  (p_1(D));
  _3 = _Literal (v4si) { _2, _Literal (v2si) { 0u, 0u } };
  return _3;
}

show that trying to code a movq (%rax), %xmm0 fails and we end up with

movq(%rdi), %xmm0
pxor%xmm1, %xmm1
punpcklqdq  %xmm1, %xmm0
ret

for both testcases with -O2 -fgimple

combine fails to match

(set (reg:V4SI 87)
(vec_concat:V4SI (reg:V2SI 88 [ MEM[(unsigned int *)p_1(D)] ])
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])))

or

(set (reg:V4SI 87)
(vec_concat:V4SI (mem:V2SI (reg:DI 90) [1 MEM[(unsigned int *)p_1(D)]+0 S8
A32])
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])))

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 30 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88274
> 
> --- Comment #7 from Jakub Jelinek  ---
> The regression started with r265241 BTW.
> 
> Here is a reassoc patch I wrote that also fixes this ICE:
> --- gcc/tree-ssa-reassoc.c.jj   2018-10-23 10:13:25.278875175 +0200
> +++ gcc/tree-ssa-reassoc.c  2018-11-30 11:13:37.232393154 +0100
> @@ -2537,8 +2537,23 @@ optimize_range_tests_xor (enum tree_code
>if (!tree_int_cst_equal (lowxor, highxor))
>  return false;
> 
> +  exp = rangei->exp;
> +  scalar_int_mode mode = as_a  (TYPE_MODE (type));
> +  int prec = GET_MODE_PRECISION (mode);
> +  if (TYPE_PRECISION (type) < prec
> +  || (wi::to_wide (TYPE_MIN_VALUE (type))
> + != wi::min_value (prec, TYPE_SIGN (type)))
> +  || (wi::to_wide (TYPE_MAX_VALUE (type))
> + != wi::max_value (prec, TYPE_SIGN (type
> +{
> +  type = build_nonstandard_integer_type (prec, TYPE_UNSIGNED (type));
> +  exp = fold_convert (type, exp);
> +  lowxor = fold_convert (type, lowxor);
> +  lowi = fold_convert (type, lowi);
> +  highi = fold_convert (type, highi);
> +}
>tem = fold_build1 (BIT_NOT_EXPR, type, lowxor);
> -  exp = fold_build2 (BIT_AND_EXPR, type, rangei->exp, tem);
> +  exp = fold_build2 (BIT_AND_EXPR, type, exp, tem);
>lowj = fold_build2 (BIT_AND_EXPR, type, lowi, tem);
>highj = fold_build2 (BIT_AND_EXPR, type, highi, tem);
>if (update_range_test (rangei, rangej, NULL, 1, opcode, ops, exp,
> @@ -2581,7 +2596,16 @@ optimize_range_tests_diff (enum tree_cod
>if (!integer_pow2p (tem1))
>  return false;
> 
> -  type = unsigned_type_for (type);
> +  scalar_int_mode mode = as_a  (TYPE_MODE (type));
> +  int prec = GET_MODE_PRECISION (mode);
> +  if (TYPE_PRECISION (type) < prec
> +  || (wi::to_wide (TYPE_MIN_VALUE (type))
> + != wi::min_value (prec, TYPE_SIGN (type)))
> +  || (wi::to_wide (TYPE_MAX_VALUE (type))
> + != wi::max_value (prec, TYPE_SIGN (type
> +type = build_nonstandard_integer_type (prec, 1);
> +  else
> +type = unsigned_type_for (type);
>tem1 = fold_convert (type, tem1);
>tem2 = fold_convert (type, tem2);
>lowi = fold_convert (type, lowi);
> 
> Do we want that too, or is the exact type in which we compute these
> uninteresting?  Note, unfortunately in this case the enum type has
> TYPE_PRECISION 32, just TYPE_MAX_VALUE of 15, and we consider such conversions
> useless, so not really sure how can vrp work reliably with that.

I wonder that as well but it has been doing that (to some limited extent)
since forever.  The middle-end really only cares about TYPE_PRECISION
everywhere (but in VRP...).

So I'd happily substitute wi::min/max_value for TYPE_MIN/MAX_VALUE
in vrp_val_min/max ... with the expected "regressions" for
-fstrict-enums (and maybe Ada).

For your patch I think you don't need the mode-precision vs.
type-precision thing or is that simply to make the code not
un-optimal?  But yes, we shouldn't generate new arithmetic
in types with non-matching TYPE_MIN/MAX_VALUE.  Ada for
example does this in the underlying type and uses VCE
exprs to convert between those (IIRC).

The current state really asks for miscompilations (with -fstrict-enums).

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
Maybe Eric wants to chime in.  IIRC we went through great lengths to preserve
VRP using TYPE_MIN/MAX_VALUE to elide bounds checking for Ada?

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Ah, arm ignores the BRANCH_COST altogether:
#define LOGICAL_OP_NON_SHORT_CIRCUIT\
  ((optimize_size)  \
   ? (TARGET_THUMB ? false : true)  \
   : TARGET_THUMB ? static_cast
(current_tune->logical_op_non_short_circuit_thumb) \
   : static_cast (current_tune->logical_op_non_short_circuit_arm))

I'd say we should throw away logical_op_non_short_circuit, branch_cost,
-mbranch-cost= from all the generic tests, and perhaps introduce --param
logical_op_non_short_circuit, which if set would override the target decision,
either to 0 or to 1, with the default of using the target macro.
Param rather than option to make it clear we can nuke it when we change the
early gimplification to ignore such decision and have some much later pass that
would adjust tests.

[Bug middle-end/88279] New: unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[hubicka at gcc dot gnu.org]

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

Bug ID: 88279
   Summary: unresolvable R_X86_64_DTPOFF32 relocation against
symbol `__gcov_indirect_call'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

$ cat test.c
int (*ptr)(void);
static
int test2(void)
{
}
test()
{
  test3();
  ptr();
}
$ cat test2.c
int (*ptr)(void);
static
int test2(void)
{
}
test3()
{
  ptr();
}
$ ~/trunk-install/bin/gcc test.c  --shared -fPIC -lpthread -o dso1.so
-fprofile-generate -L ./ -O2 
test.c:6:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
6 | test()
  | ^~~~
test.c: In function ‘test’:
test.c:8:3: warning: implicit declaration of function ‘test3’; did you mean
‘test’? [-Wimplicit-function-declaration]
8 |   test3();
  |   ^
  |   test
$ ~/trunk-install/bin/gcc test2.c  --shared -fPIC dso1.so -o dso2.so
-fprofile-generate -L ./ -O2  --save-temps  -lpthread   -fuse-ld=bfd
test2.c:6:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
6 | test3()
  | ^
/usr/bin/ld.bfd: test2.o(.text+0x10): unresolvable R_X86_64_DTPOFF32 relocation
against symbol `__gcov_indirect_call'
/usr/bin/ld.bfd: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> Maybe Eric wants to chime in.  IIRC we went through great lengths to
> preserve VRP using TYPE_MIN/MAX_VALUE to elide bounds checking for Ada?

It's the opposite, we need to hide TYPE_MIN/MAX_VALUE to preserve checks in
Ada, otherwise the optimizer happily removes them (see
ada/gcc-interface/ada-tree.h).

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

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

Stephen Kim  changed:

   What|Removed |Added

 CC||stephen.kim at oracle dot com

--- Comment #4 from Stephen Kim  ---


(In reply to jos...@codesourcery.com from comment #3)
> As of October 2017, glibc has a testcase that having main in a shared 
> library works - that's a valid use case, which should work with crt1.o.  
> If it doesn't work for some particular architecture that would be a glibc 
> bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
> failure of the glibc elf/tst-main1 test, and no such failure is listed for 
> any architecture on .

The glibc commit that triggered this bug is:
 bfff8b1becd7d01c074177df7196ab327cd8c844 

It is a patch for aarch64 only. From there, giving crt1.o rather than Scrt1.o
has become problematic. 

The patch is included in Oracle Linux while it is not in Debian. The patch was
made this year. Thus, back then 2017, I think this problem did not exist.
Unfortunately, glibc still keeps the patch. Thus, the bug might be going to be
a problem in case of other Linux distro running on arm64, I believe. Gentoo has
the same issue but it avoids by defaulting PIE: --enable-default-pie at
configure.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

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

--- Comment #5 from Stephen Kim  ---
(In reply to jos...@codesourcery.com from comment #3)
> As of October 2017, glibc has a testcase that having main in a shared 
> library works - that's a valid use case, which should work with crt1.o.  
> If it doesn't work for some particular architecture that would be a glibc 
> bug (or conceivably an ld bug) - but I'd also expect it to show up as a 
> failure of the glibc elf/tst-main1 test, and no such failure is listed for 
> any architecture on .

It is reproducible, currently with Oracle Linux. For example, you could do:
 docker run -it oraclelinux:7.5 /bin/bash

followed by:
  yum update -y

Then, the issue is reproducible. I think I am the one that discovered this
issue while building Go tools on aarch64.

[Bug middle-end/88279] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
GNU ld (GNU Binutils for Debian) 2.28

[Bug tree-optimization/88272] warning: iteration 9223372036854775807 invokes undefined behavior

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
> Where do we set the cut-off? ;)
-fuser-patience=

I would cut it off for things that are obviously derived from sign of
64bit value :)) Those are most common.

Honza

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> It's the opposite, we need to hide TYPE_MIN/MAX_VALUE to preserve checks in
> Ada, otherwise the optimizer happily removes them.

To be more explicit: in Ada, you can check at run time whether a value is valid
for its nominal subtype (i.e. you can check if it's within the range) so you
cannot have the obvious TYPE_MIN/MAX_VALUE on this nominal subtype, otherwise
these checks will be elided by VRP.

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 CC||marxin at gcc dot gnu.org
  Known to work||8.2.0
Summary|unresolvable|[9 Regression] unresolvable
   |R_X86_64_DTPOFF32   |R_X86_64_DTPOFF32
   |relocation against symbol   |relocation against symbol
   |`__gcov_indirect_call'  |`__gcov_indirect_call'
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #2 from Martin Liška  ---
Confirmed with my revision r264840 where I changed:

void * __gco-void *__gcov_indirect_call_topn_callee ATTRIBUTE_HIDDEN;
gcov_type * __gcov_indirect_call_counters;

into:

struct indirect_call_tuple
{
  /* Callee function.  */
  void *callee;

  /* Pointer to counters.  */
  gcov_type *counters;
};

struct indirect_call_tuple __gcov_indirect_call;

[Bug tree-optimization/88280] New: missing folding of logical and bitwise AND

[denis.campredon at gmail dot com]

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

Bug ID: 88280
   Summary: missing folding of logical and bitwise AND
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

The following functions should all produce the same code with optimisations on
(it is the same if `a' is replaced with a constant) 
-
int e(int i, int a) {
return i && i & a;
}

int f(int i, int a) {
return i & a && i;
}

int g(int i, int a) {
int j = i & a;

return j && i;
}

int h(int i, int a) {
int j = i & a;

return i && j;
}
-

But currently only f produces good assembly:

f(int, int):
xor eax, eax
testedi, esi
setne   al
ret

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Jakub Jelinek  ---
Created attachment 45129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45129&action=edit
gcc9-pr85368.patch

Untested fix through a new param.

Can folks test it before/after this patch please on various targets (powerpc,
arm non-cortex-m, arm cortex-m, s390x)?  I've tested it on x86_64-linux so far.

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
It is enough to test it with:
cd build-dir/gcc
make check-gcc RUNTESTFLAGS="dg.exp='binop-xor1.c builtin-bswap-7.c pr21643.c
pr46309.c' tree-ssa.exp='forwprop-28.c phi-opt-11.c phi-opt-2.c reassoc-32.c
reassoc-33.c reassoc-34.c reassoc-35.c reassoc-36.c ssa-dom-thread-11.c
ssa-dom-thread-14.c ssa-dom-thread-16.c ssa-dom-thread-4.c ssa-dom-thread-18.c
ssa-ifcombine-13.c ssa-ifcombine-ccmp-1.c ssa-ifcombine-ccmp-2.c
ssa-ifcombine-ccmp-3.c ssa-ifcombine-ccmp-4.c ssa-ifcombine-ccmp-5.c
ssa-ifcombine-ccmp-6.c ssa-thread-11.c ssa-thread-14.c vrp47.c vrp87.c'"
apply patch
make cc1
repeat above make check-gcc

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

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

Stephen Kim  changed:

   What|Removed |Added

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

--- Comment #6 from Stephen Kim  ---
This bug is reproducible only on arm64. Sorry for missing the info. That was my
bad. 

Besides, it is reproducible with a particular patch in glibc, which was made
this year. 

And, the reason that glibc test did not detect this issue is because Debian gcc
seems to default pie. I.e. it might be configured with --enable-default-pie.
Gentoo does the same. Thus, they are giving Scrt1.o.

As of today, the gcc I got after running Debian:latest docker container and
executing "apt-get update," shows this on "gcc -v":
 $ gcc -v  2>&1 | egrep -o "enable-default-pie"
 enable-default-pie

Oracle Linux on arm64 is the environment that meets the requirements for the
bug. It has the glibc patch, and the gcc is not configured to default PIE. 

Thus, if not being reproducible was the reason that the bug is closed, I would
say that it is reproducible. Please, use oraclelinux:latest docker container on
aarch64.

If this bug is closed because it is indeed user's fault not a compiler driver
error, please, close this bug again.

[Bug tree-optimization/88281] New: SLP permutation check fails to fall back to strided loads

[rguenth at gcc dot gnu.org]

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

Bug ID: 88281
   Summary: SLP permutation check fails to fall back to strided
loads
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following is not vectorized due to a group size of 17 and unsupported load
permutation:

typedef unsigned char uint8_t;
static int x264_pixel_sad_8x8( uint8_t *pix1, int i_stride_pix1, uint8_t *pix2,
int i_stride_pix2 )
{
  int i_sum = 0;
  for( int y = 0; y < 8; y++ )
{
  for( int x = 0; x < 8; x++ )
i_sum += __builtin_abs( pix1[x] - pix2[x] );
  pix1 += 17;
  pix2 += i_stride_pix2;
}
  return i_sum;
}
void x264_pixel_sad_x4_8x8( uint8_t *fenc, uint8_t *pix0, uint8_t *pix1,
uint8_t *pix2, uint8_t *pix3, int i_stride, int scores[4] )
{
  *scores = x264_pixel_sad_8x8( fenc, 16, pix0, i_stride );
}

[Bug tree-optimization/88281] SLP permutation check fails to fall back to strided loads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
 Blocks||53947
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1


Referenced Bugs:

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

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 30 Nov 2018, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88274
> 
> --- Comment #11 from Eric Botcazou  ---
> > It's the opposite, we need to hide TYPE_MIN/MAX_VALUE to preserve checks in
> > Ada, otherwise the optimizer happily removes them.
> 
> To be more explicit: in Ada, you can check at run time whether a value is 
> valid
> for its nominal subtype (i.e. you can check if it's within the range) so you
> cannot have the obvious TYPE_MIN/MAX_VALUE on this nominal subtype, otherwise
> these checks will be elided by VRP.

OK, so we don't have coverage for VRP optimizations on such types
from Ada.  That leaves us with -fstrict-enums, defaulted to off.

I seriously question the value of VRP trying to look at
TYPE_MIN/MAX_VALUE then.

[Bug target/88278] Fails to elide zeroing of upper vector register

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-* i?86-*-*
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Hmm, it looks like *movdi_internal and friends to not represent the implicit
zeroing of the upper part?

I guess RTL in general (before reload) doesn't know that V2SI is the low
part of a V4SI register.  But after reload we see (split2)

(insn 7 5 8 2 (set (reg:V8QI 20 xmm0 [orig:88 MEM[(unsigned char *)p_1(D)] ]
[88])
(mem:V8QI (reg:DI 5 di [91]) [0 MEM[(unsigned char *)p_1(D)]+0 S8 A8]))
1078 {*movv8qi_internal}
 (nil))
(insn 8 7 9 2 (set (reg:V2SI 21 xmm1 [90])
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])) 1080 {*movv2si_internal}
 (expr_list:REG_EQUIV (const_vector:V2SI [
(const_int 0 [0]) repeated x2
])
(nil)))
(insn 9 8 16 2 (set (reg:V4SI 20 xmm0 [89])
(vec_concat:V4SI (reg:V2SI 20 xmm0 [orig:88 MEM[(unsigned char
*)p_1(D)] ] [88])
(reg:V2SI 21 xmm1 [90]))) 3955 {*vec_concatv4si}
 (expr_list:REG_EQUAL (vec_concat:V4SI (subreg:V2SI (reg:V8QI 20 xmm0
[orig:88 MEM[(unsigned char *)p_1(D)] ] [88]) 0)
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
]))
(nil)))

where the pattern is probably easier to optimize (but we then fail to elide
the xmm1 register as not needed eventually)?

[Bug tree-optimization/88280] missing folding of logical and bitwise AND

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  g and h end up like this before RTL expansion (initial folding
produces this):

  j_6 = i_4(D) & a_5(D);
  _1 = i_4(D) != 0;
  _2 = j_6 != 0;
  _3 = _1 & _2;
  _7 = (int) _3;
  return _7;

and for e we do not combine the i != 0 check.

   [local count: 1073741824]:
  if (i_3(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _1 = i_3(D) & a_4(D);
  _6 = _1 != 0;
  _7 = (int) _6;

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <_7(3), i_3(D)(2)>
  return iftmp.0_2;

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88282] New: ICE in df_install_refs at gcc/df-scan.c:2379

[marxin at gcc dot gnu.org]

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

Bug ID: 88282
   Summary: ICE in df_install_refs at gcc/df-scan.c:2379
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, ramana at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Following causes ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c --param
large-stack-frame=0 -Ofast -fstack-clash-protection
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c: In function ‘bf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c:22:1: internal
compiler error: Segmentation fault
   22 | }
  | ^
0xa88a2f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:326
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7329b1 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2379
0x732a94 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x732a94 df_refs_add_to_chains
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x738fae df_bb_refs_record(int, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3350
0x7391bc df_scan_blocks()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x8f127d do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5533
0x8f127d execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5653

[Bug tree-optimization/88283] New: ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6677

[marxin at gcc dot gnu.org]

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

Bug ID: 88283
   Summary: ICE in try_improve_iv_set, at
tree-ssa-loop-ivopts.c:6677
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Probably something graphite-related:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/interchange-8.c
-fgraphite-identity -fnon-call-exceptions -fexceptions -Ofast -mabi=ilp32
during GIMPLE pass: ivopts
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/interchange-8.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/interchange-8.c:10:1:
internal compiler error: in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6677
   10 | foo (void)
  | ^~~
0x5c26ec try_improve_iv_set
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:6677
0x5c26ec find_optimal_iv_set_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:6707
0xba3ee1 find_optimal_iv_set
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:6729
0xba3ee1 tree_ssa_iv_optimize_loop
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:7586
0xba3ee1 tree_ssa_iv_optimize()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:7628
0xbbfad0 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop.c:513

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
One related testcase that fails:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c
-fstack-clash-protection -O2 -fno-tree-ccp
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c: In function ‘bf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c:22:1: internal
compiler error: Segmentation fault
   22 | }
  | ^
0xa88a2f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:326
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7329b1 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2379
0x732a94 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x732a94 df_refs_add_to_chains
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x738fae df_bb_refs_record(int, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3350
0x7391bc df_scan_blocks()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x8f127d do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5533
0x8f127d execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5653

[Bug c++/88258] [9 Regression] Infinite loop emitting diagnostics in the C++ front-end

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45130&action=edit
gcc9-pr88258.patch

Untested fix.

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
The patch changed the argument to decl_default_tls_model from a decl to a type
node, which is probably wrong. This line:

set_decl_tls_model (ic_tuple_var, decl_default_tls_model (tuple_type));

should have used ic_tuple_var instead of the tuple_type?

[Bug libgcc/88267] A new flag in GCC causes a divergence in crtbegin.o file

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> But it's hidden, so I'm not sure we care. 

I noticed that using objdump -d where the tools assigns names to locations of
which it knows name.

> OTOH not sure why options.h is being pulled in.

This should be investigated ;)

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
To clarify, the decl/type mixup is causing the compiler to use local-dynamic
TLS references where general-dynamic are intended (and were used prior to the
patch).

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
I can confirm it resolves the issue, let me prepare changelog for it.
Thanks Alexander!

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Tamar Christina  ---
Confirmed, something broke in between upstreaming and now. Taking a look.

[Bug target/88284] New: nios2: pessimistic ldw-to-stwio scheduling

[already5chosen at yahoo dot com]

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

Bug ID: 88284
   Summary: nios2: pessimistic ldw-to-stwio scheduling
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: already5chosen at yahoo dot com
  Target Milestone: ---

Created attachment 45131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45131&action=edit
demonstration of bad scheduling

Compiler generates bad scheduling for memory-to-io copy loops.
It seems that Nios2 instruction scheduler somehow don't understand that stwio
instruction depends on the value it is going to store.

I have no idea why, instead of producing random schedule, the compiler
consistently generates the worst possible schedule. Possibly, it is a result of
unfortunate interaction with one of the middle-end heuristics (attempt of
prefetch?). 
But the reason is less important than the outcome.

My demonstration code consists of four examples of good scheduling for cases of
memory-to-memory copies and four examples of bad scheduling for cases of
memory-to-io copies. An optimal scheduling for memory-to-io copies (ldw
followed by stwio) is exactly the same as for memory-to-memory copies (ldw
followed by stw).
In both cases in order to avoid pipeline stall ldw and an instruction that
depends on loaded values shell be separated by at least two unrelated
instructions.

Compiled with 'nios2-elf-gcc -c -Wall -ffreestanding -O2 --save-temps'
gcc version 8.2.0

[Bug tree-optimization/88280] missing folding of logical and bitwise AND

[denis.campredon at gmail dot com]

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

--- Comment #2 from denis.campredon at gmail dot com ---
I don't know if I should create a separate bug report or not, since it looks
kind of related.
I've tried to replace the operator of the function e with other and it
generates a branch with the following operators
--
int b_and(int i, int a) {
   return i && i & a;
}
int b_or(int i, int a) {
   return i && i | a;
}
int add(int i, int a) {
   return i && i + a;
}
int mult(int i, int a) {
   return i && i * a;
}
int left(int i, int a) {
   return i && i << a;
}
int right(int i, int a) {
   return i && i >> a;
}
int l_or(int i, int a) {
   return i && (i || a);
}
--
But does not with :
--
int b_xor(int i, int a) {
   return i && i ^ a;
}
int sub(int i, int a) {
   return i && i - a;
}

[Bug lto/88220] LTO ICE with GNU inline and alias's

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
So the issue is that in WPA we mix:
void a() __asm__("open64");

and

void open64() {}

Then we stream out:
*open64/0 (a) @0x7698f5a0
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly_exp public
  Address is taken.
  References: 
  Referring: e/2 (addr)
  Read from file: open64.o
  Availability: overwritable
  Function flags: count:1073741824 (estimated locally)
  Called by: 
  Calls: c/4 (1073741824 (estimated locally),1.00 per call) b/3 (1073741824
(estimated locally),1.00 per call) 

and in ltrans the function body of the cgraph node looks as follows:
$2 = void
(gdb) p debug_function(fn_decl, 0)
a ()
{
   [local count: 1073741824]:
  return;

}

which has no calls, thus the discrepancy in cgraph edges. I think it's the same
issue as PR87525. So Honza's turn.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

--- Comment #35 from Martin Liška  ---
Author: marxin
Date: Fri Nov 30 14:25:15 2018
New Revision: 24

URL: https://gcc.gnu.org/viewcvs?rev=24&root=gcc&view=rev
Log:
Make red zone size more flexible for stack variables (PR sanitizer/81715).

2018-11-30  Martin Liska  

PR sanitizer/81715
* asan.c (asan_shadow_cst): Remove, partially transform
into flush_redzone_payload.
(RZ_BUFFER_SIZE): New.
(struct asan_redzone_buffer): New.
(asan_redzone_buffer::emit_redzone_byte): Likewise.
(asan_redzone_buffer::flush_redzone_payload): Likewise.
(asan_redzone_buffer::flush_if_full): Likewise.
(asan_emit_stack_protection): Use asan_redzone_buffer class
that is responsible for proper aligned stores and flushing
of shadow memory payload.
* asan.h (ASAN_MIN_RED_ZONE_SIZE): New.
(asan_var_and_redzone_size): Likewise.
* cfgexpand.c (expand_stack_vars): Use smaller alignment
(ASAN_MIN_RED_ZONE_SIZE) in order to make shadow memory
for automatic variables more compact.
2018-11-30  Martin Liska  

PR sanitizer/81715
* c-c++-common/asan/asan-stack-small.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/asan-stack-small.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/asan.h
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #36 from Martin Liška  ---
Implemented on trunk.

[Bug target/88278] Fails to elide zeroing of upper vector register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
I guess
#include 

__m128i
foo (__m64 *x)
{
  return _mm_movpi64_epi64 (*x);
}
is what intrinsic users would write for this case, and that is optimized
properly:
(insn 7 6 12 2 (set (reg:V2DI 87)
(vec_concat:V2DI (mem:DI (reg:DI 89) [0 *x_3(D)+0 S8 A64])
(const_int 0 [0]))) "include/emmintrin.h":592:24 3956
{vec_concatv2di}
 (expr_list:REG_DEAD (reg:DI 89)
(nil)))

Similarly e.g.
#include 

__m256
foo (__m128 *x)
{
  return _mm256_castps128_ps256 (*x);
}
which is conceptually closest to this case.
Or
#include 

__m256i
foo (__m128i *x)
{
  return _mm256_castsi128_si256 (*x);
}

All these use something like:
(insn 7 6 13 2 (set (reg:V8SI 87)
(unspec:V8SI [
(mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
] UNSPEC_CAST)) "include/avxintrin.h":1484:20 4813 {avx_si256_si}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))
Not really sure why UNSPEC_CAST rather than representing it with something
natural like VEC_CONCAT of nonimmediate_operand and const0_operand.

[Bug target/88278] Fails to elide zeroing of upper vector register

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 30 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88278
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2018-11-30
>  Ever confirmed|0   |1
> 
> --- Comment #2 from Jakub Jelinek  ---
> I guess
> #include 
> 
> __m128i
> foo (__m64 *x)
> {
>   return _mm_movpi64_epi64 (*x);
> }
> is what intrinsic users would write for this case, and that is optimized
> properly:
> (insn 7 6 12 2 (set (reg:V2DI 87)
> (vec_concat:V2DI (mem:DI (reg:DI 89) [0 *x_3(D)+0 S8 A64])
> (const_int 0 [0]))) "include/emmintrin.h":592:24 3956
> {vec_concatv2di}
>  (expr_list:REG_DEAD (reg:DI 89)
> (nil)))
> 
> Similarly e.g.
> #include 
> 
> __m256
> foo (__m128 *x)
> {
>   return _mm256_castps128_ps256 (*x);
> }
> which is conceptually closest to this case.
> Or
> #include 
> 
> __m256i
> foo (__m128i *x)
> {
>   return _mm256_castsi128_si256 (*x);
> }
> 
> All these use something like:
> (insn 7 6 13 2 (set (reg:V8SI 87)
> (unspec:V8SI [
> (mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
> ] UNSPEC_CAST)) "include/avxintrin.h":1484:20 4813 {avx_si256_si}
>  (expr_list:REG_DEAD (reg:DI 90)
> (nil)))
> Not really sure why UNSPEC_CAST rather than representing it with something
> natural like VEC_CONCAT of nonimmediate_operand and const0_operand.

OK, it indeed seems to "work" when punning via integers:

typedef unsigned long v2di __attribute__((vector_size(16)));

v2di __GIMPLE baz (unsigned long *p)
{
  unsigned long _2;
  v2di _3;

bb_2:
  _2 = __MEM  (p_1(D));
  _3 = _Literal (v2di) { _2, _Literal (unsigned long) 0 };
  return _3;
}

looks like for this combine can do

Successfully matched this instruction:
(set (reg:V2DI 87)
(vec_concat:V2DI (mem:DI (reg:DI 89) [1 *p_1(D)+0 S8 A64])
(const_int 0 [0])))

which means the vector variants could be handled similarly
by macroizing on vector modes with matching sizes?  Or is
this undesirable?  If we declare the above canonical RTL
for zero-"extending" loads into vector registers then we
can handle this during RTL expansion I guess.

[Bug gcov-profile/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri Nov 30 15:06:22 2018
New Revision: 26

URL: https://gcc.gnu.org/viewcvs?rev=26&root=gcc&view=rev
Log:
Call decl_default_tls_model with a proper type (PR gcov-profile/88279).

2018-11-30  Alexander Monakov  

PR gcov-profile/88279
* tree-profile.c (init_ic_make_global_vars): Call
decl_default_tls_model for variable and not it's type.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-profile.c

[Bug gcov-profile/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed.

[Bug target/88278] Fails to elide zeroing of upper vector register

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #2)
> All these use something like:
> (insn 7 6 13 2 (set (reg:V8SI 87)
> (unspec:V8SI [
> (mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
> ] UNSPEC_CAST)) "include/avxintrin.h":1484:20 4813 {avx_si256_si}
>  (expr_list:REG_DEAD (reg:DI 90)
> (nil)))
> Not really sure why UNSPEC_CAST rather than representing it with something
> natural like VEC_CONCAT of nonimmediate_operand and const0_operand.

I tried to get rid of the UNSPEC_CAST in PR 50829... VEC_CONCAT with 0 may be
fine when loading from memory, but we don't want it when the argument is in a
register.

[Bug target/88278] Fails to elide zeroing of upper vector register

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Note, we also have vec_concatv2di pattern that handles:
(set (match_operand:V2DI 0 ("register_operand") ("=Yr,*x,x ,v ,v,v ,x  
,x,v ,x,x,v"))
(vec_concat:V2DI (match_operand:DI 1 ("nonimmediate_operand") (" 
0, 0,x ,Yv,r,vm,?!*y,0,Yv,0,0,v"))
(match_operand:DI 2 ("nonimm_or_0_operand") (" rm,rm,rm,rm,C ,C
,C ,x,Yv,x,m,m"
and then *vec_concatv4si which handles far less than that, just the last 5
alternatives.  Conceptually, both operations do the same thing, on the other
side not sure if it is a good idea to say to RA that it could put V2SImode
pseudos into GPRs.  So, that leaves us at the first pinsrq alternatives with
just "m" for them, not really sure they are worth it.  Then there is one v <-
r, C alternative, again, I think we shouldn't put V2SImode into GPRs, v <- vm,
C alternative that we definitely want, but it could be a separate
*vec_concatv4si_0
pattern two, as nonimmediate_operand and const0_operand don't overlap and last
x <- ?!*y, C, that's MMXish, maybe, maybe not.

[Bug target/88278] Fails to elide zeroing of upper vector register

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I wonder about something like:
--- gcc/config/i386/sse.md.jj   2018-11-29 23:16:06.481301632 +0100
+++ gcc/config/i386/sse.md  2018-11-30 16:21:21.480379008 +0100
@@ -7248,6 +7248,17 @@
(set_attr "prefix" "orig,maybe_evex,orig,maybe_evex")
(set_attr "mode" "V4SF,V4SF,V2SF,V2SF")])

+(define_insn "*vec_concatv4sf_0"
+  [(set (match_operand:V4SF 0 "register_operand"   "=v")
+   (vec_concat:V4SF
+ (match_operand:V2SF 1 "nonimmediate_operand" "xm")
+ (match_operand:V2SF 2 "const0_operand"   " C")))]
+  "TARGET_SSE2"
+  "%vmovq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex")
+   (set_attr "mode" "DF")])
+
 ;; Avoid combining registers from different units in a single alternative,
 ;; see comment above inline_secondary_memory_needed function in i386.c
 (define_insn "vec_set_0"
@@ -14409,6 +14420,23 @@
(set_attr "prefix" "orig,maybe_evex,orig,orig,maybe_evex")
(set_attr "mode" "TI,TI,V4SF,V2SF,V2SF")])

+(define_insn "*vec_concatv4si_0"
+  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
+   (vec_concat:V4SI
+ (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
+ (match_operand:V2SI 2 "const0_operand"   " C,C")))]
+  "TARGET_SSE2"
+  "@
+   %vmovq\t{%1, %0|%0, %1}
+   movq2dq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex,orig")
+   (set_attr "mode" "TI")
+   (set (attr "preferred_for_speed")
+ (if_then_else (eq_attr "alternative" "1")
+   (symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
+   (symbol_ref "true")))])
+
 ;; movd instead of movq is required to handle broken assemblers.
 (define_insn "vec_concatv2di"
   [(set (match_operand:V2DI 0 "register_operand"

but the #c0 testcases don't compile for me with -O2 -msse2 -fgimple (nor
-mavx), so I can't easily verify.

I don't see how we could get rid of those for the v <- v,C cases, unless we
analyze whatever instruction generated it and prove that it leaves all the
higher bits set to zero.  E.g. one could have a v4si to v2si downcast (just
picking the lowpart subreg) followed by concatenating it with zero, and if we
blindly drop the movq instruction, the upper bits might be non-zero.

[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Fri Nov 30 15:57:37 2018
New Revision: 266671

URL: https://gcc.gnu.org/viewcvs?rev=266671&root=gcc&view=rev
Log:
Fix ICE in substring locations from macros in header files (PR
preprocessor/88257)

PR preprocessor/88257 reports an ICE on gcc.dg/format/pr78304.c
when compiled using g++:

void test (const char *msg)
{
  printf ("size: %" PRIu32 "\n", msg);
}

due to mismatching files (and line maps) between
linemap_resolve_location and expand_location_to_spelling_point
when PRIu32 is defined in a system header.

The root cause is that expand_location_to_spelling_point stops
unwinding locations when it reaches a system header, whereas
linemap_resolve_location can resolve into a system header,
which can lead to locations within get_substring_ranges_for_loc
getting out of sync, and using the wrong line map.

This patch fixes the issue by checking that the files are the
same.

gcc/ChangeLog:
PR preprocessor/88257
* input.c (get_substring_ranges_for_loc): Fix indentation.
Bulletproof against getting a different files back from
linemap_resolve_location and expand_location_to_spelling_point.

gcc/testsuite/ChangeLog:
PR preprocessor/88257
* c-c++-common/Wformat-pr88257.c: New test.
* c-c++-common/Wformat-pr88257.h: New test header.
* c-c++-common/empty.h: New test header.


Added:
trunk/gcc/testsuite/c-c++-common/Wformat-pr88257.c
trunk/gcc/testsuite/c-c++-common/Wformat-pr88257.h
trunk/gcc/testsuite/c-c++-common/empty.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Slightly cleaned up testcase:
typedef struct A {} B;
A const a = B ();

The problem is that we have a TARGET_EXPR with B type and an empty CONSTRUCTOR
with B type, then cxx_eval_outermost_constant_expr is processing it,
5111  if (TREE_CODE (r) == CONSTRUCTOR && CLASS_TYPE_P (TREE_TYPE (r)))
5112{
5113  r = adjust_temp_type (type, r);
5114  if (TREE_CODE (t) == TARGET_EXPR
5115  && TARGET_EXPR_INITIAL (t) == r)
5116return t;
5117  else if (TREE_CODE (t) != CONSTRUCTOR)
5118{
5119  r = get_target_expr (r);
5120  TREE_CONSTANT (r) = true;
5121}
and then in the caller
5259  r = cxx_eval_outermost_constant_expr (t, true, true, false, decl);
5260  gcc_checking_assert (r == t
5261   || CONVERT_EXPR_P (t)
5262   || TREE_CODE (t) == VIEW_CONVERT_EXPR
5263   || (TREE_CONSTANT (t) && !TREE_CONSTANT (r))
5264   || !cp_tree_equal (r, t));

For A const a = A (); adjust_temp_type returns the passed r and thus r == t in
the caller, but for A const a = B (); adjust_temp_type creates a new
CONSTRUCTOR (with A type), also a new TARGET_EXPR because of that, but both are
cp_tree_equal, as it doesn't care about exact type as long as it has
same_type_p.

So, shall adjust_temp_type not bother if it is same_type_p, or shall the assert
be adjusted, or shall we adjust the type earlier already?  The assert is there
already since r166166.

[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Any progress on this?  It really slows down test runs as it hangs twice and has
to wait for the timeout to occur to continue.

[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed by r266671.

[Bug target/88278] Fails to elide zeroing of upper vector register

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On November 30, 2018 4:28:54 PM GMT+01:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88278
>
>--- Comment #6 from Jakub Jelinek  ---
>I wonder about something like:
>--- gcc/config/i386/sse.md.jj   2018-11-29 23:16:06.481301632 +0100
>+++ gcc/config/i386/sse.md  2018-11-30 16:21:21.480379008 +0100
>@@ -7248,6 +7248,17 @@
>(set_attr "prefix" "orig,maybe_evex,orig,maybe_evex")
>(set_attr "mode" "V4SF,V4SF,V2SF,V2SF")])
>
>+(define_insn "*vec_concatv4sf_0"
>+  [(set (match_operand:V4SF 0 "register_operand"   "=v")
>+   (vec_concat:V4SF
>+ (match_operand:V2SF 1 "nonimmediate_operand" "xm")
>+ (match_operand:V2SF 2 "const0_operand"   " C")))]
>+  "TARGET_SSE2"
>+  "%vmovq\t{%1, %0|%0, %1}"
>+  [(set_attr "type" "ssemov")
>+   (set_attr "prefix" "maybe_vex")
>+   (set_attr "mode" "DF")])
>+
>;; Avoid combining registers from different units in a single
>alternative,
> ;; see comment above inline_secondary_memory_needed function in i386.c
> (define_insn "vec_set_0"
>@@ -14409,6 +14420,23 @@
>(set_attr "prefix" "orig,maybe_evex,orig,orig,maybe_evex")
>(set_attr "mode" "TI,TI,V4SF,V2SF,V2SF")])
>
>+(define_insn "*vec_concatv4si_0"
>+  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
>+   (vec_concat:V4SI
>+ (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
>+ (match_operand:V2SI 2 "const0_operand"   " C,C")))]
>+  "TARGET_SSE2"
>+  "@
>+   %vmovq\t{%1, %0|%0, %1}
>+   movq2dq\t{%1, %0|%0, %1}"
>+  [(set_attr "type" "ssemov")
>+   (set_attr "prefix" "maybe_vex,orig")
>+   (set_attr "mode" "TI")
>+   (set (attr "preferred_for_speed")
>+ (if_then_else (eq_attr "alternative" "1")
>+   (symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
>+   (symbol_ref "true")))])
>+
> ;; movd instead of movq is required to handle broken assemblers.
> (define_insn "vec_concatv2di"
>   [(set (match_operand:V2DI 0 "register_operand"
>
>but the #c0 testcases don't compile for me with -O2 -msse2 -fgimple
>(nor
>-mavx), so I can't easily verify.

I have committed the prerequisite for that now. 

>I don't see how we could get rid of those for the v <- v,C cases,
>unless we
>analyze whatever instruction generated it and prove that it leaves all
>the
>higher bits set to zero.  E.g. one could have a v4si to v2si downcast
>(just
>picking the lowpart subreg) followed by concatenating it with zero, and
>if we
>blindly drop the movq instruction, the upper bits might be non-zero.

Yeah, I'm looking for a way to do low part loads from memory with zeroing the
rest.

[Bug tree-optimization/88285] New: [9 Regression] gcc.dg/predict-22.c fails on arm

[clyon at gcc dot gnu.org]

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

Bug ID: 88285
   Summary: [9 Regression] gcc.dg/predict-22.c fails on arm
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

It's not really a regression, but a new failure since this test was added
(r266587).

On arm targets, I'm seeing:
cc1: note: -freorder-blocks-and-partition not supported on this architecture
PASS: gcc.dg/predict-22.c (test for excess errors)
PASS: gcc.dg/predict-22.c scan-tree-dump-times optimized "Invalid sum" 0
PASS: gcc.dg/predict-22.c scan-tree-dump-times optimized "count 0," 1
gcc.dg/predict-22.c: dump file does not exist
UNRESOLVED: gcc.dg/predict-22.c scan-rtl-dump-times bbpart "COLD_PARTITION" 1

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #7 from Andreas Schwab  ---
If you think you have found a bug in glibc, then this is not the right place to
report it.

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[clyon at gcc dot gnu.org]

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

--- Comment #12 from Christophe Lyon  ---
Hi Jakub, thanks for doing this.
I tested on many combination of arm* targets, and it was OK except for some of
them:
--target arm-none-eabi
--with-mode thumb
--with-cpu cortex-m3
--with-fpu default

--target arm-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a5
--with-fpu vfpv3-d16-fp16

Executed from: gcc.dg/tree-ssa/tree-ssa.exp
FAIL:gcc.dg/tree-ssa/reassoc-33.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 3
FAIL:gcc.dg/tree-ssa/reassoc-34.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 1
FAIL:gcc.dg/tree-ssa/reassoc-35.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 1
FAIL:gcc.dg/tree-ssa/reassoc-36.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 1

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||vmakarov at gcc dot gnu.org
   Assignee|tnfchris at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #3 from Tamar Christina  ---
This is caused by the change in r266385 for PR87718.

That causes the cost model to go completely off the rail and also changes the
register classes.

Previously out costs were 0 in most cases, now we have large numbers like
65540004.

```
  r93 costs: GENERAL_REGS:0 FP_LO_REGS:1 FP_REGS:1
POINTER_AND_FP_REGS:1 MEM:8000
  r92 costs: GENERAL_REGS:0 FP_LO_REGS:1 FP_REGS:1
POINTER_AND_FP_REGS:1 MEM:8000
```

was before and now

```
  r93 costs: GENERAL_REGS:65540004 FP_LO_REGS:65544004 FP_REGS:65544004
POINTER_AND_FP_REGS:65544004 MEM:8000
  r92 costs: TAILCALL_ADDR_REGS:131074004 GENERAL_REGS:131074004
FP_LO_REGS:131074004 FP_REGS:131074004 POINTER_AND_FP_REGS:131074004 MEM:8000
```

The reason this crashes with stack clash enabled is because the alloca code
emits a probe at SP.

The costing now makes it think it has to spill the hard register

  Creating newreg=98 from oldreg=92, assigning class GENERAL_REGS to r98
   16: sp:DI=r98:DI
  REG_DEAD r92:DI
  REG_ARGS_SIZE 0
Inserting insn reload before:
   27: r98:DI=r92:DI


 it can't do it so it crashes in reload.

[Bug rtl-optimization/87718] [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #9 from Tamar Christina  ---
This change has quite a negative effect on the cost model in AArch64 an ICE due
to the new costs and register classes it picks.

See PR88282

Thanks,
Tamar

[Bug fortran/88137] BACKTRACE seems to have a memory leak

[jb at gcc dot gnu.org]

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

--- Comment #4 from Janne Blomqvist  ---
Author: jb
Date: Fri Nov 30 16:44:27 2018
New Revision: 266677

URL: https://gcc.gnu.org/viewcvs?rev=266677&root=gcc&view=rev
Log:
Initialize backtrace state once

From backtrace.h for backtrace_create_state:

   Calling this function allocates resources that can not be freed.
   There is no backtrace_free_state function.  The state is used to
   cache information that is expensive to recompute.  Programs are
   expected to call this function at most once and to save the return
   value for all later calls to backtrace functions.

So instead of calling backtrace_create_state every time we wish to
show a backtrace, do it once and store the result in a static
variable.  libbacktrace allows multiple threads to access the state,
so no need to use TLS.

Regtested on x86_64-pc-linux-gnu.

libgfortran/ChangeLog:

2018-11-30  Janne Blomqvist  

PR libfortran/88137
* runtime/backtrace.c (show_backtrace): Make lbstate a static
variable, initialize once.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/backtrace.c

[Bug fortran/88137] BACKTRACE seems to have a memory leak

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  ---
Author: jb
Date: Fri Nov 30 16:46:55 2018
New Revision: 266678

URL: https://gcc.gnu.org/viewcvs?rev=266678&root=gcc&view=rev
Log:
Initialize backtrace state once

From backtrace.h for backtrace_create_state:

   Calling this function allocates resources that can not be freed.
   There is no backtrace_free_state function.  The state is used to
   cache information that is expensive to recompute.  Programs are
   expected to call this function at most once and to save the return
   value for all later calls to backtrace functions.

So instead of calling backtrace_create_state every time we wish to
show a backtrace, do it once and store the result in a static
variable.  libbacktrace allows multiple threads to access the state,
so no need to use TLS.

Regtested on x86_64-pc-linux-gnu.

Backport from trunk.

libgfortran/ChangeLog:

2018-11-30  Janne Blomqvist  

PR libfortran/88137
* runtime/backtrace.c (show_backtrace): Make lbstate a static
variable, initialize once.

Modified:
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/runtime/backtrace.c

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #45129|0   |1
is obsolete||

--- Comment #13 from Jakub Jelinek  ---
Created attachment 45132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45132&action=edit
gcc9-pr85368.patch

Updated patch with those reassoc-3[23456].c tests adjusted.

[Bug fortran/88286] New: gfortran reports conflicting intent(in) with an intent(in) declared class variable

[aluaces at udc dot es]

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

Bug ID: 88286
   Summary: gfortran reports conflicting intent(in) with an
intent(in) declared class variable
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aluaces at udc dot es
  Target Milestone: ---

I get the error

test_bug.f90:19:16:

 INTENT(IN) b
1
Error: INTENT (IN) conflicts with INTENT(IN) at (1)

with the attached minimal working example.  The error is issued at the last
function, but it is not triggered if I remove either the first or the second.

If the parameter "b" is not a CLASS reference but a base type, the test passes
as well, so I think it has to be something regarding polymorphic types.

MODULE MOD_BUG
  IMPLICIT NONE

  TYPE BT
 INTEGER I
  END TYPE BT

CONTAINS

  FUNCTION si_p_loc(b)
CLASS(BT)::b
LOGICAL si_p_loc
INTENT(IN) b
  END FUNCTION si_p_loc

  FUNCTION si_v_loc(b)
CLASS(BT)::b
LOGICAL si_v_loc
INTENT(IN) b
  END FUNCTION si_v_loc

END MODULE MOD_BUG

[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
And that hook indeed returns the need for secondary reload there, so looks like
LRA bug for not honoring it?

[Bug fortran/88286] gfortran reports conflicting intent(in) with an intent(in) declared class variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

Workaroud: use

CLASS(BT), INTENT(IN) ::b

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Author: bergner
Date: Fri Nov 30 18:57:33 2018
New Revision: 266680

URL: https://gcc.gnu.org/viewcvs?rev=266680&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/87496
* gcc.target/powerpc/pr86324-1.c: Add dg-skip-if selector.
Add -mcpu=power7 option.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr86324-1.c

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Tamar Christina from comment #3)
> This is caused by the change in r266385 for PR87718.
> 
> That causes the cost model to go completely off the rail and also changes
> the register classes.
> 

  Sorry for this. It was a very sensitive code change and I think it will take
some time until the code stabilize.  But I believe that what patch for PR87718
solves is the right direction for RA.

> Previously out costs were 0 in most cases, now we have large numbers like
> 65540004.
> 
> ```

  I'll investigate this too. The biggest problem with RA cost calculations is
that machine-dependent code for register move cost is not defined correctly for
all combinations of mode, regclass, regclass.  Unfortunately, the documentation
says nothing about it.  RA tries to solve this in some ways but not always
successfully. 

  In the current case the combination is DImode, SP_REG, GENERAL_REGS.

  I'll see what can I do in RA.  I have an idea. If it works the patch will be
ready on the next week.

[Bug tree-optimization/88285] [9 Regression] gcc.dg/predict-22.c fails on arm

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
However, this same commit also introduced a regression:
FAIL: gcc.c-torture/execute/20040709-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

with gcc configured
--target arm-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

[Bug target/88287] New: [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[clyon at gcc dot gnu.org]

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

Bug ID: 88287
   Summary: [9 Regression] aarch64/sve/vcond_1.C fails since
r266620
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r266620, I have noticed that g++.target/aarch64/sve/vcond_1.C now fails.

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
FAILs just because it has too much scan-assembler in it and expects something
in particular, or do we generate worse code?
The patch certainly added some canonicalization that was previously done only
for scalar comparisons.

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
BTW, it is unclear to me how to reproduce it, I've tried
./cc1plus -quiet -O -msve-vector-bits=256 vcond_1.C -o vcond_1.s -nostdinc
-march=armv8.4-a+simd
with the match.pd changes reverted and the same without the reversion and the
generated assembly is identical.

[Bug sanitizer/88277] ASAN stack poisoning is using unaligned stores on e.g. x86_64

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #2 from Andi Kleen  ---
FWIW modern x86 CPUs are fairly good at unaligned accesses, so it might not be
worth it for performance.

[Bug libgomp/88288] New: [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

Bug ID: 88288
   Summary: [OpenACC, libgomp] Adjust offsets for present data
clauses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

As reported in ,
libgomp "is not respecting the on device offset of subarrays which may arise in
present data clauses", "causing SPEC_ACCEL 304.olbm to generate bogus results",
for example.

This will likely need to be fixed on all active release branches.

[Bug rtl-optimization/88179] [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 30 20:15:56 2018
New Revision: 266682

URL: https://gcc.gnu.org/viewcvs?rev=266682&root=gcc&view=rev
Log:
2018-11-30  Vladimir Makarov  

PR rtl-optimization/88179
* lra-constraints.c (address_eliminator::address_eliminator):
Don't eleminate regs in illegitimate address.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/85220] [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc

--- Comment #5 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #1)
> FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
> execution test
> FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
> execution test

Filed PR88288.

[Bug sanitizer/88289] New: [9 regression] r266664 causes asan to fail on many/most tests on BE

[seurer at gcc dot gnu.org]

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

Bug ID: 88289
   Summary: [9 regression] r24 causes asan to fail on
many/most tests on BE
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer 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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This appears to only cause it to fail on BE.

FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_AllocDeallocMismatch
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_AtoiAndFriendsOOBTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_AttributeNoSanitizeAddressTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_BitFieldNegativeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_BitFieldPositiveTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_BufferOverflowAfterManyFrees execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_CallocReturnsZeroMem
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_CxxExceptionTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_FileNameInGlobalReportTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_GlobalStringConstTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_GlobalTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeOOBInMemset
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeOOBRightTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeStructCopyTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LongDoubleNegativeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LongJmpTest execution
test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_MallocUsableSizeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  A

[Bug c/87924] OpenACC wait clauses without async-arguments

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Nov 30 20:39:30 2018
New Revision: 266686

URL: https://gcc.gnu.org/viewcvs?rev=266686&root=gcc&view=rev
Log:
[PR87924] Add (XFAILed) test cases for OpenACC wait clauses without
async-arguments

gcc/testsuite/
PR c/87924
* c-c++-common/goacc/asyncwait-5.c: Update.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
trunk/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Nov 30 20:39:49 2018
New Revision: 266688

URL: https://gcc.gnu.org/viewcvs?rev=266688&root=gcc&view=rev
Log:
[PR88288, OpenACC, libgomp] Adjust offsets for present data clauses

Make libgomp respect the on device offset of subarrays which may arise in
present data clauses.

libgomp/
PR libgomp/88288
* oacc-parallel.c (GOACC_parallel_keyed): Add offset to devaddrs.
* testsuite/libgomp.oacc-c-c++-common/pr88288.c: New test.

Reviewed-by: Thomas Schwinge 

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr88288.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c

[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 20:55:41 2018
New Revision: 266689

URL: https://gcc.gnu.org/viewcvs?rev=266689&root=gcc&view=rev
Log:
PR debug/85550
* g++.dg/debug/dwarf2/pr85550.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr85550.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
Dup.

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

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
*** Bug 85550 has been marked as a duplicate of this bug. ***

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
Why not update goacc_parallel_keyed to use gomp_map_val instead computing
devaddrs manually? That would help reduce the number of duplicate mystery
formulas in libgomp.

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to cesar from comment #2)
> Why not update goacc_parallel_keyed to use gomp_map_val instead computing
> devaddrs manually? That would help reduce the number of duplicate mystery
> formulas in libgomp.

Right, that's something to look into (as I had just earlier mentioned in email,
too), but for now, the objective has been to actually get the bug fix
committed, using the patch that you had written in 2016 (when "gomp_map_val"
already existed, by the way).

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:

> The glibc commit that triggered this bug is:
>  bfff8b1becd7d01c074177df7196ab327cd8c844 

That's the copyright date updates for 2017.

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code, down to at least gcc-5 :
> 
> 
> $ cat z1.f90
> program p
>write (end=1e1)
>write (end=1d1)
>write (end=1q1)
> end
> 
> 
> $ gfortran-9-20181125 -c z1.f90
> 0x619a5e gfc_format_decoder
> ../../gcc/fortran/error.c:947
> 0x131c83e pp_format(pretty_printer*, text_info*)
> ../../gcc/pretty-print.c:1390
> 0x13121e5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
> ../../gcc/diagnostic.c:1015
> 0x6198fc gfc_error_opt
> ../../gcc/fortran/error.c:1313
> 0x61aea0 gfc_error(char const*, ...)
> ../../gcc/fortran/error.c:1342
> 0x63c9b2 check_io_constraints
> ../../gcc/fortran/io.c:3755


Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -3681,7 +3681,10 @@ check_io_constraints (io_kind k, gfc_dt *dt, gfc_code 
 #define io_constraint(condition,msg,arg)\
 if (condition) \
   {\
-gfc_error(msg,arg);\
+if ((arg)->lb != NULL) \
+  gfc_error(msg,arg);\
+else \
+  gfc_error(msg,&gfc_current_locus);\
 m = MATCH_ERROR;\
   }

@@ -3741,11 +3744,14 @@ if (condition) \
   if (expr && expr->ts.type != BT_CHARACTER)
 {

-  io_constraint (gfc_pure (NULL) && (k == M_READ || k == M_WRITE),
-"IO UNIT in %s statement at %C must be "
+  if (gfc_pure (NULL) && (k == M_READ || k == M_WRITE))
+   {
+ gfc_error ("IO UNIT in %s statement at %C must be "
 "an internal file in a PURE procedure",
 io_kind_name (k));
-
+ return MATCH_ERROR;
+   }
+ 
   if (k == M_READ || k == M_WRITE)
gfc_unset_implicit_pure (NULL);
 }

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-*-linux-gnu
 CC||pinskia at gcc dot gnu.org

--- Comment #9 from Andrew Pinski  ---
(In reply to jos...@codesourcery.com from comment #8)
> On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> 
> > The glibc commit that triggered this bug is:
> >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> 
> That's the copyright date updates for 2017.

I was going to say that too.
Maybe:
https://sourceware.org/git/?p=glibc.git;a=commit;h=14d886edbd3d80b771e1c42fbd9217f9074de9c6