[Bug preprocessor/89373] macro expansion not counting braces correctly

2019-02-15 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |preprocessor
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
In the C preprocessor without a '(' everything after the ',' is the next
argument.

[Bug c/89373] New: macro expansion not counting braces correctly

2019-02-15 Thread mdblack98 at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373

Bug ID: 89373
   Summary: macro expansion not counting braces correctly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdblack98 at yahoo dot com
  Target Milestone: ---

include 

#define MYMACRO1(m) MYLIST;

#define MYMACRO(r,m) \
   MYMACRO##r(m) 


#define MYLIST {1,2,3,4,5}

// too many args -- does not allow for braces such as used for array
initialization
int ii[32] = MYMACRO(1,{1,2,3,4,5});

// too many args -- does not allow for braces such as used for array
initialization
int jj[32] = MYMACRO(1,MYLIST);

// this works
int kk[32] = MYLIST;

int
main()
{
  // all 3 of these should print 1,2,3,4,5
  for(int i=0;i<5;++i) printf("ii %d,%d\n",i,ii[i]);
  for(int i=0;i<5;++i) printf("jj %d,%d\n",i,jj[i]);
  for(int i=0;i<5;++i) printf("kk %d,%d\n",i,kk[i]);
  return 0;
}

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #15 from Ian Lance Taylor  ---
*** Bug 89277 has been marked as a duplicate of this bug. ***

[Bug go/89277] [9 Regression] libgo memory hogs in libgo testsuite (at least on s390x-linux-gnu)

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89277

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Ian Lance Taylor  ---
Closing as a duplicate per earlier comment.  Please comment if you disagree.

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

[Bug go/89171] FAIL: go/build

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171

