date:20180406

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
Thanks for the reduced testcase.

[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Apr  6 22:33:55 2018
New Revision: 259196

URL: https://gcc.gnu.org/viewcvs?rev=259196=gcc=rev
Log:
PR target/85196
* config/sparc/sparc.c (sparc_expand_move): Deal with symbolic operands
based on LABEL_REF.  Remove useless assertion.
(pic_address_needs_scratch): Fix formatting.
(sparc_legitimize_pic_address): Minor tweaks.
(sparc_delegitimize_address): Adjust assertion accordingly.
* config/sparc/sparc.md (movsi_pic_label_ref): Change label_ref_operand
into symbolic_operand.
(movsi_high_pic_label_ref): Likewise.
(movsi_lo_sum_pic_label_ref): Likewise.
(movdi_pic_label_ref): Likewise.
(movdi_high_pic_label_ref): Likewise.
(movdi_lo_sum_pic_label_ref): Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/opt/pr85196.C
  - copied unchanged from r259194, trunk/gcc/testsuite/g++.dg/opt/pr85196.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/sparc/sparc.c
branches/gcc-6-branch/gcc/config/sparc/sparc.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Apr  6 22:32:39 2018
New Revision: 259195

URL: https://gcc.gnu.org/viewcvs?rev=259195=gcc=rev
Log:
PR target/85196
* config/sparc/sparc.c (sparc_expand_move): Deal with symbolic operands
based on LABEL_REF.  Remove useless assertion.
(pic_address_needs_scratch): Fix formatting.
(sparc_legitimize_pic_address): Minor tweaks.
(sparc_delegitimize_address): Adjust assertion accordingly.
* config/sparc/sparc.md (movsi_pic_label_ref): Change label_ref_operand
into symbolic_operand.
(movsi_high_pic_label_ref): Likewise.
(movsi_lo_sum_pic_label_ref): Likewise.
(movdi_pic_label_ref): Likewise.
(movdi_high_pic_label_ref): Likewise.
(movdi_lo_sum_pic_label_ref): Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/opt/pr85196.C
  - copied unchanged from r259194, trunk/gcc/testsuite/g++.dg/opt/pr85196.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sparc/sparc.c
branches/gcc-7-branch/gcc/config/sparc/sparc.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/85271] New: Trivial copy assignment operator overwrites members not being copied

2018-04-06 Thread hstong at ca dot ibm.com

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

Bug ID: 85271
   Summary: Trivial copy assignment operator overwrites members
not being copied
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

In the following, the operator= used by Q's defaulted copy assignment operator
for the "d" subobject is a copy assignment operator of B: that is, it does not
copy the "b0" member of "d".
The expected behaviour is observed when Q's copy assignment operator is
explicitly defaulted after its first declaration, but not if it is explicitly
defaulted on its first declaration.

### SOURCE ():
extern "C" void abort(void);
struct B0 { int b0; };

struct B {
  B =(const B &) = default;
  int x;
};

struct D : B0, B {
  using B::operator=;
private:
  D =(const D &) && = default;
};

struct Q {
  Q =(const Q &) = default;
  D d;
};
//Q ::operator=(const Q &) = default;

Q qa, qb;
int main(void) {
  qb.d.b0 = 42;
  qb = qa;
  if (qb.d.b0 != 42) abort();
}


### COMPILER INVOCATION:
g++ -xc++ -std=c++2a -o inhtrivcpyassn -


### INVOCATION AND OUTPUT OF RESULTING EXECUTABLE:
> ./inhtrivcpyassn; printf '(rc=%d)\n' "$?"
Aborted ./inhtrivcpyassn
(rc=134)


### EXPECTED RUN OUTPUT:
(rc=0)


### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.1 20180405 (experimental) (GCC)

