[Bug lto/91228] [10 regression] Removing gnu_lto_v1 symbol name breaks LTO with Solaris ld

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Wed Jul 24 07:00:48 2019
New Revision: 273757

URL: https://gcc.gnu.org/viewcvs?rev=273757&root=gcc&view=rev
Log:
Fix off-by-one in simple-object-elf.c (PR lto/91228).

2019-07-24  Martin Liska  

PR lto/91228
* simple-object-elf.c (simple_object_elf_copy_lto_debug_sections):
Find first '\0' starting from gnu_lto + 1.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/simple-object-elf.c

[Bug lto/91228] [10 regression] Removing gnu_lto_v1 symbol name breaks LTO with Solaris ld

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/91223] [10 Regression] ICE: in curr_insn_transform, at lra-constraints.c:4459

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
I have one another smaller test-case:

$ cat ice.i
int a;
void fn2(short, short);

void fn1(void) {
  short b[8];
  b[0] |= a & 3;
  b[1] = a;
  fn2(b[0], b[1]);
}

$ gcc ice.i -c -Og -fno-tree-fre
during RTL pass: reload
ice.i: In function ‘fn1’:
ice.i:9:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4459
9 | }
  | ^
0x6819a5 curr_insn_transform
/home/marxin/Programming/gcc/gcc/lra-constraints.c:4459
0xc262a4 lra_constraints(bool)
/home/marxin/Programming/gcc/gcc/lra-constraints.c:4987
0xc137b4 lra(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/lra.c:2468
0xbcb7f1 do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5522
0xbcb7f1 execute
/home/marxin/Programming/gcc/gcc/ira.c:5706
Please submit a full bug report,

[Bug c++/91241] [7/8/9/10 Regression] internal compiler error: symtab_node::verify failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
 Ever confirmed|0   |1

[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
 CC||marxin at gcc dot gnu.org,
   ||matz at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||7.4.0
   Target Milestone|--- |8.4
Summary|Wrong code with -O3 |[8/9/10 Regression] Wrong
   ||code with -O3 due to unroll
   ||and jam pass
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with Michael's r255467.

[Bug fortran/91237] ICE in gfortran with preprocessor directives

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's a very old issue.

[Bug middle-end/91166] [SVE] Unfolded ZIPs of constants

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Jul 24 07:20:24 2019
New Revision: 273758

URL: https://gcc.gnu.org/viewcvs?rev=273758&root=gcc&view=rev
Log:
2019-07-24  Prathamesh Kulkarni  

PR middle-end/91166
* match.pd (vec_perm_expr(v, v, mask) -> v): New pattern.
(define_predicates): Add entry for uniform_vector_p.
(vec_same_elem_p): New match pattern.

testsuite/
* gcc.target/aarch64/sve/pr91166.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/pr91166.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 23 Jul 2019, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
> 
> --- Comment #4 from Martin Sebor  ---
> The results of relational expressions (<, >, <=, and <=) involving pointers to
> unrelated objects are undefined and unspecified in C and C++, respectively. 
> (See 6.5.8, p5 in C 11 and [expr.rel], p3 in C++ 17).

Does "unspecified" allow p > q != !(p <= q)?  I think so (it's not
implementation defined).

Still for GCC we need to find something sensible for QoI reasons.

Eventually inserting a __builtin_trap () before a condition data
dependent on such comparison is better than folding it to an
essentially random constant (at least I don't see how we could
easily get consistency here).

So this might be something for path isolation, not so much for
constant folding?  Similar things could be done for uninitialized
values participating in a controlling condition.

[Bug driver/91244] New: gcc-ar prepends --plugin option thus triggers binutils getopt_long bug 13256

[szotsaki at gmail dot com]

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

Bug ID: 91244
   Summary: gcc-ar prepends --plugin option thus triggers binutils
getopt_long bug 13256
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: szotsaki at gmail dot com
  Target Milestone: ---

"ar" seemingly doesn't accept options after a longopt (in our case "--plugin")
which makes it impossible to read instructions from command line or from a file
if "--plugin" is the first parameter. See
https://sourceware.org/bugzilla/show_bug.cgi?id=13256 for details.

Therefore I suggest appending the "--plugin" parameter to the command line
arguments.

Here is a quick patch against 9.1.0 to show what I thought of:

--- gcc/gcc-ar.c2019-07-22 17:03:21.267931991 +0200
+++ gcc/gcc-ar.c2019-07-24 09:41:27.168851170 +0200
@@ -211,13 +211,13 @@
   nargv = XCNEWVEC (const char *, ac + 4);
   nargv[0] = exe_name;
 #if HAVE_LTO_PLUGIN > 0
-  nargv[1] = "--plugin";
-  nargv[2] = plugin;
   if (is_ar && av[1] && av[1][0] != '-')
 av[1] = concat ("-", av[1], NULL);
   for (k = 1; k < ac; k++)
-nargv[2 + k] = av[k];
-  nargv[2 + k] = NULL;
+nargv[k] = av[k];
+  nargv[k + 0] = "--plugin";
+  nargv[k + 1] = plugin;
+  nargv[k + 2] = NULL;
 #else
   if (is_ar && av[1] && av[1][0] != '-')
 av[1] = concat ("-", av[1], NULL);

A somehow related ticket for @file reading: Bug 77576

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
(In reply to Steve Ellcey from comment #19)
> Should this defect be reopened?  One of the tests that was added is failing
> for me on aarch64.
> 
> FAIL: g++.dg/tree-ssa/pr83518.C  -std=gnu++98  scan-tree-dump optimized
> "return 15;"
> FAIL: g++.dg/tree-ssa/pr83518.C  -std=gnu++14  scan-tree-dump optimized
> "return 15;"
> FAIL: g++.dg/tree-ssa/pr83518.C  -std=gnu++17  scan-tree-dump optimized
> "return 15;"

It should have been fixed by r273732 (checked with a cc1 cross to aarch64,
albeit on a not clean tree...)

[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
 Status|ASSIGNED|NEW
 CC||rsandifo at gcc dot gnu.org
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
So it's a real discrepancy in between hash and equal function:

This value is being inserted:

$ (gdb) p debug_tree(comparable.first)
  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77898d20 precision:32 min  max >
$ (gdb) p *comparable.second
$16 = {
   >> = {
coeffs = {{
 = {
  val = {29, 140737488336336, 140737488336432, 12171194,
140737488336536, 140737488337344, 140737488336352, 137438953473, 0}, 
  len = 1, 
  precision = 32
}, 
members of generic_wide_int: 
static is_sign_extended = true
  }, {
 = {
  val = {-4, 137438953473, 480890236520, 576, 140737488336448,
137438953473, -17179869184, 137463206123, 140737488336464}, 
  len = 1, 
  precision = 32
}, 
members of generic_wide_int: 
static is_sign_extended = true
  }}
  }, }

with the following hash:
(gdb) p hash
$17 = 941189640

Existing hash table entry:

(gdb) p debug_tree(*entry)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77898d20 precision:32 min  max >
constant
elt0:  
constant 29>
elt1:  
constant 4294967292>>

$ (gdb) p Descriptor::hash (*entry)
$19 = 1141032448

Richard, can you please take a look?

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #5)
> Fixing the dependency for identical=true is a Good Thing(TM), but
> will not be enough to fix the test case:

Hm, another thought.

For this special case (calling the matmul library function) we could
be passing a non-contiguous lhs to the library, leading to far less
efficient code.

So, the choice of what to fix exactly is probably a bit more complicated.

[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Must be related to hashing of the TYPE_UID, following patch fixes that:

diff --git a/gcc/tree.c b/gcc/tree.c
index 8cf75f0..7a5d6ef4625 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -1644,7 +1644,6 @@ poly_int_cst_hasher::hash (tree t)
 {
   inchash::hash hstate;

-  hstate.add_int (TYPE_UID (TREE_TYPE (t)));
   for (unsigned int i = 0; i < NUM_POLY_INT_COEFFS; ++i)
 hstate.add_wide_int (wi::to_wide (POLY_INT_CST_COEFF (t, i)));

@@ -1673,7 +1672,6 @@ build_poly_int_cst (tree type, const poly_wide_int_ref
&values)
   poly_wide_int c = poly_wide_int::from (values, prec, SIGNED);

   inchash::hash h;
-  h.add_int (TYPE_UID (type));
   for (unsigned int i = 0; i < NUM_POLY_INT_COEFFS; ++i)
 h.add_wide_int (c.coeffs[i]);
   poly_int_cst_hasher::compare_type comp (type, &c);

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ada/91245] New: gnat.dg/float_value1.adb FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 91245
   Summary: gnat.dg/float_value1.adb FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, roche at adacore dot com
  Target Milestone: ---
Target: sparc*-*-solaris2.11, aarch64-suse-linux-gnu,
s390x-ibm-linux-gnu

The new gnat.dg/float_value1.adb test FAILs on Solaris/SPARC (both 32 and
64-bit):

+FAIL: gnat.dg/float_value1.adb execution test

raised PROGRAM_ERROR : float_value1.adb:20 explicit raise

Thread 2 hit Breakpoint 1, float_value1.test (msg=..., str=..., expected=...)
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/float_value1.adb:20
20   raise Program_Error;
(gdb) p msg
$1 = "0....[5 times]   "
(gdb) p str
$2 = "0.", '4' 
(gdb) p expected
$3 = " 4.", '4' , "E-01"
(gdb) where
#0  float_value1.test (msg=..., str=..., expected=...)
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/float_value1.adb:20
#1  0x00050530 in float_value1 ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/float_value1.adb:25

There are also gcc-testresults reports for Linux/aarch64 and Linux/s390x.

[Bug ada/91245] gnat.dg/float_value1.adb FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-07-24
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So how does a testcase look like?  If I read the code in dwarf2out correctly
the only way things could go wrong is a hash collision, otherwise I don't
see how the comdat sections could differ.

Can you possibly share two source files and instructions to reproduce the
conflicting comdats?

There should be also only a single symbol at the start of the comdat so
the relocation should be always resolvable.  Maybe we're somehow emitting
the same info twice into the same comdat from a single CU?

That said, w/o an object file to look at it's hard to say what's wrong.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
When we compare p>=a where a is an array (char a[3];), we can assume that p
points somewhere into the array and fold it to true (unless we decide that it
is too risky, and that for instance since we allow pointers one past the end,
we should also allow pointers one before the beginning). It is only in the rare
case where we happen to know that p cannot point into the array that we might
want to do something different (one possibility would be to fold the comparison
to an undefined ssa_name), but that shouldn't prevent the 'true' optimization
for valid code paths. Path isolation might arrive too late, after we have
already folded to true.

[Bug tree-optimization/91246] New: vectorization failure for a small loop to search array element

[jiangning.liu at amperecomputing dot com]

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

Bug ID: 91246
   Summary: vectorization failure for a small loop to search array
element
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangning.liu at amperecomputing dot com
  Target Milestone: ---

For the following simple case, the inner loop can be completely removed by
vectorization. GCC fails to do that. SIZE can be either 4 or 8.

#define SIZE 4
int f(int *data, int x)
{
int i, j;
int s = 0;

for (i = 0; i < 1024; i++) {
int found = 0;
for (j = 0; j < SIZE; j++) {
if (data[j] == x) {
found = 1;
break;
}
}
s += found;
}

return s;
}

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 24 Jul 2019, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
> 
> --- Comment #6 from Marc Glisse  ---
> When we compare p>=a where a is an array (char a[3];), we can assume that p
> points somewhere into the array and fold it to true (unless we decide that it
> is too risky, and that for instance since we allow pointers one past the end,
> we should also allow pointers one before the beginning).

That's generally possible for p >= &x, independent of whether x is
an array.

> It is only in the rare
> case where we happen to know that p cannot point into the array that we might
> want to do something different (one possibility would be to fold the 
> comparison
> to an undefined ssa_name), but that shouldn't prevent the 'true' optimization
> for valid code paths. Path isolation might arrive too late, after we have
> already folded to true.

Using an undef SSA name might trigger odd uninit warnings though, but yes.

Note I've yet have to see a testcase that shows the optimization is
useful for real code (the p >= &x I can imagine though), that is,
optimize the case where we _know_ p and q do not point to the same
object and p and q are compared with a non-equality compare.
I'd say we should not fold and path-isolate the case instead
(and consider moving that earlier if it's too late).  Since such
compares invoke undefined behavior I hope they do not come from
STL template instantiation for example.

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[tkoenig at gcc dot gnu.org]

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

--- Comment #31 from Thomas Koenig  ---
(In reply to rguent...@suse.de from comment #30)


> So something is odd with how the frontend handles 'c_'.
> 
> The symbol table has two:
> 
> __f_MOD_c_/2 (c_) @0x7f763892d300
>   Type: variable definition analyzed
>   Visibility: public
>   References:
>   Referring: __f_MOD_fs/6 (write)
>   Availability: not-ready
>   Varpool flags:
> 
> __f_MOD_c_/15 (c_) @0x7f763892df80
>   Type: variable
>   Visibility: external public
>   previous sharing asm name: 2
>   References:
>   Referring: MAIN__/8 (read)
>   Availability: not-ready
>   Varpool flags:

Ok, so I presume the best way would be to add module variables
to the Fortran global variables (name mangling should make that
uniquie, if not we have serious other problems :-)

One question: How do I get that symbol table printed out?
I can see it can be _extremely_ useful, but I don't know
how to get at it.

Thanks for the debugging on this!

[Bug c++/91247] New: Variadic template expansion - Mistmatch argument pack length

[mariogalindoq at hotmail dot com]

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

Bug ID: 91247
   Summary: Variadic template expansion - Mistmatch argument pack
length
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mariogalindoq at hotmail dot com
  Target Milestone: ---

Created attachment 46624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46624&action=edit
Full program that do not compile in gcc due to this bug.

When expanding the pack of a variadic template, the compiler adds an extra
spirous type.

The program can be executed here:

https://wandbox.org/permlink/O1mixn6gm1XWH6Hr


The following is a complete program example that do not compile in gcc but
compile in clang, for instance:


#include 

template
struct S : Lambda_types...
{
// The following only works with clang. In gcc do not compile, this a bug.
  template
  S(T&&... lambda_args) : Lambda_types{std::forward(lambda_args)}... {} //
Mistmach argument pack length !!!
  using Lambda_types::operator()...;
};

template
S(Lambda_types...) -> S;

int main()
{
  auto l1 = []()  {return 4;};
  auto l2 = [](int i) {return i*11;};
  S comb{l1,l2};

  std::cout << comb() << '\n';
  std::cout << comb(5) << '\n';
}

// This bug can be relationed with bug id 88580

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[rguenther at suse dot de]

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

--- Comment #32 from rguenther at suse dot de  ---
On Wed, 24 Jul 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
> 
> --- Comment #31 from Thomas Koenig  ---
> (In reply to rguent...@suse.de from comment #30)
> 
> 
> > So something is odd with how the frontend handles 'c_'.
> > 
> > The symbol table has two:
> > 
> > __f_MOD_c_/2 (c_) @0x7f763892d300
> >   Type: variable definition analyzed
> >   Visibility: public
> >   References:
> >   Referring: __f_MOD_fs/6 (write)
> >   Availability: not-ready
> >   Varpool flags:
> > 
> > __f_MOD_c_/15 (c_) @0x7f763892df80
> >   Type: variable
> >   Visibility: external public
> >   previous sharing asm name: 2
> >   References:
> >   Referring: MAIN__/8 (read)
> >   Availability: not-ready
> >   Varpool flags:
> 
> Ok, so I presume the best way would be to add module variables
> to the Fortran global variables (name mangling should make that
> uniquie, if not we have serious other problems :-)
> 
> One question: How do I get that symbol table printed out?
> I can see it can be _extremely_ useful, but I don't know
> how to get at it.

It's dumped by -fdump-ipa-cgraph into source.000i.cgraph.

[Bug d/91238] internal compiler error: in add_expr, at tree.c:7794

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
Further reduced, always triggers ICE, so it's not something that recently
started to happen.

---
alias T = const(char)*;
T name()
{
return "";
}
void collectDependencies(ref T)
{
}
void configurePackages(T[T] targets)
{
collectDependencies(targets[name]);
}
---

Associative array is lowered to a function call.

(const char * &) _aaGetRvalueX (targets, &targets.typeinfo, 8, &name ());


And the ICE triggers from that bounds checking wraps this in a SAVE_EXPR, and
does the condition:

SAVE_EXPR<...> != null ? SAVE_EXPR<...> : _d_arraybounds("ice91238.d", 11);

At some point during the traversal of add_expr() for the condition, it
encounters the ADDR_EXPR(CALL_EXPR(name)) in `&name ()` and inspects each
TREE_OPERAND, the first being an INTEGER_CST, triggering the check:

gcc_checking_assert (!(flags & OEP_ADDRESS_OF));

So, the front-end is guilty of taking the address of a non-lvalue, so the
codegen should better handle this.

[Bug d/91238] internal compiler error: in add_expr, at tree.c:7794

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to?  The ICE
itself happens because add_expr, when traversing a CALL_EXPR does not
unset OEP_ADDRESS_OF when processing arguments (taking the address of the
CALL_EXPR doesn't mean we are taking the address of its arguments).  Obviously
nobody thought we'd ever have an ADDR_EXPR of a CALL_EXPR and add_expr
should already assert on that...  oddly enough we handle &COND_EXPR
so that would be precedent for a "fix":

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 273758)
+++ gcc/tree.c  (working copy)
@@ -7996,6 +7996,7 @@ add_expr (const_tree t, inchash::hash &h
  }

case CALL_EXPR:
+ flags &= ~OEP_ADDRESS_OF;
  if (CALL_EXPR_FN (t) == NULL_TREE)
hstate.add_int (CALL_EXPR_IFN (t));
  break;

[Bug d/91238] internal compiler error: in add_expr, at tree.c:7794

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Richard Biener from comment #2)
> Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to?  The ICE
> itself happens because add_expr, when traversing a CALL_EXPR does not
> unset OEP_ADDRESS_OF when processing arguments (taking the address of the
> CALL_EXPR doesn't mean we are taking the address of its arguments). 

I was thinking of putting the CALL_EXPR into a TARGET_EXPR, and taking the
address of that instead.

[Bug tree-optimization/91246] vectorization failure for a small loop to search array element

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The issue is

t.c:7:3: note:   ==> examining statement: _25 = .MASK_LOAD (_43, 32B, _42);
t.c:7:3: note:   vect_is_simple_use: operand x_12(D) != _13, type of def:
internal
t.c:7:3: note:   vect_is_simple_use: vectype vector(4) 
t.c:7:3: missed:   unsupported access type for masked load.
t.c:10:12: missed:   not vectorized: relevant stmt not supported: _25 =
.MASK_LOAD (_43, 32B, _42);
t.c:7:3: missed:  bad operation or unsupported loop bound.

possibly because how we if-convert the unrolled inner loop with the
early exit you introduced.  If you remove the early exit then we
elide the outer loop and nothing is left to do (it's replaced by
s *= 1024).

If you remove the early exit and disable the unrolling we vectorize
the loop successfully (but with awkward code generation IMHO).

If you remove the pointless outer loop we no longer unroll the inner
loop but it shows we cannot handle if-converting loops with multiple
exits.

A testcase more closely matching real-world code appreciated.


Referenced Bugs:

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

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
It must be a miscompilation of gcc/tree-ssa-sccvn.c file. Using stage 2
compiler during boostrap is fine. Likewise, adding -O0 to gcc/tree-ssa-sccvn.c
is fine.

I'm using following host compiler:
$ gcc --version
gcc (SUSE Linux) 7.4.0

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So putting #pragma GCC optimize ("-O0") at line 1735 is the last position when
I don't see the ICE. So vn_walk_cb_data::push_partial_def or an inliced
function is miscompiled.

[Bug target/91248] New: __builtin___clear_cache is a no-op on SPARC

[ro at gcc dot gnu.org]

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

Bug ID: 91248
   Summary: __builtin___clear_cache is a no-op on SPARC
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-*

During the review of https://reviews.llvm.org/D64496 (which implements
__clear_cache for SPARC in LLVM's compiler-rt), the reviewer pointed out
that gcc is wrong wrt. its handling of __clear_cache on SPARC: while
sparc32_initialize_trampoline and sparc64_initialize_trampoline emit flush
insns directly, there's also __builtin___clear_cache, which currently is a
no-op
on SPARC: neither does the SPARC backend define CLEAR_INSN_CACHE (so libgcc's
__clear_cache is a no-op) nor is there a clear_cache insn.  Am I missing
somethere here?

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[dberlin at gcc dot gnu.org]

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

--- Comment #17 from Daniel Berlin  ---
Not sure how i ended up on the CC list for this one, but i actually
would disagree it would be better than nothing.
Features that can only be made to work a small amount and are
incapable of being improved tend to be the ones users complain about
the most.
In cases where you can't even get to 30% or 40%, let alone 80%, it's
often better to do nothing.

On Tue, Jul 23, 2019 at 9:20 PM egallager at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
>
> --- Comment #16 from Eric Gallager  ---
> (In reply to Jakub Jelinek from comment #12)
> > And then there is the case of endless loops in such functions (either
> > unconditional, or ones the compiler is not able to detect), exit calls, both
> > either directly in the const/pure function or in some function it calls.  So
> > in all, I'm afraid such a warning would diagnose only the most trivial 
> > cases.
>
> That would still be better than nothing.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
I've got it:

  /* We support up to 512-bit values (for V8DFmode).  */
  unsigned char buffer[64];
  int len;

  while (!partial_defs.is_empty ())
{
  pd_data pd = partial_defs.pop ();
  if (TREE_CODE (pd.rhs) == CONSTRUCTOR)
+  {
+size_t x = MIN ((HOST_WIDE_INT)sizeof (buffer), pd.size);
+size_t offset =  MAX (0, pd.offset);
+fprintf (stderr, "memset: %ld, offset: %ld\n", x, offset);
/* Empty CONSTRUCTOR.  */
memset (buffer + MAX (0, pd.offset),
-   0, MIN ((HOST_WIDE_INT)sizeof (buffer), pd.size));
+   0, x);
+  }


$ ./gcc/xgcc -Bgcc /tmp/ice.ii -c -O3
memset: 64, offset: 8
during GIMPLE pass: fre
...

So a nice example of stack corruption. Richi can you please prepare a patch for
it?

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
One can see it on x86_64 with the following patch:

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 9369c36f50e..6192540c219 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -1816,10 +1816,15 @@ vn_walk_cb_data::push_partial_def (const pd_data &pd,
tree vuse,
 {
   pd_data pd = partial_defs.pop ();
   if (TREE_CODE (pd.rhs) == CONSTRUCTOR)
-   /* Empty CONSTRUCTOR.  */
-   memset (buffer + MAX (0, pd.offset),
-   0, MIN ((HOST_WIDE_INT)sizeof (buffer),
-   pd.size + MIN (0, pd.offset)));
+   {
+ unsigned HOST_WIDE_INT offset = MAX (0, pd.offset);
+ unsigned HOST_WIDE_INT size = MIN ((HOST_WIDE_INT)sizeof (buffer),
+pd.size + MIN (0, pd.offset));
+ gcc_assert (offset + size <= sizeof (buffer));
+
+ /* Empty CONSTRUCTOR.  */
+ memset (buffer + offset, 0, size);
+   }
   else
{
  unsigned pad = 0;

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Ooops (double-oops, see 2nd hunk...).  Testing the following:

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 273758)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -1818,7 +1870,7 @@ vn_walk_cb_data::push_partial_def (const
   if (TREE_CODE (pd.rhs) == CONSTRUCTOR)
/* Empty CONSTRUCTOR.  */
memset (buffer + MAX (0, pd.offset),
-   0, MIN ((HOST_WIDE_INT)sizeof (buffer),
+   0, MIN ((HOST_WIDE_INT)sizeof (buffer) - MAX (0, pd.offset),
pd.size + MIN (0, pd.offset)));
   else
{
@@ -1833,7 +1885,7 @@ vn_walk_cb_data::push_partial_def (const
  pad = GET_MODE_SIZE (mode) - pd.size;
}
  len = native_encode_expr (pd.rhs, buffer + MAX (0, pd.offset),
-   sizeof (buffer - MAX (0, pd.offset)),
+   sizeof (buffer) - MAX (0, pd.offset),
MAX (0, -pd.offset) + pad);
  if (len <= 0 || len < (pd.size - MAX (0, -pd.offset)))
{

[Bug c/91232] Adding -fPIC with optimization level > 0 resulting a busy hang in my program

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
>Can I please have any pointers which could explain why that particular 
>computation is invoking an undefined behaviour ?

Signed integer overflow.

[Bug d/91238] internal compiler error: in add_expr, at tree.c:7794

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Iain Buclaw from comment #3)
> (In reply to Richard Biener from comment #2)
> > Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to?  The ICE
> > itself happens because add_expr, when traversing a CALL_EXPR does not
> > unset OEP_ADDRESS_OF when processing arguments (taking the address of the
> > CALL_EXPR doesn't mean we are taking the address of its arguments). 
> 
> I was thinking of putting the CALL_EXPR into a TARGET_EXPR, and taking the
> address of that instead.

That sounds good to me.

[Bug target/91248] __builtin___clear_cache is a no-op on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
(> neither does the SPARC backend define CLEAR_INSN_CACHE (so libgcc's
> __clear_cache is a no-op) nor is there a clear_cache insn.  Am I missing
> somethere here?

Probably that nobody knows about and therefore uses __builtin___clear_cache...

[Bug tree-optimization/91249] New: Missed optimization: division and multiplying ops in ffast-math mode

[zamazan4ik at tut dot by]

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

Bug ID: 91249
   Summary: Missed optimization: division and multiplying ops in
ffast-math mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

For this code:

float foo(float x, float y)
{
return x * y/y;
}


gcc(trunk,9,8,7,6,5) with '-O3 -ffast-math' produces this:


foo(float, float):
mulss   xmm0, xmm1
divss   xmm0, xmm1
ret


clang(trunk) with '-O3 -ffast-math' produces this:


foo(float, float):   # @foo(float, float)
ret


Notes: playground on godbolt - https://godbolt.org/z/Qjr3OD

[Bug tree-optimization/91250] New: Missed optimization: is not used vfnmsub213ss

[zamazan4ik at tut dot by]

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

Bug ID: 91250
   Summary: Missed optimization: is not used vfnmsub213ss
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

For this code:

float foo(float a, float b, float c)
{
return a * -b - c;
}


gcc(trunk) with '-O3 -ffast-math -march=haswell' produces this:


foo(float, float, float):
vfmadd132ss xmm0, xmm2, xmm1
vxorps  xmm0, xmm0, XMMWORD PTR .LC0[rip]
ret


clang (trunk) with '-O3 -ffast-math -march=haswell' produces this:


foo(float, float, float):
vfnmsub213ssxmm0, xmm1, xmm2 # xmm0 = -(xmm1 * xmm0) - xmm2
ret


Note: playground on godbolt - https://godbolt.org/z/NTMVdg

[Bug tree-optimization/91250] Missed optimization: is not used vfnmsub213ss

[zamazan4ik at tut dot by]

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

--- Comment #2 from Alexander Zaitsev  ---
But on this example all is fine:


float foo(float a, float b, float c)
{
return -a * -b - c;
}

[Bug tree-optimization/91250] Missed optimization: is not used vfnmsub213ss

[zamazan4ik at tut dot by]

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

--- Comment #1 from Alexander Zaitsev  ---
Another example of missed optimization:

float foo(float a, float b, float c)
{
return -a * b - c;
}

[Bug c++/91247] Variadic template expansion - Mistmatch argument pack length

[mariogalindoq at hotmail dot com]

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

--- Comment #1 from Mario Galindo  ---
When expanding the pack of a variadic template, the compiler erroneously adds
an extra spurious type.

[Bug driver/91244] gcc-ar prepends --plugin option thus triggers binutils getopt_long bug 13256

[szotsaki at gmail dot com]

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

--- Comment #1 from Szőts Ákos  ---
Ps.: I've just realised that it's possible to unify the loop with the next
#else section and have only lines

  nargv[k + 0] = "--plugin";
  nargv[k + 1] = plugin;

inside the #if condition, thus removing code duplication.

[Bug middle-end/91250] Missed optimization: is not used vfnmsub213ss

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
  Component|tree-optimization   |middle-end
Version|unknown |10.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  We're canonicalizing this as

  _1 = .FMA (b_3(D), a_4(D), c_5(D));
  _6 = -_1;

which expansion doesn't handle.  It works without -ffast-math.

When trying to fix also consider

float foo(float a, float b, float c)
{
return -(a * b + c);
}

[Bug tree-optimization/91249] Missed optimization: division and multiplying ops in ffast-math mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-24
Version|unknown |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, reassoc should handle this.

[Bug c/91251] New: Revision 272645 on top of 9.1.0 caused ICE: in extract_insn, at recog.c:2310

[didin at synopsys dot com]

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

Bug ID: 91251
   Summary: Revision 272645 on top of 9.1.0 caused ICE: in
extract_insn, at recog.c:2310
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: didin at synopsys dot com
  Target Milestone: ---

After applying changes from revision=272645 on top of 9.1.0 ICE appeared.

---COMPILER CONFIGURATION--
Using built-in specs.

Target: arc-buildroot-linux-uclibc
Configured with: ./configure --prefix=/worktrees/br_ica/output/host
--sysconfdir=/worktrees/br_ica/output/host/etc --enable-static
--target=arc-buildroot-linux-uclibc
--with-sysroot=/worktrees/br_ica/output/host/arc-buildroot-linux-uclibc/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --with-gmp=/worktrees/br_ica/output/host
--with-mpc=/worktrees/br_ica/output/host
--with-mpfr=/worktrees/br_ica/output/host --with-pkgversion='Buildroot
2019.08-git-00654-gcf9e8ebe47-dirty' --with-bugurl=http://bugs.buildroot.net/
--disable-libquadmath --disable-libsanitizer --enable-tls --disable-libmudflap
--enable-threads --without-isl --without-cloog --with-cpu=archs
--enable-languages=c,c++
--with-build-time-tools=/worktrees/br_ica/output/host/arc-buildroot-linux-uclibc/bin
--enable-shared --disable-libgomp
Thread model: posix
gcc version 9.1.0 (Buildroot 2019.08-git-00654-gcf9e8ebe47-dirty) 



REDUCED TEST CASE--
char *XkbIndentText(unsigned size)
{
static char buf[32];
register int i;

if (size > 31)
size = 31;

for (i = 0; i < size; i++) {
   buf[i] = ' ';
}
buf[size] = '\0';
return buf;
}


COMMAND LINE USED FOR COMPILATION-

./arc-linux-gcc -c test.c -fpic -O2
test.c: In function ‘XkbIndentText’:
test.c:14:1: error: unrecognizable insn:
   14 | }
  | ^
(insn 68 64 69 4 (set (reg:SI 178)
(unspec:SI [
(symbol_ref:SI ("buf.1422") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC)) -1
 (nil))
during RTL pass: sched1
test.c:14:1: internal compiler error: in extract_insn, at recog.c:2310
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[rearnsha at gcc dot gnu.org]

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

--- Comment #19 from Richard Earnshaw  ---
Surely the real problem is that the expansion doesn't really understand about
the 'don't care' location and that we can therefore put any value in that?

That additional knowledge would allow the earlier passes of the compiler to
rewrite this as a simple store of zero to then entire object.

[Bug rtl-optimization/91223] [10 Regression] ICE: in curr_insn_transform, at lra-constraints.c:4459

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #6 from Vladimir Makarov  ---
  Thank you for reporting this.  I've started to work on the PR.  I think the
fix will be ready this week.

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

[sje at gcc dot gnu.org]

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

--- Comment #21 from Steve Ellcey  ---
(In reply to Richard Biener from comment #20)
> (In reply to Steve Ellcey from comment #19)
> It should have been fixed by r273732 (checked with a cc1 cross to aarch64,
> albeit on a not clean tree...)

OK, I rested with top-of-tree that includes this patch and the tests
are not failing for me now.  My earlier testing did not have this patch
in it.

[Bug c/91252] New: [Bug] When use -flto "weak symbol" are converted to "t".

[akhilesh.k at samsung dot com]

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

Bug ID: 91252
   Summary: [Bug] When use -flto "weak symbol" are converted to
"t".
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

when i use -flto "weak symbol" are converted to "t". 

I really don't know whether this is bug or expected behavior, because in GCC
Source i am not able to find the code for this conversion. 


@akhilesh-ubuntu:~/akhilesh/lto$ gcc -flto -o nornal myapp.c; nm -C ./nornal |
grep power
00400532 t power
@akhilesh-ubuntu:~/akhilesh/lto$ gcc -o nornal myapp.c; nm -C ./nornal | grep
power
00400532 W power
@akhilesh-ubuntu:~/akhilesh/lto$ 


@akhilesh-ubuntu:~/akhilesh/lto$ cat myapp.c 
#include 
#include 
int __attribute__((weak)) power(int x);

int power(int x)
{
  return x*x;
}
int main(int argc, char **argv)
{
  printf("power() = %d\n", power(atoi(argv[1])));
  return 0;
}
=
@akhilesh-ubuntu:~/akhilesh/lto$ 

I am using gcc 8.3.0 version and binutils version is 2.29.1

@akhilesh-ubuntu:~/akhilesh/lto$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-arm-src-snapshot-8.3-2019.03/configure
--disable-multilib
Thread model: posix
gcc version 8.3.0 (Linaro GCC 8.2-2018.08~d

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
(In reply to rguent...@suse.de from comment #5)
> Does "unspecified" allow p > q != !(p <= q)?  I think so (it's not
> implementation defined).

The exact C++ words that apply here are:

(4.3)  Otherwise [if two unequal pointers don't point into the same object],
neither pointer is required to compare greater than the other.

(it's not explicitly unspecified, but it sounds at least as loose).  So the
answer is yes.

I agree with producing a sensible result for QoI (especially if there's no
warning).  A result that's consistent between [in]equality and relational
expressions would qualify.

I also agree that diagnosing all these unspecified (or undefined in C) cases
would be helpful as they (at least in the straightforward instances) are most
likely coding mistakes.  I might look into it, though my first concern is about
the instances that result from some earlier transformations and where warnings
will be seen as false positives.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
(In reply to Martin Sebor from comment #8)
> I also agree that diagnosing all these unspecified (or undefined in C) cases
> would be helpful as they (at least in the straightforward instances) are
> most likely coding mistakes.

Note that there is already a sanitizer for that. Of course it isn't the same as
a warning.

[Bug fortran/91253] New: gfortran.dg/continuation_6.f fails when using latest glibc

[sje at gcc dot gnu.org]

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

Bug ID: 91253
   Summary: gfortran.dg/continuation_6.f fails when using latest
glibc
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

When testing GCC with the latest GLIBC, specifically one which creates a
math-vector-fortran.h header file, the gfortran.dg/continuation_6.f test
fails.

If I take the f951 command line:

/home/sellcey/tot/install/usr/libexec/gcc/aarch64-linux-gnu/10.0.0/f951
continua
tion_6.f -ffixed-form -quiet -mlittle-endian -mabi=lp64 -auxbase continuation_6 
-O2 -Wall -std=f2003 -version -ffixed-form -fintrinsic-modules-path
/home/sellce
y/tot/install/usr/lib/gcc/aarch64-linux-gnu/10.0.0/finclude
-fpre-include=/home/
sellcey/tot/install/usr/include/finclude/math-vector-fortran.h -o c.s

and remove '-pre-include=/home/.' then the test passes and prints out
the expected warning message.  If the -pre-include option is there then the
warning message does not appear.

I wonder if we turn off warning messages while processing this header file and
forget to turn them back on?

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at redhat dot com]

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

--- Comment #20 from Jeffrey A. Law  ---
Just to be clear, the expansion in question happens very early, essentially
pre-gimple, not at the gimple/RTL border and it's driven by a target macro.

I guess another approach would be to write the whole test in gimple so that we
could avoid the paths that query the target macros and ensure DSE gets the code
in a suitable form.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

--- Comment #21 from Iain Sandoe  ---
Author: iains
Date: Wed Jul 24 19:59:22 2019
New Revision: 273768

URL: https://gcc.gnu.org/viewcvs?rev=273768&root=gcc&view=rev
Log:
[Darwin] Partial reversion of 273749.

We still need to cater for pr80556, for the single-arch case.

2019-07-24  Iain Sandoe  

gcc/

PR bootstrap/87030
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Revert r273749.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Wed Jul 24 20:34:03 2019
New Revision: 273771

URL: https://gcc.gnu.org/viewcvs?rev=273771&root=gcc&view=rev
Log:
PR driver/80545 - option -Wstringop-overflow not recognized by Fortran

gcc/cp/ChangeLog:

PR driver/80545
* decl.c (finish_function): Use lang_mask.

gcc/testsuite/ChangeLog:

PR driver/80545
* gcc.misc-tests/help.exp: Add tests.
* lib/options.exp: Handle C++.

gcc/ChangeLog:

PR driver/80545
* diagnostic.c (diagnostic_classify_diagnostic): Use lang_mask.
(diagnostic_report_diagnostic): Same.
* diagnostic.h (diagnostic_context::option_enabled): Add an argument.
(diagnostic_context::lang_mask): New data member.
* ipa-pure-const.c (suggest_attribute): Use
lang_hooks.option_lang_mask ().
* opts-common.c (option_enabled): Handle new argument.
(get_option_state): Pass an additional argument.
* opts.c (print_filtered_help): Print supported languages for
unsupported options.  Adjust printing of current state.
* opts.h (option_enabled): Add argument.
* toplev.c (print_switch_values): Use lang_mask.
(general_init): Set global_dc->lang_mask.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/ipa-pure-const.c
trunk/gcc/opts-common.c
trunk/gcc/opts.c
trunk/gcc/opts.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.misc-tests/help.exp
trunk/gcc/testsuite/lib/options.exp
trunk/gcc/toplev.c

[Bug fortran/88227] ICE in gfc_convert_boz, at fortran/target-memory.c:788

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> (In reply to Dominique d'Humieres from comment #6)
> > The following test giveS ALSO an ICE with -m32
> > 
> > % cat boz_10.f90
> > print *, real(b'1010101001101',10)
> > end
> > % gfortran -m32 boz_10.f90
> > f951: internal compiler error: Segmentation fault: 11
> > libbacktrace could not find executable to open
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> 
> I've thought about this, and think it can be fixed by
> removing the use gfc_max_integer_kind variable.  Simply
> convert the BOZ to an GMP mpz_t with a suitable width.
> As I don't use multilib or the precision promoting
> options I cannot test the change.

In gfortran's current manifestation, it is not possible
to support BOZ conversion when someone uses a rather 
poor combination of options.  The following patch prevents
the ICE.

Index: check.c
===
--- check.c (revision 273766)
+++ check.c (working copy)
@@ -108,9 +108,8 @@ is_boz_constant (gfc_expr *a)
 bool
 gfc_boz2real (gfc_expr *x, int kind)
 {
-  extern int gfc_max_integer_kind;
   gfc_typespec ts;
-  int len;
+  int i, len;
   char *buf, *str;

   if (!is_boz_constant (x))
@@ -165,6 +164,11 @@ gfc_boz2real (gfc_expr *x, int kind)
   x->boz.str = XCNEWVEC (char, len + 1);
   strncpy (x->boz.str, buf, len);

+  i = gfc_validate_kind (BT_REAL, kind, false);
+  if (gfc_real_kinds[i].mode_precision > 8 * gfc_max_integer_kind)
+gfc_fatal_error ("Insufficient INTEGER kind required "
+"in BOZ conversion at %L!", &x->where);
+
   /* Convert to widest possible integer.  */
   gfc_boz2int (x, gfc_max_integer_kind);
   ts.type = BT_REAL;

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #96 from The Written Word  
---
(In reply to dave.anglin from comment #91)
> On 2019-07-23 5:53 p.m., bugzilla-gcc at thewrittenword dot com wrote:
> > In file included from
> > /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/cmath:43,
> >  from
> > /opt/build/china/gcc-8.3.0/libstdc++-v3/include/precompiled/stdc++.h:41:
> > /opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ext/type_traits.h:103:34:
> > internal compiler error: Segmentation fault
> >  struct __add_unsigned;
> >   ^
> Disable precompiled headers for now.  This will make it easier to find
> problems.

Thanks. That worked. But the build failed again, with what looks like a similar
segfault:
libtool: compile:  /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -shared-libgcc
-B/opt/build/china/gcc-8.3.0/.obj/./gcc -nostdinc++
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/src/.libs
-L/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-B/opt/build/gcc8/ia64-hp-hpux11.31/bin/
-B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/include -isystem
/opt/build/gcc8/ia64-hp-hpux11.31/sys-include
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/../libgcc
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
-I/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include
-I/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=atexit_thread.lo -g -O2 -c
/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/atexit_thread.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o atexit_thread.o
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI,
which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
In file included from
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/bits/move.h:55,
 from
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/bits/nested_exception.h:40,
 from
/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/exception:144,
 from /opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/new:40,
 from
/opt/build/china/gcc-8.3.0/libstdc++-v3/libsupc++/atexit_thread.cc:26:
/opt/build/china/gcc-8.3.0/.obj/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:363:36:
internal compiler error: Segmentation fault
 struct __is_pointer_helper<_Tp*>
^

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #97 from The Written Word  
---
(In reply to C. Heide from comment #73)
> With that change, and some other cajoling (the previously mentioned
> duplicate symbols and operand64 problem, and -O1 to work around the ICE), I
> can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.

No issues with PCH or libsupc++ like I'm seeing?

[Bug target/91189] 20% binary size regression in avr-gcc 9.1.0 from 8.3.0

[zygmuntptak at gmail dot com]

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

Zygmunt  changed:

   What|Removed |Added

 CC||zygmuntptak at gmail dot com

--- Comment #1 from Zygmunt  ---
I can confirm a problem with gcc 9.1.0.

I hit into it today when I tried compile DFU bootloder from LUFA project for
atmega32u4.
>From some unknwon reason for me it compiles without any problem for atmega16u2.

Compiling DFU bootloader for atmega32u4 and atmega16u2 works on gcc-8.3.0.

[Bug jit/87808] gcc_lib_dir is missing from libgccjit's search path when driver is not installed

[doko at debian dot org]

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

--- Comment #7 from Matthias Klose  ---
a patch was posted at
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01045.html

[Bug c/91254] New: Wrong generate code with a series of array access

[alebencz at gmail dot com]

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

Bug ID: 91254
   Summary: Wrong generate code with a series of array access
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alebencz at gmail dot com
  Target Milestone: ---

Created attachment 46625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46625&action=edit
Source that generates the error

The attached program serves to calculate the PI number, after a series of
attempts I found it to be a mistake in GCC, because I tested with other
compilers and the system ran correctly, calculating the PI number, tested with
DMC, VC ++, TCC and OrangeC, I did the same test with GCC on PPC64LE with GCC
version 8.3.0 and on s390x.

The system enters on the first loop, and, never go out.

[Bug c/91254] Wrong generate code with a series of array access

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-07-24
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does -fwrapv fix the issue?
If it does, then does -fsanitize=undefined detect an issue at runtime?

[Bug c/91254] Wrong generate code with a series of array access

[alebencz at gmail dot com]

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

--- Comment #2 from Alexandre Bencz  ---
same problem, with -fwrapv, the program still stucked... and, for a test, I
tried to use the -fsanitize=undefined and the program still stucked...

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[cameron.heide at betasystems dot com]

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

--- Comment #98 from C. Heide  ---
(In reply to The Written Word from comment #97)
> (In reply to C. Heide from comment #73)
> > With that change, and some other cajoling (the previously mentioned
> > duplicate symbols and operand64 problem, and -O1 to work around the ICE), I
> > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.
> 
> No issues with PCH or libsupc++ like I'm seeing?

No, but the only "working" build I've had so far was with the "#undef
MAKE_DECL_ONE_ONLY" hack and had the duplicate symbol problem. If I remove that
hack as recommended, I then get a segfault ICE even earlier than you do, where
the stage 2 compiler seems completely broken and crashes even on a single empty
function (haven't been able to do much with that yet).

[Bug c/91254] Wrong generate code with a series of array access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
I only quickly glanced at the attached test program but the first thing I
noticed is that the memset call clears only a subset of the array elements.  If
the rest of the test case depends on the array being zeroed out as it seems to
it's not going to behave predictably.

  #define ARRAY_SIZE 128000

  int main(int argc, char **argv)
  {
int casas = argc == 2 ? atoi(argv[1]) : 1000;
int x[ARRAY_SIZE];
int xc;
memset(x, 0, ARRAY_SIZE);   <<<

Presumably this should be:

memset(x, 0, sizeof x);

[Bug c/91254] Wrong generate code with a series of array access

[alebencz at gmail dot com]

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

--- Comment #4 from Alexandre Bencz  ---
It's true ... I did not realize this ... well, for testing purposes made a test
using malloc to allocate the array and zeroed all bytes using the memset, with
the correct size and the error persists. I also tested just adjusting the
memset and the error persists.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #99 from The Written Word  
---
(In reply to C. Heide from comment #98)
> (In reply to The Written Word from comment #97)
> > (In reply to C. Heide from comment #73)
> > > With that change, and some other cajoling (the previously mentioned
> > > duplicate symbols and operand64 problem, and -O1 to work around the ICE), 
> > > I
> > > can now get gcc-8.3 to do a full bootstrap on HP-UX 11.23 ia64.
> > 
> > No issues with PCH or libsupc++ like I'm seeing?
> 
> No, but the only "working" build I've had so far was with the "#undef
> MAKE_DECL_ONE_ONLY" hack and had the duplicate symbol problem. If I remove
> that hack as recommended, I then get a segfault ICE even earlier than you
> do, where the stage 2 compiler seems completely broken and crashes even on a
> single empty function (haven't been able to do much with that yet).

What linker patch do you have installed?

[Bug tree-optimization/86688] missing -Wstringop-overflow using a non-string local array in strnlen with excessive bound

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Jul 25 00:29:17 2019
New Revision: 273783

URL: https://gcc.gnu.org/viewcvs?rev=273783&root=gcc&view=rev
Log:
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source not folded
PR tree-optimization/86688 - missing -Wstringop-overflow using a non-string
local array in strnlen with excessive bound

gcc/ChangeLog:

PR tree-optimization/91183
PR tree-optimization/86688
* builtins.c (compute_objsize): Handle MEM_REF.
* tree-ssa-strlen.c (class ssa_name_limit_t): New.
(get_min_string_length): Remove.
(count_nonzero_bytes): New function.
(handle_char_store): Rename...
(handle_store): to this.  Handle multibyte stores via integer types.
(strlen_check_and_optimize_stmt): Adjust conditional and the called
function name.

gcc/testsuite/ChangeLog:

PR tree-optimization/91183
PR tree-optimization/86688
* gcc.dg/Wstringop-overflow-14.c: New test.
* gcc.dg/attr-nonstring-2.c: Remove xfails.
* gcc.dg/strlenopt-70.c: New test.
* gcc.dg/strlenopt-71.c: New test.
* gcc.dg/strlenopt-72.c: New test.
* gcc.dg/strlenopt-8.c: Remove xfails.

Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-14.c
trunk/gcc/testsuite/gcc.dg/strlenopt-70.c
trunk/gcc/testsuite/gcc.dg/strlenopt-71.c
trunk/gcc/testsuite/gcc.dg/strlenopt-72.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-9.c
trunk/gcc/testsuite/gcc.dg/attr-nonstring-2.c
trunk/gcc/testsuite/gcc.dg/strlenopt-8.c
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/91183] strlen of a strcpy result with a conditional source not folded

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Jul 25 00:29:17 2019
New Revision: 273783

URL: https://gcc.gnu.org/viewcvs?rev=273783&root=gcc&view=rev
Log:
PR tree-optimization/91183 - strlen of a strcpy result with a conditional
source not folded
PR tree-optimization/86688 - missing -Wstringop-overflow using a non-string
local array in strnlen with excessive bound

gcc/ChangeLog:

PR tree-optimization/91183
PR tree-optimization/86688
* builtins.c (compute_objsize): Handle MEM_REF.
* tree-ssa-strlen.c (class ssa_name_limit_t): New.
(get_min_string_length): Remove.
(count_nonzero_bytes): New function.
(handle_char_store): Rename...
(handle_store): to this.  Handle multibyte stores via integer types.
(strlen_check_and_optimize_stmt): Adjust conditional and the called
function name.

gcc/testsuite/ChangeLog:

PR tree-optimization/91183
PR tree-optimization/86688
* gcc.dg/Wstringop-overflow-14.c: New test.
* gcc.dg/attr-nonstring-2.c: Remove xfails.
* gcc.dg/strlenopt-70.c: New test.
* gcc.dg/strlenopt-71.c: New test.
* gcc.dg/strlenopt-72.c: New test.
* gcc.dg/strlenopt-8.c: Remove xfails.

Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-14.c
trunk/gcc/testsuite/gcc.dg/strlenopt-70.c
trunk/gcc/testsuite/gcc.dg/strlenopt-71.c
trunk/gcc/testsuite/gcc.dg/strlenopt-72.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/object-size-9.c
trunk/gcc/testsuite/gcc.dg/attr-nonstring-2.c
trunk/gcc/testsuite/gcc.dg/strlenopt-8.c
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/91246] vectorization failure for a small loop to search array element

[jiangning.liu at amperecomputing dot com]

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

--- Comment #2 from Jiangning Liu  ---
Created attachment 46626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46626&action=edit
A new test

Attached is a test case that is more closely matching the real-world code.

[Bug tree-optimization/91246] vectorization failure for a small loop to search array element

[jiangning.liu at amperecomputing dot com]

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

--- Comment #3 from Jiangning Liu  ---
Expect to vectorize the inner loop by generating the code below for x86,

vpbroadcastd [mem], ymm0
vpaddd [mem], ymm0, ymm1
vpbroadcastd reg, ymm2
vpcmpeqd ymm2, ymm1, k0
kortestw k0, k0
cmovne ...

AArch64 should have vectorization instructions counterpart to implement the
same functionality.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81453

--- Comment #10 from Eric Gallager  ---
(In reply to Martin Sebor from comment #8)
> (In reply to rguent...@suse.de from comment #5)
> > Does "unspecified" allow p > q != !(p <= q)?  I think so (it's not
> > implementation defined).
> 
> The exact C++ words that apply here are:
> 
> (4.3)  Otherwise [if two unequal pointers don't point into the same object],
> neither pointer is required to compare greater than the other.
> 
> (it's not explicitly unspecified, but it sounds at least as loose).  So the
> answer is yes.
> 
> I agree with producing a sensible result for QoI (especially if there's no
> warning).  A result that's consistent between [in]equality and relational
> expressions would qualify.
> 
> I also agree that diagnosing all these unspecified (or undefined in C) cases
> would be helpful as they (at least in the straightforward instances) are
> most likely coding mistakes.  I might look into it, though my first concern
> is about the instances that result from some earlier transformations and
> where warnings will be seen as false positives.

Now that you're getting into the diagnostics aspect of this I'd just like to
point out that this could be tied in with fixing bug 81453 at the same time and
the new warnings could be grouped under the -Wordered-pointer-comparison flag
proposed there

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org]

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

Bug 91236 Summary: [10 Regression] ICE in walk_non_aliased_vuses at 
gcc/tree-ssa-alias.c:3395 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91236

   What|Removed |Added

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

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/91236] [10 Regression] ICE in walk_non_aliased_vuses at gcc/tree-ssa-alias.c:3395 on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 25 06:57:46 2019
New Revision: 273787

URL: https://gcc.gnu.org/viewcvs?rev=273787&root=gcc&view=rev
Log:
2019-07-25  Richard Biener  

PR tree-optimization/91236
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): Fix
size of CONSTRUCTOR write.  Fix buffer size we pass to
native_encode_expr.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c