--- Comment #1 from Ian Lance Taylor  ---
I don't know what is happening here and I don't have access to a riscv64
machine to test on (there doesn't seem to be one in the compile farm).  The
errors are incorrect in that these are not expected dependencies, not
unexpected ones.  This may be a bug in the generation of top level composite
literals, though I can't think of any reason that would be specific to riscv64,
and of course it is working on other systems.

Do you have any suggestions for how I could debug this?

[Bug middle-end/89371] New: missed vectorisation with "#pragma omp simd collapse(2)"

2019-02-15 Thread arnaud02 at users dot sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371

Bug ID: 89371
   Summary: missed vectorisation with "#pragma omp simd
collapse(2)"
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud02 at users dot sourceforge.net
  Target Milestone: ---

void ff(double* res, double const* a, double const* b, int ncell, int neq)
{
#pragma omp simd collapse(2)
  for(int icell=0; icell < ncell; ++icell)
  {
  for(int ieq=0; ieq

[Bug c++/88512] Too much STL in error output

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512

--- Comment #10 from Jonathan Wakely  ---
I've created bug 89370 to request showing the type as std::string.

[Bug c++/88512] Too much STL in error output

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512

--- Comment #9 from Jonathan Wakely  ---
It's easy for you to say that after looking at the reason it failed and knowing
what the code is trying to do (obviously "insert" modifies the string, so it
can't be const). But the compiler has to try every overload, and doesn't know
what your intention is, or what the word "insert" means.

The problem here is (as before) that std::string has eight overloads of insert
(and just as many for assign, and begin, and replace etc), and there's nothing
the compiler can do about that.

Potentially the compiler could be changed so that if all the overload
candidates are non-const and the object is const, it just says that. But that's
another fairly specialized diagnostic just for this case. Most classes simply
don't have eight overloads of the same function.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Let me put together a patch for the negative offsets.  The argc patch is useful
on its own, independent of this bug.

[Bug go/89368] [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Thanks for the report.  Fixed.

[Bug c++/84916] Tweaks to template type elision

2019-02-15 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84916

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|9.0 |10.0

--- Comment #4 from David Malcolm  ---
I have a patch for this, queuing for gcc 10 stage 1.

[Bug c++/60920] Crash on double template header due to default template parameter

2019-02-15 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60920

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed by the patch which fixed c++/85264.

[Bug sanitizer/80953] Support libsanitizer on Solaris

2019-02-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953

--- Comment #35 from Eric Botcazou  ---
> Right: 64-bit Solaris/SPARC uses the full 64-bit address space:
> 
> https://docs.oracle.com/cd/E37838_01/html/E66175/advanced-2.
> html#SSFDGadvanced-5
> 
> The gap between the low and high parts cannot be determined
> programmatically right now and varies between different sparc machines.

Linux uses an equivalent VM layout (although the primary stack is in the low
part instead of the high part).  I think that on Linux the hole is fully
determined by the number of bits available for virtual addresses.

> Even if that could be fixed (there's been talk about adding an interface
> to determine that information at runtime), the current shadow address
> calculation cannot cope with such a discontinuous address space.

Right, but you can tweak it once the position of the hole is determined.  I
have done so for a 52-bit VM layout (T4 and later apparently) and, modulo fixes
all over the place (libsanitizer, libbacktrace, compiler, testsuite), I now
have a 100% clean ASAN testsuite on both 32-bit and 64-bit SPARC/Linux.

Trying on Solaris now...

[Bug go/89368] [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923

2019-02-15 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Feb 15 21:04:58 2019
New Revision: 268948

URL: https://gcc.gnu.org/viewcvs?rev=268948=gcc=rev
Log:
PR go/89368
compiler: write barrier check nil-check policy tweak

Tweak the recipe for generating writeBarrier loads to insure that the
dereference expr is marked as not requiring a nil check (not needed
for gccgo, but needed for gollvm).

Fixes https://gcc.gnu.org/PR89368

Reviewed-on: https://go-review.googlesource.com/c/162904

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/wb.cc

[Bug c++/84536] [7/8/9 Regression] ICE with non-type template parameter

2019-02-15 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84536

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P4  |P3
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-15
 CC||paolo.carlini at oracle dot com
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
I would argue for P3, because, if we slightly tweak it to:

template auto foo(N...); // -> void {}

void bar()
{
  foo<>();
}

we don't emit any diagnostics before ICEing.

[Bug fortran/89077] ICE using * as len specifier for character parameter

2019-02-15 Thread anlauf at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077

--- Comment #17 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #16)
> Regarding the unwanted padding with \0, the following patch seems to
> solve the issue with transfer.

Regtested cleanly and submitted here:

https://gcc.gnu.org/ml/fortran/2019-02/msg00126.html

[Bug target/89372] New: Incorrect PMULHRSW

2019-02-15 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89372

Bug ID: 89372
   Summary: Incorrect PMULHRSW
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

sse.md has

(define_mode_iterator PMULHRSW
  [V4HI V8HI (V16HI "TARGET_AVX2")])

(define_expand "_pmulhrsw3_mask"
  [(set (match_operand:PMULHRSW 0 "register_operand")
(vec_merge:PMULHRSW
  (truncate:PMULHRSW
(lshiftrt:
  (plus:
(lshiftrt:
  (mult:
(sign_extend:
  (match_operand:PMULHRSW 1 "nonimmediate_operand"))
(sign_extend:
  (match_operand:PMULHRSW 2 "nonimmediate_operand")))
  (const_int 14))
(match_dup 5))
  (const_int 1)))
  (match_operand:PMULHRSW 3 "register_operand")
  (match_operand: 4 "register_operand")))]
  "TARGET_AVX512BW && TARGET_AVX512VL"
{
  operands[5] = CONST1_RTX(mode);
  ix86_fixup_binary_operands_no_copy (MULT, mode, operands);
})

But AVX512BW doesn't support V4HI.

(define_expand "_pmulhrsw3"
  [(set (match_operand:PMULHRSW 0 "register_operand")
(truncate:PMULHRSW
  (lshiftrt:
(plus:
  (lshiftrt:
(mult:
  (sign_extend:
(match_operand:PMULHRSW 1 "nonimmediate_operand"))
  (sign_extend:
(match_operand:PMULHRSW 2 "nonimmediate_operand")))
(const_int 14))
  (match_dup 3))
(const_int 1]
  "TARGET_AVX2"
{
  operands[3] = CONST1_RTX(mode);
  ix86_fixup_binary_operands_no_copy (MULT, mode, operands);
})


But V4HI V8HI doesn't require AVX2.

[Bug c/88944] Suggested alternative C stdbool.h

2019-02-15 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-15
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks.

FWIW trunk (gcc 9) no longer suggests "_Bool".

I have a patch pending (for gcc 10) which implements the header suggestion.

[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
With -fpic it actually rejects both static_asserts.
In all the cases, it is symtab_node::equal_address_to that attempts to decide
if the two VAR_DECLs need to be the same or distinct or unknown.
Without templates and without -fpic that function returns true, because both
are defined locally and we can easily decide that they must be different, but
with -fpic, the generic code allows them to be interposed and fails.  Even
without -fpic, for templates the variables are DECL_COMDAT and thus not really
known if defined by the current or some other TU.

No idea if C++ standard says anything here and constexpr evaluation shouldn't
use some different rules (or in addition to what the generic code says).

[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>

2019-02-15 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370

Jonny Grant  changed:

   What|Removed |Added

 CC||jg at jguk dot org

--- Comment #1 from Jonny Grant  ---
Many thanks!
Happy to pay $200 bounty for this feature to implementer or FSF/GNU etc

[Bug c++/88512] Too much STL in error output

2019-02-15 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512

--- Comment #12 from Jonny Grant  ---
(In reply to Jonathan Wakely from comment #9)
> It's easy for you to say that after looking at the reason it failed and
> knowing what the code is trying to do (obviously "insert" modifies the
> string, so it can't be const). But the compiler has to try every overload,
> and doesn't know what your intention is, or what the word "insert" means.
> 
> The problem here is (as before) that std::string has eight overloads of
> insert (and just as many for assign, and begin, and replace etc), and
> there's nothing the compiler can do about that.
> 
> Potentially the compiler could be changed so that if all the overload
> candidates are non-const and the object is const, it just says that. But
> that's another fairly specialized diagnostic just for this case. Most
> classes simply don't have eight overloads of the same function.

Sounds good, those insert methods aren't 'const' so at least the first line
could say that...

eg:
$ g++ -Wall -c -o int int.cpp
int.cpp: In function ‘int main()’:
int.cpp:13:21: error: no matching function for call to
‘std::string::insert(size_t, const string&) const’
   str.insert(4, str2);
 ^
   Note, ‘str’ is const and all ‘std::string::insert()’ methods are non-const

[Bug middle-end/89371] missed vectorisation with "#pragma omp simd collapse(2)"

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89371

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||missed-optimization, openmp
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Well, in this case I don't see any advantage of using collapsed loops, it won't
make the loop more readable and is much harder to vectorize, so why not to
write it that way?
Yes, there is certainly room for improvement to undo this kind of stuff.

[Bug c++/88512] Too much STL in error output

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512

--- Comment #11 from Jonathan Wakely  ---
There's also Bug 53281

[Bug c++/89370] New: Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89370

Bug ID: 89370
   Summary: Output std::string in diagnostics instead of
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Errors involving std::string are unreadable (see Bug 88512 comment 8). Nobody
cares that it's:

'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::__const_iterator, _CharT) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::__const_iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer =
const char*]'
 1745 |   insert(__const_iterator __p, _CharT __c)
  |   ^~


The type std::__cxx11::basic_string<_CharT, _Traits, _Alloc> should be shown as
std::string. That alone makes it far more readable. And if we don't show it as
a template specialization maybe we don't need the entire "[with ...]" part at
all, but if we do need it, we should reduce it ...

I don't think expanding the return type or the __const_iterator type in the
"[with ...]" part is very useful:

std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;

std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;


And why on Earth is it telling us what the pointer and const_pointer types
are?! They don't appear in the member function signature at all!

typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*;

 typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer =
const char*

Cool story bro. Those types are not relevant.

[Bug lto/87525] [7/8/9 Regression] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2

2019-02-15 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #19 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #14)
> Martin,
> it seems to me that ipa-cp should not clone extern inline functions unless
> it sees that it helps to clone some real functions called from it. Why the
> costmodel thinks it is profitable?

It does not special-case that kind of situation.  Still it is not
easy, because the cloning decisions are made on the final sweep over
the call graph from callers to callees and whether any callees would
be cloned will only be decided in the future.

Still, the cost model should probably evaluate these cases
differently, perhaps like the patch below.  To the extent to which I
am able to reproduce the issue (only on gcc 8 and in the "correct"
case it segfaults as opposed to endless loop), the adjustment helps,
but it is of course only a heuristics.

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index e868b9c2623..f148ceef393 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -4685,15 +4685,23 @@ decide_about_value (struct cgraph_node *node, int
index, HOST_WIDE_INT offset,
   fprintf (dump_file, " (caller_count: %i)\n", caller_count);
 }

-  if (!good_cloning_opportunity_p (node, val->local_time_benefit,
-  freq_sum, count_sum,
-  val->local_size_cost)
-  && !good_cloning_opportunity_p (node,
- val->local_time_benefit
- + val->prop_time_benefit,
- freq_sum, count_sum,
- val->local_size_cost
- + val->prop_size_cost))
+  if (DECL_EXTERNAL (node->decl) && DECL_DECLARED_INLINE_P (node->decl))
+{
+  if (!good_cloning_opportunity_p (node, val->prop_time_benefit,
+  freq_sum, count_sum,
+  val->local_size_cost
+  + val->prop_size_cost))
+   return false;
+}
+  else if (!good_cloning_opportunity_p (node, val->local_time_benefit,
+   freq_sum, count_sum,
+   val->local_size_cost)
+  && !good_cloning_opportunity_p (node,
+  val->local_time_benefit
+  + val->prop_time_benefit,
+  freq_sum, count_sum,
+  val->local_size_cost
+  + val->prop_size_cost))
 return false;

   if (dump_file)

[Bug target/89369] [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45739=edit
gcc9-pr89369.patch

Untested fix.
The recently added patterns want to do x |= (unsigned) ((reg:DI) >> cnt), and
as the zero_extract in the patterns show, it always wants to extract exactly 32
bits.  So, in my understanding of the rsbg instruction, we want to rotate
by 32 + cnt (correct in the pattern) and want to use 32,63 as I3/I4, so we only
do the operation on the low 32 bits.
In the testcase, rxsbg %r1,%r11,40,63,56 is emitted when we need to do:
unsigned long long var = 0x50ef69fef3e09994ULL;
unsigned r1 = ...;
r1 |= (unsigned) (var >> 8);
but that instruction instead of doing |= 0xfef3e099 we need is doing |=
0xf3e099, the top 8 bits are lost.  The patch changes it to rxsbg
%r1,%r11,32,63,56 which works properly.  The patch also changes 3 other rxsbg
instructions on the testcase, like rxsbg %r12,%r9,64,63,32 which were emitted
for |= (unsigned) (var >> 0), note the strange 64 in there, I bet it is xoring
also the upper bits of the 64-bit destination, but we don't really care that
much about those.  That said, the patch changes that to rxsbg
%r12,%r9,32,64,32.

Finally, I believe having 256 byte static buffer for each of these instructions
(times how many times it is expanded for ) is not a good idea, because it
increases .bss unnecessarily, plus the %ld in there will not really work e.g.
on cross compilers from 32-bit hosts to s390x-linux, while GEN_INT for these
small constants, while it creates rtxes, is all cached and likely already
constructed.

[Bug target/89369] New: [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369

Bug ID: 89369
   Summary: [9 Regression]  pseudo-RNG miscompiled on s390x-linux
with -O2 -march=zEC12 -mtune=z13 starting with r266203
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase is miscompiled with -O2 -march=zEC12 -mtune=z13 starting
with r266203:

#if __SIZEOF_INT__ == 4 && __SIZEOF_LONG_LONG__ == 8 && __CHAR_BIT__ == 8
struct S { unsigned int u[4]; };

static void
foo (struct S *out, struct S const *in, int shift)
{
  unsigned long long th, tl, oh, ol;
  th = ((unsigned long long) in->u[3] << 32) | in->u[2];
  tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
  oh = th >> (shift * 8);
  ol = tl >> (shift * 8);
  ol |= th << (64 - shift * 8);
  out->u[1] = ol >> 32;
  out->u[0] = ol;
  out->u[3] = oh >> 32;
  out->u[2] = oh;
}

static void
bar (struct S *out, struct S const *in, int shift)
{
  unsigned long long th, tl, oh, ol;
  th = ((unsigned long long) in->u[3] << 32) | in->u[2];
  tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
  oh = th << (shift * 8);
  ol = tl << (shift * 8);
  oh |= tl >> (64 - shift * 8);
  out->u[1] = ol >> 32;
  out->u[0] = ol;
  out->u[3] = oh >> 32;
  out->u[2] = oh;
}

__attribute__((noipa)) static void
baz (struct S *r, struct S *a, struct S *b, struct S *c, struct S *d)
{
  struct S x, y;
  bar (, a, 1);
  foo (, c, 1);
  r->u[0] = a->u[0] ^ x.u[0] ^ ((b->u[0] >> 11) & 0xdfefU) ^ y.u[0] ^
(d->u[0] << 18);
File rh1677602.c saved

[jakub@tucnak gcc]$ cat rh1677602.c 
#if __SIZEOF_INT__ == 4 && __SIZEOF_LONG_LONG__ == 8 && __CHAR_BIT__ == 8
struct S { unsigned int u[4]; };

static void
foo (struct S *out, struct S const *in, int shift)
{
  unsigned long long th, tl, oh, ol;
  th = ((unsigned long long) in->u[3] << 32) | in->u[2];
  tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
  oh = th >> (shift * 8);
  ol = tl >> (shift * 8);
  ol |= th << (64 - shift * 8);
  out->u[1] = ol >> 32;
  out->u[0] = ol;
  out->u[3] = oh >> 32;
  out->u[2] = oh;
}

static void
bar (struct S *out, struct S const *in, int shift)
{
  unsigned long long th, tl, oh, ol;
  th = ((unsigned long long) in->u[3] << 32) | in->u[2];
  tl = ((unsigned long long) in->u[1] << 32) | in->u[0];
  oh = th << (shift * 8);
  ol = tl << (shift * 8);
  oh |= tl >> (64 - shift * 8);
  out->u[1] = ol >> 32;
  out->u[0] = ol;
  out->u[3] = oh >> 32;
  out->u[2] = oh;
}

__attribute__((noipa)) static void
baz (struct S *r, struct S *a, struct S *b, struct S *c, struct S *d)
{
  struct S x, y;
  bar (, a, 1);
  foo (, c, 1);
  r->u[0] = a->u[0] ^ x.u[0] ^ ((b->u[0] >> 11) & 0xdfefU) ^ y.u[0] ^
(d->u[0] << 18);
  r->u[1] = a->u[1] ^ x.u[1] ^ ((b->u[1] >> 11) & 0xddfecb7fU) ^ y.u[1] ^
(d->u[1] << 18);
  r->u[2] = a->u[2] ^ x.u[2] ^ ((b->u[2] >> 11) & 0xbffaU) ^ y.u[2] ^
(d->u[2] << 18);
  r->u[3] = a->u[3] ^ x.u[3] ^ ((b->u[3] >> 11) & 0xbff6U) ^ y.u[3] ^
(d->u[3] << 18);
}

int
main ()
{
  struct S a[] = { { 0x04d3, 0xbc5448db, 0xf22bde9f, 0xebb44f8f },
   { 0x03a32799, 0x60be8246, 0xa2d266ed, 0x7aa18536 },
   { 0x15a38518, 0xcf655ce1, 0xf3e09994, 0x50ef69fe },
   { 0x88274b07, 0xe7c94866, 0xc0ea9f47, 0xb6a83c43 },
   { 0xcd0d0032, 0x5d47f5d7, 0x5a0afbf6, 0xaea87b24 },
   { 0, 0, 0, 0 } };
  baz ([5], [0], [1], [2], [3]);
  if (a[4].u[0] != a[5].u[0] || a[4].u[1] != a[5].u[1]
  || a[4].u[2] != a[5].u[2] || a[4].u[3] != a[5].u[3])
__builtin_abort ();
  return 0;
}
#else
int
main ()
{
  return 0;
}
#endif

[Bug target/89369] [9 Regression] pseudo-RNG miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r266203

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89369

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-15
 CC||iii at gcc dot gnu.org,
   ||krebbel at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug target/85711] [8 regression] ICE in aarch64_classify_address, at config/aarch64/aarch64.c:5678

2019-02-15 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-15
 CC||wilco at gcc dot gnu.org
Summary|ICE in  |[8 regression] ICE in
   |aarch64_classify_address,   |aarch64_classify_address,
   |at  |at
   |config/aarch64/aarch64.c:56 |config/aarch64/aarch64.c:56
   |78  |78
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #4 from Wilco  ---
Fixed in GCC9, still failing in GCC8.

[Bug c++/88512] Too much STL in error output

2019-02-15 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512

--- Comment #8 from Jonny Grant  ---
Another example. 9 line file.  Gives 48 lines of STL warnings...  G++ only
needs to say something clear:

"error: std::string 'str' is const, and as such insert() method cannot be
called"

// g++ -Wall -c -o int int.cpp
#include 
int main()
{
  const std::string str ="abc";// NB. This 'str' should not be const
  const std::string str2 ="1 ";
  str.insert(4, str2);
  return str.size();
}


G++8 output:

$ g++-8 -Wall -c -o int int.cpp
int.cpp: In function ‘int main()’:
int.cpp:13:21: error: no matching function for call to
‘std::__cxx11::basic_string::insert(int, const string&) const’
   str.insert(4, str2);
 ^
In file included from /usr/include/c++/8/string:52,
 from int.cpp:3:
/usr/include/c++/8/bits/basic_string.h:1524:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::const_iterator, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type, _CharT) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::const_pointer =
const char*; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type =
long unsigned int]’
   insert(const_iterator __p, size_type __n, _CharT __c)
   ^~
/usr/include/c++/8/bits/basic_string.h:1524:7: note:   candidate expects 3
arguments, 2 provided
/usr/include/c++/8/bits/basic_string.h:1568:9: note: candidate: ‘template std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::iterator std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::const_iterator, _InputIterator, _InputIterator) [with _InputIterator =
_InputIterator;  = ; _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’
 insert(const_iterator __p, _InputIterator __beg, _InputIterator __end)
 ^~
/usr/include/c++/8/bits/basic_string.h:1568:9: note:   template argument
deduction/substitution failed:
int.cpp:13:21: note:   candidate expects 3 arguments, 2 provided
   str.insert(4, str2);
 ^
In file included from /usr/include/c++/8/string:52,
 from int.cpp:3:
/usr/include/c++/8/bits/basic_string.h:1602:7: note: candidate: ‘void
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator,
std::initializer_list<_Tp>) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
__gnu_cxx::__normal_iterator >;
typename __gnu_cxx::__alloc_traits::rebind<_CharT>::other>::pointer = char*]’
   insert(iterator __p, initializer_list<_CharT> __l)
   ^~
/usr/include/c++/8/bits/basic_string.h:1602:7: note:   no known conversion for
argument 1 from ‘int’ to ‘std::__cxx11::basic_string::iterator’ {aka
‘__gnu_cxx::__normal_iterator >’}
/usr/include/c++/8/bits/basic_string.h:1622:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned
int]’ 
   insert(size_type __pos1, const basic_string& __str)
   ^~
/usr/include/c++/8/bits/basic_string.h:1622:7: note:   passing ‘const string*’
{aka ‘const std::__cxx11::basic_string*’} as ‘this’ argument discards
qualifiers
/usr/include/c++/8/bits/basic_string.h:1645:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned
int]’
   insert(size_type __pos1, const basic_string& __str,
   ^~
/usr/include/c++/8/bits/basic_string.h:1645:7: note:   candidate expects 4
arguments, 2 provided
/usr/include/c++/8/bits/basic_string.h:1668:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,

[Bug go/89368] New: [9 regression] ICE in go/gofrontend/expressions.cc:4669 after r268923

2019-02-15 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89368

Bug ID: 89368
   Summary: [9 regression] ICE in
go/gofrontend/expressions.cc:4669 after r268923
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: seurer at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

r268922 builds fine but starting with 268923 a bootstrap build ICEs with

libtool: compile:  /home/seurer/gcc/build/gcc-test2/./gcc/gccgo
-B/home/seurer/gcc/build/gcc-test2/./gcc/
-B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/include -isystem
/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/sys-include -O2
-g -I . -c -fgo-pkgpath=runtime -fgo-c-header=runtime.inc.raw
-fgo-compiling-runtime /home/seurer/gcc/gcc-test2/libgo/go/runtime/alg.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/atomic_pointer.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/cgo_gccgo.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/cgocall.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/cgocheck.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/chan.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/compiler.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/cpuprof.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/cputicks.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/debug.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/env_posix.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/error.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/extern.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/fastlog2.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/fastlog2table.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/ffi.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/float.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/hash64.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/heapdump.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/iface.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/lfstack.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/lfstack_64bit.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/lock_futex.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/malloc.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/map.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/map_fast32.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/map_fast64.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/map_faststr.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mbarrier.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mbitmap.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mcache.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mcentral.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mem_gccgo.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mfinal.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mfixalloc.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgc.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgc_gccgo.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgclarge.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcmark.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcsweep.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcsweepbuf.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mgcwork.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mheap.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mprof.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/msan0.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/msize.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mstats.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/mwbbuf.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/netpoll.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/netpoll_epoll.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/os_gccgo.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/os_linux.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/os_linux_ppc64x.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/panic.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/print.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/proc.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/profbuf.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/proflabel.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/race0.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/rdebug.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/relax_stub.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/runtime.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/runtime1.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/runtime2.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/rwmutex.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/select.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/sema.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/signal_gccgo.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/signal_sighandler.go
/home/seurer/gcc/gcc-test2/libgo/go/runtime/signal_unix.go

[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.

2019-02-15 Thread frank.secilia at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367

--- Comment #1 from Frank Secilia  ---
Created attachment 45738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45738=edit
verbose compiler output

[Bug rtl-optimization/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2019-02-15 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from acsawdey at gcc dot gnu.org ---
Fixed in trunk.

[Bug rtl-optimization/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2019-02-15 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308

--- Comment #6 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Fri Feb 15 15:41:25 2019
New Revision: 268942

URL: https://gcc.gnu.org/viewcvs?rev=268942=gcc=rev
Log:
2019-02-15  Aaron Sawdey  

PR rtl-optimization/88308
* shrink-wrap.c (move_insn_for_shrink_wrap): Fix LABEL_NUSES counts
on copied instruction.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/shrink-wrap.c

[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.

2019-02-15 Thread frank.secilia at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367

--- Comment #2 from Frank Secilia  ---
I searched for existing bugs. I don't know the codebase, but I think it may be
another repro case for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181.

[Bug c++/89367] New: Constexpr expression is not constexpr in template, but is constexpr in non-template.

2019-02-15 Thread frank.secilia at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89367

Bug ID: 89367
   Summary: Constexpr expression is not constexpr in template, but
is constexpr in non-template.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frank.secilia at gmail dot com
  Target Milestone: ---

Created attachment 45737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45737=edit
minimal preprocessed test case

Morning, folks!

I'm trying to make compile-time type ids. It's based on the fact that per-type
static instances have unique addresses. I'm using those addresses as the type
id. 

Originally, I figured this wouldn't work because taking the address of
something couldn't be constexpr, but the address of a variable is known at
compile time, so I gave it a try. g++ accepts it for a non-template type, but
not if the type is a template. 

Attached is a preprocessed minimal test case, but here is something slightly
more verbose with a few comments:

// Concrete type with unique, per-type constexpr id.
struct type_1
{
static constexpr char const unique_address{};
static constexpr void const* const id{_address};
};
constexpr char const type_1::unique_address;
constexpr void const* const type_1::id;

// Another concrete type with same.
struct type_2
{
static constexpr char const unique_address{};
static constexpr void const* const id{_address};
};
constexpr char const type_2::unique_address;
constexpr void const* const type_2::id;

// Types have different ids and these evaluate at compile time, as expected.
static_assert(type_1::id != type_2::id);

// Same, but in a template.
template 
struct type_id
{
static constexpr char const unique_address{};
static constexpr void const* const id{_address};
};

template 
constexpr char const type_id::unique_address;

template 
constexpr void const* const type_id::id;

// This does not compile.
static_assert(type_id::id != type_id::id);

The reasons I think this is a bug is because the only difference between the
succeeding and failing case is that the failing case is templated, and because
this works on clang.

I posted about this on stack overflow here
https://stackoverflow.com/questions/43955536/constexpr-unique-id-compiles-with-clang-but-not-with-gcc.
The simpler example at the bottom is missing a const on the out-of-line
definitions, but the behavior is the same with or without them.

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

2019-02-15 Thread rafael at espindo dot la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337

--- Comment #10 from Rafael Avila de Espindola  ---
(In reply to Martin Sebor from comment #9)
> The warning is very simple: it just looks for excessive sizes in calls
> emitted in the optimized IL.  When the call is there (either because it's in
> the source code as is or because it's been synthesized by GCC based on the
> invariants it can infer from the code) it triggers.  It runs after all
> high-level optimizations, including DCE, and assumes that if the statement
> is in the IL it is reachable.  Compiling the test case with
> -fdump-tree-optimized=/dev/stdout shows the GIMPLE the warning works with:
> 
>[local count: 233860936]:
>   # iftmp.6_113 = PHI 
>   memset (iftmp.6_113, 0, 18446744073709551613);
> 
> I think the issue can essentially be reduced to the following:
> 
> $ cat z.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout z.c
> void f (char *d, const char *s)
> {
>   if (__builtin_strstr (s, "ABC"))
> {
>   __SIZE_TYPE__ n = __builtin_strlen (s) - 3;
> 
>   if (n > __builtin_strlen (s))   // cannot be true
> __builtin_memset (d, 0, n - __builtin_strlen (s));
>   }
> }
> 
> ;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
> 
> Removing basic block 6
> Removing basic block 7
> f (char * d, const char * s)
> {
>   char * _1;
>   long unsigned int _2;
> 
>[local count: 1073741824]:
>   _1 = __builtin_strstr (s_5(D), "ABC");
>   if (_1 != 0B)
> goto ; [70.00%]
>   else
> goto ; [30.00%]
> 
>[local count: 751619278]:
>   _2 = __builtin_strlen (s_5(D));
>   if (_2 <= 2)
> goto ; [33.00%]
>   else
> goto ; [67.00%]
> 
>[local count: 248034361]:
>   __builtin_memset (d_6(D), 0, 18446744073709551613); [tail call]
> 
>[local count: 1073741824]:
>   return;
> 
> }
> 
> 
> z.c: In function ‘f’:
> z.c:8:9: warning: ‘__builtin_memset’ specified size 18446744073709551613
> exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
> 8 | __builtin_memset (d, 0, n - __builtin_strlen (s));
>   | ^
> 
> GCC doesn't have the smarts to figure out that when s contains a substring
> of length 3 then strlen(s) must be at least 3.  As a result, it doesn't
> eliminate the memset call in the function and the warning triggers.  Suppose
> we teach GCC how to figure this out from the strstr call (which might be a
> useful optimization) and then someone comes along with a test case that uses
> strspn() instead of strstr().  We can also teach GCC about strstr() but then
> someone else might use regcomp() or some user-defined function that we won't
> have access to.  At some point we'll have to call it good enough.

Absolutely, this is the halting problem after all.

The question is not to give up or not, it is whether to warn when we do. If we
do, we get potential warnings every time gcc gives up on solving the halting
problem.

The uninitialized variable warning was at least split in two, one for the cases
where gcc is not sure.

Maybe we should have a general flag that disables all warnings where gcc cannot
prove that there is a path from a function entry to the broken statement?

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

--- Comment #14 from Ian Lance Taylor  ---
OK, patch committed.  Should we leave this bug report open?

[Bug target/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion

2019-02-15 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616

--- Comment #5 from rguenther at suse dot de  ---
On February 15, 2019 2:37:25 PM GMT+01:00, "marxin at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616
>
>Martin Liška  changed:
>
>   What|Removed |Added
>
>  CC||marxin at gcc dot gnu.org
>
>--- Comment #4 from Martin Liška  ---
>The issues is gone after r255474.

Likely latent. The rev. Shouldn't have affected code generation.

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

--- Comment #13 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Feb 15 14:51:10 2019
New Revision: 268941

URL: https://gcc.gnu.org/viewcvs?rev=268941=gcc=rev
Log:
PR go/89123
internal/cpu, runtime: add S/390 CPU capability support

Patch by Robin Dapp.

Updates https://gcc.gnu.org/PR89123

Reviewed-on: https://go-review.googlesource.com/c/162887

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/internal/cpu/cpu_gccgo.c
trunk/libgo/go/internal/cpu/cpu_s390x.go
trunk/libgo/go/runtime/os_linux_s390x.go

[Bug fortran/89366] New: Fails to compile BIND(C) interface with assumed-length character argument

2019-02-15 Thread Bader at lrz dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366

Bug ID: 89366
   Summary: Fails to compile BIND(C) interface with assumed-length
character argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 45736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45736=edit
test code

The extensions in C interop imply that an assumed-length character dummy
argument can appear in a BIND(C) interface, and is mapped to a C descriptor.
However, the attached test code fails to compile with the following error
message:

assumed_length_01_pos.f90:12:35:

   12 |  subroutine process_string(this, ierr) BIND(C)
  |   1
Error: Character argument ?this? at (1) must be length 1 because procedure
?process_string? is BIND(C)

[Bug fortran/89365] New: Inquiry functions for assumed rank objects fail

2019-02-15 Thread Bader at lrz dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365

Bug ID: 89365
   Summary: Inquiry functions for assumed rank objects fail
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 45735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45735=edit
test code

The attached test code produces failures for the SHAPE, LBOUND and UBOUND
intrinsics when applied to assumed-rank objects with the POINTER or ALLOCATABLE
attribute. Note that for these cases the behaviour should be as for
deferred-shape objects.

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

--- Comment #12 from Ian Lance Taylor  ---
Sorry for the delay, will look at the patch now.

You can test a single target libgo target by using make to build the /check
target.  For example, to test the bytes package, cd to the libgo build
directory and run "make bytes/check".

[Bug ipa/89330] IPA inliner touches released cgraph_edges

2019-02-15 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330

Martin Jambor  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot 
gnu.org

--- Comment #8 from Martin Jambor  ---
I have proposed the fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01225.html

[Bug fortran/89364] New: Assumed rank object with incorrect values for shape and bounds

2019-02-15 Thread Bader at lrz dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364

Bug ID: 89364
   Summary: Assumed rank object with incorrect values for shape
and bounds
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 45734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45734=edit
test code

The attached code compiles without complaints with gfortran 9.0 trunk, but
produces incorrect values for the SHAPE, LBOUND and UBOUND intrinsics on the
last dimension if the actual argument is an assumed-size array.

[Bug ipa/89330] IPA inliner touches released cgraph_edges

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330

--- Comment #7 from Martin Liška  ---
Created attachment 45733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45733=edit
Follow up patch that releases memory

Survives GCC LTO bootstrap and can build Inkscape with LTO.

[Bug fortran/89363] New: RANK incorrect for unallocated allocatable

2019-02-15 Thread Bader at lrz dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89363

Bug ID: 89363
   Summary: RANK incorrect for unallocated allocatable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 45732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45732=edit
test code

The attached program compiles without complaints using gfortran 9.0 trunk
build, but delivers an incorrect value for the RANK() intrinsic if the dummy is
declared with assumed RANK and the ALLOCATABLE attribute, and the actual
argument has the status "not allocated".

Instead of "2", values are returned that change from run to run.

[Bug target/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
The issues is gone after r255474.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #7 from Martin Liška  ---
Started probably in r228194 (change from 400MB -> 1400MB RAM usage).

[Bug target/89361] [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-15
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45731=edit
gcc9-pr89361.patch

Untested fix.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||marxin at gcc dot gnu.org
  Known to work|6.4.0   |8.2.0, 9.0
  Known to fail||6.4.0

--- Comment #6 from Martin Liška  ---
Fixed on trunk in r251412 which is a revision where I introduced switch
expansion as a GIMPLE pass.

[Bug ipa/89330] IPA inliner touches released cgraph_edges

2019-02-15 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330

--- Comment #6 from Martin Jambor  ---
Created attachment 45730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45730=edit
Untested fix

I'm testing the attached fix.

[Bug libbacktrace/89362] New: [8/9 regression] zlib support breaks libbacktrace on strict-alignment platforms

2019-02-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89362

Bug ID: 89362
   Summary: [8/9 regression] zlib support breaks libbacktrace on
strict-alignment platforms
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---

The new zlib support (PR other/67165) has broken the library on
strict-alignment platforms, for example SPARC64/Linux.  Here's a typical ICE
report:

ebotcazou@gcc202:~/build$ gcc/cc1 -quiet pr35318.c -m32 -mcpu=ultrasparc   
pr35318.c: In function 'foo':
pr35318.c:9:1: error: unrecognizable insn:
9 | }
  | ^
(insn 14 28 29 2 (parallel [
(set (reg:DF 10 %o2 [orig:113 x ] [113])
(asm_operands/v:DF ("") ("=r,r") 0 [
(reg:SI 11 %o3 [orig:113 x+4 ] [113])
(mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -24 [0xffe8])) [3
%sfp+-24 S8 A64])
]
 [
(asm_input:DF ("%0,0") pr35318.c:8)
(asm_input:SI ("m,r") pr35318.c:8)
]
 [] pr35318.c:8))
(set (reg:DF 2 %g2 [orig:114 y ] [114])
(asm_operands/v:DF ("") ("=r,r") 1 [
(reg:SI 11 %o3 [orig:113 x+4 ] [113])
(mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -24 [0xffe8])) [3
%sfp+-24 S8 A64])
]
 [
(asm_input:DF ("%0,0") pr35318.c:8)
(asm_input:SI ("m,r") pr35318.c:8)
]
 [] pr35318.c:8))
]) "pr35318.c":8:3 -1
 (nil))
during RTL pass: reload

during RTL pass: reload
pr35318.c:9:1: internal compiler error: in extract_constrain_insn, at
recog.c:2211

pr35318.c:9:1: internal compiler error: Bus error
Bus error

Program received signal SIGBUS, Bus error.
0x01138ab4 in elf_uncompress_chdr (state=0xfff8000100044000, 
compressed=0xfff8000104ca48af "", compressed_size=4074875, 
zdebug_table=0xfff800010353e000, error_callback=
0x111dfc4 <__sanitizer::(anonymous namespace)::ErrorCallback(void*,
char const*, int)>, data=0x7fed5b8, uncompressed=0x7fec670, 
uncompressed_size=0x7fec668)
at
/home/ebotcazou/src/libsanitizer/libbacktrace/../../libbacktrace/elf.c:2580
2580  if (chdr->ch_type != ELFCOMPRESS_ZLIB)

The problem is that most debug sections have alignment 1 so you cannot do:

 chdr = (const b_elf_chdr *) compressed;

and expect to have a valid b_elf_chdr on strict-alignment platforms.

This also breaks the sanitizer on these platforms.

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Yeah, it adds an artificial field like:
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea939bd0 context >
ignored decl_6 QI pr89358.c:2:8 size 
unit-size 
align:8 warn_if_not_align:0 offset_align 8 offset  bit-offset  context
 chain >

DECL_FIELD_IS_BASE is lost after free-lang-data I'd say, so what LTO ODR
checking could look for is FIELD_DECL is NULL DECL_NAME, DECL_ARTIFICIAL,
DECL_IGNORED_P with size_zero_node DECL_SIZE and ignore those if missing just
in one case?

[Bug target/89361] [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361

Jakub Jelinek  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org
   Target Milestone|--- |7.5

[Bug target/89361] New: [7/8/9 Regression] s390 broken without S390_USE_TARGET_ATTRIBUTE, likely since r257489

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89361

Bug ID: 89361
   Summary: [7/8/9 Regression] s390 broken without
S390_USE_TARGET_ATTRIBUTE, likely since r257489
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

When configuring s390x-linux with old binutils or without binutils, when
HAVE_AS_MACHINE_MACHINEMODE is not defined, the resulting compiler is totally
broken.
The problem is that s390_indirect_branch_settings is never called in that case,
so cfun->machine->indirect_branch_{jump,call} and
cfun->machine->function_return_{reg,mem} are indirect_branch_unset / 0 and thus
it emits unconditionally the indirect branch stuff, regardless of what options
user actually used.

[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables

2019-02-15 Thread pjp at fedoraproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210

--- Comment #3 from P J P  ---
Similar options under review for LLVM
  -> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #11 from Jan Hubicka  ---
I will take a look. I suppose the representation of classes differs based on
std setting and that makes the ODR verifier to think they are different.

[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648

2019-02-15 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835

--- Comment #14 from Mark Wielaard  ---
(In reply to Mark Wielaard from comment #12)
> (In reply to Martin Sebor from comment #11)
> > Ah, but you mentioned elfutilts, not binutils.  I've now downloaded and
> > built elfutils-0.175.  It took a bit more effort because --disable-werror
> > doesn't work there but once I got past that I just got the three
> > -Wformat-truncation instances below:
> > 
> > DiagnosticCount   UniqueFiles
> > -Wformat-truncation=  332
> > 
> > -Wformat-truncation Instances:
> >   /src/elfutils-0.175/src/ar.c:1468
> >   /src/elfutils-0.175/src/ar.c:859
> >   /src/elfutils-0.175/src/arlib.c:63
> 
> I am not seeing these, but they might have been fixed in git. We like to
> keep the code warning free since we always build with -Werror.

Aha, I now see, you are using -Wformat-truncation=2. Then yes, these snprintfs
formats could produce more characters than would fit in the given buffer/size.
But that is kind of the point of the code, that we don't overflow the given
buffer. The snprintf is supposed to truncate to what would fit in these cases.
I can see if I could come up with something smarter to detect this without
using snprintf, but that seems to defeat the point of using snprintf. So for
now we just don't use -Wformat-truncation=2. (Background, ar files are weird,
they use fixed size character fields for numbers as decimal strings without a
zero terminator, but right padded with spaces.)

The specific warnings which we enable can be found in config/eu.am and depend
on some configure checks to make sure gcc supports them:

AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
-Wold-style-definition -Wstrict-prototypes -Wtrampolines \
$(LOGICAL_OP_WARNING) $(DUPLICATED_COND_WARNING) \
$(NULL_DEREFERENCE_WARNING) $(IMPLICIT_FALLTHROUGH_WARNING) \
$(if $($(*F)_no_Werror),,-Werror) \
$(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
$(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
$(if $($(*F)_no_Wpacked_not_aligned),-Wno-packed-not-aligned,) \
$($(*F)_CFLAGS)

With the following (if supported):

STACK_USAGE_WARNING=-Wstack-usage=262144
LOGICAL_OP_WARNING=-Wlogical-op
DUPLICATED_COND_WARNING=-Wduplicated-cond
NULL_DEREFERENCE_WARNING=-Wnull-dereference
IMPLICIT_FALLTHROUGH_WARNING=-Wimplicit-fallthrough=5

As you can see individual files can turn off some of these if necessary in the
Makefile by adding file_no_Wxxx. So the easiest way to see which warnings are
used it by running make V=1 which for this specific case gives (note the -m32
since I am running this on x86_64):

gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/local/share/locale"' 
-DDEBUGPRED=0 -DSRCDIR=\"/home/mark/src/elfutils/src\"
-DOBJDIR=\"/opt/local/build/elfutils-obj/src\" -I.
-I/home/mark/src/elfutils/src -I..  -I. -I/home/mark/src/elfutils/src
-I/home/mark/src/elfutils/lib -I.. -I/home/mark/src/elfutils/src/../libelf
-I/home/mark/src/elfutils/src/../libebl -I/home/mark/src/elfutils/src/../libdw
-I/home/mark/src/elfutils/src/../libdwelf
-I/home/mark/src/elfutils/src/../libdwfl
-I/home/mark/src/elfutils/src/../libasm  -std=gnu99 -Wall -Wshadow -Wformat=2
-Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op
-Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused
-Wextra-D_FORTIFY_SOURCE=2 -m32 -g -O2 -DBAD_FTS=1 -MT readelf.o -MD -MP
-MF .deps/readelf.Tpo -c -o readelf.o /home/mark/src/elfutils/src/readelf.c
/home/mark/src/elfutils/src/readelf.c: In function ‘print_debug_str_section’:
/home/mark/src/elfutils/src/readelf.c:10167:15: error: ‘%*llx’ directive output
between 4 and 2147483647 bytes may cause result to exceed ‘INT_MAX’
[-Werror=format-overflow=]
10167 |   printf (" [%*" PRIx64 "]  \"%s\"\n", digits, (uint64_t) offset,
str);
  |   ^~
/home/mark/src/elfutils/src/readelf.c:10167:18: note: format string is defined
here
10167 |   printf (" [%*" PRIx64 "]  \"%s\"\n", digits, (uint64_t) offset,
str);
/home/mark/src/elfutils/src/readelf.c:10167:15: note: directive argument in the
range [0, 18446744073709551614]
10167 |   printf (" [%*" PRIx64 "]  \"%s\"\n", digits, (uint64_t) offset,
str);
  |   ^~
cc1: all warnings being treated as errors

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||hubicka at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
Started with r241187.

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #9 from Martin Liška  ---
So I ended up with:

--- 1.ii ---
struct a {};
struct b : a {
} c;
--- 2.ii ---
cat 2.ii
struct a {};
struct b : a {
} c2;

$ g++ -flto -c -std=c++14 1.ii && g++ -flto -c -std=c++17 2.ii && g++ [12].o
-shared
1.ii:2:8: warning: type ‘struct b’ violates the C++ One Definition Rule [-Wodr]
 struct b : a {
^
2.ii:2:8: note: a type with different bases is defined in another translation
unit
 struct b : a {
^

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction

--- Comment #8 from Martin Liška  ---
I'm trying to creduce that..

[Bug rtl-optimization/66152] [9 Regression] suboptimal load bytes to stack

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 45729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45729=edit
gcc9-pr66152.patch

Untested fix to handle '\0's embedded at the start of in the middle of
STRING_CSTs when storing it into memory.

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

2019-02-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349

--- Comment #10 from Eric Botcazou  ---
> Building gcc 8 with gcc 8 is fine.

OK, thanks.

> Can you please Eric try to reproduce that locally?

Sure, as soon as the compiler builds again for me...
  https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01155.html

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Martin Liška  ---
(In reply to Eric Botcazou from comment #8)
> > It won't help. Note that my original reproducer was openSUSE package build
> > (which always uses bootstrap).
> 
> Well, at least it would give some hint as to what goes wrong and whether
> this is an issue in GCC 8 or GCC 9.  Can you try with GCC 8 itself then?

Building gcc 8 with gcc 8 is fine.
Can you please Eric try to reproduce that locally?

[Bug rtl-optimization/89242] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
Summary|[7 Regression] ICE in   |ICE in verify_dominators,
   |verify_dominators, at   |at dominance.c:1184 (error:
   |dominance.c:1184 (error:|dominator of 7 should be 5,
   |dominator of 7 should be 5, |not 2)
   |not 2)  |
  Known to fail|7.4.0   |

--- Comment #7 from Martin Liška  ---
Fixed on all active branches.

[Bug ipa/89009] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.4.0
Summary|[7 Regression]  |Miscompilation (missing
   |Miscompilation (missing |function call) with
   |function call) with |-fvisibility=hidden -fpic
   |-fvisibility=hidden -fpic   |-O2 -fno-inline
   |-O2 -fno-inline |
  Known to fail|7.4.0   |

--- Comment #18 from Martin Liška  ---
Fixed on all active branches.

[Bug ipa/89009] [7 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009

--- Comment #17 from Martin Liška  ---
Author: marxin
Date: Fri Feb 15 10:58:49 2019
New Revision: 268937

URL: https://gcc.gnu.org/viewcvs?rev=268937=gcc=rev
Log:
Backport r268762

2019-02-15  Martin Liska  

Backport from mainline
2019-02-11  Martin Liska  

PR ipa/89009
* ipa-cp.c (build_toporder_info): Remove usage of a param.
* ipa-inline.c (inline_small_functions): Likewise.
* ipa-pure-const.c (propagate_pure_const): Likewise.
(propagate_nothrow): Likewise.
* ipa-reference.c (propagate): Likewise.
* ipa-utils.c (struct searchc_env): Remove unused field.
(searchc): Always search across AVAIL_INTERPOSABLE.
(ipa_reduced_postorder): Always allow AVAIL_INTERPOSABLE as
the only called IPA pure const can properly not propagate
across interposable boundary.
* ipa-utils.h (ipa_reduced_postorder): Remove param.
2019-02-15  Martin Liska  

Backport from mainline
2019-02-11  Martin Liska  

PR ipa/89009
* g++.dg/ipa/pr89009.C: New test.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/ipa-cp.c
branches/gcc-7-branch/gcc/ipa-inline.c
branches/gcc-7-branch/gcc/ipa-pure-const.c
branches/gcc-7-branch/gcc/ipa-reference.c
branches/gcc-7-branch/gcc/ipa-utils.c
branches/gcc-7-branch/gcc/ipa-utils.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89242] [7 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri Feb 15 10:59:02 2019
New Revision: 268938

URL: https://gcc.gnu.org/viewcvs?rev=268938=gcc=rev
Log:
Backport r268873

2019-02-15  Martin Liska  

Backport from mainline
2019-02-14  Martin Liska  

PR rtl-optimization/89242
* dce.c (delete_unmarked_insns): Call free_dominance_info we
process a transformation.
2019-02-15  Martin Liska  

Backport from mainline
2019-02-14  Martin Liska  

PR rtl-optimization/89242
* g++.dg/pr89242.C: New test.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dce.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug go/89123] Too many go test failures on s390x-linux

2019-02-15 Thread rdapp at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123

--- Comment #11 from rdapp at linux dot ibm.com ---
Ping.

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

--- Comment #7 from Jonathan Wakely  ---
Taking just this code:

template
  struct binary_function
  {
typedef _Arg1 first_argument_type;
typedef _Arg2 second_argument_type;
typedef _Result result_type;
  };

template
  struct less : public binary_function<_Tp, _Tp, bool>
  {
constexpr
bool
operator()(const _Tp& __x, const _Tp& __y) const
{ return __x < __y; }
  };

int f(int i, int j)
{
  return less()(i, j);
}

Compiling as C++14 and C++14 and comparing the -fdump-tree-original dumps I
see:

--- f.cc.003t.original.14   2019-02-15 10:43:10.841906030 +
+++ f.cc.003t.original.17   2019-02-15 10:43:15.442914718 +
@@ -10,5 +10,5 @@
 ;; enabled by -tree-original


-< = (int) less::operator() (_EXPR
, (const int &) , (const int &) )>>;
+< = (int) less::operator() (_EXPR
, (const int &) , (const int &) )>>;


So the generated code is slightly different when using -std=c++17, would that
cause -Wodr to complain?

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

--- Comment #6 from Jonathan Wakely  ---
It's true that the two bases are defined in different translation units, but
that's irrelevant. What the C++ language requires is that the definitions
consist of the same sequence of tokens, it doesn't matter which file they are
defined in. If I am allergic to headers it's perfectly fine to copy & paste the
same code into the top of every translation unit instead of using headers.

The relevant rule is http://eel.is/c++draft/basic.def.odr#12 and the example
above doesn't violate it.

[Bug rtl-optimization/66152] [9 Regression] suboptimal load bytes to stack

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-15
Version|unknown |9.0
   Target Milestone|--- |9.0
Summary|suboptimal load bytes to|[9 Regression] suboptimal
   |stack   |load bytes to stack
 Ever confirmed|0   |1

--- Comment #6 from Jakub Jelinek  ---
That only happens if there is '\0' embedded in the created string before end.
Anyway, this makes it a regression.

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

--- Comment #5 from Jonathan Wakely  ---
This shows it has nothing to do with r243379 at all:


template
  struct binary_function
  {
typedef _Arg1 first_argument_type;
typedef _Arg2 second_argument_type;
typedef _Result result_type;
  };

template
  struct less : public binary_function<_Tp, _Tp, bool>
  {
constexpr
bool
operator()(const _Tp& __x, const _Tp& __y) const
{ return __x < __y; }
  };

int f(int i, int j);

#if __cplusplus < 201703L

int f(int i, int j)
{
  return less()(i, j);
}

#else

int main()
{
  return less()(3, 4) == f(2, 1);
}

#endif


g++ -flto -c src.cc
g++ -flto -c src.cc -std=c++17 -o src17.o
g++ -flto src.o src17.o
src.cc:10:10: warning: type ‘struct less’ violates the C++ One Definition Rule
[-Wodr]
   struct less : public binary_function<_Tp, _Tp, bool>
  ^
src.cc:10:10: note: a type with different bases is defined in another
translation unit
   struct less : public binary_function<_Tp, _Tp, bool>
  ^
src.cc:14:5: warning: ‘operator()’ violates the C++ One Definition Rule 
[-Wodr]
 operator()(const _Tp& __x, const _Tp& __y) const
 ^
src.cc:14:5: note: ‘operator()’ was previously declared here
 operator()(const _Tp& __x, const _Tp& __y) const
 ^


This shows the exact same source code, compiled with -std=c++14 and -std=c++17,
and bogus warnings about different bases.

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

--- Comment #4 from Jonathan Wakely  ---
I see this warning even when compiling preprocessed source that was all
produced using -std=c++14 (so the input source code is identical):

g++ -E main.cpp -o main.ii
g++ -E test.cpp -o test.ii
g++ -flto -c main.ii -std=c++17
g++ -flto -c test.ii
g++ -flto main.o test.o
/usr/include/c++/8/bits/stl_function.h:381:12: note: type ‘struct less’ itself
violates the C++ One Definition Rule
 struct less : public binary_function<_Tp, _Tp, bool>
^

So this appears to be a difference introduced by the compiler, not the source
code. Either there's a compiler bug causing unwanted differences depending on
-sd options, or the warnings need to be suppressed because the differences are
intended.

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

--- Comment #3 from Jonathan Wakely  ---
That change introduces some differences between C++98 and later modes, but the
testcase use C++14 and C++17. There are no differences in the code. There's
certainly no difference between std::less in the two modes.

Even so, we need to be able to make parts of the std::lib conditional on the
standard version, as long as the semantics remain the same. These warnings are
not helpful if they make users worry about harmless implementation details.

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

2019-02-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from Eric Botcazou  ---
> It won't help. Note that my original reproducer was openSUSE package build
> (which always uses bootstrap).

Well, at least it would give some hint as to what goes wrong and whether this
is an issue in GCC 8 or GCC 9.  Can you try with GCC 8 itself then?

[Bug lto/45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 88858, which changed state.

Bug 88858 Summary: ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox 
build with LTO and PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88858

   What|Removed |Added

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

[Bug lto/88858] ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88858

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.0
 Resolution|--- |FIXED
  Known to fail|7.4.0   |

--- Comment #5 from Martin Liška  ---
GCC 7 branch is not affected, closing then.

[Bug tree-optimization/89360] New: GCC doesn't emit movcc instruction in some cases

2019-02-15 Thread SztfG at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89360

Bug ID: 89360
   Summary: GCC doesn't emit movcc instruction in some cases
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---
Target: x86_64-linux-gnu

Here are two function:

void sort2_ternary(int a, int b, int *pa, int *pb)
{
  *pa = a < b ? a : b;
  *pb = a < b ? b : a;
}

void sort2_if(int a, int b, int *pa, int *pb)
{
  if (a < b) {
*pa = a;
*pb = b;
  }
  else
  {
*pa = b;
*pb = a;
  }
}

GCC does not emit CMOVcc (conditional move) on GCC 8.2 if we compile it as C++
code

https://godbolt.org/z/ytE0Ix

sort2_ternary(int, int, int*, int*):
cmp edi, esi
jge .L2
mov eax, edi
mov edi, esi
mov esi, eax
.L2:
mov DWORD PTR [rdx], esi
mov DWORD PTR [rcx], edi
ret
sort2_if(int, int, int*, int*):
cmp edi, esi
jge .L5
mov DWORD PTR [rdx], edi
mov DWORD PTR [rcx], esi
ret
.L5:
mov DWORD PTR [rdx], esi
mov DWORD PTR [rcx], edi
ret

but if compile it as C code, sort2_ternary have MOVcc:

sort2_ternary:
cmp esi, edi
mov eax, edi
cmovle  eax, esi
cmovl   esi, edi
mov DWORD PTR [rdx], eax
mov DWORD PTR [rcx], esi
ret

but sort2_if remains same.


On GCC trunk there is no difference between compiling this as C or C++ for
sort2_ternary(), but sort2_if() still doesn't have CMOVcc instruction in it for
both case.


Measuring cmov vs branch-mov performance: https://github.com/xiadz/cmov

[Bug rtl-optimization/66152] suboptimal load bytes to stack

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
That changed with r263511, which now treats the {0,1,2,3,4,5,6,7} initializer
like "\0\1\2\3\4\5\6\7", so that means even GCC 8 expanded the latter this way.

[Bug rtl-optimization/66152] suboptimal load bytes to stack

2019-02-15 Thread SztfG at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152

--- Comment #4 from SztfG at yandex dot ru ---
GCC from trunk doing this:

.Ltext0:
.LC0:
  .string ""
  .ascii "\001\002\003\004\005\006\007"
bar:
.LFB0:
  sub rsp, 24
  mov rax, QWORD PTR .LC0[rip]
  lea rdi, [rsp+8]
  mov QWORD PTR [rsp+8], rax
  call foo
.LVL0:
  add rsp, 24
  ret
.LFE0:

instead movabsq $506097522914230528, %rax

[Bug lto/89358] [7/8/9 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358

Martin Liška  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org
  Known to work||6.4.0
Summary|Combining -std=c++14 and|[7/8/9 Regression]
   |-std=c++17 objects gives|Combining -std=c++14 and
   |ODR warnings|-std=c++17 objects gives
   ||ODR warnings
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #2 from Martin Liška  ---
I see it starting with r243379, would it be possible culprit of that?

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Martin Liška  ---
(In reply to Eric Botcazou from comment #6)
> > My reproducer described in the first comment was:
> > 1) build gcc trunk w/o bootstrap and install it
> > 2) use the compiler and build gcc-8 branch w/o bootstrap
> > 3) Ada FE is successfully built, but Ada runtime build fails (with gcc-8 Ada
> > FE)
> 
> Sure, but the question is what happens if remove --disable-bootstrap from
> the configure line you posted?

It won't help. Note that my original reproducer was openSUSE package build
(which always uses bootstrap).

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

--- Comment #8 from Jakub Jelinek  ---
Created attachment 45728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45728=edit
gcc9-pr89350.patch

Untested patch for the argc range stuff.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

--- Comment #7 from Martin Liška  ---
Thanks for analysis.

> 
> The bogus warning can be avoided in the first case simply by punting on
> offsets that could be in the negative range, but almost certainly not
> without some false negatives. 

Yes, I can confirm that adding a check for negative values can make
the warning gone.

>  I'm not sure it's necessarily a good tradeoff
> (I don't know that it isn't either).  Is this code representative of some
> wide-spread idiom?

I see it just in one package.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

--- Comment #6 from Martin Liška  ---
Created attachment 45727
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45727=edit
original test-case

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

--- Comment #5 from Martin Liška  ---
> That said, I bet the original package code didn't have the warning in main
> but somewhere else.

Yes.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

--- Comment #4 from Jakub Jelinek  ---
Note, e.g. C99 guarantees that:
"If they are declared, the parameters to the main function shall obey the
following constraints:
— The value of argc shall be nonnegative."
Similarly C++, http://eel.is/c++draft/basic.start.main
"The value of argc shall be non-negative."

So, we could do this, or perhaps add
lang_GNU_C () || lang_GNU_CXX () || lang_GNU_OBJC ()
check too, evrp is pre-IPA pass and thus it can check the defining language
easily.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

2019-02-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Well, we could perhaps do something like:
--- gcc/gimple-ssa-evrp.c.jj2019-01-01 12:37:15.712998659 +0100
+++ gcc/gimple-ssa-evrp.c   2019-02-15 09:27:49.569441402 +0100
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.
 #include "tree-cfgcleanup.h"
 #include "vr-values.h"
 #include "gimple-ssa-evrp-analyze.h"
+#include "tree-dfa.h"

 class evrp_folder : public substitute_and_fold_engine
 {
@@ -307,6 +308,21 @@ execute_early_vrp ()
   scev_initialize ();
   calculate_dominance_info (CDI_DOMINATORS);

+  /* argc in main is never negative.  */
+  if (MAIN_NAME_P (DECL_NAME (current_function_decl))
+  && DECL_ARGUMENTS (current_function_decl))
+{
+  tree argc = DECL_ARGUMENTS (current_function_decl);
+  if (TYPE_MAIN_VARIANT (TREE_TYPE (argc)) == integer_type_node)
+   {
+ argc = ssa_default_def (cfun, argc);
+ if (argc && SSA_NAME_RANGE_INFO (argc) == NULL)
+   set_range_info (argc, VR_RANGE,
+   wi::zero (TYPE_PRECISION (integer_type_node)),
+   wi::to_wide (TYPE_MAX_VALUE (integer_type_node)));
+   }
+}
+
   /* Walk stmts in dominance order and propagate VRP.  */
   evrp_dom_walker walker;
   walker.walk (ENTRY_BLOCK_PTR_FOR_FN (cfun));
(not really sure if it will work fine with Ada, it does some games with main).

That said, I bet the original package code didn't have the warning in main but
somewhere else.