[Bug translation/90180] ambiguous diagnostic for "out of range"

2019-04-19 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90180

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Most middle-end diagnostics format ranges using the [min, max] notation (and
less commonly [min, max + 1) for half open intervals).  If I'm reading the
s390.c code correctly, here (0..%wu) would be rendered as the closed interval
[0, %wu] by the middle-end.  We should adopt the same convention throughout. 
Thus confirmed.

[Bug translation/90164] wrong tense in ABI change diagnostic

2019-04-19 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90164

--- Comment #3 from Martin Sebor  ---
Agreed.

[Bug translation/90164] wrong tense in ABI change diagnostic

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90164

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  There seems to be little consistency between "changes" and "has
changed" -- it's 11 vs 6.  But "has changed" seems more appropriate here
since/when it's still in effect in the current version.

$ grep " change[ds] " gcc/po/gcc.pot | grep ABI
msgid "AVX512F vector argument without AVX512F enabled changes the ABI"
msgid "AVX512F vector return without AVX512F enabled changes the ABI"
msgid "AVX vector argument without AVX enabled changes the ABI"
msgid "AVX vector return without AVX enabled changes the ABI"
msgid "SSE vector argument without SSE enabled changes the ABI"
msgid "SSE vector return without SSE enabled changes the ABI"
msgid "MMX vector argument without MMX enabled changes the ABI"
msgid "MMX vector return without MMX enabled changes the ABI"
"the ABI of passing struct with a flexible array member has changed in GCC 4.4"
msgid "the ABI of passing union with long double has changed in GCC 4.4"
"the ABI of passing structure with complex float member has changed in GCC 4.4"
"the ABI for passing parameters with %d-byte alignment has changed in GCC 4.6"
"empty class %qT parameter passing ABI changes in %<-fabi-version=12%> (GCC 8)"
msgid "target attribute or pragma changes AltiVec ABI"
msgid "target attribute or pragma changes darwin64 ABI"
"the ABI of passing aggregates with %d-byte alignment has changed in GCC 5"
msgid "the ABI of passing homogeneous float aggregates has changed in GCC 5"

[Bug translation/79878] verify_gimple_assign_single: replace error with internal_error

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79878

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
This predates pr90149 but that one has more detail so I'm resolving this as a
dupe of the latter.

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

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149

--- Comment #5 from Martin Sebor  ---
*** Bug 79878 has been marked as a duplicate of this bug. ***

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Thu Apr 18 20:26:07 2019
New Revision: 270447

URL: https://gcc.gnu.org/viewcvs?rev=270447=gcc=rev
Log:
PR middle-end/89797 - ICE on a vector_size (1LU << 33) int variable 

gcc/ChangeLog:
* tree.h (TYPE_VECTOR_SUBPARTS): Use HOST_WIDE_INT_1U.
* config/aarch64/aarch64.c (aarch64_simd_vector_alignment): Avoid
assuming type size fits in SHWI.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/tree.h

[Bug translation/90162] exclamation mark in diagnostic!!!!!1111!!!!

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90162

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The -Wformat-diag checker I'm working on detects this.  The
capitalization should also be corrected.

[Bug translation/90158] aarch64: wrong quotation in diagnostics

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90158

Martin Sebor  changed:

   What|Removed |Added

 Blocks||90156

--- Comment #3 from Martin Sebor  ---
See pr90156 for the general request to add a checker for these misquoting
patterns.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90156
[Bug 90156] add linter check suggesting to replace %<%s%> with %qs

[Bug translation/90156] add linter check suggesting to replace %<%s%> with %qs

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90156

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I'm working on it for GCC 10.

[Bug translation/90160] missing quote in diagnostic

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90160

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90158
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed.  See also pr90158 for similar issues.

[Bug translation/90158] aarch64: wrong quotation in diagnostics

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90158

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  Let me add the \"%s\" pattern to my diagnostic checker to flag
outside %< and %>.

I'll see if also flagging plain either %s or " %s " wouldn't cause too many
false positives for valid uses.

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

2019-04-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-18
 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
FWIW, I'm working on a -Wformat enhancement to detect this and some of the
other translation problems you have pointed out.  I'm also going through
gcc.pot and looking for patterns like this to detect myself but having them
pointed out by someone actually doing the translation is very helpful.  Thank
you!

As for this specific error (and others like it) in tree-cfg.c and a few other
files, they are issued for failures detected by internal consistency checks
that ultimately do trigger an internal compiler error.  In my patch I disable
the detection of these problems via #pragma GCC diagnostic ignored
"-Wformat-diag" but another option is to simply fix them:

  error ("%qs of non-mode-precision operand", "BIT_FIELD_REF");

The challenge with doing it that it would changing a fair number of messages
and in some cases, make the format strings look pretty cryptic (by replacing
multiple strings with %s directives).

[Bug bootstrap/90132] make bootstrap fails with -O3 (gcc9 snapshot 20190414)

2019-04-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132

--- Comment #2 from Martin Sebor  ---
I think the following test case reproduces what's going on in decNumber.c. 
Both GCC 8 and 9 issue the warning (IIRC, the warning was added in GCC 7 for
writes but enhanced to reads in GCC 8).

$ cat a.c && gcc -O3 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
struct S
{
  int n, a[1];
};

static inline void f (int *d, const struct S *p)
{
  const int *e = p->n > 1 ? p->a + p->n : p->a + 1;

  for (const int *s = p->a + 1; s < e; ++s, ++d)
*d = *s;
}

void g (struct S*);

void h (int *d)
{
  struct S s = { 0 };
  g ();
  f (d, );
}

;; Function h (h, funcdef_no=1, decl_uid=1920, cgraph_uid=2, symbol_order=1)

Removing basic block 6
Removing basic block 7
h (int * d)
{
  struct S s;
  int _6;
  long unsigned int _7;
  long unsigned int _8;
  const int * iftmp.0_9;
  unsigned long _15;
  unsigned long _16;
  sizetype _20;
  unsigned long _23;
  sizetype _24;
  unsigned long _25;
  unsigned long _26;

   [local count: 118111600]:
  s = {};
  g ();
  _6 = s.n;
  if (_6 > 1)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 69685844]:
  _7 = (long unsigned int) _6;
  _8 = _7 * 4;
  iftmp.0_9 =  + _8;
  if ([(void *) + 8B] < iftmp.0_9)
goto ; [93.20%]
  else
goto ; [6.80%]

   [local count: 64949629]:
  _26 = (unsigned long) iftmp.0_9;
  _16 = (unsigned long) [(void *) + 8B];
  _15 = ~_16;
  _23 = _15 + _26;
  _25 = _23 >> 2;
  _24 = _25 + 1;
  _20 = _24 * 4;
  __builtin_memcpy (d_4(D), [(void *) + 8B], _20); [tail call]

   [local count: 118111601]:
  s ={v} {CLOBBER};
  return;

}


a.c: In function ‘h’:
cc1: warning: ‘__builtin_memcpy’ reading 4 or more bytes from a region of size
0 [-Wstringop-overflow=]

[Bug bootstrap/90132] make bootstrap fails with -O3 (gcc9 snapshot 20190414)

2019-04-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-17
 CC||msebor at gcc dot gnu.org
 Blocks||88443
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I can reproduce the warning without -fPIC:

$ (cd /build/gcc-svn-self/libdecnumber  && /build/gcc-svn/gcc/xgcc -B
/build/gcc-svn/gcc  -I/src/gcc/svn/libdecnumber -I.  -O3 -g3 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long  -fno-lto
-I/src/gcc/svn/libdecnumber -I. -S /src/gcc/svn/libdecnumber/decNumber.c)
/src/gcc/svn/libdecnumber/decNumber.c: In function ‘decNumberPower’:
cc1: warning: ‘__builtin_memcpy’ reading 2 or more bytes from a region of size
0 [-Wstringop-overflow=]
$ 

