[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 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 (&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

[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/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 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 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/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 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 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 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 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 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&root=gcc&view=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/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&root=gcc&view=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/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 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&root=gcc&view=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 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 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 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 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 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 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 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 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&action=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 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&pasted 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/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 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 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 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 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 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 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 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&action=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 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 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&root=gcc&view=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 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&root=gcc&view=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

[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 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&root=gcc&view=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 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&root=gcc&view=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&root=gcc&view=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 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 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 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&action=edit
Fortran sample program

[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 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.

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 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 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 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 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 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&root=gcc&view=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 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&root=gcc&view=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/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 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 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/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 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 (&a, 0, 4);
  _2 = _1 != 0B;
  _5 = (int) _2;
  a ={v} {CLOBBER};
  return _5;

}

[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 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 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&root=gcc&view=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 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 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&root=gcc&view=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 c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-11
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.2
Summary|internal compiler error: in |[8/9 Regression] internal
   |finish_member_declaration,  |compiler error: in
   |at cp/semantics.c:3057  |finish_member_declaration,
   ||at cp/semantics.c:3057
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
You don't really need the include,
typedef __PTRDIFF_TYPE__ ptrdiff_t;
template  class b {};
template  class B { using e = ptrdiff_t; };
template 
bool operator!=(B, b);
class l;
template  class m {
public:
  using o = B;
  using iterator = b;
};
class l {
public:
  int f;
};
template  class F {
public:
  using j = m;
  using o = typename j::o;
  using iterator = typename j::iterator;
  o begin() const;
};
class p {
  bool k() const;
  F::iterator c;
  F d;
};
bool p::k() const {
  if (d.begin() != c)
return true;
  return false;
}

reproduces it too.
Started with r254843.

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
Summary|attribute nonstring fails   |attribute nonstring fails
   |to squash   |to squash
   |-Wstringop-truncation   |-Wstringop-truncation
   |warning |warning at an offset

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00566.html

[Bug libffi/85722] testsuite failure in libffi

[chrisgiorgi at gmail dot com]

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

--- Comment #9 from Chris Giorgi  ---
Created attachment 44118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44118&action=edit
gcc-7.3.1-r1.ebuild

Funtoo gcc ebuild attached, enabling go triggers libffi test failures.
Repo, including patches applied at:
https://github.com/TemptorSent/overlay-dev-gcc-kit/tree/master/sys-devel/gcc

Versions extracted from ebuild:
GCC_ARCHIVE_VER="7.3.0"
GCC_SVN_REV="259984"

GMP_VER="6.1.2"
GMP_EXTRAVER=""
MPFR_VER="4.0.1"
MPC_VER="1.1.0"
CLOOG_VER="0.18.4"
ISL_VER="0.16.1"

GNAT32="gnat-gpl-2014-x86-linux-bin.tar.gz"
GNAT64="gnat-gpl-2017-x86_64-linux-bin.tar.gz"

[Bug rtl-optimization/85745] 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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #2 from Bernd Edlinger  ---
Removing const fixes the build for me.
Thanks for investigating!

[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 #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 17:29:14 2018
New Revision: 260169

URL: https://gcc.gnu.org/viewcvs?rev=260169&root=gcc&view=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-8-branch/gcc/testsuite/gfortran.dg/pr85687.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/check.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[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 #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 17:30:57 2018
New Revision: 260170

URL: https://gcc.gnu.org/viewcvs?rev=260170&root=gcc&view=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-8-branch/gcc/testsuite/gfortran.dg/pr85521_1.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85521_2.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/array.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 17:32:28 2018
New Revision: 260171

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

PR fortran/70870
Backport from trunk
* data.c (gfc_assign_data_value): Check that a data object does
not also have default initialization.

2018-05-11  Steven G. Kargl  

PR fortran/70870
Backport from trunk
* gfortran.dg/pr70870_1.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr70870_1.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/data.c
branches/gcc-8-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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 17:58:03 2018
New Revision: 260174

URL: https://gcc.gnu.org/viewcvs?rev=260174&root=gcc&view=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-7-branch/gcc/testsuite/gfortran.dg/pr85687.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/check.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[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&root=gcc&view=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 fortran/70870] Segmentation violation in gfc_assign_data_value

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 18:00:41 2018
New Revision: 260176

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

PR fortran/70870
Backport from trunk
* data.c (gfc_assign_data_value): Check that a data object does
not also have default initialization.

2018-05-11  Steven G. Kargl  

PR fortran/70870
Backport from trunk
* gfortran.dg/pr70870_1.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70870_1.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/data.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[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 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&action=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&root=gcc&view=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/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&root=gcc&view=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/70870] Segmentation violation in gfc_assign_data_value

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri May 11 18:35:20 2018
New Revision: 260181

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

PR fortran/70870
Backport from trunk
* data.c (gfc_assign_data_value): Check that a data object does
not also have default initialization.

2018-05-11  Steven G. Kargl  

PR fortran/70870
Backport from trunk
* gfortran.dg/pr70870_1.f90: New test.

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

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[kargl at gcc dot gnu.org]

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

Bug 70870 Summary: Segmentation violation in gfc_assign_data_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70870

   What|Removed |Added

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

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

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

[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism

[hpa at zytor dot com]

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

H. Peter Anvin  changed:

   What|Removed |Added

 CC||hpa at zytor dot com

--- Comment #9 from H. Peter Anvin  ---
How is this different from raise(SIGTRAP);?

[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.