[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Apr  6 22:30:05 2018
New Revision: 259194

URL: https://gcc.gnu.org/viewcvs?rev=259194=gcc=rev
Log:
PR target/85196
* config/sparc/sparc.c (sparc_expand_move): Deal with symbolic operands
based on LABEL_REF.  Remove useless assertion.
(pic_address_needs_scratch): Fix formatting.
(sparc_legitimize_pic_address): Minor tweaks.
(sparc_delegitimize_address): Adjust assertion accordingly.
* config/sparc/sparc.md (movsi_pic_label_ref): Change label_ref_operand
into symbolic_operand.
(movsi_high_pic_label_ref): Likewise.
(movsi_lo_sum_pic_label_ref): Likewise.
(movdi_pic_label_ref): Likewise.
(movdi_high_pic_label_ref): Likewise.
(movdi_lo_sum_pic_label_ref): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr85196.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/sparc/sparc.md
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

2018-04-06 Thread zeccav at gmail dot com

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

--- Comment #7 from Vittorio Zecca  ---
You are welcome, very fast fix, keep up the good work!

[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header

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

--- Comment #1 from Martin Sebor  ---
LWG issues 343 has some bakckground into this problem:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#343

It was resolved via LWG #1178 without solving the portability problem:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178

[Bug c++/85270] New: Trivial assignment operator not considered such

2018-04-06 Thread hstong at ca dot ibm.com

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

Bug ID: 85270
   Summary: Trivial assignment operator not considered such
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Trivial copy assignment operator not considered such

GCC stops considering a trivial copy assignment operator to be trivial when a
non-trivial copy assignment operator is added to the class. Works with Clang;
fails with GCC.

### SOURCE ():
struct Q {
  Q =(const Q &) = default;
  // defaulted on first declaration, not user-provided; trivial

  Q =(Q &); // not a viable candidate at P1
};

static_assert(__is_trivially_assignable(Q &, const Q &), ""); // (P1)
// Assertion succeeds with Clang and ICC, but fails with GCC.


### COMPILER INVOCATION:
g++ -xc++ -std=c++2a -fsyntax-only -


### ACTUAL OUTPUT:
:8:15: error: static assertion failed


### EXPECTED OUTPUT:
(Clean compile)


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.1 20180405 (experimental) (GCC)

[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

2018-04-06 Thread vmakarov at gcc dot gnu.org

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

--- Comment #13 from Vladimir Makarov  ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #5)
> > I guess it depends on what exactly a normal subreg on lhs means.
> > The documentation says:
> >   When used as an lvalue, 'subreg' is a word-based accessor.
> >   Storing to a 'subreg' modifies all the words of REG that
> >   overlap the 'subreg', but it leaves the other words of REG
> >   alone.
> 
> 
> But this wording applies only to multi-word registers. We can't use the
> above wording for 512bit single-word register, since we don't know how the
> move will affect the bits outside the subreg. We can say that the move
> "modifies all the words of REG that overlap the 'subreg', since we have only
> one 512-bit word of a 512-bit register.
> 

OK.

> So, I think that the transformation in the Comment 10 is invalid for
> registers that can't be decomposed to independent word-sized registers (to
> use "word-based accessor"), e.g. V32HImode xmm20. Perhaps the mentioned
> alter_subreg should choose correct approach based on TARGET_HARD_REGNO_NREGS?

Actually I do the same things as the old reload does.  It has practically the
same alter_subreg code.  May be the reload and LRA code is not up to date to
treat correctly this situation. I don't know.

  What I can do is to generate (strict_low_part (subreg:DI (reg:V32HI ))) to reflect the new semantics.  Something like

Index: lra.c
===
--- lra.c   (revision 258691)
+++ lra.c   (working copy)
@@ -487,14 +487,26 @@ int lra_curr_reload_num;
 void
 lra_emit_move (rtx x, rtx y)
 {
-  int old;
-
+  int old, regno;
+  machine_mode mode;
+  rtx reg;
+
   if (GET_CODE (y) != PLUS)
 {
   if (rtx_equal_p (x, y))
return;
   old = max_reg_num ();
-  emit_move_insn (x, y);
+  if (GET_CODE (x) == SUBREG
+ && REG_P (reg = SUBREG_REG (x))
+ && GET_MODE_SIZE (mode = GET_MODE (reg)).to_constant () >
UNITS_PER_WORD
+ && (regno = REGNO (reg)) >= FIRST_PSEUDO_REGISTER
+ && ira_reg_class_max_nregs[lra_get_allocno_class (regno)][mode] == 1)
+   {
+ x = gen_rtx_STRICT_LOW_PART (VOIDmode, x);
+ emit_insn (gen_rtx_SET (x, y));
+   }
+  else
+   emit_move_insn (x, y);
   if (REG_P (x))
lra_reg_info[ORIGINAL_REGNO (x)].last_reload = ++lra_curr_reload_num;
   /* Function emit_move can create pseudos -- so expand the pseudo


  But we need insn patterns for such cases which are absent in i386 md files. 
Without adding them, compiler will crash in LRA.

[Bug middle-end/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|fortran |middle-end

--- Comment #12 from Andrew Pinski  ---
match.pd looks like it has a type bug:
/* Simplify pointer equality compares using PTA.  */
(for neeq (ne eq)
 (simplify
  (neeq @0 @1)
  (if (POINTER_TYPE_P (TREE_TYPE (@0))
   && ptrs_compare_unequal (@0, @1))
   { neeq == EQ_EXPR ? boolean_false_node : boolean_true_node; })))


It assumes all types of EQ_EXPR/NE_EXPR will be boolean_type_node which is not
true.
It should be using constant_boolean_node (neeq != EQ_EXPR, type); .

[Bug c++/85269] New: warn for referenced standard symbols that aren't guaranteed to be declared in a header

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

Bug ID: 85269
   Summary: warn for referenced standard symbols that aren't
guaranteed to be declared in a header
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Unlike C, the C++ standard lets standard library implementations structure
headers in whatever way is convenient for them, which extends to having any
header include any other.  As a result, writing non-trivial (and sometimes even
trivial) C++ programs that are guaranteed to compile with any conforming C++
compiler can be tricky.

For example, the following compiles successfully with libstdc++ even though it
isn't guaranteed to compile:

  #include 

  void f (std::locale);

The following

  std::locale global;

on the other hand doesn't compile with libstdc++ because std::locale is only
declared in  and not defined.  It does, however, compile with Visual
C++ which must be more "promiscuous" than libstdc++ in its header dependencies.
 There probably are examples that go the other way around.

It occurs to me that the suggestions G++ issues in response to a program using
a standard symbol without #including the appropriate header could also be used
to provide a warning to help users find the most appropriate header to include
to get each symbol declared.  That way, the snippet above would trigger a
warning pointing out that to use std::locale one should #include  first
even if the symbol happens to be declared in the header.

[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683

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

--- Comment #3 from Martin Sebor  ---
There are actually yet another couple of bugs at play here.  In the test case
compiled without -D_FORTIFY_SOURCE, strcpy(buf, "hello ") is folded into a
MEM_REF by gimple_fold_builtin_strcpy() without checking to see if there's room
in the destination, so that's not diagnosed.

If the subsequent strcat() doesn't append more characters than would fit in the
destination if it were empty the strcat() also isn't diagnosed because it too
is folded, this time by gimple_fold_builtin_strcat() and into __builtin_memcpy.
 At the time it's folded the length of the string to which it's being appended
is not available.

When __builtin_memcpy() is handled in tree-ssa-strlen it should be able to warn
on the overflow because it should have access to the length of the destination
string and it knows the length of the source.  But strlen doesn't know how to
deal with MEM_REF (either due to bug 77357 or one of the other strlen missing
optimizations tracked under the meta bug 83819), and even if it did, 
handle_builtin_memcpy() in strlen doesn't do any overflow checking.

Finally, at the time the overflow checking is done during expansion in
builtins.c, although the length of the destination string that __builtin_memcpy
is being called to append to isn't accessible anymore, the memcpy destination
is  + 4 which is too simple for compute_builtin_object_size() to handle (it
handles non-constant offsets but not the trivial constant case).  This works in
GCC 7 where the destination is [(void *) + 4B] that
compute_builtin_object_size() does know how to deal with.  Phew!

So with all these gaps the following isn't diagnosed in GCC 8 while it is
caught in GCC 7.

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

void f (void)
{
  __builtin_strcpy (a, "1234");
  __builtin_strcat (a, "567");
}


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

f ()
{
  char[4] * _4;

   [local count: 1073741825]:
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})"1234"];
  _4 =  + 4;
  __builtin_memcpy (_4, "567", 4); [tail call]
  return;

}

[Bug target/80022] arc: diagnostic ending in two periods

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

--- Comment #1 from Andrew Pinski  ---
*** Bug 85268 has been marked as a duplicate of this bug. ***

[Bug target/85268] Typo in "PIC is not supported"

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Already filed by you as bug 80022.

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

[Bug target/85268] Typo in "PIC is not supported"

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

--- Comment #1 from Andrew Pinski  ---
Except warning should not have any.

[Bug target/85268] New: Typo in "PIC is not supported"

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

Bug ID: 85268
   Summary: Typo in "PIC is not supported"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From config/arc/arc.c:

  warning (DK_WARNING,
   "PIC is not supported for %s. Generating non-PIC code only..",
   arc_cpu_string);

There can only be one period at the end of a sentence.

[Bug tree-optimization/85267] Untranslatable strings in verify_variant_match

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

Roland Illig  changed:

   What|Removed |Added

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

--- Comment #3 from Roland Illig  ---
Resolving a bug as a duplicate requires a comment, so here it is.

/* This is a comment. */

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

[Bug tree-optimization/80021] untranslateable diagnostic "type variant differs by " #flag "."

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

--- Comment #2 from Roland Illig  ---
*** Bug 85267 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/85267] Untranslatable strings in verify_variant_match

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

--- Comment #2 from Roland Illig  ---
Exact duplicate of #80021, which was just missing the keyword
"verify_variant_match".

[Bug tree-optimization/85267] Untranslatable strings in verify_variant_match

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

--- Comment #1 from Andrew Pinski  ---
This is another one of these error which should be an inform or sorry that only
comes out when dealing with internal compiler errors.  There is another bug
about this case.

[Bug tree-optimization/85267] New: Untranslatable strings in verify_variant_match

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

Bug ID: 85267
   Summary: Untranslatable strings in verify_variant_match
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From tree.c:

#define verify_variant_match(flag)  \
  do {  \
if (flag (tv) != flag (t))  \
  { \
error ("type variant differs by " #flag ".");   \
debug_tree (tv);\
return false;   \
  } \
  } while (false)

Since GNU Gettext does not expand macro parameters, it extracts the following
message for translation:

msgid "type variant differs by "

This message ID is useless because it never occurs in practice.

Proper fix: Never use error() with macro parameters.

[Bug target/85236] missing _mm256_atan2_ps

2018-04-06 Thread glisse at gcc dot gnu.org

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

--- Comment #5 from Marc Glisse  ---
(In reply to bking from comment #4)
> I understand that is a part of SVML, but doesn't that mean using the Intel
> Compiler?  Which means not using GCC.  Is there not a plan to add it?  Or is
> that the intent of glibc?

As Richard said, yes, the current situation is that this would fit much better
in glibc's libmvec. It already provides vector versions of sin, cos, exp, log,
pow and sincos (under different names than SVML), it should be extended to more
functions. Another possibility would be to link to Intel's SVML when it is
present. Although gcc already has a way to use SVML for autovectorization, it
isn't clear in this particular case whether it is something the compiler should
provide, the library vendor (Intel), or the user.

[Bug c++/85110] Missing underlines for some bad arguments

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

--- Comment #4 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00342.html

[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I'm testing a fix for both problems.

[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
With -Wno-system-headers GCC 8 prints:

In file included from /usr/include/string.h:635,
 from pr85259.c:1:
In function ‘strcat’,
inlined from ‘main’ at pr85259.c:8:3:
/usr/include/bits/string3.h:148:10: warning: ‘__builtin___memcpy_chk’ forming
offset [7, 13] is out of the bounds [0, 6] of object ‘buf’ with type ‘char[6]’
[-Warray-bounds]
   return __builtin___strcat_chk (__dest, __src, __bos (__dest));
  ^~
pr85259.c: In function ‘main’:
pr85259.c:3:6: note: ‘buf’ declared here
 char buf[6];
  ^~~

This is better but it's a warning for the strcat call while there should be a
warning for the strcpy() call first because it overflows the buffer.  A bug in
handle_builtin_strcpy() in tree-ssa-strlen causes GCC to miss this case.  So
there are two bugs in play here: the system header suppression and the
detection of strcpy overflow with a string literal.

[Bug target/85236] missing _mm256_atan2_ps

2018-04-06 Thread bking at rtlogic dot com

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

--- Comment #4 from bking at rtlogic dot com ---
I understand that is a part of SVML, but doesn't that mean using the Intel
Compiler?  Which means not using GCC.  Is there not a plan to add it?  Or is
that the intent of glibc?

[Bug c++/85265] New: [concepts] ICE with missing identifier

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

Bug ID: 85265
   Summary: [concepts] ICE with missing identifier
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

The following invalid code snippet (compiled with "-fconcepts")
triggers an ICE since GCC 6.1.0:

=
template concept bool C = true;

C{} void foo();
=

bug99.cc:3:3: error: expected identifier before '}' token
 C{} void foo();
   ^
bug99.cc:3:3: internal compiler error: tree check: expected identifier_node,
have error_mark in find_local_binding, at cp/name-lookup.c:143
0x78cf20 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9322
0x620722 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3135
0x620722 find_local_binding
../../gcc/gcc/cp/name-lookup.c:143
0x9085f2 do_pushdecl
../../gcc/gcc/cp/name-lookup.c:2998
0x9085f2 pushdecl(tree_node*, bool)
../../gcc/gcc/cp/name-lookup.c:3148
0x95f65a process_template_parm(tree_node*, unsigned int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:4432
0x86575d process_introduction_parm
../../gcc/gcc/cp/constraint.cc:1376
0x86575d finish_template_introduction(tree_node*, tree_node*)
../../gcc/gcc/cp/constraint.cc:1408
0x944368 cp_parser_template_introduction
../../gcc/gcc/cp/parser.c:27066
0x944368 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:27170
0x949714 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x949b31 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12648
0x949e24 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x949e24 c_parse_file()
../../gcc/gcc/cp/parser.c:39029
0xa49bb6 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]


Referenced Bugs:

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

[Bug c++/85266] New: Inconsistent _Pragma behavior for macro with and without arguments

2018-04-06 Thread sdaniel.cole at gmail dot com

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

Bug ID: 85266
   Summary: Inconsistent _Pragma behavior for macro with and
without arguments
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sdaniel.cole at gmail dot com
  Target Milestone: ---

I'm trying to use the _Pragma operator to disable warnings for code inside a
macro. It seems to work when the macro has no arguments (without parenthesis),
but doesn't work when it has arguments (even having empty parenthesis causes
the change in behavior).

The following works as expected (shadow warning disabled for macro only):

struct RAII{
RAII();
~RAII();
};

#define RAII_BLOCK  \
_Pragma("GCC diagnostic push \"-Wshadow\"") \
_Pragma("GCC diagnostic ignored \"-Wshadow\"")  \
auto a = RAII();\
_Pragma("GCC diagnostic pop")

void foo() {
RAII_BLOCK;
{
RAII_BLOCK;
}
}


The following doesn't work as expected (a warning is still generated):

struct RAII{
RAII();
~RAII();
};

#define RAII_BLOCK()\
_Pragma("GCC diagnostic push \"-Wshadow\"") \
_Pragma("GCC diagnostic ignored \"-Wshadow\"")  \
auto a = RAII();\
_Pragma("GCC diagnostic pop")

void foo() {
RAII_BLOCK();
{
RAII_BLOCK();
}
}

I compile the above using:
g++ -c test.cpp -Wshadow

https://godbolt.org/g/D22MYu

[Bug gcov-profile/85245] [GCOV] A return statement in the if(0) block is wrongly marked as executed when they are nested in the true block of if (cond-expression) statement in gcov

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug gcov-profile/85243] [GCOV] A return statement in the if(0) block is wrongly marked as executed when prefixed with an array declaration statement and followed by a "for(;cond-expression;) return;

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((interception::real_cxa_throw)) != (0)" (0x0, 0x0)

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||8.0
  Known to fail||7.3.0

--- Comment #20 from Martin Liška  ---
It's good that it works with current trunk, so I'll bisect that..

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed, closing.

Thanks for the bug report!

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Apr  6 18:49:21 2018
New Revision: 259188

URL: https://gcc.gnu.org/viewcvs?rev=259188=gcc=rev
Log:
2018-04-06  Thomas Koenig  

PR libfortran/85253
* m4/matmul_internal.m4: If ycount == 1, add one more row to
the internal buffer.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Regenerated.
* generated/matmul_c4.c: Regenerated.
* generated/matmul_c8.c: Regenerated.
* generated/matmul_i1.c: Regenerated.
* generated/matmul_i16.c: Regenerated.
* generated/matmul_i2.c: Regenerated.
* generated/matmul_i4.c: Regenerated.
* generated/matmul_i8.c: Regenerated.
* generated/matmul_r10.c: Regenerated.
* generated/matmul_r16.c: Regenerated.
* generated/matmul_r4.c: Regenerated.
* generated/matmul_r8.c: Regenerated.
* generated/matmulavx128_c10.c: Regenerated.
* generated/matmulavx128_c16.c: Regenerated.
* generated/matmulavx128_c4.c: Regenerated.
* generated/matmulavx128_c8.c: Regenerated.
* generated/matmulavx128_i1.c: Regenerated.
* generated/matmulavx128_i16.c: Regenerated.
* generated/matmulavx128_i2.c: Regenerated.
* generated/matmulavx128_i4.c: Regenerated.
* generated/matmulavx128_i8.c: Regenerated.
* generated/matmulavx128_r10.c: Regenerated.
* generated/matmulavx128_r16.c: Regenerated.
* generated/matmulavx128_r4.c: Regenerated.
* generated/matmulavx128_r8.c: Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/matmul_c10.c
trunk/libgfortran/generated/matmul_c16.c
trunk/libgfortran/generated/matmul_c4.c
trunk/libgfortran/generated/matmul_c8.c
trunk/libgfortran/generated/matmul_i1.c
trunk/libgfortran/generated/matmul_i16.c
trunk/libgfortran/generated/matmul_i2.c
trunk/libgfortran/generated/matmul_i4.c
trunk/libgfortran/generated/matmul_i8.c
trunk/libgfortran/generated/matmul_r10.c
trunk/libgfortran/generated/matmul_r16.c
trunk/libgfortran/generated/matmul_r4.c
trunk/libgfortran/generated/matmul_r8.c
trunk/libgfortran/generated/matmulavx128_c10.c
trunk/libgfortran/generated/matmulavx128_c16.c
trunk/libgfortran/generated/matmulavx128_c4.c
trunk/libgfortran/generated/matmulavx128_c8.c
trunk/libgfortran/generated/matmulavx128_i1.c
trunk/libgfortran/generated/matmulavx128_i16.c
trunk/libgfortran/generated/matmulavx128_i2.c
trunk/libgfortran/generated/matmulavx128_i4.c
trunk/libgfortran/generated/matmulavx128_i8.c
trunk/libgfortran/generated/matmulavx128_r10.c
trunk/libgfortran/generated/matmulavx128_r16.c
trunk/libgfortran/generated/matmulavx128_r4.c
trunk/libgfortran/generated/matmulavx128_r8.c
trunk/libgfortran/m4/matmul_internal.m4

[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((interception::real_cxa_throw)) != (0)" (0x0, 0x0)

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #19 from Martin Liška  ---
Great job. I can confirm that and I'll work on that after upcoming weekend.

[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Apr  6 18:09:53 2018
New Revision: 259185

URL: https://gcc.gnu.org/viewcvs?rev=259185=gcc=rev
Log:
PR c++/85214 - ICE with alias, generic lambda, constexpr if.

Here, since the condition for the constexpr if depends on the type of 'j',
it's still dependent when we are partially instantiating the inner lambda,
so we need to defer instantiating the constexpr if.  When we instantiated
the inner lambda, we tried to substitute into the typename, which failed
because we didn't have a declaration of 'i' available.

Fixed by teaching extract_locals_r to capture local typedefs such as 'ar';
if we have the typedef handy, we don't need to substitute into its
definition.

* pt.c (extract_locals_r): Remember local typedefs.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/81764] [6/7/8 Regression] Visibility attributes for explicitly instantiated template class get warned if it has been implicitly instantiated

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

--- Comment #3 from Martin Sebor  ---
This is another one of those cases where implementations diverge:

Clang and ICC silently accept the program in comment #0 and give an error for
the one in comment #1.
GCC issues -Wattributes for both.
MSVC silently accepts the program in comment #1 but gives a warning when the
alignment specified on the specialization is different than on the primary.

MSVC doesn't understand visibility attributes but it does accept __declspec
dllexport and dllimport.  It allows the example in comment #0 with __declspec
(dllimport) and also with the primary declared dllexport and the instantiation
declared dllimport.  That makes sense because both declarations would typically
appear this way in a library header and an explicit instantiation directive
declared dllexport in some source file of the library.  The C++ constraint that
"no attribute-specifier-seq shall appertain to an explicit instantiation"
disallows this use case (one of the main uses cases in Windows class template
DLLs).

GCC for i686-pc-cygwin also issues a warning for this modified test case and so
is incompatible with MSVC:

$ cat pr81764.C && i686-pc-cygwin-g++ -S -Wall pr81764.C
template class g;

template
class __declspec (dllexport) g
{
g() = default;

static int f(int x)
{
return g<>::yyy::u(x); // g<> instantiated here
}


struct yyy
{
static int u(int x){
return x+ sizeof...(T);
}
};
};

extern template class __declspec (dllimport) g<>; 
template class  g<>;
pr81764.C:22:46: warning: type attributes ignored after type is already defined
[-Wattributes]
 extern template class __declspec (dllimport) g<>;
  ^~~

[Bug c++/85227] [7/8 Regression] ICE with structured binding of a forward declared variable

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |7.4
Summary|[7/8/ Regression] ICE with  |[7/8 Regression] ICE with
   |structured binding of a |structured binding of a
   |forward declared variable   |forward declared variable

[Bug c++/84269] More suggestions for missing #include

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from David Malcolm  ---
r259184 should cover everything so far; closing this one out.

[Bug c++/84269] More suggestions for missing #include

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

--- Comment #13 from David Malcolm  ---
Author: dmalcolm
Date: Fri Apr  6 17:36:33 2018
New Revision: 259184

URL: https://gcc.gnu.org/viewcvs?rev=259184=gcc=rev
Log:
C++: more std header hints; filter on C++ dialect (PR c++/84269)

This patch adds more suggestions as per:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269#c10
some of which need C++14 and C++17, and some of which use headers that
exist in earlier standards.

For example,  exists in C++98, but if the user attempts to
use std::make_shared with -std=c++98, they are suggested to include
, even if they've already included it.

This patch adds the missing names, and fixes the nonsensical suggestions
by detecting if the name isn't available yet, based on the user's
dialect, and reporting things more intelligently:

t.cc: In function 'void test_make_shared()':
t.cc:5:8: error: 'make_shared' is not a member of 'std'
   std::make_shared();
^~~
t.cc:5:8: note: 'std::make_shared' is only available from C++11 onwards

gcc/cp/ChangeLog:
PR c++/84269
* name-lookup.c (struct std_name_hint): Move out of
get_std_name_hint; add field "min_dialect".
(get_std_name_hint): Add min_dialect values to all initializers.
Add , , , , ,
, , , , , ,
, , , and .
Add fstream, ifstream, and ofstream to .
Add istringstream, ostringstream, and stringstream to .
Add basic_string to .
Add tuple_element and tuple_size to .
Add declval to .
Fix ordering of  and .
Return a std_name_hint, rather than a const char *.
(get_cxx_dialect_name): New function.
(maybe_suggest_missing_std_header): Detect names that aren't yet
available in the current dialect, and instead of suggesting a
missing #include, warn about the dialect.

gcc/testsuite/ChangeLog:
PR c++/84269
* g++.dg/lookup/missing-std-include-6.C: Move std::array and
std::tuple here since they need C++11.
* g++.dg/lookup/missing-std-include-8.C: New test.
* g++.dg/lookup/missing-std-include.C: Move std::array and
std::tuple test to missing-std-include-6.C to avoid failures
with C++98.


Added:
trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C
trunk/gcc/testsuite/g++.dg/lookup/missing-std-include.C

[Bug debug/85252] [6/7 Regression] ICE with -g for static zero-length array initialization

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |-g for static zero-length   |-g for static zero-length
   |array initialization|array initialization

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues

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

Bug 84872 Summary: [8 Regression] ICE in create_preheader, at 
cfgloopmanip.c:1536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872

   What|Removed |Added

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

[Bug c++/85210] [7 Regression] ICE with broken structured binding in template

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |broken structured binding   |broken structured binding
   |in template |in template

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr  6 17:28:54 2018
New Revision: 259183

URL: https://gcc.gnu.org/viewcvs?rev=259183=gcc=rev
Log:
PR debug/85252
* dwarf2out.c (rtl_for_decl_init): For STRING_CST initializer only
build CONST_STRING if TYPE_MAX_VALUE is non-NULL and is INTEGER_CST.

* gcc.dg/debug/pr85252.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/pr85252.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr  6 17:28:02 2018
New Revision: 259182

URL: https://gcc.gnu.org/viewcvs?rev=259182=gcc=rev
Log:
PR rtl-optimization/84872
* cfgloopmanip.c (create_preheader): Use make_forwarder_block even if
nentry == 1 when CP_FALLTHRU_PREHEADERS and single_entry is
EDGE_CROSSING edge.

* gcc.dg/graphite/pr84872.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr84872.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloopmanip.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85210] [7/8 Regression] ICE with broken structured binding in template

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr  6 17:27:01 2018
New Revision: 259181

URL: https://gcc.gnu.org/viewcvs?rev=259181=gcc=rev
Log:
PR c++/85210
* pt.c (tsubst_decomp_names): Return error_mark_node and assert
errorcount is set if tsubst doesn't return a VAR_DECL.

* g++.dg/cpp1z/decomp42.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp42.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85260] [8 Regression] python-2.7.14 miscompiled at -O3

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from David Malcolm  ---
This is a bug in CPython: the code is assuming 16-byte alignment, but the
allocator only guarantees 8-byte alignment:
  https://bugs.python.org/issue27987
  https://bugs.python.org/issue31912 
  https://mail.python.org/pipermail/python-dev/2018-January/152011.html

[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #16 from Jason Merrill  ---
Yes.

[Bug c/85260] [8 Regression] python-2.7.14 miscompiled at -O3

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Actually, it seems to be a python bug to me.
Reduced testcase:

typedef struct S {
  long ob_refcnt;
  void *ob_type;
  void *in_class;
  void *in_dict;
  void *in_weakreflist;
} PyClassObject;
PyClassObject *foo (void);
typedef union U {
  struct {
union U *gc_next;
union U *gc_prev;
long gc_refs;
  } gc;
  long double dummy;
} PyGC_Head;

void *
bar (void *klass, void *dict)
{
  PyClassObject *inst = foo ();
  inst->in_class = klass;
  inst->in_dict = dict;
  PyGC_Head *g = (PyGC_Head *)inst - 1;
  g->gc.gc_prev->gc.gc_next = g;
  return inst;
}

While PyClassObject seems to have 8-byte alignment, the code assumes there is a
PYGC_Head object in front of it, and that because of the long double member has
16-byte alignment.  So, I believe if the function (_PyObject_GC_New in the
original testcase) returns something that is not 16-byte aligned, which is what
happens when it segfaults, then it is an application bug - UB because
g->gc.gc_prev is then access to misaligned *g.  Richard's changes derive
alignment information from that access and assume that inst must be also
16-byte aligned.

[Bug c++/82152] [7 Regression] ICE on invalid code in C++17 mode if inheriting constructors are used

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c/85260] [8 Regression] python-2.7.14 miscompiled at -O3

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|8.0: python-2.7.14  |[8 Regression]
   |miscompiled at -O3  |python-2.7.14 miscompiled
   ||at -O3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Seems to have started with r250870, it is slp2 that creates a vector store that
needs 16-byte alignment, but the pointer is only 8-byte aligned.  Will try to
minimize a testcase.

[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r251438.

[Bug c++/85264] [7/8 Regression] ICE with extraneous template parameter list

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r235213.

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

2018-04-06 Thread thopre01 at gcc dot gnu.org

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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to fail||6.4.1, 7.3.1

--- Comment #3 from Thomas Preud'homme  ---
(In reply to Ramana Radhakrishnan from comment #2)
> What about earlier branches ?

Oh yes, forgot the previous fpscr fix was also backported.

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

2018-04-06 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
What about earlier branches ?

Your Weekly Breeze - April. 05 - April. 11

2018-04-06 Thread Oasis Living Magazine

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlpsend3.com/zFW1Ci

Having problems viewing Weekly Breeze Click here (
http://myoasisliving.com/weekly_breeze/weekly_breeze.php ).

TOP PICS

Apr 05 - Apr 11

"Never be bullied into silence. Never allow yourself to be made a
victim. Accept no one's definition of your life; define yourself." —
Harvey Fierstein, American actor and playwright

The world at his fingertips
Oasis Living chatted to Shaun Agostine, a child prodigy who made his
first professional tour as a pianist at the ripe old age of eight >> (
http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99
)

Spruce up for spring
With the cooler months passing and the high heat of summer imminent,
take advantage of these breezy and energised months to redecorate >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/bcbf2b3187e12154b1401ef156b
)

A month to remember
A recap of last month’s happenings at the Al Ain Rugby Club >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/1234bcbf2b3187e12154b1401ef156b
)

Riding into the past
Behind the Garden City’s frst train tour operator >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/bcbf2b3187e12154b1401ef156b
)

Trailblazing success
Al Ain’s finest earn places among the world >> (
http://myoasisliving.com/en/news/news_detail/news_id_enc/bcbf2b3187e12154b1401ef156b
)

"AGENDA"

Thursday

Zip in and Out Lunch in Aloft Al Ain’s Olive Tree from 12 to 5pm:
Dh61 per including two courses and soft drinks. Later, it’s Seafood
Night from 7 to 11pm: Dh199 per person.

An Evening Brunch is available at Al Ain Rotana’s Zest from 6:30 to
11pm: Dh187++ including soft drinks, Dh220++ including grape and hops.
And it’s Moodz in the City in the hotel’s Moodz from 7pm to
3.30am: Dh100 including two drinks.

Happy Hour in Danat Al Ain Resort's McGettigan’s from 5 to 8pm with
40 per cent off all house drinks, and it’s also Teacher’s Night
there from 2 to 10pm with a 20 per cent discount offer.

Thursday BBQ Buffet in The Palm Greens Restaurant at AESGC’s Golf
Club from 6.30 to 10.30pm: Dh199 per person with free-flow of one
selected beverage, Dh99 with free-flow of soft drinks - members
discount also applies on total bill.

Lebanese Night in Al Rikab Restaurant at AESGC’s Equestrian Club
from 10pm to 3.30am: Dh100 per person with cold and hot meza; Dh150
with cold meza, mixed grills, fruits and sweets - live entertainment
available.

Family Dining Night in AESGC's Rugby Club's Amblers Restaurant from
5.30pm with a 20 per cent discount for families.

Seafood Extravaganza at Hilton Al Ain’s Flavours from 7 to 11pm:
Dh139++. It’s also Sizzling Thursday in the hotel’s Paco’s from
4pm to 2am: Dh60++.

Friday

Friday Brunch in Zest at Al Ain Rotana from 12.30 to 3.30pm: Dh212++
depending on drinks package. And Hinky Dinks Friday Brunch in the
hotel’s Trader Vic’s featuring four starters, four main courses
and dessert samples with unlimited cocktails, mocktails, reds, whites,
and malt beverages: 12.30 to 4.30pm: Dh312 per. Later, it's Hi5 Night
in the hotel's Moodz from 7pm to 3.30am: Dh100 including two drinks.

European Brunch in Aloft Al Ain’s Olive Tree from 11am to 2pm,
Dh129, and It’s a Pizza Party later on from 7 to 11pm: Dh39 per
pizza including a soft drink.

Friday Brunch in Danat Al Ain Resort's McGettigan’s from 12 to
4.30pm: Dh152. It’s also Happy Hour in the same venue from 5 to 8pm
with 40 per cent off all house drinks, and a Drunch buffet is also
available: Dh99.

Friday Family Buffet in Al Rikab Restaurant at AESGC’s Equestrian
Club, from 12 to 6pm: Dh95 per person, Dh45 for kids aged six to 12
with live entertainment and outdoor activities kicking off at 4pm. And
in the evening, it’s Iraqui Night in the same venue from 10pm to
3.30am: free entry for all.

Friday Carving Day in Amblers Restaurant, AESGC's Rugby Club, from 1
to 5pm, Dh85 with free-flow of soft drinks, Dh155 with free-flow of
one selected beverage.

Friday Family Brunch in Hilton Al Ain’s Flavours from 1 to 4pm:
Dh109++ including soft drinks; Dh149++ including house beverages.
It’s also Unlimited Fridays in the hotel’s Paco’s for Dh150++
from 9pm to 12am.

Saturday

Arabian Night in Al Ain Rotana's Moodz from 7pm to 3.30am: Dh100
including two drinks.

Saturday SOS in Danat Al Ain Resort's McGettigan’s from 12 to 5pm:
Dh78. It’s also Happy Hour in the same venue from 5 to 8pm with 40
per cent off all house drinks.

Saturday Roast from 1 to 4pm in Aloft Al Ain’s The Rooftop:
Dh120++.

Sunday

Sunday Roast in Hilton Al Ain’s Paco’s from 5pm to 2am: Dh60++,
Dh100++ with two hops.

[Bug c++/85021] "Missing #include" hints for unrecognized names that would implicitly be in "std"

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
Implemented for trunk (gcc 8) in r259179 (v2 of patch)

[Bug c++/85021] "Missing #include" hints for unrecognized names that would implicitly be in "std"

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Fri Apr  6 15:46:04 2018
New Revision: 259179

URL: https://gcc.gnu.org/viewcvs?rev=259179=gcc=rev
Log:
C++: suggest missing headers for implicit use of "std" (PR c++/85021)

We provide fix-it hints for the most common "std" names when an explicit
"std::" prefix is present, however we don't yet provide fix-it hints for
this implicit case:

  using namespace std;
  void f() {  cout << "test"; }

for which we emit:

  t.cc: In function 'void f()':
  t.cc:2:13: error: 'cout' was not declared in this scope
  void f() {  cout << "test"; }
  ^~~~

This patch detects if a "using namespace std;" directive is present
in the current namespace, and if so, offers a suggestion for
unrecognized names that are in our list of common "std" names:

  t.cc: In function 'void f()':
  t.cc:2:13: error: 'cout' was not declared in this scope
   void f() {  cout << "test"; }
   ^~~~
  t.cc:2:13: note: 'std::cout' is defined in header ''; did you
forget to '#include '?
  +#include 
   using namespace std;
   void f() {  cout << "test"; }
   ^~~~

gcc/cp/ChangeLog:
PR c++/85021
* name-lookup.c (using_directives_contain_std_p): New function.
(has_using_namespace_std_directive_p): New function.
(suggest_alternatives_for): Simplify if/else logic using early
returns.  If no candidates were found, and there's a
"using namespace std;" directive, call
maybe_suggest_missing_std_header.
(maybe_suggest_missing_header): Split later part of the function
into..
(maybe_suggest_missing_std_header): New.

gcc/testsuite/ChangeLog:
PR c++/85021
* g++.dg/lookup/missing-std-include-7.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85264] New: [7/8 Regression] ICE with extraneous template parameter list

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

Bug ID: 85264
   Summary: [7/8 Regression] ICE with extraneous template
parameter list
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 7.1.0:

=
template struct A {};

template
template struct A {};

A a;
=

bug.cc: In substitution of 'template > template
struct A [with T = ; int  = {int}]':
bug.cc:6:14:   required from here
bug.cc:6:14: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:11875
 A a;
  ^
0x644533 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11875
0x96952a tsubst_arg_types
../../gcc/gcc/cp/pt.c:13549
0x96973d tsubst_function_type
../../gcc/gcc/cp/pt.c:13711
0x96a1c3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14440
0x979422 tsubst_template_args
../../gcc/gcc/cp/pt.c:12137
0x96a855 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14301
0x986c57 get_partial_spec_bindings
../../gcc/gcc/cp/pt.c:22385
0x987176 most_specialized_partial_spec
../../gcc/gcc/cp/pt.c:22618
0x99107f instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10567
0x99107f instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:11100
0x9d8b6d complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:136
0x885e67 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:5275
0x8ac107 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:5238
0x93d1b3 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19610
0x944988 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13049
0x945798 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12874
0x949722 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12772
0x949b31 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12648
0x949e24 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x949e24 c_parse_file()
../../gcc/gcc/cp/parser.c:39029
Please submit a full bug report, [etc.]

Before, the code was wrongly accepted.
If I use regular template parameters instead of parameter packs, the code
is also wrongly accepted (since at least GCC 3.1.1).

[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns

2018-04-06 Thread segher at gcc dot gnu.org

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

--- Comment #14 from Segher Boessenkool  ---
-msvr4-struct-return=standard and -msvr4-struct-return=compat, perhaps?

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

2018-04-06 Thread zeccav at gmail dot com

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

--- Comment #4 from Vittorio Zecca  ---
After applying the fix in comment #3 the asan message disappeared.

[Bug tree-optimization/85257] [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43873=edit
gcc8-pr85257.patch

Untested fix, actually either of the fold-const.c or tree-ssa-sccvn.c changes
is enough to fix this.

The fold-const.c change is needed because when using 3 argument
native_encode_expr, it is assumed that we return 0 whenever it didn't fit
fully, which we violated for VECTOR_CSTs if length was exactly on a boundary
between two elements.

And the tree-ssa-sccvn.c change is an optimization, there is no reason to
compute bytes we aren't interested in, and for larger VECTOR_CSTs like this one
because of that not being able to optimize at all; we can use the 4 argument
form instead and just compute the bytes we want; in that case the returned
length can be just partial of what were asking for, so we need to verify it is
enough for what we try to decode.

[Bug c++/85242] [6/7/8 Regression] ICE with invalid template parameter

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Apr  6 15:12:34 2018
New Revision: 259178

URL: https://gcc.gnu.org/viewcvs?rev=259178=gcc=rev
Log:
PR c++/85242 - ICE with class definition in template parm.

* cp-tree.h (PROCESSING_REAL_TEMPLATE_DECL_P): False if
processing_template_parmlist.

Added:
trunk/gcc/testsuite/g++.dg/template/error58.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h

[Bug c++/85240] [6/7 Regression] ICE with function without deduced return type

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Fri Apr  6 15:12:28 2018
New Revision: 259177

URL: https://gcc.gnu.org/viewcvs?rev=259177=gcc=rev
Log:
PR c++/85240 - LTO ICE with using of undeduced auto fn.

* cp-gimplify.c (cp_genericize_r): Discard using of undeduced auto.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn51.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c

[Bug c++/85263] New: [concepts] ICE with parameter pack matching

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

Bug ID: 85263
   Summary: [concepts] ICE with parameter pack matching
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

The following invalid code snippet (compiled with "-fconcepts") triggers
an ICE since GCC 6.1.0:

===
template concept bool C = true;

C{A, B} void foo();
===

bug.cc:3:3: error: cannot match pack for introduced parameter
 C{A, B} void foo();
   ^
bug.cc:3:7: internal compiler error: tree check: accessed elt 1 of tree_vec
with 0 elts in process_introduction_parm, at cp/constraint.cc:1325
 C{A, B} void foo();
   ^
0x78f405 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
../../gcc/gcc/tree.c:9520
0x5e94ec tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
../../gcc/gcc/tree.h:3356
0x5e94ec process_introduction_parm
../../gcc/gcc/cp/constraint.cc:1325
0x5e94ec finish_template_introduction(tree_node*, tree_node*)
../../gcc/gcc/cp/constraint.cc:1408
0x944368 cp_parser_template_introduction
../../gcc/gcc/cp/parser.c:27066
0x944368 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:27170
0x949714 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x949b31 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12648
0x949e24 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4563
0x949e24 c_parse_file()
../../gcc/gcc/cp/parser.c:39029
0xa49bb6 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]


Referenced Bugs:

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

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

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

--- Comment #3 from Thomas Koenig  ---
Yep, looking at the code, it seems that in this special
case, we need one more row in the temporary buffer.

This seems to cure it.

Index: m4/matmul_internal.m4
===
--- m4/matmul_internal.m4   (Revision 259152)
+++ m4/matmul_internal.m4   (Arbeitskopie)
@@ -234,7 +234,7 @@ sinclude(`matmul_asm_'rtype_code`.m4')dnl

   /* Adjust size of t1 to what is needed.  */
   index_type t1_dim;
-  t1_dim = (a_dim1-1) * 256 + b_dim1;
+  t1_dim = (a_dim1- (ycount > 1)) * 256 + b_dim1;
   if (t1_dim > 65536)
t1_dim = 65536;

[Bug c++/85262] New: [6/7/8 Regression] Trouble with constructor and -fpermissive

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

Bug ID: 85262
   Summary: [6/7/8 Regression] Trouble with constructor and
-fpermissive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-fpermissive")
triggers an ICE on trunk:


struct A {};

template struct B : A
{
  B()
  {
A::A(A());
  }
};

B<0> b;


bug.cc: In constructor 'B< >::B()':
bug.cc:7:13: warning: cannot call constructor 'A::A' directly [-fpermissive]
 A::A(A());
 ^
bug.cc:7:13: note: for a function-style cast, remove the redundant '::A'
bug.cc: In instantiation of 'B< >::B() [with int  = 0]':
bug.cc:11:6:   required from here
bug.cc:7:10: internal compiler error: in tsubst_copy, at cp/pt.c:15625
 A::A(A());
  ^~~
0x63a8eb tsubst_copy
../../gcc/gcc/cp/pt.c:15625
0x96682b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18658
0x967f8c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18295
0x965a11 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17543
0x971627 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17099
0x97092e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16300
0x96e71f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16583
0x97005c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16286
0x96e71f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16583
0x96d8b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16271
0x96d8b8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23682
0x99476b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23798
0x8b8e3b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4725
Please submit a full bug report, [etc.]

In GCC 6 and GCC 7 the code is wrongly rejected (when parsing the template,
the call to A::A is accepted with "-fpermissive", but at instantiation time
it is rejected) while a version without template compiles:

bug.cc: In constructor 'B< >::B()':
bu5.cc:7:13: warning: cannot call constructor 'A::A' directly [-fpermissive]
 A::A(A());
 ^
bug.cc:7:13: note: for a function-style cast, remove the redundant '::A'
bug.cc: In instantiation of 'B< >::B() [with int  = 0]':
bug.cc:11:6:   required from here
bug.cc:7:9: error: cannot call constructor 'A::A' directly
 A::A(A());
 ^

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

2018-04-06 Thread jamborm at gcc dot gnu.org

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

Martin Jambor  changed:

   What|Removed |Added

  Attachment #43588|0   |1
is obsolete||

--- Comment #8 from Martin Jambor  ---
Created attachment 43872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43872=edit
Current patch

This patch, which speeds up mcf and which is more consistent with the IPA-CP
design and does not miscompile mcf, has passed LTO bootstrap and testing, I
will try it on a few bigger applications and submit it shortly afterwards.

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Probably my memory saving patch.

I'll investigate.

[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562

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

--- Comment #2 from Jason Merrill  ---
Further reduced:

struct g {
  constexpr operator int() { return true; }
};
template  constexpr bool m = true;
template  struct C { typedef double q; };
void ao() {
  [](auto i) {
  using ar = typename C::q;
  [](auto j) {
using as = typename C::q;
if constexpr (m) {}
  }(g());
  }(g());
}

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

2018-04-06 Thread thopre01 at gcc dot gnu.org

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-06
 Ever confirmed|0   |1
  Known to fail||8.0.1

--- Comment #1 from Thomas Preud'homme  ---
Have a patch, testing it.

[Bug c++/85249] [6/7/8 Regression] ICE with invalid default parameter

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r186346.

[Bug target/85261] New: __builtin_arm_set_fpscr ICEs with constant input

2018-04-06 Thread thopre01 at gcc dot gnu.org

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

Bug ID: 85261
   Summary: __builtin_arm_set_fpscr ICEs with constant input
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: thopre01 at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

The following code ICES when compiled with -mcpu=cortex-m4 -mfloat-abi=hard
-mfpu=fpv4-sp-d16 on trunk:

void
test_fpscr (void)
{
  __builtin_arm_set_fpscr (0);
}

[Bug c/85260] New: 8.0: python-2.7.14 miscompiled at -O3

2018-04-06 Thread manuel.lauss at googlemail dot com

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

Bug ID: 85260
   Summary: 8.0: python-2.7.14 miscompiled at -O3
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.lauss at googlemail dot com
  Target Milestone: ---

python-2.7.14 seems to be miscompiled at -O3, while -O2 is fine.
gcc-8 as of 20180405. gcc-7.3.1 -O3 is fine as well.

build # LD_LIBRARY_PATH=$PWD ./python 
Segmentation fault (core dumped)

#0  0x7f784416d43a in PyInstance_NewRaw (klass=klass@entry=0x7f78439209a8,
dict=0x7f7843d66910, dict@entry=0x0) at
/tmp-ram/portage/dev-lang/python-2.7.14-r1/work/Python-2.7.14/Objects/classobject.c:544
544 inst->in_dict = dict;

(gdb) list
539 return NULL;
540 }
541 inst->in_weakreflist = NULL;
542 Py_INCREF(klass);
543 inst->in_class = (PyClassObject *)klass;
544 inst->in_dict = dict;
545 _PyObject_GC_TRACK(inst);
546 return (PyObject *)inst;
547 }

Dump of assembler code for function PyInstance_NewRaw:
   0x7f784416d3d0 <+0>: push   %rbp
   0x7f784416d3d1 <+1>: push   %rbx
   0x7f784416d3d2 <+2>: sub$0x18,%rsp
   0x7f784416d3d6 <+6>: mov0x149b9b(%rip),%rax#
0x7f78442b6f78
   0x7f784416d3dd <+13>:cmp%rax,0x8(%rdi)
   0x7f784416d3e1 <+17>:jne0x7f784416d490 
   0x7f784416d3e7 <+23>:mov%rdi,%rbx
   0x7f784416d3ea <+26>:mov%rsi,%rbp
   0x7f784416d3ed <+29>:test   %rsi,%rsi
   0x7f784416d3f0 <+32>:je 0x7f784416d4b0 
   0x7f784416d3f6 <+38>:mov0x8(%rsi),%rax
   0x7f784416d3fa <+42>:testb  $0x20,0xab(%rax)
   0x7f784416d401 <+49>:je 0x7f784416d4d0 
   0x7f784416d407 <+55>:incq   (%rsi)
   0x7f784416d40a <+58>:mov0x1496cf(%rip),%rdi#
0x7f78442b6ae0
   0x7f784416d411 <+65>:callq  0x7f784414a390 <_PyObject_GC_New@plt>
   0x7f784416d416 <+70>:test   %rax,%rax
   0x7f784416d419 <+73>:je 0x7f784416d4e8 
   0x7f784416d41f <+79>:vmovq  %rbx,%xmm1
   0x7f784416d424 <+84>:movq   $0x0,0x20(%rax)
   0x7f784416d42c <+92>:vpinsrq $0x1,%rbp,%xmm1,%xmm0
   0x7f784416d432 <+98>:incq   (%rbx)
   0x7f784416d435 <+101>:   cmpq   $0xfffe,-0x10(%rax)
=> 0x7f784416d43a <+106>:   vmovaps %xmm0,0x10(%rax)
   0x7f784416d43f <+111>:   lea-0x20(%rax),%rbx
   0x7f784416d443 <+115>:   jne0x7f784416d478 
   0x7f784416d445 <+117>:   mov0x149834(%rip),%rdx#
0x7f78442b6c80
   0x7f784416d44c <+124>:   movq   $0xfffd,-0x10(%rax)
   0x7f784416d454 <+132>:   mov(%rdx),%rcx
   0x7f784416d457 <+135>:   mov%rcx,-0x20(%rax)
   0x7f784416d45b <+139>:   mov0x8(%rcx),%rcx
   0x7f784416d45f <+143>:   mov%rcx,-0x18(%rax)
   0x7f784416d463 <+147>:   mov%rbx,(%rcx)
   0x7f784416d466 <+150>:   mov(%rdx),%rdx
   0x7f784416d469 <+153>:   mov%rbx,0x8(%rdx)
   0x7f784416d46d <+157>:   add$0x18,%rsp
   0x7f784416d471 <+161>:   pop%rbx
   0x7f784416d472 <+162>:   pop%rbp
   0x7f784416d473 <+163>:   retq   
   0x7f784416d474 <+164>:   nopl   0x0(%rax)
   0x7f784416d478 <+168>:   lea0xf4d1d(%rip),%rdi#
0x7f784426219c
   0x7f784416d47f <+175>:   mov%rax,0x8(%rsp)
   0x7f784416d484 <+180>:   callq  0x7f784414b980 
   0x7f784416d489 <+185>:   mov0x8(%rsp),%rax
   0x7f784416d48e <+190>:   jmp0x7f784416d445 
   0x7f784416d490 <+192>:   mov$0x209,%esi
   0x7f784416d495 <+197>:   lea0xf6184(%rip),%rdi#
0x7f7844263620
   0x7f784416d49c <+204>:   callq  0x7f784414c090
<_PyErr_BadInternalCall@plt>
   0x7f784416d4a1 <+209>:   add$0x18,%rsp
   0x7f784416d4a5 <+213>:   xor%eax,%eax
   0x7f784416d4a7 <+215>:   pop%rbx
   0x7f784416d4a8 <+216>:   pop%rbp
   0x7f784416d4a9 <+217>:   retq   
   0x7f784416d4aa <+218>:   nopw   0x0(%rax,%rax,1)
   0x7f784416d4b0 <+224>:   callq  0x7f784414be40 
   0x7f784416d4b5 <+229>:   mov%rax,%rbp
[...]

configured with
CFLAGS="-O3 -march=haswell -mtune=haswell -pipe"
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--libdir=/usr/lib64 --with-fpectl --enable-shared --enable-ipv6 --with-threads
--enable-unicode=ucs4 --infodir=${prefix}/share/info
--mandir=${prefix}/share/man --with-computed-gotos --with-dbmliborder=gdbm
--with-libc=

[Bug tree-optimization/85259] New: [8 Regression] Missing -Wstringop-overflow= since r256683

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

Bug ID: 85259
   Summary: [8 Regression] Missing -Wstringop-overflow= since
r256683
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: law at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---

Since the revision, for:

$ cat /tmp/xx11.c
#include 

char buf[6];
int main(int argc, char **argv) {
strcpy(buf,"hello ");
strcat(buf,"world!");
return 0;
}

$ gcc -O2 -Wall /tmp/xx11.c -D_FORTIFY_SOURCE=2
[no output]

Before the revision I see:
/usr/include/bits/string_fortified.h:128:10: warning: ‘__builtin___memcpy_chk’
writing 7 bytes into a region of size 6 overflows the destination
[-Wstringop-overflow=]

[Bug target/85255] [8 Regression] wrong code with -O2 -fno-tree-fre -mavx512f

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jakub Jelinek  ---
Dup.  I've added testcase from this PR into my patch, still waiting for review.

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

[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f

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

--- Comment #2 from Jakub Jelinek  ---
*** Bug 85255 has been marked as a duplicate of this bug. ***

[Bug c++/85254] boost::is_final does not work for template types

2018-04-06 Thread redi at gcc dot gnu.org

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

--- Comment #3 from Jonathan Wakely  ---
Reduced a little further:

template  struct remove_cv{ typedef T type; };

template  struct is_final
{
  static const bool value = __is_final(typename remove_cv::type);
};

struct final1 final {};
template  struct final2 final {};

static_assert( is_final::value, "" );
static_assert( is_final::value, "" );


This should compile but fails with:

is_final_test.cpp:12:16: error: static assertion failed
 static_assert( is_final::value, "" );
^

[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases

2018-04-06 Thread redi at gcc dot gnu.org

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

--- Comment #4 from Jonathan Wakely  ---
Bug 77660 also looks related

[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r253601.

[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/85257] [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r213045.  I'll have a look.

[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r242422.

[Bug c++/85254] boost::is_final does not work for template types

2018-04-06 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-06
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Reduced to less than 30kloc

namespace boost {

   template 
   struct integral_constant
   {
  static const bool value = val;
   };

   template 
   bool const integral_constant::value;

template  struct remove_cv{ typedef T type; };

template  struct is_final
  : integral_constant<__is_final(typename remove_cv::type)> {};

}

struct final1 final {};
template  struct final2 final {};

static_assert( boost::is_final::value, "" );
static_assert( boost::is_final::value, "" );

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

2018-04-06 Thread jamborm at gcc dot gnu.org

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

Bug 84947 Summary: UBSAN: 
ipcp_bits_lattice::meet_with(generic_wide_int >, 
generic_wide_int >, unsigned int) 
../../gcc/ipa-cp.c:1058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947

   What|Removed |Added

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

[Bug ipa/84947] UBSAN: ipcp_bits_lattice::meet_with(generic_wide_int<fixed_wide_int_storage<192> >, generic_wide_int<fixed_wide_int_storage<192> >, unsigned int) ../../gcc/ipa-cp.c:1058

2018-04-06 Thread jamborm at gcc dot gnu.org

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
Fixed

[Bug middle-end/85123] [8 regression] test case gcc.dg/pr63594-2.c begins failing with r254862

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Thus fixed.

[Bug middle-end/85123] [8 regression] test case gcc.dg/pr63594-2.c begins failing with r254862

2018-04-06 Thread tnfchris at gcc dot gnu.org

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

--- Comment #7 from Tamar Christina  ---
Patch has been reverted as r259169.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

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

--- Comment #22 from Jakub Jelinek  ---
Another gentle ping.  As has been mentioned, powerpcspe also lacks
gcc-8/changes.html entry.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

2018-04-06 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Target|*-*-solaris2|x86-*-solaris2
   Priority|P1  |P3

--- Comment #69 from Richard Biener  ---
So if sparc*-solaris is clean the priority can be lowered since x86-solaris is
neither primary nor secondary.  Making it P3 to not completely fall off the
radar.

[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization

2018-04-06 Thread themos.tsikas at gmail dot com

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

--- Comment #5 from Themos Tsikas  ---
If you find a gcc version that doesn't ICE, make sure you try the options "-g
-O".

[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

2018-04-06 Thread rguenth at gcc dot gnu.org

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

--- Comment #19 from Richard Biener  ---
Luckily both failure classes are immutable (via access limitations) so the
following issue with the __dual_ios_failure idea doesn't exist:

 catch (old-ABI )
   {
 modify e in-place
 throw;
   }
 ...
 catch (new-ABI )
   {
 ... expect modified content ...
   }

[Bug c++/85242] [6/7/8 Regression] ICE with invalid template parameter

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85258] New: [7/8 Regression] ICE with invalid range-based for-loop