[Bug tree-optimization/85756] New: wrong code at -Os on x86-64-linux-gnu in 32-bit mode

[su at cs dot ucdavis.edu]

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

Bug ID: 85756
   Summary: wrong code at -Os on x86-64-linux-gnu in 32-bit mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180511 (experimental) [trunk revision 260178] (GCC) 
$ 
$ gcctk -m32 -O0 small.c; ./a.out
$ 
$ gcctk -m32 -Os small.c
$ ./a.out
Segmentation fault (core dumped)
$ 


-


int printf (const char *, ...);

int a, c, *e, f, h = 10;
short b;
unsigned int p;

void fn1 ()
{
  unsigned j = 1, m = 430523;
  int k, n = 1, *l = 
L:
  p = m;
  m = -((~65535U | j) - n);
  f = b << ~(n - 8);
  n = (m || b) ^ f;
  j = p;
  if (p < m)
*l = k < 3;
  if (!n)
l = 
  if (c)
{
  printf ("%d", a);
  goto L;
}
  if (!*l)
*e = 1;
}

int main ()
{
  fn1 ();
  return 0; 
}

[Bug target/85755] PowerPC Gcc's -mupdate produces inefficient code on power8/power9 machines

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
That is, that GCC 8 did not do pre-increment, but it did no silliness
with float registers.

[Bug target/85755] PowerPC Gcc's -mupdate produces inefficient code on power8/power9 machines

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-12
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Before RA it is all just fine:

insn_cost 4 for14: [++r121:DI]=r122:DI
  REG_INC r121:DI
insn_cost 4 for15: r122:DI=r122:DI+0x1
insn_cost 0 for30: {pc={(r129:DI!=0x1)?L16:pc};r129:DI=r129:DI-0x1;clobber
scratch;clobber scratch;}
  REG_BR_PROB 955630228

IRA make a good choice:

Disposition:
3:r121 l0 30:r122 l0 94:r125 l0 32:r126 l0 4
5:r127 l0681:r129 l066

and then LRA comes along:

 Choosing alt 6 in insn 14:  (0) ^m  (1) d {*movdi_internal64}
  Creating newreg=132 from oldreg=122, assigning class FLOAT_REGS to r132
   14: [++r121:DI]=r132:DI
  REG_INC r121:DI
Inserting insn reload before:
   35: r132:DI=r122:DI

We want to have alt 0 instead (r -> YZ), which gives

0 Non input pseudo reload: reject++
  alt=0,overall=7,losers=1,rld_nregs=0

but we get alt 6 (d -> ^m), which gives

  alt=6,overall=6,losers=1,rld_nregs=1

Putting the disparagement on the correct operand, i.e. as  ^d -> m  gives

alt=6,overall=12,losers=1 -- refuse

and we should make that change; but yes we want an stdu, too.  Should "Y"
allow that?

GCC 7 did this fine; GCC 8 of a month ago, too.  What changed?

[Bug target/85755] PowerPC Gcc's -mupdate produces inefficient code on power8/power9 machines

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Sigh, i forgot -mcpu=power8 on that last test.

GCC 7 was just fine, stdu, everything.

GCC 8 was bad already.

[Bug tree-optimization/85724] strspn of one-element arrays can be assumed to return zero

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug libffi/85722] testsuite failure in libffi

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Created attachment 44115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44115=edit
libffi test log

(In reply to Chris Giorgi from comment #6)
> Sorry, only pasted one link, here's the libffi test log:
> http://termbin.com/vzy5

Now also attached.

[Bug c++/85746] Premature evaluation of __builtin_constant_p?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug sanitizer/85556] attribute no_sanitize does not accept multiple options as documented

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Fri May 11 07:37:35 2018
New Revision: 260154

URL: https://gcc.gnu.org/viewcvs?rev=260154=gcc=rev
Log:
Support LLVM style of no_sanitize attribute (PR sanitizer/85556).

2018-05-11  Martin Liska  

PR sanitizer/85556
* doc/extend.texi: Document LLVM style format for no_sanitize
attribute.
2018-05-11  Martin Liska  

PR sanitizer/85556
* c-attribs.c (handle_no_sanitize_attribute): Iterate all
TREE_LIST values.
2018-05-11  Martin Liska  

PR sanitizer/85556
* c-c++-common/ubsan/attrib-6.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/attrib-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85725] strchr and strstr of a one-element array with a non-empty string can be assumed to return null

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
doesn't strchr (a, '1') return a if a[0] == '1'?  You seem to read
"in the string s" as imposing s to be properly null-terminated.  I don't.

[Bug c++/85746] New: Premature evaluation of __builtin_constant_p?

[glisse at gcc dot gnu.org]

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

Bug ID: 85746
   Summary: Premature evaluation of __builtin_constant_p?
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

int f(int a,int b){
  int c = __builtin_constant_p(a < b);
  return c;
}

In C or C++98, __builtin_constant_p is passed to the middle-end for further
optimization. In C++11, the front-end produces "c = 0;". That's because C++11
says we should check if the initializer can be constexpr-evaluated, and inside
constexpr evaluation we force the early (pessimistic) evaluation of
__builtin_constant_p.
Maybe we should only evaluate __builtin_constant_p to false when we are
committed to a constexpr evaluation, not for tentative ones as in initializers?
Or maybe we need different versions of __builtin_constant_p for people who want
to use it as if constexpr() and for those who want late optimization?

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
(In reply to Andrew Pinski from comment #1)
> These functions are not functional equivalent.
> 
> In the b.c, it records the max location but it is the last element which
> contains that value.  While in c.c, the first element which contains the
> value is recorded.

I do not understand.

The only difference between the files is

$ diff -u -b b.c c.c
--- b.c 2018-05-10 22:22:06.276904322 +0200
+++ c.c 2018-05-10 22:21:50.028801008 +0200
@@ -14,7 +14,7 @@
   nm = -1;
   for (i=0; i m, 0))