The variable being read is dnOne:

   [local count: 3614127]:
  # iftmp.231_443 = PHI 
  smsup_444 =  + iftmp.231_443;
  if ([(void *) + 12B] < smsup_444)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 3216573]:
  _110 = (unsigned long) smsup_444;
  _550 = (unsigned long) [(void *) + 12B];
  _568 = ~_550;
  _525 = _110 + _568;
  _524 = _525 >> 1;
  _520 = _524 + 1;
  _518 = _520 * 2;
  __builtin_memcpy (d_434, [(void *) + 12B], _518);

The offset 12 in the MEM_REF corresponds to sizeof (decnumber). 
compute_builtin_object_size() returns zero for [(void *) + 12B] and
_518's range is ~[1, 1], so either zero or 2 or more.  The warning doesn't
consider the unlikely case of zero and treats the anti-range as [2, SIZE_MAX].

The missing location information suggests the memcpy call is the result of some
transformation.  The reference to smsup implies it comes from this loop in
decNumberCopy() (the only function in the translation unit that defines the
smsup variable):

  if (src->digits>3) {
const uint16_t *smsup, *s;
uint16_t *d;


d=dest->lsu+1;
smsup=src->lsu+((src->digits)<=49?d2utable[src->digits]:((src->digits)+3
-1)/3);
for (s=src->lsu+1; slsu+1 is past the end of the dnOne object but smsup has one of two
values: src->lsu + d2utable[src->digits] or src->lsu + 1, and the first one
doesn't look determinate because dnOne is also used as some sort of a temporary
by decNumberPower and its digits member (initially set to 1) is overwritten. 
So the loop gets transformed into memcpy that reads some number other than 1
from an object of size zero.

Adding an assertion like in the otherwise untested patch below should let GCC
see that dnOne.digits is unchanged.  I don't know enough about the library to
tell if that's actually correct or what the correct macro or value to use here
might be.

===
--- libdecnumber/decNumber.c(revision 270418)
+++ libdecnumber/decNumber.c(working copy)
@@ -2188,6 +2188,8 @@ decNumber * decNumberPower(decNumber *res, const d
}
  /* [inv now points to big-enough buffer or allocated storage] */
  decNumberCopy(inv, dac);  /* copy the 1/lhs */
+ if (dnOne.digits > 1)
+   __builtin_unreachable ();
  decNumberCopy(dac, );   /* restore acc=1 */
  lhs=inv;  /* .. and go forward with new lhs */
#if DECSUBSET


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565

--- Comment #13 from Martin Sebor  ---
As noted in the duplicate pr90122, the test case below shows that GCC already
relies on different extern declarations denoting distinct objects.  It just
doesn't fold the address equality expression for some reason.

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-fno-common x.c
extern int a, b;

void foo ();
void bar ();

void f (void)
{
  if ( == )   // not folded
foo ();

  int i = a;
  b = 0;
  if (i != a) // folded to false
bar ();
}

;; Function f (f, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=2)

Removing basic block 5
f ()
{
   [local count: 1073741824]:
  if ( == )
goto ; [17.43%]
  else
goto ; [82.57%]

   [local count: 187153200]:
  foo ();

   [local count: 1073741824]:
  b = 0;
  return;

}

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565

--- Comment #12 from Martin Sebor  ---
*** Bug 90122 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/90122] inequality of addresses of distinct objects not folded

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Thanks for the pointer!  I forgot about that ancient bug.  It looks like an
exact duplicate of pr43565.

A and b's addresses must be different because they are distinct declarations of
different objects.  There's no way (in standard C) to make them refer to the
same object.  That GCC itself relies on different declarations denoting
distinct objects is evident from the second if being eliminated.

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

[Bug tree-optimization/90122] New: inequality of addresses of distinct objects not folded

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122

Bug ID: 90122
   Summary: inequality of addresses of distinct objects not folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below GCC folds the second test (as expected, on the
assumption that distinct declarations refer to distinct objects) but fails to
fold the first.

Clang folds both (into false and true, respectively).  GCC will only do that if
a and b are static or local.

Same with extern arrays of known size.

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-fno-common x.c
extern int a, b;

void foo ();
void bar ();

void f (void)
{
  if ( == )
foo ();

  int i = a;
  b = 0;
  if (i != a)
bar ();
}

;; Function f (f, funcdef_no=0, decl_uid=1910, cgraph_uid=1, symbol_order=2)

Removing basic block 5
f ()
{
   [local count: 1073741824]:
  if ( == )
goto ; [17.43%]
  else
goto ; [82.57%]

   [local count: 187153200]:
  foo ();

   [local count: 1073741824]:
  b = 0;
  return;

}

[Bug c++/65799] Allows constexpr conversion from cv void * to other type

2019-04-16 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799

Martin Sebor  changed:

   What|Removed |Added

 Blocks||55004

--- Comment #6 from Martin Sebor  ---
Sure, I can look into it sometime in stage 1.  But I'm not sure these bugs are
related.  The test case in comment #0 and those in pr60760 and pr71091 are
about invalid uses of null pointers in constexpr contexts.  The test cases here
don't involve bull pointers.  Rejecting invalid casts was the subject of
pr49171 (fixed in r259629).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c/90081] stdint constant macros evaluating to wrong type

2019-04-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081

Martin Sebor  changed:

   What|Removed |Added

URL||http://www.open-std.org/jtc
   ||1/sc22/wg14/www/docs/summar
   ||y.htm#dr_456
 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
UINT8_C(-5) isn't valid but expanding the macros to their arguments isn't
conforming either.  C11 DR #456 suggests compiler magic is necessary to make
the macros correct:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_456 (Also see
C99 DR 209: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_209.htm).

[Bug c/89798] excessive vector_size silently accepted and truncated

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 22:37:12 2019
New Revision: 270331

URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev
Log:
Commit a change missed in r270326:

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .


Modified:
trunk/gcc/c-family/c-attribs.c

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 22:37:12 2019
New Revision: 270331

URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev
Log:
Commit a change missed in r270326:

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .


Modified:
trunk/gcc/c-family/c-attribs.c