+  if (a[i] > m)
{
  m = a[i];
  nm = i;

Does this change the semantics of the comparison? If it does, it
would be a bug in __builtin_expect.

[Bug target/85744] Returning INT_FAST64_MIN become zero

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
   Last reconfirmed||2018-05-11
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
You should have read https://gcc.gnu.org/bugs/ which explains what we need for
a valid bug report, and would have done that before reporting it.

You probably forgot to declare the function in the calling code so the compiler
assumed it returned int, and only used the low 32 bits, which are all zero.

[Bug target/85744] Returning INT_FAST64_MIN become zero

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Jonathan Wakely  ---
Sorry, I didn't mean to change the status, re-closing.

[Bug target/85733] [8 regression] ARM -mbe8 behaviour doesn't match documentation

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

[Bug rtl-optimization/85745] New: variable with asm register assignment allocated in wrong reg

[bernd.edlinger at hotmail dot de]

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

Bug ID: 85745
   Summary: variable with asm register assignment allocated in
wrong reg
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Created attachment 44114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44114=edit
reduced test case

This prevents linux v4.7 and before to be built with gcc-8.1.0 on armv7
targets.

$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf-linux64/libexec/gcc/arm-linux-gnueabihf/8.1.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-8.1.0/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64 --target=arm-linux-gnueabihf
--enable-languages=all --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 8.1.0 (GCC) 

$ arm-linux-gnueabihf-gcc -save-temps -Os -c test.c
test.s: Assembler messages:
test.s:39: Error: .err encountered


in test.s we see, that __r2 is allocated in r3 but that is unexpected,
it should have been r2:
sys_oabi_sendmsg:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
cmp r1, #0
bxeqlr
uxthr2, r2
cmp r2, #1
cmpeq   r0, #0
bxnelr
mov r3, #0
str lr, [sp, #-4]!
ldr r3, [r3]
mov r0, r1
sub r1, r3, #1
mov r3, #110
.syntax divided
@ 37 "000.c" 1
.ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12;
.ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif
.ifnc r3,r2; .ifnc r3r2,fpr11; .ifnc r3r2,r11fp; .ifnc r3r2,ipr12;
.ifnc r3r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif
.ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12;
.ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif
bl  __put_user_4
@ 0 "" 2
.arm
.syntax unified
ldr pc, [sp], #4


The after v4.8 this macro was a bit simplified, and causes less register
pressure, but I think it works only by chance.

I am not sure if that is a wrong expectation or a compiler bug.
It would be fixed when __r2 is declared volatile for instance.

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Dup of PR23094 (and fixed).

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

[Bug tree-optimization/85720] bad codegen for looped assignment of primitives at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||amker at gcc dot gnu.org
  Component|middle-end  |tree-optimization

--- Comment #5 from Richard Biener  ---
(In reply to Mathias Stearn from comment #4)
> (In reply to Marc Glisse from comment #3)
> > Again, you are ignoring aliasing issues (just like in your other PR the
> > function copy isn't equivalent to memmove). Does adding __restrict change
> > the result? Also, B[i]=B[i]+1 doesn't look like a memset...
> 
> Sorry, I typoed. It was supposed to be B[i] = A[i] + 1. That still does
> basically the same thing though: https://godbolt.org/g/dtmU5t. Good point
> about aliasing though. I guess the right code gen in that case would
> actually be something that detected the overlap and did the right calls to
> memset to only set each byte once. Or just do the simple thing:
> 
> if (b > a && b < a + n) {
>   memset(b, 1, n);
>   memset(a, 0, n);
> } else {
>   memset(a, 0, n);
>   memset(b, 1, n);
> }
> 
> Yes, __restrict helps, but that isn't part of standard c++, and it seems
> like it never will be.

GCC supports it since forever...  but yes, currently loop distribution
doesn't consider runtime aliasing in this case (it can do it now but
is keyed to vectorization).  It also doesn't have a way to distinguish
forward vs. backward dependence and split the case like you propose.

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 11 07:42:50 2018
New Revision: 260156

URL: https://gcc.gnu.org/viewcvs?rev=260156=gcc=rev
Log:
PR c/85696
* c-omp.c (c_omp_predetermined_sharing): Return
OMP_CLAUSE_DEFAULT_SHARED for artificial vars with integral type.

* cp-tree.h (cxx_omp_predetermined_sharing_1): New prototype.
* cp-gimplify.c (cxx_omp_predetermined_sharing): New wrapper around
cxx_omp_predetermined_sharing_1.  Rename old function to ...
(cxx_omp_predetermined_sharing_1): ... this.
* semantics.c (finish_omp_clauses): Use cxx_omp_predetermined_sharing_1
instead of cxx_omp_predetermined_sharing.

* c-c++-common/gomp/pr85696.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr85696.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85692] Two source permute not used for vector initialization

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 11 07:38:49 2018
New Revision: 260155

URL: https://gcc.gnu.org/viewcvs?rev=260155=gcc=rev
Log:
PR tree-optimization/85692
* tree-ssa-forwprop.c (simplify_vector_constructor): Try two
source permute as well.

* gcc.target/i386/pr85692.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr85692.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Fri, 11 May 2018, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80617
> 
> --- Comment #12 from Marc Glisse  ---
> (In reply to Richard Biener from comment #11)
> > Dup of PR23094 (and fixed).
> 
> Richard, comment #9 shows that the original testcase is only half-fixed 
> (though
> the other half seems hard to fix). Does this mean you consider the second half
> as WONTFIX?

So ...

  __old_val_5 = MEM[(void * &)a_2(D)];
  MEM[(void * &)a_2(D)] = 0B;
  __old_val_6 = MEM[(void * &)b_3(D)];
  MEM[(void * &)b_3(D)] = 0B;
  MEM[(void * &)a_2(D)] = __old_val_6;
  _7 = MEM[(void * &)b_3(D)];
  MEM[(void * &)b_3(D)] = __old_val_5;
  if (_7 != 0B)

.. the logic is that if a and b alias they have to exactly overlap
and thus _7 is __old_val_6 which is then 0.

While it might be quite interesting to try considering this
it requires a bit too much magic for the current machinery ;)
We've already value-numbered __old_val_6 but we would need to
re-visit its def with the constraint a_2 == b_3 so this would
add some back-propagation to the forward-working value-numbering.

The PR23094 fix is already somewhat limited and I'm not holding
my breath on the above given it doesn't fit any existing
optimization algorithm very well...  (complexity also explodes
once you need to consider any combination of exact-overlap
aliases).

We can re-open this to track the issue.

[Bug target/85744] Returning INT_FAST64_MIN become zero

[cerlane at nscc dot sg]

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

--- Comment #7 from cerlane  ---
(In reply to Jonathan Wakely from comment #5)
> You should have read https://gcc.gnu.org/bugs/ which explains what we need
> for a valid bug report, and would have done that before reporting it.
> 
> You probably forgot to declare the function in the calling code so the
> compiler assumed it returned int, and only used the low 32 bits, which are
> all zero.

No that is not true. I have the function declared in the header file. It is
included everywhere.
The problem is harder to debug. For all other #values, they work correctly. I
still can't figure out the issue. I tested every combination including compiler
flags before my last reply. If it turns out to be a compiler issue, I will
resubmit. Thanks.

[Bug tree-optimization/85726] [6/7/8/9 Regression] div C1 to div C2 match.pd suboptimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2
   Target Milestone|--- |6.5

--- Comment #2 from Richard Biener  ---
Confirmed.  On x86 the diff from GCC 4.8 to GCC 7 at -O2 is

@@ -6,8 +6,16 @@
 x:
 .LFB0:
.cfi_startproc
+   movl%edi, %eax
+   movl$715827883, %edx
+   imull   %edx
+   movl%edi, %eax
+   sarl$31, %eax
+   sarl$3, %edx
+   subl%eax, %edx
leal15(%rdi), %eax
testl   %edi, %edi
+   movl%edx, ww(%rip)
movl$1431655766, %edx
cmovs   %eax, %edi
movl%edi, %ecx
@@ -15,9 +23,9 @@
sarl$4, %ecx
movl%ecx, %eax
imull   %edx
-   subl%edi, %edx
-   leal(%rdx,%rdx,2), %eax
-   movl%edx, ww(%rip)
+   movl%edx, %eax
+   subl%edi, %eax
+   leal(%rax,%rax,2), %eax
subl%eax, %ecx
movl%ecx, %eax
ret

[Bug libffi/85722] testsuite failure in libffi

[chrisgiorgi at gmail dot com]

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

--- Comment #6 from Chris Giorgi  ---
Sorry, only pasted one link, here's the libffi test log:
http://termbin.com/vzy5

[Bug libffi/85722] testsuite failure in libffi

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(Based on discussion on IRC these log files are just copy from the
terminal connected to the machines where gcc is being built, because of some
weird restricted system with limited access which also prevents attaching files
here properly)

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #44 from Richard Biener  ---
(In reply to Jason Merrill from comment #40)
> (In reply to Richard Biener from comment #39)
> > so - how do I make X::X used and thus prevail?  It looks like it doesn't
> > really exist
> 
> True, for C++14 and up, "X x{};" does aggregate initialization rather than
> calling the constructor.  We ought to warn about this at function scope, but
> we clear the object first, so it isn't actually uninitialized.
> 
> As you found, removing the {} makes it use the constructor.
> 
> > OK, doing void foo() { X x; } shows
> > 
> > X::X (struct X * const this)
> > {
> >   _1 = this->x2;
> >   this->x1 = _1;
> >   this->x2 = 0;
> > }
> > 
> > foo ()
> > {
> >   struct X x;
> > 
> >   try
> > {
> >   X::X ();
> > }
> >   finally
> > {
> >   x = {CLOBBER};
> > }
> > }
> > 
> > warning would need inlining of the constructor which only happens after
> > the early warning pass, the late one isn't run at -O0 and with optimization
> > everything of course vanishes.
> 
> I was wondering about a maybe-uninitialized warning for the constructor
> without considering where it's called from; even if a particular object is
> zero-initialized when we enter the implicit constructor, the constructor
> shouldn't rely on that.  Basically, warn as if there were a clobber, without
> there actually being one.

Interesting suggestion but that's IMHO a bit too much information from
the outside to pack into the middle-end code.  That we're dealing with
accesses to *this and that we are inside a constructor.  You'd need to
add that here, tree-ssa-uninit.c:warn_uninitialized_vars

  /* Do not warn if it can be initialized outside this function.
 If we did not reach function entry then we found killing
 clobbers on all paths to entry.  */
  if (fentry_reached
  /* ???  We'd like to use ref_may_alias_global_p but that
 excludes global readonly memory and thus we get bougs
 warnings from p = cond ? "a" : "b" for example.  */
  && (!VAR_P (base)
  || is_global_var (base)))
continue;

given we have to constrain this to must-aliases of *this the easiest
check would be sth like

   && (!eligible-constructor (cfun)
   || TREE_CODE (base) != MEM_REF
   || TREE_OPERAND (base, 0) != default-def-of-this-parm))

and then elide the warning to maybe-uninit.  I guess we now have a flag
whether a function is a constructor and we also can get at the this
parm-decl so in theory "enhancing" the warning this way would be possible.

[Bug target/85744] Returning INT_FAST64_MIN become zero

[cerlane at nscc dot sg]

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

cerlane  changed:

   What|Removed |Added

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

--- Comment #4 from cerlane  ---
(In reply to Andrew Pinski from comment #3)
> Can you provide the preprocessed source then?

To provide the preprocessed source, I extracted the function and call it
directly from the same file. It then returns the correct value. However, when I
called the "actual" function, which is in an archive, I reproduce the error. 

This means it is not a gcc standard error, but a compilation or some other
issues. I am unsure if this is the correct place to continue the discussion.

Thanks very much for your very quick response in any case.

[Bug tree-optimization/85721] bad codegen for looped copy of primitives at -O2 and -O3 (differently bad)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 CC||amker at gcc dot gnu.org
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
Indeed loop distribution doesn't consider to alias-version the loop this way
for pattern recognition.

[Bug ipa/85734] --suggest-attribute=malloc misdiagnoses static functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|c   |ipa
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I guess this applies to all attribute suggestions.  Honza?

[Bug fortran/85738] internal compiler error: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 Ever confirmed|0   |1
  Known to fail||7.3.1

--- Comment #1 from Richard Biener  ---
And with -fno-checking:

t.f90:8:0:

 gx=fx(l)**2/(2*(2*l + 1))

internal compiler error: in convert_move, at expr.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
Confirmed with a Haswell CPU as well.  Without the __builtin_expect we
rightfully predict the branch to be 50%/50% which means BB re-ordering will do
either nothing to pre-existing order or apply some other magic.  CFG
construction makes the
flow exactly as visible in the source.

So not sure what you are asking here, but annotating the libgfortran routines
or inline expansion from the FE with __builtin_expect is probably a good idea.

At least I can't really see how to easily derive a new predictor that would
match
this case...

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 9.1+ so far, backports queued.

[Bug c++/85739] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[freddie_chopin at op dot pl]

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

--- Comment #1 from Freddie Chopin  ---
I'm currently in the process of reducing the test case with the wonderful tool
that I've found yesterday - C-Reduce (; I hope that I'll be able to upload
something short and generic (not requiring arm-none-eabi) within a few hours.

[Bug target/85606] [8 regression] Assembly file generated for ARM Cortex-M0 should not specify `.arch armv6-m` at all or use `.arch armv6s-m`

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri May 11 09:28:10 2018
New Revision: 260157

URL: https://gcc.gnu.org/viewcvs?rev=260157=gcc=rev
Log:
[arm] PR target/85606 prefer armv6s-m for armv6-m parts

When Arm introduced ARMv6-M there were two variants, ARMv6-M and
ARMv6S-M.  The two differed only in support for the SVC instruction.
Later on SVC was then made a mandatory part of ARMv6-M and the
ARMv6S-M name was dropped.  GCC and GAS, however still recognize both
names and at least some versions of GAS still distinguish between the
two.

To address this, this patch changes the architecture for the ARMv6-m
cortex parts (m0, m0plus, m1 and the variants will small multiply
units) to use the ARMv6S-M name in conjunction with the assembler.
This avoids problems with them rejecting code that was previously
accepted with older versions of GCC where we did not pass an explicit
architecture string through to the compiler when using -mcpu on the
command line.

PR target/85606
* config/arm/arm-cpus.in: Add comment that ARMv6-m and ARMv6S-m are now
equivalent.
(cortex-m0): Use armv6s-m isa.
(cortex-m0plus): Likewise.
(cortex-m1): Likewise.
(cortex-m0.small-multiply): Likewise.
(cortex-m0plus.small-multiply): Likewise.
(cortex-m1.small-multiply): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-cpus.in

[Bug c++/85747] suboptimal code without constexpr

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Antony Polukhin from comment #0)
> Could the compiler detect that `a[7]` holds values known at compile time and
> force the constexpr on `sort(a + 0, a + 7);`?

There has to be a limit. If I write a program that computes the trillion's
decimal of pi, this is a constant, do you expect the compiler to evaluate the
whole program and compile it to just return cst? We are moving into a realm
where we would want to mix compilation and execution, sort of JIT.
For smaller functions, some heuristics could be used to try compile-time
evaluation, but sorting an array of size 7 already seems large to me.

> Could the compiler detect that
> the function `generate()` is an `__attribute__((const))` function without
> arguments and fully evaluate it's body?

If you call the function twice in a row, the compiler removes the second call
and reuses the result from the first, so at least it notices that generate is
pure.

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Thomas Koenig from comment #5)
> (In reply to Andrew Pinski from comment #1)
> > These functions are not functional equivalent.
> > 
> > In the b.c, it records the max location but it is the last element which
> > contains that value.  While in c.c, the first element which contains the
> > value is recorded.
> 
> I do not understand.
> 
> The only difference between the files is
> 
> $ diff -u -b b.c c.c
> --- b.c 2018-05-10 22:22:06.276904322 +0200
> +++ c.c 2018-05-10 22:21:50.028801008 +0200
> @@ -14,7 +14,7 @@
>nm = -1;
>for (i=0; i  {
> -  if (__builtin_expect (a[i] > m, 0))
> +  if (a[i] > m)
> {
>   m = a[i];
>   nm = i;
> 
> Does this change the semantics of the comparison? If it does, it
> would be a bug in __builtin_expect.

The documentation is hard to understand but you are correct that it just says
we are expecting the value of the comparison to be false.

Anyways the problem here is a bit more complex than just marking the edge as
expect.

For aarch64 we produce csel (which is basically cmov) for both loops:
.L11:
ldr w4, [x5, x2, lsl 2]
cmp w3, w4
cselw0, w0, w2, ge
add x2, x2, 1
cselw3, w3, w4, ge
cmp w1, w2
bgt .L11

[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #20 from Richard Biener  ---
*** Bug 80617 has been marked as a duplicate of this bug. ***

[Bug c++/85715] internal compiler error: in reshape_init_class ( in anonymous union )

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Thus a duplicate.

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

[Bug c++/84874] [6/7 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:5800

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||daffra.claudio at gmail dot com

--- Comment #8 from Richard Biener  ---
*** Bug 85715 has been marked as a duplicate of this bug. ***

[Bug libffi/85722] testsuite failure in libffi

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
You are building gmp/mpfr in-tree - what versions?  __i386__ isn't defined on
x86_64 so the issue looks in whatever does those "testcases".  The log isn't
helpful as it seems to be produced with -jN and isn't part of the libffi
testsuite.

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.2

[Bug tree-optimization/85692] Two source permute not used for vector initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for 9.1+, thanks for the patch and report.

[Bug target/85733] [8 regression] ARM -mbe8 behaviour doesn't match documentation

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |8.2
Summary|ARM -mbe8 behaviour doesn't |[8 regression] ARM -mbe8
   |match documentation |behaviour doesn't match
   ||documentation
 Ever confirmed|0   |1

[Bug c++/85717] anonymous union in initializer list : do not handle the types correctly

[daffra.claudio at gmail dot com]

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

--- Comment #4 from claudio daffra  ---

I expect that the compiler regardless of the location of the types 

always gives me the same result, error message or warning

indeed :

# case integer before double :

union 
{
uint64_tinteger ;   
double  real;
} ;

gives me error, about narrowing conversion :

prova.cpp:32:5: error: narrowing conversion of '3.3999e+0' from
'double' to 'uint64_t {aka long long unsigned int}' inside { } [-Wnarrowing]
  t1 = { 1 ,"a",3.4 } ;
 ^

# case double before integer, compile without warning or error me :


union 
{
double  real;
uint64_tinteger ;   
} ;

and about output gives me undefined behavior about integer

t1 = { 1 ,"a",3.4 } ;   
std::cout << t1.real << "\n" ;

t1 = { 1 ,"a",2 } ;
std::cout << t1.integer << "\n" ;   

C:\prj>x.exe
6.6
3
3.4
4611686018427387904

however if it is a normal behavior of c++ or compiler, close it.

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Richard Biener from comment #7)
> Confirmed with a Haswell CPU as well.  Without the __builtin_expect we
> rightfully predict the branch to be 50%/50% which means BB re-ordering will
> do either nothing to pre-existing order or apply some other magic.  CFG
> construction makes the
> flow exactly as visible in the source.
> 
> So not sure what you are asking here, but annotating the libgfortran routines
> or inline expansion from the FE with __builtin_expect is probably a good
> idea.

If the code is emitted in Fortran FE, that it's similar to specific predictors:
grep for 'PRED_FORTRAN_'. These are predictors emitted by the FE and can have
specific probability based on SPEC benchmarks. 

Can you Thomas point me to code that emits the maxloc/minloc?

> 
> At least I can't really see how to easily derive a new predictor that would
> match
> this case...

Agree.

[Bug target/85606] [8,9 regression] Assembly file generated for ARM Cortex-M0 should not specify `.arch armv6-m` at all or use `.arch armv6s-m`

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|[8 regression] Assembly |[8,9 regression] Assembly
   |file generated for ARM  |file generated for ARM
   |Cortex-M0 should not|Cortex-M0 should not
   |specify `.arch armv6-m` at  |specify `.arch armv6-m` at
   |all or use `.arch armv6s-m` |all or use `.arch armv6s-m`

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

[Bug c++/85747] suboptimal code without constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Well.  Besides of the C++ frontend the compiler has no facility to fully
evaluate a part of a program but for cases like this it would rely on
inlining then unrolling and then constant propagation.  All this work has
limits and heuristics and there are just cases where the heuristics need
to give up...

What's the reason for writing the code as you pasted it?

Note that sort isn't a const function since it modifies global memory.

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[juergen.reuter at desy dot de]

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

--- Comment #17 from Jürgen Reuter  ---
Sorry, I don't want to generate unnecessary traffic, I'm just scrolling thru
old c.l.f. discussions and stumble over some old reports there from time to
time.

[Bug tree-optimization/85725] strchr and strstr of a one-element array with a non-empty string can be assumed to return null

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

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

--- Comment #2 from Andreas Schwab  ---
The C standard defines a string as "a contiguous sequence of characters
terminated by and including the first null character" (7.1.1).

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #27 from Martin Liška  ---
I'm sorry for not having enough time. If GCC 7 and 8 is fine, then I won't
spend much time investigating version 6. Thanks for understanding.

[Bug fortran/85742] sizeof allocatable arrays returning wrong value

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Since it's my doing, I am on to it.

Thanks for the heads up

Paul

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #15 from Jürgen Reuter  ---
This gives in ICE now with the current trunk, while it just shows an error
message for a "Deleted feature" when using -std=f95.

[Bug fortran/85742] [8/9 Regression] sizeof allocatable arrays returning wrong value

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
 Status|NEW |ASSIGNED
  Known to work||7.3.0
   Target Milestone|--- |8.2
Summary|sizeof allocatable arrays   |[8/9 Regression] sizeof
   |returning wrong value   |allocatable arrays
   ||returning wrong value
  Known to fail||8.1.0, 9.0

--- Comment #2 from Dominique d'Humieres  ---
Caused by r257065. Marked as ASSIGNED.

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> This gives in ICE now with the current trunk, while it just shows
> an error message for a "Deleted feature" when using -std=f95.

Confirmed from at least 4.8 up to trunk (9.0).

[Bug c++/85747] New: suboptimal code without constexpr

[antoshkka at gmail dot com]

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

Bug ID: 85747
   Summary: suboptimal code without constexpr
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the following code snippet:

// Bubble-like sort. Anything complex enough will work
template 
constexpr void sort(It first, It last) {
for (;first != last; ++first) {
auto it = first;
++it;
for (; it != last; ++it) {
if (*it < *first) {
auto tmp = *it;
*it = *first;
*first = tmp;
}
}
}
}

static int generate() {
int a[7] = {3, 7, 4, 2, 8, 0, 1};
sort(a + 0, a + 7);
return a[0] + a[6];
}

int no_constexpr() {
return generate();
}



Above code generates ~30 assembly instructions instead of just generating:

no_constexpr():
  mov eax, 8
  ret



But if we change `static` to `constexpr` then the compiler will optimize the
code correctly.

Could the compiler detect that `a[7]` holds values known at compile time and
force the constexpr on `sort(a + 0, a + 7);`? Could the compiler detect that
the function `generate()` is an `__attribute__((const))` function without
arguments and fully evaluate it's body?

[Bug debug/85748] dbg, gfortran: Erroneous watch of matrix rows as formal arguments using assumed shape

[eberhard.fr...@th-nuernberg.de]

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

Eberhard Franz  changed:

   What|Removed |Added

 CC||eberhard.franz@th-nuernberg
   ||.de

--- Comment #1 from Eberhard Franz  ---
Created attachment 44117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44117=edit
Fortran sample program

[Bug debug/85748] New: dbg, gfortran: Erroneous watch of matrix rows as formal arguments using assumed shape

[eberhard.fr...@th-nuernberg.de]

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

Bug ID: 85748
   Summary: dbg, gfortran: Erroneous watch of matrix rows as
formal arguments using assumed shape
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eberhard.fr...@th-nuernberg.de
  Target Milestone: ---

The newer versions of gdb have greatly simplified watching of Fortran arrays.
No longer *((real_8 *)y)@2 or similiar when one wants to watch arrays passed by
assumed shape to a subprogram. Just type the name of the array ... Thank you
very much for it!

But I believe there is a bug in watching arrays in a special case. This special
case occurs when you pass the row of a matrix (e.g. A(3, :)) to a subprogram
using assumed shape. The subprogram handles such vectors absolutely correctly,
but the vectors are displayed incorrectly using print in gdb. Obviously one
will see the first element of the row followed by wrong elements.

This error doesn't occur when one uses explict shape passing the matrix row.

I wrote a little sample program in order to demonstrate this behaviour and
attached it.

[Bug target/83687] [6 Regression] ARM NEON invalid optimisation for vabd/vabdl

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed on the active branches.

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I can see what the patch does to this testcase on x86_64 - it enables BB
vectorization of the first two loops after runrolling.  I don't see anything
suspicious here on x86_64 and 525.x264_r works fine for me.

Can you claify whether test, ref or train inputs fail for you?  I tried
AVX256, AVX128 and plain old SSE sofar without any issue but ref takes some
time...

Can you check whether the following reduced file produces the same assembly
for add4x4_idct as in the complete benchmark?  If so it should be possible to
generate a runtime testcase from it.  Please attach preprocessed source if
that doesn't work out.

Sofar I do suspect we are hitting a latent target issue?

#include 
static uint8_t x264_clip_uint8( int x )
{
  return x&(~255) ? (-x)>>31 : x;
}
void add4x4_idct( uint8_t *p_dst, int16_t dct[16])
{
  int16_t d[16];
  int16_t tmp[16];
  for( int i = 0; i < 4; i++ )
{
  int s02 =  dct[0*4+i] +  dct[2*4+i];
  int d02 =  dct[0*4+i] -  dct[2*4+i];
  int s13 =  dct[1*4+i] + (dct[3*4+i]>>1);
  int d13 = (dct[1*4+i]>>1) -  dct[3*4+i];
  tmp[i*4+0] = s02 + s13;
  tmp[i*4+1] = d02 + d13;
  tmp[i*4+2] = d02 - d13;
  tmp[i*4+3] = s02 - s13;
}
  for( int i = 0; i < 4; i++ )
{
  int s02 =  tmp[0*4+i] +  tmp[2*4+i];
  int d02 =  tmp[0*4+i] -  tmp[2*4+i];
  int s13 =  tmp[1*4+i] + (tmp[3*4+i]>>1);
  int d13 = (tmp[1*4+i]>>1) -  tmp[3*4+i];
  d[0*4+i] = ( s02 + s13 + 32 ) >> 6;
  d[1*4+i] = ( d02 + d13 + 32 ) >> 6;
  d[2*4+i] = ( d02 - d13 + 32 ) >> 6;
  d[3*4+i] = ( s02 - s13 + 32 ) >> 6;
}
  for( int y = 0; y < 4; y++ )
{
  for( int x = 0; x < 4; x++ )
p_dst[x] = x264_clip_uint8( p_dst[x] + d[y*4+x] );
  p_dst += 32;
}
}

[Bug target/85606] [8 regression] Assembly file generated for ARM Cortex-M0 should not specify `.arch armv6-m` at all or use `.arch armv6s-m`

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri May 11 09:30:49 2018
New Revision: 260158

URL: https://gcc.gnu.org/viewcvs?rev=260158=gcc=rev
Log:
[arm] PR target/85606 prefer armv6s-m for armv6-m parts

When Arm introduced ARMv6-M there were two variants, ARMv6-M and
ARMv6S-M.  The two differed only in support for the SVC instruction.
Later on SVC was then made a mandatory part of ARMv6-M and the
ARMv6S-M name was dropped.  GCC and GAS, however still recognize both
names and at least some versions of GAS still distinguish between the
two.

To address this, this patch changes the architecture for the ARMv6-m
cortex parts (m0, m0plus, m1 and the variants will small multiply
units) to use the ARMv6S-M name in conjunction with the assembler.
This avoids problems with them rejecting code that was previously
accepted with older versions of GCC where we did not pass an explicit
architecture string through to the compiler when using -mcpu on the
command line.

PR target/85606
* config/arm/arm-cpus.in: Add comment that ARMv6-m and ARMv6S-m are now
equivalent.
(cortex-m0): Use armv6s-m isa.
(cortex-m0plus): Likewise.
(cortex-m1): Likewise.
(cortex-m0.small-multiply): Likewise.
(cortex-m0plus.small-multiply): Likewise.
(cortex-m1.small-multiply): Likewise.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm-cpus.in

Hollow Rotor - Lower Cost Rotor for Downhole PC Pump / Mud Motor

[EvenWall]

__ 


Even Wall Thickness Hollow Rotor For Downhole PC Pump
* Well washing through hollow rotor;

* Steam injection into well through hollow sucker rod and hollow rotor;
  * use of same components of sucker rod pumping system for both pumping and 
injecting.
  * The system requires the drilling of only one well for injection.
  * The injected steam builds up a steam chamber that rises to the top of the 
reservoir.
  * While steam injection heats up the oil and improves the flow 
characteristic, hot oil drains  into the production well.

* Huge cost savings  because of material saving,price is 1/3 lower compared 
with solid rotor.


-- 

Subscription Reminder: You're Subscribed to, EvenWall 
Using the address: gcc-bugs@gcc.gnu.org

From: evenw...@hawne.com
Wuhan EvenWall Machinery Co., Ltd.

[Bug c++/85739] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[freddie_chopin at op dot pl]

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

Freddie Chopin  changed:

   What|Removed |Added

  Attachment #44111|0   |1
is obsolete||

--- Comment #2 from Freddie Chopin  ---
Created attachment 44116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44116=edit
reduced and generic test case for gcc 8.1.0

I attach reduced test case for gcc 8.1.0. Interestingly today I cannot
reproduce the error for previous versions of gcc, which means that either I
just got confused yesterday or the triggering code is a bit different. So for
now let's ignore previous versions and focus on gcc 8.1.0.

Using the test case:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ --version
g++ (GCC) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -c Scheduler-8.cpp -std=c++14

$ g++ -c Scheduler-8.cpp -std=c++17
Scheduler-8.cpp: In instantiation of ‘class B’:
Scheduler-8.cpp:29:20:   required from here
Scheduler-8.cpp:3:47: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3057
 template  class B { using e = ptrdiff_t; };
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Fri May 11 09:35:55 2018
New Revision: 260160

URL: https://gcc.gnu.org/viewcvs?rev=260160=gcc=rev
Log:
2018-05-11  Paul Thomas  

PR fortran/68846
PR fortran/70864
backport from trunk
* resolve.c (get_temp_from_expr): The temporary must not have
dummy or intent attributes.

2018-05-11  Paul Thomas  

PR fortran/68846
backport from trunk
* gfortran.dg/temporary_3.f90 : New test.

PR fortran/70864
backport from trunk
* gfortran.dg/temporary_2.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/temporary_2.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/temporary_3.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/70864] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Fri May 11 09:35:55 2018
New Revision: 260160

URL: https://gcc.gnu.org/viewcvs?rev=260160=gcc=rev
Log:
2018-05-11  Paul Thomas  

PR fortran/68846
PR fortran/70864
backport from trunk
* resolve.c (get_temp_from_expr): The temporary must not have
dummy or intent attributes.

2018-05-11  Paul Thomas  

PR fortran/68846
backport from trunk
* gfortran.dg/temporary_3.f90 : New test.

PR fortran/70864
backport from trunk
* gfortran.dg/temporary_2.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/temporary_2.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/temporary_3.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/83687] [6 Regression] ARM NEON invalid optimisation for vabd/vabdl

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri May 11 09:35:31 2018
New Revision: 260159

URL: https://gcc.gnu.org/viewcvs?rev=260159=gcc=rev
Log:
[arm] PR target/83687: Fix invalid combination of VSUB + VABS into VABD

PR target/83687
* config/arm/neon.md (neon_vabd_2): Use VCVTF mode iterator.
Remove integer-related logic from pattern.
(neon_vabd_3): Likewise.

* gcc.target/arm/neon-combine-sub-abs-into-vabd.c: Delete integer
tests.
* gcc.target/arm/pr83687.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/pr83687.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/neon.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog
   
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/neon-combine-sub-abs-into-vabd.c

[Bug rtl-optimization/85745] variable with asm register assignment allocated in wrong reg

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The reason this happens is that the register variable is marked const.  Don't
do that.  If it is const, the compiler optimizes it more aggressively - it will
happily fold uses of the variable to the constant ininitializer, so the inline
asm becomes "r" (110) instead of "r" (__r2) and thus it can use any register.
This is how C++ behaved for years and how C in GCC behaves since the folding
improvements.
--- gcc/c/c-fold.c  2018-05-10 19:39:13.750529734 +0200
+++ gcc/c/c-fold.c  2018-05-11 17:57:12.941957170 +0200
@@ -165,7 +165,10 @@ c_fully_fold_internal (tree expr, bool i
   if (!IS_EXPR_CODE_CLASS (kind) || kind == tcc_statement)
 {
   /* Except for variables which we can optimize to its initializer.  */
-  if (VAR_P (expr) && !lval && (optimize || in_init))
+  if (VAR_P (expr)
+ && !lval
+ && (optimize || in_init)
+ && !DECL_HARD_REGISTER (expr))
{
  if (in_init)
ret = decl_constant_value_1 (expr, true);
would be a workaround for this, but not really sure if we want to use it.

[Bug c++/85746] Premature evaluation of __builtin_constant_p?

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #2)
> For different versions there is the
> http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00355.html
> patch.

Time to ping that one? ;-)
(I don't have a particular opinion about how __builtin_early_constant_p should
behave)

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Author: jamborm
Date: Fri May 11 15:55:15 2018
New Revision: 260165

URL: https://gcc.gnu.org/viewcvs?rev=260165=gcc=rev
Log:
Check is_single_const in intersect_with_plats

2018-05-11  Martin Jambor  

PR ipa/85655
* ipa-cp.c (intersect_with_plats): Check that the lattice contains
single const.

testsuite/
* g++.dg/lto/pr85655_0.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/lto/pr85655_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85747] suboptimal code without constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
IMHO just use constexpr if you care about compile time evaluation guarantees,
that is what it has been added for.

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Fri May 11 15:58:29 2018
New Revision: 260166

URL: https://gcc.gnu.org/viewcvs?rev=260166=gcc=rev
Log:
Check is_single_const in intersect_with_plats

2018-05-11  Martin Jambor  

PR ipa/85655
* ipa-cp.c (intersect_with_plats): Check that the lattice contains
single const.

testsuite/
* g++.dg/lto/pr85655_0.C: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr85655_0.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/ipa-cp.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

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

[thopre01 at gcc dot gnu.org]

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

--- Comment #13 from Thomas Preud'homme  ---
Remains now:

1) add support for PIC access to the guard
2) finish cleanup of the patch

[Bug tree-optimization/82571] missing strlen optimization for memchr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||6.4.0, 7.3.0, 8.1.0

--- Comment #1 from Martin Sebor  ---
Looks like I forgot to include a test case in comment #0.  Here's a simple one
showing the optimization done for strchr and the missing equivalent
optimization for memchr.

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
int f0 (void)
{
  char a[] = "123";
  return 0 != __builtin_strchr (a, 0);   // folded to 1
}

int f1 (void)
{
  char a[] = "123";
  return 0 != __builtin_memchr (a, 0, sizeof a);   // not folded but could be
}

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

f0 ()
{
   [local count: 1073741825]:
  return 1;

}



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

f1 ()
{
  char a[4];
  void * _1;
  _Bool _2;
  int _5;

   [local count: 1073741825]:
  a = "123";
  _1 = __builtin_memchr (, 0, 4);
  _2 = _1 != 0B;
  _5 = (int) _2;
  a ={v} {CLOBBER};
  return _5;

}

[Bug c++/85746] Premature evaluation of __builtin_constant_p?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
For different versions there is the
http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00355.html
patch.

[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with -mprefer-vector-width=256 or 512 on Zen

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor  ---
When benchmarking GCC 8 on an older Ivy Bridge Xeon, I also got 549.fotonik3d_r
verification error just with -Ofast -g -march=native -mtune=native

[Bug target/85733] [8,9 regression] ARM -mbe8 behaviour doesn't match documentation

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri May 11 13:30:55 2018
New Revision: 260163

URL: https://gcc.gnu.org/viewcvs?rev=260163=gcc=rev
Log:
[arm] PR target/85733 Restore be8 linking behaviour for ARMv6-M and products
deriving from its capabilities

My patch last year to automate passing the be8 flag to the linker had
a nasty flaw in that I forgot entirely that the ARMv6-M architecture
did not derive its capabilities directly from the ARMv6 capability
list, but was a new group of capabilities (since it needs to leave out
the ARM -- notm -- feature bit).  The feature list defined was thus
missing the be8 bit.  Furthermore, any product derived from that
feature group consequently lacked the be8 feature as well and this
included all ARMv7 and ARMv8 parts.

The fix is embarrassingly simple...

PR target/85733
* config/arm/arm-cpus.in (fgroup ARMv6m): Add be8 feature.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm-cpus.in

[Bug ipa/85734] --suggest-attribute=malloc misdiagnoses static functions

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
I will take a look.

Regards,
Prathamesh

[Bug middle-end/81914] [7 Regression] gcc 7.1 generates branch for code which was branchless in earlier gcc version

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #14 from Martin Liška  ---
Jakub I see you fixed the most interesting case, can we close that?

[Bug c++/85717] anonymous union in initializer list : do not handle the types correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
This behaviour is required by the C++ standard, GCC is not allowed to change
it.

In C++20 you will be able to use designated-initializers to select which me,ber
of the union to initialize:

t1 = { 1 ,"a", { .real=3.4 } } ;
t1 = { 1 ,"a", { .integer = 2 } } ;

[Bug target/85733] [8,9 regression] ARM -mbe8 behaviour doesn't match documentation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Keywords|documentation   |

--- Comment #2 from Richard Earnshaw  ---
Documentation is correct.  That the implementation does not match it is the
problem.

[Bug target/85733] [8,9 regression] ARM -mbe8 behaviour doesn't match documentation

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri May 11 13:29:41 2018
New Revision: 260162

URL: https://gcc.gnu.org/viewcvs?rev=260162=gcc=rev
Log:
[arm] PR target/85733 Restore be8 linking behaviour for ARMv6-M and products
deriving from its capabilities

My patch last year to automate passing the be8 flag to the linker had
a nasty flaw in that I forgot entirely that the ARMv6-M architecture
did not derive its capabilities directly from the ARMv6 capability
list, but was a new group of capabilities (since it needs to leave out
the ARM -- notm -- feature bit).  The feature list defined was thus
missing the be8 bit.  Furthermore, any product derived from that
feature group consequently lacked the be8 feature as well and this
included all ARMv7 and ARMv8 parts.

The fix is embarrassingly simple...

PR target/85733
* config/arm/arm-cpus.in (fgroup ARMv6m): Add be8 feature.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-cpus.in

[Bug ipa/85734] --suggest-attribute=malloc misdiagnoses static functions

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
There is function_always_visible_to_compiler_p which should disable this sort
of warning. So I suppose we want to test it prior warning about malloc
attribute?

[Bug c++/85747] suboptimal code without constexpr

[antoshkka at gmail dot com]

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

--- Comment #3 from Antony Polukhin  ---
(In reply to Richard Biener from comment #1)
> What's the reason for writing the code as you pasted it?

I've tried to provide a simplified case. In real world `generate()` function
will have some arguments and depending on those it could be either constexpr
evaluated or not.

There's plenty of pre C++14 code that is not well maintained and does not use
constexpr a lot, but functions could be treated and evaluated as constexpr in
C++14.

Main reason for this ticket - is to have some out-of-the-box speedup for such
legacy code. Function without arguments seemed to be a good place to start.

[Bug c++/85747] suboptimal code without constexpr

[antoshkka at gmail dot com]

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

--- Comment #4 from Antony Polukhin  ---
(In reply to Marc Glisse from comment #2)
> (In reply to Antony Polukhin from comment #0)
> > Could the compiler detect that `a[7]` holds values known at compile time and
> > force the constexpr on `sort(a + 0, a + 7);`?
> 
> There has to be a limit. If I write a program that computes the trillion's
> decimal of pi, this is a constant, do you expect the compiler to evaluate
> the whole program and compile it to just return cst? We are moving into a
> realm where we would want to mix compilation and execution, sort of JIT.
> For smaller functions, some heuristics could be used to try compile-time
> evaluation, but sorting an array of size 7 already seems large to me.

Does providing some kind of -Oon-the-fly switch solves the issue with JIT
compile times while still allows more optimizations for the traditional non JIT
 -O2 builds?

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #20 from Martin Liška  ---
(In reply to Xi Ruoyao from comment #19)
> I think the best result would be like FMV, for e.g.
> 
> int foo(void) __attribute__((symver("@1.1")))
> {
>   return 0;
> }
> 
> int foo(void) __attribute__((symver("@@1.2")))
> {
>   return 1;
> }
> 
> Would produce two symbols "foo.symver.1.1" and "foo.symver.1.2", and
> 
> .symver foo.symver.1.1 foo@1.1
> .symver foo.symver.1.2 foo@@1.2
> 
> And we can also use
> 
> int foo(void) __attribute__((symver("@1.0"), alias("foo_old")));
> 
> But this seems difficult in C FE, it tends to complain the "redefine" of foo
> - note that FMV is still only for C++ until now.

Sounds reasonable to me. I have some experience with MVC so I will work on that
in this stage1.

[Bug target/85733] [8,9 regression] ARM -mbe8 behaviour doesn't match documentation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
Fixed

[Bug c++/85747] suboptimal code without constexpr

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Antony Polukhin from comment #4)
> Does providing some kind of -Oon-the-fly switch solves the issue with JIT
> compile times while still allows more optimizations for the traditional non
> JIT  -O2 builds?

Not sure what you mean by -Oon-the-fly. If you want to JIT compile the code,
you more or less need to embed a compiler in the executable...

The closest I can think of is -fprofile-values. It is possible to collect the
values of constants during a training run and use them during a second
compilation. But then knowing more constants in one compilation than the other
may change the code in ways that the PGO framework will not like.

[Bug tree-optimization/85725] strchr and strstr of a one-element array with a non-empty string can be assumed to return null

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
That's right: unless otherwise specified, string functions require as arguments
valid strings, or as the C++ standard defines them, NTBS (nul-terminated byte
string).  Thus the only valid string that can be stored in char[1] is the empty
string.  The memchr function must be used to find the first occurrence of a
character in an arbitrary (not necesarily nul-terminated) sequence of bytes.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
  Known to fail||9.0

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Rainer Orth from comment #3)
> Created attachment 44108 [details]
> i386-pc-solaris2.11 ipa-icf-38.exe.wpa.073i.icf
> 
> It's only one part that fails
> 
> FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not fixup_cfg4 "Function
> bar"
> 
> which was introduced by
> 
> 2018-05-02  Tom de Vries  
> 
> PR testsuite/85106
> * gcc.dg/ipa/ipa-icf-38.c: Use scan-ltrans-tree-dump.
> [...]

According to log file alias support is mission on solaris. Thus following patch
should fix that by skipping the test:

diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
index 85531ab1cf3..45525844551 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
@@ -1,4 +1,5 @@
 /* { dg-do link } */
+/* { dg-require-alias "" } */
 /* { dg-options "-O2 -fdump-ipa-icf -flto -fdump-tree-fixup_cfg4" } */
 /* { dg-require-effective-target lto } */
 /* { dg-additional-sources "ipa-icf-38a.c" }*/

Can you please verify that?

[Bug c++/85717] anonymous union in initializer list : do not handle the types correctly

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Given that integer literals are convertible to FP (or even are also FP
literals) what do you expect?

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse  ---
(In reply to Richard Biener from comment #11)
> Dup of PR23094 (and fixed).

Richard, comment #9 shows that the original testcase is only half-fixed (though
the other half seems hard to fix). Does this mean you consider the second half
as WONTFIX?

[Bug fortran/85521] [8/9 Regression] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2049

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 17:59:05 2018
New Revision: 260175

URL: https://gcc.gnu.org/viewcvs?rev=260175=gcc=rev
Log:
2018-05-11  Steven G. Kargl  

PR fortran/85521
Backport from trunk
* array.c (gfc_resolve_character_array_constructor): Substrings
with upper bound smaller than lower bound are zero length strings.

2018-05-11  Steven G. Kargl  

PR fortran/85521
Backport from trunk
* gfortran.dg/pr85521_1.f90: New test.
* gfortran.dg/pr85521_2.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85521_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85521_2.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/array.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/85749] Possible -Wsign-conversion false negative with std::default_random_engine

[martingalvan at sourceware dot org]

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

--- Comment #1 from martingalvan at sourceware dot org ---
Created attachment 44119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44119=edit
Preprocessed source

[Bug fortran/85687] ICE in gfc_sym_identifier, at fortran/trans-decl.c:351

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 18:33:05 2018
New Revision: 260179

URL: https://gcc.gnu.org/viewcvs?rev=260179=gcc=rev
Log:
2018-05-11  Steven G. Kargl  

PR fortran/85687
Backport from trunk
* check.c (gfc_check_rank): Check that the argument is a data object.

2018-05-11  Steven G. Kargl  

PR fortran/85687
Backport from trunk
* gfortran.dg/pr85687.f90: new test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr85687.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/check.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/85750] New: Default initialization of derived type array missing

[stephan.kramer at imperial dot ac.uk]

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

Bug ID: 85750
   Summary: Default initialization of derived type array missing
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stephan.kramer at imperial dot ac.uk
  Target Milestone: ---

In The following program, the derived type array that is returned by make_list
does not have its components initialized.

module bar
  implicit none
  type ilist
integer :: count = 0
integer, dimension(:), pointer :: ptr => null()
  end type ilist

  contains

  function make_list(i)
integer, intent(in) :: i
type(ilist), dimension(2) :: make_list

make_list(i)%count = 1

  end function make_list

end module bar
program foo
  use bar
  implicit none

  type(ilist), dimension(:), allocatable :: mylist

  allocate(mylist(1:2))
  mylist = make_list(1)
  print *, mylist%count
  mylist = make_list(2)
  print *, mylist%count

end program foo

What I get:

$ gfortran test.f90 
$ ./a.out 
   1   0
   1   1

What I expect:
   1   0
   0   1
i.e. make_list should return an array for which all entries have a zero %count
component, except for the specified entry that's set to 1.

The program does work correctly if I leave out the %ptr from the ilist derived
type definition.

Latest gfortran I've tried is 8.1, but I see the same failure on 7.3, 7.2 and
6.2. The results are correct with gfortran 5.4

$ gfortran -v test.f90 
Driving: gfortran -v test.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.1.0-1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as
--with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.1.0 (Debian 8.1.0-1) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/f951 test.f90 -quiet -dumpbase test.f90
-mtune=generic -march=x86-64 -auxbase test -version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-linux-gnu/8/finclude -o /tmp/cch78iQf.s
GNU Fortran (Debian 8.1.0-1) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Debian 8.1.0-1) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/bin/x86_64-linux-gnu-as -v --64 -o /tmp/ccwUDNGB.o /tmp/cch78iQf.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.30
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/8/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper

[Bug libstdc++/85749] Possible -Wsign-conversion false negative with std::default_random_engine

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
There's also a template constructor, which is the one that gets used:

  template::value>
   ::type>
explicit
linear_congruential_engine(_Sseq& __q)
{ seed(__q); }

The conversion to unsigned now happens when calling seed(__q), which is in the
std::lib code and so gets suppressed because it's in a system header (and using
-Wsystem-headers produces a lot of warnings from the std::lib code).

That constructor is only supposed to be used for seed sequence types, but
nothign in the standard actually ensures that, and so it gets used for your
example too. That might be a defect in the standard.

I'm going to re-assign this to libstdc++, so we can make that constructor less
greedy.

[Bug c++/85749] New: Possible -Wsign-conversion false negative with std::default_random_engine

[martingalvan at sourceware dot org]

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

Bug ID: 85749
   Summary: Possible -Wsign-conversion false negative with
std::default_random_engine
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martingalvan at sourceware dot org
  Target Milestone: ---

I have the following code:

#include 
#include 

int main()
{
const auto seed =
std::chrono::system_clock::now().time_since_epoch().count();
std::default_random_engine generator(seed);

generator.seed(seed);

return 0;
}

If I build this using g++ -std=c++17 -Wsign-conversion -o random random.cpp, I
get the following warning:

random.cpp: In function ‘int main()’:
random.cpp:9:24: warning: conversion to ‘std::linear_congruential_engine::result_type {aka long unsigned int}’ from
‘long int’ may change the sign of the result [-Wsign-conversion]
 generator.seed(seed);

However, AFAIK the std::default_random_engine constructor also takes a
result_type (which should be unsigned). Therefore, the warning should also come
up when constructing 'generator'.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-8ubuntu3.2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)

[Bug fortran/85521] [8/9 Regression] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2049

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 18:34:14 2018
New Revision: 260180

URL: https://gcc.gnu.org/viewcvs?rev=260180=gcc=rev
Log:
2018-05-11  Steven G. Kargl  

PR fortran/85521
Backport from trunk
* array.c (gfc_resolve_character_array_constructor): Substrings
with upper bound smaller than lower bound are zero length strings.

2018-05-11  Steven G. Kargl  

PR fortran/85521
Backport from trunk
* gfortran.dg/pr85521_1.f90: New test.
* gfortran.dg/pr85521_2.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr85521_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr85521_2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/array.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/85687] ICE in gfc_sym_identifier, at fortran/trans-decl.c:351

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed.

[Bug fortran/85521] [8/9 Regression] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2049

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.2 |6.5

--- Comment #10 from kargl at gcc dot gnu.org ---
Fixed.

[Bug middle-end/85751] New: RFE: option to align code using breakpoint instructions when unreachable

[hpa at zytor dot com]

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

Bug ID: 85751
   Summary: RFE: option to align code using breakpoint
instructions when unreachable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

For most (all?) targets, there exists a breakpoint or other trap instruction
which can be inserted at any point in the code stream, e.g. 0xcc (int3) on x86.

Currently, gcc aligns code by the default platform option, which is some kind
of NOP, as the assembler can't know if a fallthrough is possible.

It would be preferable to pad with a trapping instruction *if* the padding area
is unreachable and not subject to fallthrough.

This does not require any binutils changes, as the align directives already
optionally support specifying the value of the padding bytes.