[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 22:37:12 2019
New Revision: 270331

URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev
Log:
Commit a change missed in r270326:

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .


Modified:
trunk/gcc/c-family/c-attribs.c

[Bug c/88383] ICE calling _builtin_has_attribute with an expression

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 22:37:12 2019
New Revision: 270331

URL: https://gcc.gnu.org/viewcvs?rev=270331=gcc=rev
Log:
Commit a change missed in r270326:

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .


Modified:
trunk/gcc/c-family/c-attribs.c

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from Martin Sebor  ---
Fixed in r270326.

[Bug c/89798] excessive vector_size silently accepted and truncated

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0
  Known to fail||8.3.0

--- Comment #6 from Martin Sebor  ---
Fixed in r270326.

[Bug c/88383] ICE calling _builtin_has_attribute with an expression

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #4 from Martin Sebor  ---
Fixed in r270326.

[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288
Bug 89288 depends on bug 88383, which changed state.

Bug 88383 Summary: ICE calling _builtin_has_attribute with an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383

   What|Removed |Added

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

[Bug c/88383] ICE calling _builtin_has_attribute with an expression

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 19:01:17 2019
New Revision: 270326

URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev
Log:
PR c/88383 - ICE calling __builtin_has_attribute on a reference
PR c/89288 - ICE in tree_code_size, at tree.c:865
PR c/89798 - excessive vector_size silently accepted and truncated
PR c/89797 - ICE on a vector_size (1LU << 33) int variable

gcc/ChangeLog:

PR c/89797
* targhooks.c (default_vector_alignment): Avoid assuming
argument fits in SHWI.
* tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in
a shift expression.
* doc/extend.texi (__builtin_has_attribute): Add a clarifying note.

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .

gcc/cp/ChangeLog:

PR c/88383
PR c/89288
* parser.c (cp_parser_has_attribute_expression): Handle assignment
expressions.

gcc/testsuite/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-c++-common/attributes-1.c: Adjust.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/builtin-has-attribute-7.c: New test.
* c-c++-common/builtin-has-attribute-4.c: Adjust expectations.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/pr71574.c: Adjust.
* gcc.dg/pr25559.c: Adjust.
* gcc.dg/attr-vector_size.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c
trunk/gcc/testsuite/gcc.dg/attr-vector_size.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attributes-1.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c
trunk/gcc/testsuite/c-c++-common/pr71574.c
trunk/gcc/testsuite/gcc.dg/pr25559.c
trunk/gcc/tree.h

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 19:01:17 2019
New Revision: 270326

URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev
Log:
PR c/88383 - ICE calling __builtin_has_attribute on a reference
PR c/89288 - ICE in tree_code_size, at tree.c:865
PR c/89798 - excessive vector_size silently accepted and truncated
PR c/89797 - ICE on a vector_size (1LU << 33) int variable

gcc/ChangeLog:

PR c/89797
* targhooks.c (default_vector_alignment): Avoid assuming
argument fits in SHWI.
* tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in
a shift expression.
* doc/extend.texi (__builtin_has_attribute): Add a clarifying note.

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .

gcc/cp/ChangeLog:

PR c/88383
PR c/89288
* parser.c (cp_parser_has_attribute_expression): Handle assignment
expressions.

gcc/testsuite/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-c++-common/attributes-1.c: Adjust.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/builtin-has-attribute-7.c: New test.
* c-c++-common/builtin-has-attribute-4.c: Adjust expectations.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/pr71574.c: Adjust.
* gcc.dg/pr25559.c: Adjust.
* gcc.dg/attr-vector_size.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c
trunk/gcc/testsuite/gcc.dg/attr-vector_size.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attributes-1.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c
trunk/gcc/testsuite/c-c++-common/pr71574.c
trunk/gcc/testsuite/gcc.dg/pr25559.c
trunk/gcc/tree.h

[Bug c/89798] excessive vector_size silently accepted and truncated

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 19:01:17 2019
New Revision: 270326

URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev
Log:
PR c/88383 - ICE calling __builtin_has_attribute on a reference
PR c/89288 - ICE in tree_code_size, at tree.c:865
PR c/89798 - excessive vector_size silently accepted and truncated
PR c/89797 - ICE on a vector_size (1LU << 33) int variable

gcc/ChangeLog:

PR c/89797
* targhooks.c (default_vector_alignment): Avoid assuming
argument fits in SHWI.
* tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in
a shift expression.
* doc/extend.texi (__builtin_has_attribute): Add a clarifying note.

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .

gcc/cp/ChangeLog:

PR c/88383
PR c/89288
* parser.c (cp_parser_has_attribute_expression): Handle assignment
expressions.

gcc/testsuite/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-c++-common/attributes-1.c: Adjust.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/builtin-has-attribute-7.c: New test.
* c-c++-common/builtin-has-attribute-4.c: Adjust expectations.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/pr71574.c: Adjust.
* gcc.dg/pr25559.c: Adjust.
* gcc.dg/attr-vector_size.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c
trunk/gcc/testsuite/gcc.dg/attr-vector_size.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attributes-1.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c
trunk/gcc/testsuite/c-c++-common/pr71574.c
trunk/gcc/testsuite/gcc.dg/pr25559.c
trunk/gcc/tree.h

[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 12 19:01:17 2019
New Revision: 270326

URL: https://gcc.gnu.org/viewcvs?rev=270326=gcc=rev
Log:
PR c/88383 - ICE calling __builtin_has_attribute on a reference
PR c/89288 - ICE in tree_code_size, at tree.c:865
PR c/89798 - excessive vector_size silently accepted and truncated
PR c/89797 - ICE on a vector_size (1LU << 33) int variable

gcc/ChangeLog:

PR c/89797
* targhooks.c (default_vector_alignment): Avoid assuming
argument fits in SHWI.
* tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in
a shift expression.
* doc/extend.texi (__builtin_has_attribute): Add a clarifying note.

gcc/c-family/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-attribs.c (type_valid_for_vector_size): Detect excessively
large sizes.
(validate_attribute): Handle DECLs and expressions.
(has_attribute): Handle types referenced by expressions.
Avoid considering array attributes in ARRAY_REF expressions .

gcc/cp/ChangeLog:

PR c/88383
PR c/89288
* parser.c (cp_parser_has_attribute_expression): Handle assignment
expressions.

gcc/testsuite/ChangeLog:

PR c/88383
PR c/89288
PR c/89798
PR c/89797
* c-c++-common/attributes-1.c: Adjust.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/builtin-has-attribute-7.c: New test.
* c-c++-common/builtin-has-attribute-4.c: Adjust expectations.
* c-c++-common/builtin-has-attribute-6.c: New test.
* c-c++-common/pr71574.c: Adjust.
* gcc.dg/pr25559.c: Adjust.
* gcc.dg/attr-vector_size.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c
trunk/gcc/testsuite/gcc.dg/attr-vector_size.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attributes-1.c
trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c
trunk/gcc/testsuite/c-c++-common/pr71574.c
trunk/gcc/testsuite/gcc.dg/pr25559.c
trunk/gcc/tree.h

[Bug tree-optimization/81435] missing strlen optimization for strcat past the beginning of clear array

2019-04-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81435

--- Comment #3 from Martin Sebor  ---
I think it means that Andrew is a maintainer of the overall tree-ssa
infrastructure.  AFAIK, he has not done any work on the strlen optimizations in
the file.  Jakub is the author of the pass so he knows the most about it.  But
he's also aware of most bugs that come in so I don't think he needs to be CC'd.

Most of the bugs I raised for the strlen pass are enhancements.  I noticed them
while testing various warnings (-Wstringop-overflow, -Wrestrict, etc.) where
they imply false negatives.  The optimizations themselves aren't necessarily
critical to performance but the better the strlen pass is at optimizing stuff
the better the warnings are at finding bugs.

I expect to be doing some work on the strlen pass for GCC 10 so I might pick up
some of these bugs in the process.

[Bug c/90036] [8/9 Regression] false positive: directive argument is null [-Werror=format-overflow=]

2019-04-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||diagnostic
   Last reconfirmed||2019-04-10
 CC||msebor at gcc dot gnu.org
 Blocks||85741
 Ever confirmed|0   |1
Summary|False positive: directive   |[8/9 Regression] false
   |argument is null|positive: directive
   |[-Werror=format-overflow=]  |argument is null
   ||[-Werror=format-overflow=]
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
(When reporting bugs we ask for a test case.  Please see
https://www.gnu.org/software/gcc/bugs).

That said, I can reproduce the warning with the top of trunk and with GCC 8. 
The reason why the warning is issued for sprintf and not for strlen is because
it is implemented differently between the two functions (it runs on different
IL).

The null in the IL is the result of the jump threading optimization.  The
warning can be suppressed by adding 'assert (vstring)' just above the sprintf
call.

Here's the IL the warning code sees:

stab_start_class_type (void * p, const char * tag, unsigned int id, bfd_boolean 
structp, unsigned int size, bfd_boolean vptr, bfd_boolean ownvptr)
{
  ...
   [local count: 237404318]:
  if (ownvptr_24(D) != 0)
goto ; [100.00%]
  else
goto ; [0.00%]
  ...
   [local count: 0]:
  _51 = strlen (0B);
  _59 = _51 + 3;
  vtable_16 = xmalloc (_59);
  sprintf (vtable_16, "~%%%s", 0B);
  _18 = MEM[(struct stab_write_handle *)p_22(D)].type_stack;
  _18->vtable = vtable_16;
  goto ; [100.00%]
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug middle-end/90037] [9 Regression] -Wnull-dereference false positive after r269302

2019-04-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1698478
  Known to work||8.3.0
 Blocks||86172
  Known to fail||9.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r269302:

r269302 | rguenth | 2019-03-01 04:21:30 -0500 (Fri, 01 Mar 2019) | 16 lines

2019-03-01  Richard Biener  

PR middle-end/89497
* tree-cfgcleanup.h (cleanup_tree_cfg): Add SSA update flags
argument, defaulted to zero.
* passes.c (execute_function_todo): Pass down SSA update flags
to cleanup_tree_cfg.
* tree-cfgcleanup.c: Include tree-into-ssa.h and tree-cfgcleanup.h.
(cleanup_tree_cfg_noloop): After cleanup_control_flow_pre update SSA
form if requested.
(cleanup_tree_cfg): Get and pass down SSA update flags.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
[Bug 86172] [meta-bug] issues with -Wnull-dereference

[Bug middle-end/90037] New: [9 Regression] -Wnull-dereference false positive after r269302

2019-04-10 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037

Bug ID: 90037
   Summary: [9 Regression] -Wnull-dereference false positive after
r269302
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46134=edit
Test case.

The false positive for the attached test case was reported in 
https://bugzilla.redhat.com/show_bug.cgi?id=1698478:

$ gcc -O2 -S -Wall -Wextra -Wnull-dereference bz1698478.c
bz1698478.c: In function ‘parse_with_separator’:
bz1698478.c:121:14: warning: potential null pointer dereference
[-Wnull-dereference]
  121 |   grp = (*g == '+' ? 0 : getgrnam (g));
  |  ^~

[Bug c++/90029] optimizing local exceptions, or are they an observable side effect

2019-04-09 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90029

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64501
 Resolution|--- |DUPLICATE
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Exceptions whose effects aren't observable could be optimized away.  I think
this is also what pr53294 requests.  See also pr64501.

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

[Bug c++/53294] Optimize out some exception code

2019-04-09 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53294

Martin Sebor  changed:

   What|Removed |Added

 CC||federico.kircheis at gmail dot 
com

--- Comment #4 from Martin Sebor  ---
*** Bug 90029 has been marked as a duplicate of this bug. ***

[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range

2019-04-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977

--- Comment #4 from Martin Sebor  ---
You're right that the conversion from int128_t to unsigned long can result in
truncation, so the range of the result is that of unsigned long.  Yet I suspect
that relying on it is more likely unintentional and a bug.  The question in my
mind is whether narrowing int128_t conversions should be diagnosed just in
these contexts (i.e., -Wstringop-overflow) or in others as well.

[Bug middle-end/89998] [7/8/9 regression] ICE: verify_gimple failed in printf-return-value

2019-04-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89998

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||msebor at gcc dot gnu.org
 Blocks||85741

--- Comment #7 from Martin Sebor  ---
This is another instance of the mismatched built-in signature problem.  With
-Wextra GCC 9 prints:

  warning: mismatch in return type of built-in function ‘sprintf’; expected
‘int’ [-Wbuiltin-declaration-mismatch]
1 | unsigned int sprintf (char *str, const char *fmt, ...);

As we discussed, having the warning for the declaration disable treating the
function as a built-in will avoid these bugs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug c/89990] request warning: Use of out of scope compound literals

2019-04-08 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
I agree that this would be a very useful enhancement.

The value of a pointer becomes indeterminate after the lifetime of the object
to which it points has ended.  Even reading such a pointer is undefined, never
mind dereferencing it.  GCC could use that to issue helpful diagnostics even in
absence of any evidence that the pointer is dereferenced, such as in the
modified example below:

   int foo (mytype *ptr)
   {
 if (!ptr) {
   ptr = &(mytype) { };
 }

 bar (ptr);   // undefined
   }

This applies not just to compound literals but to all other objects, including
auto, allocated, and thread local storage.

[Bug c/89950] attribute aligned ignored with attribute vector_size

2019-04-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89968

--- Comment #2 from Martin Sebor  ---
Yes, unlike in pr89968, in this case the order of the attributes matters.  When
aligned comes after vector_size the former is respected.

[Bug c/89968] attribute packed fails to reduce char vector member alignment

2019-04-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968

--- Comment #4 from Martin Sebor  ---
The alignment is respected for members of other types than char so the order of
the attributes doesn't seem to matter here (it does matter in pr89950):

$ cat pr89968-2.c && gcc -S -O2 -Wall -fdump-tree-optimized=/dev/stdout
pr89968-2.c 
struct S
{
  char c;
  __attribute__ ((aligned (64), packed, vector_size (1024))) int v;   // okay
};

int f (void) { return sizeof (struct S); }// 1088
int g (void) { return __alignof__ (struct S); }   // 64

__attribute__ ((aligned (64), vector_size (1024))) int v1;
int h1 (void) { return __alignof__ (v1); }// 1024

__attribute__ ((vector_size (1024), aligned (64))) int v2;
int h2 (void) { return __alignof__ (v2); }// 64




;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)

f ()
{
   [local count: 1073741824]:
  return 1088;

}



;; Function g (g, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=1)

g ()
{
   [local count: 1073741824]:
  return 64;

}



;; Function h1 (h1, funcdef_no=2, decl_uid=1916, cgraph_uid=3, symbol_order=3)

h1 ()
{
   [local count: 1073741824]:
  return 1024;

}



;; Function h2 (h2, funcdef_no=5, decl_uid=1920, cgraph_uid=4, symbol_order=5)

h2 ()
{
   [local count: 1073741824]:
  return 64;

}

[Bug c++/89980] [9 Regression] pointer initialization with empty string folded to zero

2019-04-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|bootstrap   |c++
 Resolution|--- |FIXED
Summary|[9 Regression] bootstrap|[9 Regression] pointer
   |failed  |initialization with empty
   ||string folded to zero

--- Comment #11 from Martin Sebor  ---
Fixed in r270177.

[Bug bootstrap/89980] [9 Regression] bootstrap failed

2019-04-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Fri Apr  5 19:49:38 2019
New Revision: 270177

URL: https://gcc.gnu.org/viewcvs?rev=270177=gcc=rev
Log:
PR bootstrap/89980 - pointer initialization with empty string folded to zero

gcc/cp/ChangeLog:

PR bootstrap/89980
* decl.c (reshape_init_array_1): Avoid treating empty strings
as zeros in array initializers.
Use trivial_type_p () instead of TYPE_HAS_TRIVIAL_DFLT().

gcc/testsuite/ChangeLog:

PR bootstrap/89980
* g++.dg/init/array52.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/array52.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/89980] [9 Regression] bootstrap failed

2019-04-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00221.html

[Bug bootstrap/89980] [9 Regression] bootstrap failed

2019-04-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980

--- Comment #5 from Martin Sebor  ---
Thanks for the small test case.

The affected x86 targets are presumably limited to i386.  My x86_64 bootstrap
was successful.

[Bug c++/71487] sorry, unimplemented: mangling offset_ref

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71487

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2016-06-26 00:00:00 |2019-4-4
 CC||msebor at gcc dot gnu.org
  Known to fail||8.3.0, 9.0

--- Comment #4 from Martin Sebor  ---
No change in GCC 8 or 9:

pr71487.C: In instantiation of ‘void PropertyMatcher::operator()(U) [with
U = std::__cxx11::basic_string; F = long unsigned int
(std::__cxx11::basic_string::*)() const; T = int]’:
pr71487.C:30:34:   required from here
pr71487.C:15:39: warning: comparison of integer expressions of different
signedness: ‘long unsigned int’ and ‘int’ [-Wsign-compare]
   15 |  std::cout << ((actual.*memfun)() == expected) << std::endl;
  |   ^~~~
pr71487.C: In instantiation of ‘decltype (Property((&
std::__cxx11::basic_string::size), declval())) HasLength(T) [with T =
int]’:
pr71487.C:31:1:   required from here
pr71487.C:25:6: sorry, unimplemented: mangling offset_ref
   25 | auto HasLength(T expected) -> decltype(Property(::string::size,
declval())) {
  |  ^

[Bug c++/89974] ICE on a definition of a non-type specialization on a struct object with pointer to member function

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Fixed via r270155.

[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #4 from Martin Sebor  ---
Fixed in r270155.

[Bug c++/47488] sorry, unimplemented: string literal in function template signature

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0
  Known to fail||4.6.0, 4.8.5, 4.9.4, 5.4.0,
   ||6.4.0, 7.3.0, 8.3.0

--- Comment #16 from Martin Sebor  ---
Fixed in GCC 9.

[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in r270155.

[Bug c++/89974] ICE on a definition of a non-type specialization on a struct object with pointer to member function

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 23:10:23 2019
New Revision: 270155

URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev
Log:
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89878 - same specializations on a zero-initialized struct object as a
non-type parameter treated as distinct
PR c++/89833 - sorry, unimplemented: string literal in function template
signature
PR c++/47488 - sorry, unimplemented: string literal in function template
signature

gcc/cp/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.

gcc/testsuite/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/abi/mangle69.C
trunk/gcc/testsuite/g++.dg/abi/mangle70.C
trunk/gcc/testsuite/g++.dg/abi/mangle71.C
trunk/gcc/testsuite/g++.dg/abi/mangle72.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C
trunk/gcc/testsuite/g++.dg/init/array51.C
trunk/gcc/testsuite/g++.dg/template/nontype29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47488] sorry, unimplemented: string literal in function template signature

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488

--- Comment #15 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 23:10:23 2019
New Revision: 270155

URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev
Log:
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89878 - same specializations on a zero-initialized struct object as a
non-type parameter treated as distinct
PR c++/89833 - sorry, unimplemented: string literal in function template
signature
PR c++/47488 - sorry, unimplemented: string literal in function template
signature

gcc/cp/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.

gcc/testsuite/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/abi/mangle69.C
trunk/gcc/testsuite/g++.dg/abi/mangle70.C
trunk/gcc/testsuite/g++.dg/abi/mangle71.C
trunk/gcc/testsuite/g++.dg/abi/mangle72.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C
trunk/gcc/testsuite/g++.dg/init/array51.C
trunk/gcc/testsuite/g++.dg/template/nontype29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 23:10:23 2019
New Revision: 270155

URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev
Log:
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89878 - same specializations on a zero-initialized struct object as a
non-type parameter treated as distinct
PR c++/89833 - sorry, unimplemented: string literal in function template
signature
PR c++/47488 - sorry, unimplemented: string literal in function template
signature

gcc/cp/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.

gcc/testsuite/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/abi/mangle69.C
trunk/gcc/testsuite/g++.dg/abi/mangle70.C
trunk/gcc/testsuite/g++.dg/abi/mangle71.C
trunk/gcc/testsuite/g++.dg/abi/mangle72.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C
trunk/gcc/testsuite/g++.dg/init/array51.C
trunk/gcc/testsuite/g++.dg/template/nontype29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 23:10:23 2019
New Revision: 270155

URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev
Log:
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89878 - same specializations on a zero-initialized struct object as a
non-type parameter treated as distinct
PR c++/89833 - sorry, unimplemented: string literal in function template
signature
PR c++/47488 - sorry, unimplemented: string literal in function template
signature

gcc/cp/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.

gcc/testsuite/ChangeLog:

PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/abi/mangle69.C
trunk/gcc/testsuite/g++.dg/abi/mangle70.C
trunk/gcc/testsuite/g++.dg/abi/mangle71.C
trunk/gcc/testsuite/g++.dg/abi/mangle72.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C
trunk/gcc/testsuite/g++.dg/init/array51.C
trunk/gcc/testsuite/g++.dg/template/nontype29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89974] ICE on a definition of a non-type specialization on a struct object with pointer to member function

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Martin Sebor  ---
Fixed via r270154.

[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 22:38:10 2019
New Revision: 270154

URL: https://gcc.gnu.org/viewcvs?rev=270154=gcc=rev
Log:
PR middle-end/89957 - ICE calling strnlen with an int128_t bound in a known
range
PR middle-end/89911 - [9 Regression] ICE in get_attr_nonstring_decl

gcc/ChangeLog:

PR middle-end/89957
PR middle-end/89911
* builtins.c (expand_builtin_strnlen): Make sure wi::ltu_p operands
have the same precision since the function crashes otherwise.
* calls.c (maybe_warn_nonstring_arg): Avoid assuming strnlen() call
has non-zero arguments.

gcc/testsuite/ChangeLog:

PR middle-end/89957
PR middle-end/89911
* gcc.dg/Wstringop-overflow-13.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r270154.

[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 22:38:10 2019
New Revision: 270154

URL: https://gcc.gnu.org/viewcvs?rev=270154=gcc=rev
Log:
PR middle-end/89957 - ICE calling strnlen with an int128_t bound in a known
range
PR middle-end/89911 - [9 Regression] ICE in get_attr_nonstring_decl

gcc/ChangeLog:

PR middle-end/89957
PR middle-end/89911
* builtins.c (expand_builtin_strnlen): Make sure wi::ltu_p operands
have the same precision since the function crashes otherwise.
* calls.c (maybe_warn_nonstring_arg): Avoid assuming strnlen() call
has non-zero arguments.

gcc/testsuite/ChangeLog:

PR middle-end/89957
PR middle-end/89911
* gcc.dg/Wstringop-overflow-13.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/89934] [8 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Patch backported to GCC 8 via r270153.

[Bug middle-end/89934] [8 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 22:16:11 2019
New Revision: 270153

URL: https://gcc.gnu.org/viewcvs?rev=270153=gcc=rev
Log:
Backport from 9.0.

PR middle-end/89934 - ICE on a call with fewer arguments to strncpy declared
without prototype

gcc/ChangeLog:

PR middle-end/89934
* gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Bail
out if the number of arguments is less than expected.

gcc/testsuite/ChangeLog:

PR middle-end/89934
* gcc.dg/Wrestrict-19.c: New test.
* gcc.dg/Wrestrict-5.c: Add comment.  Remove unused code.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/Wrestrict-19.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-warn-restrict.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/Wrestrict-5.c

[Bug middle-end/89934] [8 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

Summary|[9 Regression] ICE on a |[8 Regression] ICE on a
   |call with fewer arguments   |call with fewer arguments
   |to strncpy declared without |to strncpy declared without
   |prototype   |prototype
  Known to fail||8.3.0

--- Comment #7 from Martin Sebor  ---
Fixed in GCC 9 in r270152.

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Thu Apr  4 21:59:49 2019
New Revision: 270152

URL: https://gcc.gnu.org/viewcvs?rev=270152=gcc=rev
Log:
PR middle-end/89934 - ICE on a call with fewer arguments to strncpy declared
without prototype

gcc/ChangeLog:

PR middle-end/89934
* gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Bail
out if the number of arguments is less than expected.

gcc/testsuite/ChangeLog:

PR middle-end/89934
* gcc.dg/Wrestrict-19.c: New test.
* gcc.dg/Wrestrict-5.c: Add comment.  Remove unused code.


Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-19.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wrestrict-5.c

[Bug middle-end/89977] New: missing -Wstringop-overflow with an out-of-bounds int128_t range

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977

Bug ID: 89977
   Summary: missing -Wstringop-overflow with an out-of-bounds
int128_t range
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Additional testing of the patch for pr89957 exposed the following:

GCC diagnoses the buffer overflow in f() below but fails to diagnose the same
buffer overflow in g().  The get_range_info() function returns VR_VARYING for
the int128_t variable in g().

$ cat z.c && gcc -S -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
char a[3];

__attribute__ ((noipa))
void f (int n)
{
  if (n < 7)
n = 7;
  __builtin_memset (a, 0, n);
}

__attribute__ ((noipa))
void g (__int128_t n)
{
  if (n < 7)
n = 7;
  __builtin_memset (a, 0, n);
}
z.c: In function ‘f’:
z.c:8:3: warning: ‘__builtin_memset’ forming offset [4, 7] is out of the bounds
[0, 3] of object ‘a’ with type ‘char[3]’ [-Warray-bounds]
8 |   __builtin_memset (a, 0, n);
  |   ^~
z.c:1:6: note: ‘a’ declared here
1 | char a[3];
  |  ^

;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=1)

__attribute__((noipa, noinline, noclone, no_icf))
f (int n)
{
  long unsigned int _1;

   [local count: 1073741824]:
  n_3 = MAX_EXPR ;
  _1 = (long unsigned int) n_3;
  __builtin_memset (, 0, _1); [tail call]
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=2)

__attribute__((noipa, noinline, noclone, no_icf))
g (__int128 n)
{
  long unsigned int _1;

   [local count: 1073741824]:
  n_3 = MAX_EXPR ;
  _1 = (long unsigned int) n_3;
  __builtin_memset (, 0, _1); [tail call]
  return;

}

[Bug c++/89974] New: ICE on a definition of a non-type specialization on a struct object with pointer to member function

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974

Bug ID: 89974
   Summary: ICE on a definition of a non-type specialization on a
struct object with pointer to member function
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following C++ 2a program causes an ICE.  An equivalent program using a
pointer to member data compiles successfully.  I came across this while testing
my patch for pr47488, pr89833, and pr89876.

$ cat z.C && gcc -c -O2 -Wall -Wextra -std=c++2a z.C
struct A { void (A::*p)(); };
template  struct X { };
X x;

z.C:3:9: internal compiler error: canonical types differ for identical types
‘void (A::*)()’ and ‘void (A::*)()’
3 | X x;
  | ^
0xb7ba72 comptypes(tree_node*, tree_node*, int)
/src/gcc/git-svn/gcc/cp/typeck.c:1479
0x9b0829 find_substitution
/src/gcc/git-svn/gcc/cp/mangle.c:692
0x9b8840 write_type
/src/gcc/git-svn/gcc/cp/mangle.c:2054
0x9c10a7 write_template_arg_literal
/src/gcc/git-svn/gcc/cp/mangle.c:3357
0x9bd561 write_expression
/src/gcc/git-svn/gcc/cp/mangle.c:2890
0x9bfdcd write_expression
/src/gcc/git-svn/gcc/cp/mangle.c:3150
0x9bfdcd write_expression
/src/gcc/git-svn/gcc/cp/mangle.c:3150
0x9c572f mangle_template_parm_object(tree_node*)
/src/gcc/git-svn/gcc/cp/mangle.c:4267
0xa8c265 get_template_parm_object
/src/gcc/git-svn/gcc/cp/pt.c:6702
0xa8e048 convert_nontype_argument
/src/gcc/git-svn/gcc/cp/pt.c:7160
0xa91795 convert_template_argument
/src/gcc/git-svn/gcc/cp/pt.c:8070
0xa93370 coerce_template_parms
/src/gcc/git-svn/gcc/cp/pt.c:8547
0xa93a65 coerce_innermost_template_parms
/src/gcc/git-svn/gcc/cp/pt.c:8666
0xa96177 lookup_template_class_1
/src/gcc/git-svn/gcc/cp/pt.c:9357
0xa9885d lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/src/gcc/git-svn/gcc/cp/pt.c:9716
0xb240c0 finish_template_type(tree_node*, tree_node*, int)
/src/gcc/git-svn/gcc/cp/semantics.c:3312
0xa223e1 cp_parser_template_id
/src/gcc/git-svn/gcc/cp/parser.c:16479
0xa2f9be cp_parser_class_name
/src/gcc/git-svn/gcc/cp/parser.c:23274
0xa0d6d7 cp_parser_qualifying_entity
/src/gcc/git-svn/gcc/cp/parser.c:6693
0xa0c6cd cp_parser_nested_name_specifier_opt
/src/gcc/git-svn/gcc/cp/parser.c:6379
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c/89968] attribute packed fails to reduce char vector member alignment

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ABI, diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=59220

--- Comment #1 from Martin Sebor  ---
See also pr59220 for a related bug.

[Bug c/89968] New: attribute packed fails to reduce char vector member alignment

2019-04-04 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968

Bug ID: 89968
   Summary: attribute packed fails to reduce char vector member
alignment
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

>From the following discussion: https://gcc.gnu.org/ml/gcc/2019-04/msg00030.html

The following test case shows that GCC fails to reduce the alignment of a char
vector member.  Clang and ICC succeed and return the expected values from the
two functions (1088 and 64, respectively).

$ cat z.c && gcc -c -O2 -Wall -fdump-tree-optimized=/dev/stdout z.c
struct S
{
  char c;
  __attribute__ ((aligned (64), packed, vector_size (1024))) char v;
};

int f (void) { return sizeof (struct S); }
int g (void) { return __alignof__ (struct S); }

z.c:4:3: warning: ‘packed’ attribute ignored for field of type ‘char’
[-Wattributes]
4 |   __attribute__ ((aligned (64), packed, vector_size (1024))) char v;
  |   ^

;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)

f ()
{
   [local count: 1073741824]:
  return 2048;   ;; Expected 1088

}



;; Function g (g, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=1)

g ()
{
   [local count: 1073741824]:
  return 1024;   ;; Expected 64

}

[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Martin Sebor  changed:

   What|Removed |Added

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

[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89911

--- Comment #1 from Martin Sebor  ---
The crashing code (the wi::ltu_p call):

  if (!TREE_NO_WARNING (exp)
  && wi::ltu_p (wi::to_wide (maxobjsize), min)
  && warning_at (loc, OPT_Wstringop_overflow_,
 "%K%qD specified bound [%wu, %wu] "
 "exceeds maximum object size %E",
 exp, func, min.to_uhwi (), max.to_uhwi (), maxobjsize))
TREE_NO_WARNING (exp) = true;

The test case was reduced from pr89911.

[Bug middle-end/89957] New: ICE calling strnlen with an int128_t bound in a known range

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Bug ID: 89957
   Summary: ICE calling strnlen with an int128_t bound in a known
range
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

$ cat z.c && gcc -c -O2 -Wall z.c
typedef __SIZE_TYPE__ size_t;

extern size_t strnlen ();

size_t foo (__int128_t n)
{
  if (n < 0)
n = 0;
  return strnlen ("", n);
}
z.c: In function ‘foo’:
z.c:9:23: warning: ‘strnlen’ argument 2 type is ‘__int128’ where ‘long unsigned
int’ is expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
9 |   return strnlen ("", n);
  |   ^
z.c:3:15: note: built-in ‘strnlen’ declared here
3 | extern size_t strnlen ();
  |   ^~~
during RTL pass: expand
z.c:9:10: internal compiler error: in decompose, at wide-int.h:963
9 |   return strnlen ("", n);
  |  ^~~
0x877bc0 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
/src/gcc/svn/gcc/wide-int.h:963
0x95f62a wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
/src/gcc/svn/gcc/wide-int.h:1013
0x95f5f6 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
/src/gcc/svn/gcc/wide-int.h:788
0x9e15df bool wi::ltu_p >,
generic_wide_int
>(generic_wide_int > const&,
generic_wide_int const&)
/src/gcc/svn/gcc/wide-int.h:1913
0x9c2fea expand_builtin_strnlen
/src/gcc/svn/gcc/builtins.c:3154
0x9d22c9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/src/gcc/svn/gcc/builtins.c:7533
0xbfc03c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/svn/gcc/expr.c:11029
0xbee2c3 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/svn/gcc/expr.c:8274
0xbe310a store_expr(tree_node*, rtx_def*, int, bool, bool)
/src/gcc/svn/gcc/expr.c:5673
0xbe143a expand_assignment(tree_node*, tree_node*, bool)
/src/gcc/svn/gcc/expr.c:5436
0xa1ece5 expand_call_stmt
/src/gcc/svn/gcc/cfgexpand.c:2722
0xa226b3 expand_gimple_stmt_1
/src/gcc/svn/gcc/cfgexpand.c:3691
0xa22d6e expand_gimple_stmt
/src/gcc/svn/gcc/cfgexpand.c:3850
0xa22e86 expand_gimple_tailcall
/src/gcc/svn/gcc/cfgexpand.c:3897
0xa2b406 expand_gimple_basic_block
/src/gcc/svn/gcc/cfgexpand.c:5863
0xa2d224 execute
/src/gcc/svn/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c/89946] [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-03
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE first appeared in r250521 when the attribute was added. 
The handler for the attributes does no validation:

  static tree
  handle_patchable_function_entry_attribute (tree *, tree, tree, int, bool *)
  {
/* Nothing to be done here.  */
return NULL_TREE;
  }

With struct attribute_spec extended to describe basic properties of attribute
arguments besides just their number, basic attribute argument validation could
be done in decl_attributes, similarly to how mutually exclusive attributes are
handled.

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00149.html

[Bug c/89950] New: attribute aligned ignored with attribute vector_size

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950

Bug ID: 89950
   Summary: attribute aligned ignored with attribute vector_size
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When attribute aligned appears in conjunction with attribute vector_size on the
same declaration and when the former specifies a different alignment than the
latter attribute implies, the alignment specified by the former attribute is
ignored.

However, when attribute aligned is specified on a vector (re)declaration
without attribute vector_size, the alignment is honored.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (void)
{
  typedef __attribute__ ((vector_size (1024))) int Vec_1k;
  typedef __attribute__ ((aligned (256)))  Vec_1k V;
  _Static_assert (__alignof__ (V) == 256);   // passes
  _Static_assert (__builtin_has_attribute (V, aligned (256)));   // passes

  V v;
  _Static_assert (__alignof__ (v) == 256);   // passes
  _Static_assert (__builtin_has_attribute (v, aligned (256)));   // passes
}

void g (void)
{
  typedef __attribute__ ((aligned (256), vector_size (1024))) int V;

  _Static_assert (__alignof__ (V) == 256);   // fails
  _Static_assert (__builtin_has_attribute (V, aligned (256)));   // fails

  V v;
  _Static_assert (__alignof__ (v) == 256);   // fails
  _Static_assert (__builtin_has_attribute (v, aligned (256)));   // fails
}
z.c: In function ‘g’:
z.c:17:3: error: static assertion failed
   17 |   _Static_assert (__alignof__ (V) == 256);   //
fails
  |   ^~
z.c:18:3: error: static assertion failed
   18 |   _Static_assert (__builtin_has_attribute (V, aligned (256)));   //
fails
  |   ^~
z.c:21:3: error: static assertion failed
   21 |   _Static_assert (__alignof__ (v) == 256);   //
fails
  |   ^~
z.c:22:3: error: static assertion failed
   22 |   _Static_assert (__builtin_has_attribute (v, aligned (256)));   //
fails
  |   ^~

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83655,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83603

--- Comment #3 from Martin Sebor  ---
See also pr83603 and pr83655 for similar errors.

Now that GCC diagnoses calls with incompatible/incorrect arguments to built-ins
declared without a prototype the solution suggested in the review of the fix
for the latter:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00244.html
i.e., using gimple_call_builtin_p(), might be worth revisiting for GCC 10
(though it might be obviated by rejecting the incompatible calls or by
replacing them with traps).

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[9 Regression] ICE in   |[9 Regression] ICE on a
   |tree_fits_uhwi_p, at|call with fewer arguments
   |tree.c:7237 |to strncpy declared without
   ||prototype

--- Comment #2 from Martin Sebor  ---
Declaring a built-in function with an incompatible signature is unsafe but GCC
only diagnoses it with -Wextra (starting with GCC 9).  Calling a library
function with fewer arguments than it expects is undefined.   Calling a
built-in function with fewer arguments is invalid and diagnosed (also starting
in GCC 9) but not rejected.

The call should either be rejected with an error (like Clang does) or replaced
with a trap to avoid the undefined behavior at runtime, but it's too late to
make that change for GCC 9.  Hopefully in GCC 10.

In the meantime, let me remove the assumption that the call is valid from the
-Wrestrict pass.

[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-03
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89833
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html

[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html

[Bug c++/47488] sorry, unimplemented: string literal in function template signature

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 CC||msebor at gcc dot gnu.org

--- Comment #14 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00108.html

[Bug c/89798] excessive vector_size silently accepted and truncated

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00108.html

[Bug c/89798] excessive vector_size silently accepted and truncated

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

--- Comment #3 from Martin Sebor  ---
One of the reasons why big vectors don't work seems to be the assumption in
TYPE_VECTOR_SUBPARTS() that they can't be bigger than 2^31.  But fixing this
function alone doesn't seem to be sufficient.

inline poly_uint64
TYPE_VECTOR_SUBPARTS (const_tree node)
{
  STATIC_ASSERT (NUM_POLY_INT_COEFFS <= 2);
  unsigned int precision = VECTOR_TYPE_CHECK (node)->type_common.precision;
  if (NUM_POLY_INT_COEFFS == 2)
{
  poly_uint64 res = 0;
  res.coeffs[0] = 1 << (precision & 0xff);
  if (precision & 0x100)
res.coeffs[1] = 1 << (precision & 0xff);
  return res;
}
  else
return 1 << precision;
}

[Bug target/89932] ICE in must_pass_in_stack_var_size_or_pad, at calls.c:5824

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Not a recent regression.

[Bug c/89933] [7/8/9 Regression] ICE in merge_decls, at c/c-decl.c:2517

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The ICE was introduced in r237137:

r237137 | mpolacek | 2016-06-06 11:50:23 -0400 (Mon, 06 Jun 2016) | 8 lines

* c-typeck.c (comptypes_internal): Handle comparisons of
INTEGER_TYPE, FIXED_POINT_TYPE, and REAL_TYPE nodes.  Don't check
TYPE_REF_CAN_ALIAS_ALL.

Before then GCC failed to accept the code:

t.c:2:22: error: conflicting types for ‘a’
 typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));
  ^
t.c:1:22: note: previous declaration of ‘a’ was here
 typedef unsigned int a __attribute__ ((__aligned__(8), __may_alias__));
  ^

[Bug middle-end/89934] [9 Regression] ICE in tree_fits_uhwi_p, at tree.c:7237

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Introduced in r255031:

r255031 | msebor | 2017-11-21 15:01:58 -0500 (Tue, 21 Nov 2017) | 29 lines

PR tree-optimization/82945 - add warning for passing non-strings to functions
that expect string arguments

gcc/ChangeLog:

PR tree-optimization/82945
* builtins.c (expand_builtin_strlen): Call maybe_warn_nonstring_arg.
* calls.h (maybe_warn_nonstring_arg): Declare new function.
* calls.c (get_attr_nonstring_decl, maybe_warn_nonstring_arg): New
functions.
(initialize_argument_information): Call maybe_warn_nonstring_arg.
* calls.h (get_attr_nonstring_decl): Declare new function.
* doc/extend.texi (attribute nonstring): Update.
* gimple-fold.c (gimple_fold_builtin_strncpy): Call
get_attr_nonstring_decl and handle it.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Same.  Improve
detection of nul-termination.
(strlen_to_stridx): Change to a pointer.
(handle_builtin_strlen, handle_builtin_stxncpy): Adjust.
(pass_strlen::execute): Same.

[Bug c/89685] [9 Regression] ICE on attribute copy with a compound expression

2019-04-01 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89685

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Mon Apr  1 17:04:10 2019
New Revision: 270062

URL: https://gcc.gnu.org/viewcvs?rev=270062=gcc=rev
Log:
PR c/89685 - ICE on attribute copy with a compound expression

gcc/c-family/ChangeLog:

PR c/89685
* c-attribs.c (handle_copy_attribute): Handle references and
non-constant expressions.

gcc/testsuite/ChangeLog:

PR c/89685
* gcc.dg/attr-copy-8.c: New test.
* g++.dg/ext/attr-copy-2.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ext/attr-copy-2.C
trunk/gcc/testsuite/gcc.dg/attr-copy-8.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/testsuite/ChangeLog

[Bug c/89685] [9 Regression] ICE on attribute copy with a compound expression

2019-04-01 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89685

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in 270062.

[Bug c++/89901] carat of error not on the return type

2019-04-01 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89901

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
The message could be improved by adding a note similar to the one GCC prints
for the same incompatibility in function argument initialization.  In the test
case below, the note in the second error makes it clear exactly where the
incompatibility is but it hard not to misread the first error as suggesting the
problem is also in the argument initialization.  In both cases, the placement
of the caret on the opening parenthesis (rather than on the first letter of the
function name) doesn't seem like the most fortunate choice, especially with the
char** being right under it.

$ gcc -S -Wall z.C
char **f (const char**);

void g (const char **s)
{
  const char **a = f (s);
  g (f (s));
  (void)
}
z.C: In function ‘void g(const char**)’:
z.C:5:22: error: invalid conversion from ‘char**’ to ‘const char**’
[-fpermissive]
5 |   const char **a = f (s);
  |~~^~~
  |  |
  |  char**
z.C:6:8: error: invalid conversion from ‘char**’ to ‘const char**’
[-fpermissive]
6 |   g (f (s));
  |  ~~^~~
  ||
  |char**
z.C:3:22: note:   initializing argument 1 of ‘void g(const char**)’
3 | void g (const char **s)
  | ~^

[Bug c++/89898] New: invalid function template definition with non-type class argument accepted

2019-03-31 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898

Bug ID: 89898
   Summary: invalid function template definition with non-type
class argument accepted
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the following, the invalid function template definition is accepted in c++2a
mode:

$ cat z.C && gcc -c -Wall -std=c++2a z.C
struct A { };
template  struct X { };
template > void f () { }   // invalid

[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

2019-03-31 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Martin Sebor  ---
The converse of accepting multiple definitions of the same symbol is that valid
redeclarations of the same symbol are rejected as shown in the test case below:

$ cat z.C && gcc -c -Wall -std=c++2a z.C
struct A1 { char c[5]; };

template  struct B { };

typedef B  A_A;
typedef B   A_AZ___;
typedef BA_AZZ__;
typedef B A_AZZZ_;
typedef B  A_A;

extern A_A same_type_B_A1_A;
extern A_AZ___ same_type_B_A1_A;
extern A_AZZ__ same_type_B_A1_A;
extern A_AZZZ_ same_type_B_A1_A;
extern A_A same_type_B_A1_A;
z.C:12:16: error: conflicting declaration ‘A_AZ___ same_type_B_A1_A’
   12 | extern A_AZ___ same_type_B_A1_A;
  |^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
   11 | extern A_A same_type_B_A1_A;
  |^~~~
z.C:13:16: error: conflicting declaration ‘A_AZZ__ same_type_B_A1_A’
   13 | extern A_AZZ__ same_type_B_A1_A;
  |^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
   11 | extern A_A same_type_B_A1_A;
  |^~~~
z.C:14:16: error: conflicting declaration ‘A_AZZZ_ same_type_B_A1_A’
   14 | extern A_AZZZ_ same_type_B_A1_A;
  |^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
   11 | extern A_A same_type_B_A1_A;
  |^~~~
z.C:15:16: error: conflicting declaration ‘A_A same_type_B_A1_A’
   15 | extern A_A same_type_B_A1_A;
  |^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
   11 | extern A_A same_type_B_A1_A;
  |^~~~

[Bug c++/89894] poor error message when redefining a function overloaded on a non-type specialization

2019-03-30 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89894

--- Comment #2 from Martin Sebor  ---
Actually, it's not specific to non-type specializations or even templates.  The
same problem happens with ordinary types.  Non-type template specializations
just exacerbate it.

$ cat z.C && gcc -c -Wall z.C
struct A { };
typedef A B;

typedef A T;
typedef B U;

void h (T) { }
void h (U) { }

z.C:8:6: error: redefinition of ‘void h(U)’
8 | void h (U) { }
  |  ^
z.C:7:6: note: ‘void h(T)’ previously defined here
7 | void h (T) { }
  |  ^

[Bug c++/89894] poor error message when redefining a function overloaded on a non-type specialization

2019-03-30 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89894

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
David, you might be interested in this.

[Bug c++/89894] New: poor error message when redefining a function overloaded on a non-type specialization

2019-03-30 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89894

Bug ID: 89894
   Summary: poor error message when redefining a function
overloaded on a non-type specialization
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The error message below make it difficult to understand what exactly the root
cause problem is: the names of the types of the arguments are different and no
other detail is provided.  If the definitions of T and U and far apart (e.g.,
in different headers perhaps even supplied by different libraries) and
complicated (e.g., the result of some non-trivial algorithm) determining what
makes the types the same could be a non-trivial exercise.

Including a note in the error message pointing to the types underlying the
aliases would help.

Providing more detail about the underlying types, such as the values of the
constants the underlying templates are instantiated on analogously to what's
done for ordinary templates, would help even more.

$ cat z.C && gcc -c -Wall -std=c++2a z.C
struct A { int i; };
template  struct B { };

constexpr A f () { return A{1<<27}; }
constexpr A g () { return A{134217728}; }
typedef B T;
typedef B U;

void h (T) { }
void h (U) { }

z.C:10:6: error: redefinition of ‘void h(U)’
   10 | void h (U) { }
  |  ^
z.C:9:6: note: ‘void h(T)’ previously defined here
9 | void h (T) { }
  |  ^

[Bug c++/89878] New: same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

2019-03-28 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878

Bug ID: 89878
   Summary: same specializations on a zero-initialized struct
object as a non-type parameter treated as distinct
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a patch for bug 89833 I noticed that the C++ 2a test case below
is accepted even though it redefines the same function f() three times, each
time taking an argument of the same type: B, with the only difference
between them being the form of initialization of the non-type parameter.  The
mangling of each of the functions is also distinct when it should be the same.

$ cat u.C && gcc -c -Wall -Wextra -std=c++2a u.C && nm u.o
struct A { int a[3]; };

template  struct B { };

void f (B) { }
void f (B) { }
void f (B) { }
void f (B) { }
 T _Z1f1BIXtl1AEEE
0010 T _Z1f1BIXtl1AtlA3_iLi0E
0020 T _Z1f1BIXtl1AtlA3_iLi0ELi0E
0030 T _Z1f1BIXtl1AtlA3_iLi0ELi0ELi0E

[Bug c++/58031] invalid class template partial specialization accepted where argument list identical to primary template

2019-03-28 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58031

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.3.0, 7.3.0,
   ||8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug c++/89874] invalid conversion accepted in decltype in a template

2019-03-28 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89874

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=47488

--- Comment #2 from Martin Sebor  ---
See pr47488 for the origin of the test case.

[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

2019-03-28 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89876

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=47488,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89833

--- Comment #2 from Martin Sebor  ---
I stumbled into it while working on a fix for bug 47488 for GCC 9, which in
turn was precipitated by bug 89833.

[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

2019-03-28 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89876

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
Summary|ICE in convert_like_real on |[8/9 Regression] ICE in
   |decltype expression |convert_like_real on
   |involving string conversion |decltype expression
   |to char*|involving string conversion
   ||to char*
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r254437:

r254437 | marxin | 2017-11-06 04:02:15 -0500 (Mon, 06 Nov 2017) | 25 lines

Instrument function exit with __builtin_unreachable in C++


Prior to that change GCC would reject the test case with a slightly better for
of an ICE:

t.C: In substitution of ‘template decltype (f(T(), "")) g(T) [with T =
int]’:
t.C:7:17:   required from here
t.C:5:13: warning: ISO C++ forbids converting a string constant to ‘char*’
[-Wwrite-strings]
 decltype (f (T (), "")) g (T) { }
   ~~^~
t.C: In instantiation of ‘decltype (f(T(), "")) g(T) [with T = int]’:
t.C:5:25: sorry, unimplemented: string literal in function template signature
 decltype (f (T (), "")) g (T) { }
 ^

  1   2   3   4   5   6   7   8   9   10   >