[Bug fortran/84354] New: Replace '%qs' with %qs in fortran/decl.c

[fmarchal at perso dot be]

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

Bug ID: 84354
   Summary: Replace '%qs' with %qs in fortran/decl.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

Many occurrence of '%qs' in fortran/decl.c.

%qs is already quoted. '%qs' is doubly quoted.

[Bug tree-optimization/84353] New: [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[asolokha at gmx dot com]

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

Bug ID: 84353
   Summary: [8 Regression] [graphite] ICE in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*,
i?86-*-*

gcc-8.0.0-alpha20180211 snapshot (r257571) ICEs when compiling the following
snippet w/ -O1 -floop-parallelize-all -fno-tree-loop-im:

long long unsigned int zq;
int aj, kh, j9;

void
he (int qi)
{
  for (;;)
{
  if (zq != 0 && aj != 0)
{
  for (kh = 0; kh < 2; ++kh)
{
}

  if (zq != (long long unsigned int) qi)
qi = j9;

  while (aj != 0)
++aj;
}

  while (aj < 1)
{
}
}
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180211 -O1 -floop-parallelize-all
-fno-tree-loop-im -c hwtdekhq.c
during GIMPLE pass: graphite
hwtdekhq.c: In function 'he':
hwtdekhq.c:5:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
 he (int qi)
 ^~
0x58c8a2 translate_isl_ast_to_gimple::set_codegen_error()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:205
0x140f095 translate_isl_ast_to_gimple::set_codegen_error()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:311
0x140f095
translate_isl_ast_to_gimple::gcc_expression_from_isl_expr_int(tree_node*,
isl_ast_expr*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:308
0x140f29a translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:340
0x140f29a translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:340
0x140fe73 translate_isl_ast_to_gimple::graphite_create_new_guard(edge_def*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:873
0x1412af5 translate_isl_ast_to_gimple::translate_isl_ast_node_if(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:892
0x1412a25 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:859
0x1412f0c graphite_regenerate_ast_isl(scop*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite-isl-ast-to-gimple.c:1505
0x140d11d graphite_transform_loops()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite.c:413
0x140e69f graphite_transforms
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite.c:475
0x140e69f execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/graphite.c:552

[Bug tree-optimization/84316] missing -Wnull-dereference on a variable null array reference with LTO

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|lto |tree-optimization

--- Comment #3 from Martin Sebor  ---
It's not a bug in LTO or interacting with it.

Let me re-classify it as tree-optimization because it's a missing warning on
trivially incorrect code (comment #0).

[Bug translation/84207] Hard coded plural in gimple-fold.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00699.html

[Bug target/83760] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 13 03:07:04 2018
New Revision: 257611

URL: https://gcc.gnu.org/viewcvs?rev=257611=gcc=rev
Log:
PR target/83760
* config/sh/sh.c (find_barrier): Consider a sibling call
a barrier as well.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug c++/84348] [7/8 Regression] ICE with invalid friend declaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-13
 CC||msebor at gcc dot gnu.org
  Known to work||5.4.0, 6.4.0
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE originated with 240756 (GCC 7.0.0):

r240756 | jason | 2016-10-04 16:42:58 -0400 (Tue, 04 Oct 2016) | 23 lines

Implement P0091R2, Template argument deduction for class templates.

[Bug c++/84349] [6/7/8 Regression] ICE with auto in function cast

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE originated with r202540 in GCC 4.9.0:

r202540 | abutcher | 2013-09-12 17:04:52 -0400 (Thu, 12 Sep 2013) | 31 lines

Support using 'auto' in a function parameter list to introduce an implicit
template parameter.

Prior to that, GCC would error out with:

t.C:2:19: error: parameter declared ‘auto’
 int i = (*(int(*)(auto)) p)(0);
   ^
t.C:2:30: error: too many arguments to function
 int i = (*(int(*)(auto)) p)(0);
  ^

[Bug target/83760] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[8 Regression] [SH] ICE in  |[7/8 Regression] [SH] ICE
   |maybe_record_trace_start|in maybe_record_trace_start
   |building glibc  |building glibc
   |tst-copy_file_range.c   |tst-copy_file_range.c

--- Comment #4 from Jeffrey A. Law  ---
I know what's causing all these SH failures in maybe_record_trace_start.  Will
be committing a patch shortly.

[Bug target/78459] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #9 from Jeffrey A. Law  ---
Went back to the 2016 sources for Nov 22.  Reconfirmed, then applied my patch
to fix find_barrier in the sh backend and poof, problem solved.  Marking as a
duplicate.  Will fix the marker on 83760 to indicate it was a gcc-7 regression.

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

[Bug target/83760] [8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
*** Bug 78459 has been marked as a duplicate of this bug. ***

[Bug c++/84318] [6/7/8 Regression] attribute deprecated on function templates different than class templates

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug target/80863] [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jeffrey A. Law  ---
Actually, don't worry about it Paul.  I found the bug behind 83760 and I'm
pretty sure it's the culprit here too.

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

[Bug target/83760] [8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #2 from Jeffrey A. Law  ---
*** Bug 80863 has been marked as a duplicate of this bug. ***

[Bug target/83760] [8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #1 from Jeffrey A. Law  ---
*** Bug 83785 has been marked as a duplicate of this bug. ***

[Bug target/83785] sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Turns out that frame insns in delay slots was a red herring.  I've got a handle
on it now and I'm sure this is a dup of 83760.

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

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #5)
> I think you should do this check inside address_offset?

I don't think that is possible.  The callers of address_offset assume if
address_offset returns a non-NULL rtx, then it *IS* a constant (eg, they use
INTVAL() on its return value).  The problematical address we have here doesn't
have constant offset, so to "change" anything, we'd have to return non-NULL
(otherwise we return true from mem_operand_gpr) and that would cause issues
with INTVAL...or I'd have to guard all return values of address_offset.

I'll also note that the patch also matches the usage of mem_operand_ds_form()
which also has an early out for an unsupported case before it calls
address_offset:

bool
mem_operand_ds_form (rtx op, machine_mode mode)
{
  unsigned HOST_WIDE_INT offset;
  int extra;
  rtx addr = XEXP (op, 0);

  if (!offsettable_address_p (false, mode, addr))
return false;

  op = address_offset (addr);
  if (op == NULL_RTX)
return true;

...

[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
(In reply to igor.v.tsimbalist from comment #4)
> Created attachment 43400 [details]
> patch

2 questions:

1. Should 32-bit multilib target libraries compiled on 64-bit host
enable CET?
2. Should 64-bit multilib target libraries compiled with 32-bit compiler
enable CET?

[Bug c++/84352] noreturn function previously declared without the attribute accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Known to fail||5.3.0, 6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
The bug has always existed and is not a regression.

[Bug c++/84352] New: noreturn function previously declared without the attribute accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 84352
   Summary: noreturn function previously declared without the
attribute accepted
   Product: gcc
   Version: 8.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 C++ standard specifies that "The first declaration of a function shall
specify the noreturn attribute if any declaration of that function specifies
the noreturn attribute."

GCC silently accepts programs thaat violate this rule and emits what could be
viewed by the author of the called function as buggy code.  Other compilers,
including Clang, Intel ICC, and MSVC all reject the test case as expected.

(GCC does issue a -Wsuggest-attribute=noreturn warning for the definition of
g().)

$ cat t.C && gcc -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.C
int f ();// not declared noreturn

int g ()
{
  return f () + f ();// f() called just once
}

[[noreturn]] int f ();   // invalid, first f is not noreturn


;; Function g (_Z1gv, funcdef_no=0, decl_uid=2353, cgraph_uid=0,
symbol_order=0)

g ()
{
  int D.2356;
  int _1;
  int _2;

   :
  f ();

}

[Bug other/84351] Provide dependency information also when linking

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to jpakkane from comment #0)
> If linking supported generating dependency files like -M does for source
> compilations, this would not be a problem and

... and?

The main problem is that GCC doesn't do the linking, it just calls the linker.
GCC is not involved in resolving -lmydep to a file on disk, that's the linker.

So the feature would have to be added to the linker, not to GCC.

[Bug other/84351] New: Provide dependency information also when linking

[jpakkane at gmail dot com]

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

Bug ID: 84351
   Summary: Provide dependency information also when linking
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpakkane at gmail dot com
  Target Milestone: ---

The -M flag and its like is very useful for reliable dependencies. It would be
great if the same would work also when linking.

The use case is the following. Suppose you build a project with a dependency
that comes in via pkg-config. The eventual link line looks like this:

gcc -o final_exe source.o -L/path/to/my/place -L/path/to/somewhere/else -lmydep

It is very difficult to tell where the dependency library will be picked up
from. If the user updates any library by doing a "make/ninja install" from the
dependency file, then it is hard to know that the dependency libraries have
changed and thus require a rebuild. (usually doing an install updates headers,
which _do_ trigger a rebuild but some systems only overwrite installed files if
they have changed so looking only at header files is not reliable).

If linking supported generating dependency files like -M does for source
compilations, this would not be a problem and

[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
This should be fixed by Marek's patch for 83692.

[Bug c++/67054] Constructor inheritance with non-default constructible members

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Leonid Koppel from comment #8)
> Fixed in 7.2.

Indeed, thanks.

[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84341] [6/7 Regression] ICE with #pragma omp atomic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |6.5
Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |#pragma omp atomic  |#pragma omp atomic

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

[Bug c++/84341] [6/7/8 Regression] ICE with #pragma omp atomic

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 12 22:25:41 2018
New Revision: 257607

URL: https://gcc.gnu.org/viewcvs?rev=257607=gcc=rev
Log:
PR c++/84341
* parser.c (cp_parser_binary_expression): Use build_min instead of
build2_loc to build the no_toplevel_fold_p toplevel binary expression.

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

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr84341.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
I think you should do this check inside address_offset?

[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default

[igor.v.tsimbalist at intel dot com]

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

--- Comment #5 from igor.v.tsimbalist at intel dot com ---
Beside the patch configure files have to be regenerated.

[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default

[igor.v.tsimbalist at intel dot com]

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

--- Comment #4 from igor.v.tsimbalist at intel dot com ---
Created attachment 43400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43400=edit
patch

[Bug c++/33911] attribute deprecated vs. templates

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #20 from Martin Sebor  ---
(In reply to Jonathan Wakely from comment #16)

Although Clang doesn't, warning for uses of a deprecated primary seems
correct/useful to me because there's no way to define a specialization of the
primary that's not deprecated.  In your test case, there is no specialization
of  b() that would not use some specialization of the primary class template,
and since every specialization is a use of the primary, that would not be
subject to its deprecated attribute.  (It seems analogous to warning for an
unused constexpr function that can never be used in a core constant
expression.)

I've compiled all the test cases in this bug and, modulo bug(s) that are
already being tracked elsewhere, they all result in the expected warnings. 
With that I'm going to resolve this bug as fixed.

If you feel it's important to only warn for code that's instantiated, rather
than reopening this bug I suggest opening a separate bug just for that.

[Bug c++/84338] [8 Regression] sizeof...() returns always 1 in variadic lambda inside a template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/33911] attribute deprecated vs. templates

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84347

--- Comment #19 from Martin Sebor  ---
(In reply to Elias Pipping from comment #18)

In my view (while working on some fixes in this area), deprecating a primary
template is a request to diagnose all uses of the template-id, including
declarations of partial specializations and explicit specializations.  The way
to achieve the effect you are looking for is to

1) declare the primary template without deprecated:

  template struct enable_if;

2) define one partial specialization deprecated:

  template struct [[deprecated]] enable_if {};

3) define the complement of the first partial specialization that's not
deprecated:

  template struct enable_if { };

This should cause uses of the first (deprecated) partial specialization to be
diagnosed.  This is also what Clang does.  GCC doesn't diagnose it because of
bug 84347 but will once the bug is fixed.

[Bug c++/84347] attribute deprecated on a class partial specialization has no effect

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Both Clang and Intel ICC behave as expected:

t.C(3): warning #1478: class "A" (declared at line 1) was declared
deprecated
  A aci; // -Wdeprecated-declarations (good)
 ^
t.C(11): warning #1478: variable "V [with T=int *]" (declared at line 5) was
declared deprecated
(void)V;// -Wdeprecated-declarations (good)
  ^
t.C(18): warning #1478: class "B" (declared at line 14) was declared
deprecated
  B bpi;// missing -Wdeprecated-declarations
  ^
Compiler returned: 0

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
This actually seems to be a constraint problem caused by mem_operand_gpr()
which implements the "Y" constraint (ie, mem's ok for GPR load/stores) allowing
altivec type addresses that contain the 'and' like we see in the ICE above. 
The patch below fixes the ICE and I'm going to bootstrap and regtest it.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 257606)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -8220,6 +8220,12 @@
   int extra;
   rtx addr = XEXP (op, 0);

+  /* Don't allow altivec type addresses like (mem: (and: ...)).
+ See PR target/84279.  */
+
+  if (GET_CODE (addr) == AND)
+return false;
+
   op = address_offset (addr);
   if (op == NULL_RTX)
 return true;

[Bug sanitizer/84340] [8 regression] g++.dg/asan/use-after-scope-types-1.C (and others) fails after r257585

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #1 from Jakub Jelinek  ---
It fails on x86_64-linux and i686-linux as well.

[Bug target/80863] [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Jeffrey A. Law from comment #4)
> We would need the cpp output to thoroughly analyze this.  You can get the
> cpp output using "-save-temps" on the comment line and passing along the
> generated .ii file.
> 
> This may be fixed or it may have just gone latent.  It's hard to tell
> without having that .ii file.

So, gcc-8 (r257435) itself builds fine [1] but the latest gcc-snapshot we have
in Debian unstable still fails [2], but that version might be older than the
gcc-8 package in unstable.

I'll watch out for the next gcc-snapshot upload to Debian unstable and see if
the problem still persists. As you said, it might have already been fixed.

In the meantime, I willl try to generate the preprocessed source and attach it
to the bug report.

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-8=sh4=8-20180207-2=1518231517=0
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=sh4=20180124-1=1517056220=0

[Bug target/63435] Bad code with weak vs localalias on AIX

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Eric Gallager  ---
So, if this is only a problem in 4.9 and earlier, I'm assuming I can close this
as FIXED, since GCC 5 branch is now closed

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Let's keep this open to see if any platform develops a regression
with the fix.

[Bug target/80863] [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-02-12
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #4 from Jeffrey A. Law  ---
We would need the cpp output to thoroughly analyze this.  You can get the cpp
output using "-save-temps" on the comment line and passing along the generated
.ii file.

This may be fixed or it may have just gone latent.  It's hard to tell without
having that .ii file.

[Bug libgcc/68126] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2239 while compiling under platform mips64el

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #3 from Jeffrey A. Law  ---
Agree with Steve on this.  It's a bug in the host compiler.  We're not fixing
bugs in gcc-4.4 anymore.

Given what we know about this class of problems, -fno-delayed-branch could help
here as a workaround.  Or -fno-schedule-insns -fno-schedule-insns2.

[Bug c++/84350] New: [7/8 Regression] ICE with new and auto

[reichelt at gcc dot gnu.org]

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

Bug ID: 84350
   Summary: [7/8 Regression] ICE with new and auto
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: 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 void foo(T... t)
{
  new auto(t...);
}

void bar()
{
  foo();
}
===

bug.cc: In instantiation of 'void foo(T ...) [with T = {}]':
bug.cc:8:7:   required from here
bug.cc:3:3: internal compiler error: Segmentation fault
   new auto(t...);
   ^~
0xeb087f crash_signal
../../gcc/gcc/toplev.c:325
0x95f158 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x95f158 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:25993
0x960805 do_auto_deduction(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/pt.c:25953
0x8d1104 build_new(vec**, tree_node*, tree_node*,
vec**, int, int)
../../gcc/gcc/cp/init.c:3596
0x95bf0c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17582
0x968d99 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17114
0x968d99 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16852
0x968620 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16073
0x965eb1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16336
0x965148 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16044
0x965148 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23398
0x98f79b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23514
0x8b19fb c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4715
Please submit a full bug report, [etc.]

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Feb 12 20:51:16 2018
New Revision: 257605

URL: https://gcc.gnu.org/viewcvs?rev=257605=gcc=rev
Log:
2018-02-12  Thomas Koenig  

PR fortran/68746
* gfortran.dg/read_dir.f90: Re-add dg-do run.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/read_dir.f90

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Feb 12 20:48:32 2018
New Revision: 257604

URL: https://gcc.gnu.org/viewcvs?rev=257604=gcc=rev
Log:
2018-02-12  Thomas Koenig  

PR fortran/68746
* gfortran.dg/read_dir.f90: Remove xfails. Also allow iostat
of zero for read.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/read_dir.f90

[Bug c++/67054] Constructor inheritance with non-default constructible members

[lkoppel at uwaterloo dot ca]

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

--- Comment #8 from Leonid Koppel  ---
Fixed in 7.2.

[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Gallager  ---
(In reply to Hale Wang from comment #8)
> I have submitted a patch to community for further discussion. Refer to:
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02238.html.

Does this patch still apply against trunk?

[Bug target/63908] [e500v2] "float_bessel"case failed on e500v2 platforms

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org,
   ||hainque at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Eric Gallager  ---
(In reply to leimaohui from comment #9)
> (In reply to jos...@codesourcery.com from comment #8)
> > Olivier Hainque referred to having a 4.9 version of his patch, I suggest 
> > you ask him.
> 
> Will these patches be backported to gcc 4.9.3 ?

No, the gcc 4.9 branch is closed.

[Bug c++/84349] New: [6/7/8 Regression] ICE with auto in function cast

[reichelt at gcc dot gnu.org]

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

Bug ID: 84349
   Summary: [6/7/8 Regression] ICE with auto in function cast
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: 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 4.9.0:


void* p;
int i = (*(int(*)(auto)) p)(0);


bug.cc:2:30: internal compiler error: Segmentation fault
 int i = (*(int(*)(auto)) p)(0);
  ^
0xeb087f crash_signal
../../gcc/gcc/toplev.c:325
0x8d81fb vec::last()
../../gcc/gcc/vec.h:837
0x8d81fb finish_lambda_scope()
../../gcc/gcc/cp/lambda.c:1357
0x934afd cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19650
0x93bac8 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13038
0x93c8d8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12863
0x940832 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12761
0x940c41 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12637
0x940f34 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x940f34 c_parse_file()
../../gcc/gcc/cp/parser.c:38857
0xa3f566 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #31 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/80174] [meta-bug] Fortran lto issues

[tkoenig at gcc dot gnu.org]

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

Bug 68560 Summary: [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now 
fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560

   What|Removed |Added

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

[Bug fortran/68649] [6/7/8 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[tkoenig at gcc dot gnu.org]

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

Bug 68560 Summary: [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now 
fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560

   What|Removed |Added

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

[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[tkoenig at gcc dot gnu.org]

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

--- Comment #30 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Feb 12 20:27:11 2018
New Revision: 257603

URL: https://gcc.gnu.org/viewcvs?rev=257603=gcc=rev
Log:
2018-02-12  Thomas Koenig  

PR fortran/68560
* trans-intrinsic.c (gfc_conv_intrinsic_shape): New function.
(gfc_conv_intrinsic_function): Call it.

2018-02-12  Thomas Koenig  

PR fortran/68560
* gfortran.dg/shape_9.f90: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/shape_9.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/84348] New: [7/8 Regression] ICE with invalid friend declaration

[reichelt at gcc dot gnu.org]

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

Bug ID: 84348
   Summary: [7/8 Regression] ICE with invalid friend declaration
   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
  Target Milestone: ---

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


template struct A
{
  friend auto foo;
};


bug.cc:3:15: error: 'foo' is neither function nor member function; cannot be
declared friend
   friend auto foo;
   ^~~
bug.cc:3:15: internal compiler error: in cp_finish_decl, at cp/decl.c:6806
0x6000c1 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6806
0x8b0037 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:1002
0x9260ee cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:23871
0x92707a cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:23345
0x92707a cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22487
0x9290d9 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22739
0x9290d9 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16745
0x936266 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13606
0x93a9a5 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27051
0x93ad2c cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26743
0x93b5ec cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26980
0x93b5ec cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:26999
0x940959 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12710
0x940c41 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12637
0x940f34 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x940f34 c_parse_file()
../../gcc/gcc/cp/parser.c:38857
0xa3f566 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Feb 12 20:13:30 2018
New Revision: 257602

URL: https://gcc.gnu.org/viewcvs?rev=257602=gcc=rev
Log:
2018-02-12  Thomas Koenig  

PR fortran/68560
* gfortran.dg/shape_9.f90: New test.

2018-02-12  Thomas Koenig  

PR fortran/68560
* gfortran.dg/shape_9.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/shape_9.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/84347] attribute deprecated on a class partial specialization has no effect

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
It doesn't look like G++ has ever diagnosed theses uses of attribute deprecated
so unlike bug 84318 this is not a regression.

[Bug c++/84347] New: attribute deprecated on a class partial specialization has no effect

[msebor at gcc dot gnu.org]

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

Bug ID: 84347
   Summary: attribute deprecated on a class partial specialization
has no effect
   Product: gcc
   Version: 8.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: ---

G++ diagnoses uses of a specialization of a primary class or variable template
declared deprecated but it fails to diagnose uses of a partial specialization
of a class template declared deprecated.

$ cat t.C && gcc -S -Wall -Wextra t.C
template  struct __attribute__ ((deprecated)) A { };

A aci; // -Wdeprecated-declarations (good)

template  int V;
template  int __attribute__ ((deprecated)) V;

void f ()
{
  (void)V; // no warning (good)
  (void)V;// -Wdeprecated-declarations (good)
}

template  struct B { };
template  struct __attribute__ ((deprecated)) B { };

B bi;  // no warning (good)
B bpi;// missing -Wdeprecated-declarations
t.C:3:1: warning: ‘template struct A’ is deprecated
[-Wdeprecated-declarations]
 A aci; // -Wdeprecated-declarations (good)
 ^
t.C:1:56: note: declared here
 template  struct __attribute__ ((deprecated)) A { };
^
t.C: In function ‘void f()’:
t.C:11:9: warning: ‘V’ is deprecated [-Wdeprecated-declarations]
   (void)V;// -Wdeprecated-declarations (good)
 ^~~
t.C:6:53: note: declared here
 template  int __attribute__ ((deprecated)) V;
 ^

[Bug c++/84341] [6/7/8 Regression] ICE with #pragma omp atomic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/84334] [8 Regression] Stack overflow with -Ofast -frounding-math

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
With -frounding-math, CCP produces things like:

  _465 = 9.99974752427078783512115478515625e-7 +
4.99873689375817775726318359375e-6;

Guessing:
When we have cst1+cst2+cst3, the transformation gives cst1+(cst2+cst3), where
cst2+cst3 does not simplify because of -frounding-math, so it is transformed
again to cst2+(cst1+cst3) or similar, and we cycle. We should not transform
when cst2+cst3 will not simplify (I think there have been similar issues
recently).

I can't test or debug anything for a couple weeks, so I may be completely
wrong.

-Ofast -frounding-math makes little sense to me.

[Bug go/84215] Random results in go/libgo tests

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
I just committed a patch that may affect some of these failures.  Please let me
know if you notice any change.  Thanks.

[Bug go/84215] Random results in go/libgo tests

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Feb 12 18:50:16 2018
New Revision: 257599

URL: https://gcc.gnu.org/viewcvs?rev=257599=gcc=rev
Log:
PR go/84215
runtime, sync/atomic: use write barrier for atomic pointer functions

This copies atomic_pointer.go from 1.10rc2.  It was omitted during the
transition of the runtime from C to Go, and I forgot about it.

This may help with https://gcc.gnu.org/PR84215.

Reviewed-on: https://go-review.googlesource.com/93197

Added:
trunk/libgo/go/runtime/atomic_pointer.go
Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/runtime/stubs.go
trunk/libgo/go/sync/atomic/atomic.c

[Bug fortran/84346] Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Priority|P3  |P4

[Bug fortran/84346] New: Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

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

Bug ID: 84346
   Summary: Statement functions should not accept keywords
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

A statement function always has an implicit interface.
A function with an implicit interface should not accept
keywords.

program foo
   real :: x, y
   integer :: i, j
   fcn(x,i) = x * i
   y = 42.
   j = 2
   print *, fcn(i=j, x=y)  ! This violates a constraint.
end program foo

[Bug c++/84338] [8 Regression] sizeof...() returns always 1 in variadic lambda inside a template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-12
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from kargl at gcc dot gnu.org ---
The patch from comment #2 has been applied to the
6-branch, 7-branch, and trunk.

[Bug fortran/54223] Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks fo rthe bug report.

[Bug fortran/84276] Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #18 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[kargl at gcc dot gnu.org]

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

--- Comment #14 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Feb 12 18:26:44 2018
New Revision: 257597

URL: https://gcc.gnu.org/viewcvs?rev=257597=gcc=rev
Log:
2018-02-12  Francois-Xavier Coudert  

PR fortran/35299
ChangeLog for r257566
* gfortran.dg/statement_function_3.f: New test.

2018-02-12  Francois-Xavier Coudert  

PR fortran/35299
ChangeLog for r257566
* resolve.c (resolve_formal_arglist): Update error message.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_3.f
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/84276] Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

--- Comment #17 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Feb 12 18:25:41 2018
New Revision: 257596

URL: https://gcc.gnu.org/viewcvs?rev=257596=gcc=rev
Log:
2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
in_statement_function.

2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_2.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/54223] Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Feb 12 18:25:41 2018
New Revision: 257596

URL: https://gcc.gnu.org/viewcvs?rev=257596=gcc=rev
Log:
2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
in_statement_function.

2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_2.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/84345] New: [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[asolokha at gmx dot com]

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

Bug ID: 84345
   Summary: [8 Regression] ICE: qsort checking failed (error:
qsort comparator non-negative on sorted output: 1)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-8.0.0-alpha20180211 snapshot (r257571) ICEs when compiling the following
snippet w/ -O2 -fsched2-use-superblocks -ftree-parallelize-loops=2
-fno-sched-critical-path-heuristic -fno-tree-dce --param
tracer-min-branch-probability=49:

int zq, h9;

void
m0 (unsigned long int sc)
{
  zq = 0;

  if (sc == 0 && h9 == 0)
for (sc = 0; sc < 200; ++sc)
  {
  }
}

% gcc-8.0.0-alpha20180211 -O2 -fsched2-use-superblocks
-ftree-parallelize-loops=2 -fno-sched-critical-path-heuristic -fno-tree-dce
--param tracer-min-branch-probability=49 -c nx05nihn.c
nx05nihn.c: In function 'm0':
nx05nihn.c:12:1: error: qsort comparator non-negative on sorted output: 1
 }
 ^
during RTL pass: sched2
nx05nihn.c:12:1: internal compiler error: qsort checking failed
0x7428bc qsort_chk_error
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/vec.c:201
0x742923 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/vec.c:253
0x1479810 ready_sort_real
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/haifa-sched.c:3086
0x14818e4 schedule_block(basic_block_def**, void*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/haifa-sched.c:6674
0x150681b schedule_ebb(rtx_insn*, rtx_insn*, bool)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-ebb.c:537
0x1506ee4 schedule_ebbs()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-ebb.c:657
0xc4c294 rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-rgn.c:3735
0xc4c294 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-rgn.c:3873

[Bug c++/84344] New: [concepts] ICE with invalid use of auto

[reichelt at gcc dot gnu.org]

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

Bug ID: 84344
   Summary: [concepts] ICE with invalid use of auto
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: 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 triggers ICE since GCC 6.1.0
if compiled with "-fconcepts":

=
template void foo() {}

template void foo();
=

bug.cc: In instantiation of 'void foo() [with  =
auto]':
bug.cc:3:25:   required from here
bug.cc:1:32: internal compiler error: Segmentation fault
 template void foo() {}
^
0xeb087f crash_signal
../../gcc/gcc/toplev.c:325
0x117dff4 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3131
0x117dff4 ultimate_transparent_alias_target
../../gcc/gcc/varasm.c:1285
0x117f21e notice_global_symbol(tree_node*)
../../gcc/gcc/varasm.c:1670
0xae482a cgraph_node::finalize_function(tree_node*, bool)
../../gcc/gcc/cgraphunit.c:452
0x9a556f expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:4242
0x96522d instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23419
0x98f79b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23514
0x8b19fb c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4715
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 target/84336] [8 Regression] ICE in extract_insn, at recog.c:2304

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Feb 12 18:08:02 2018
New Revision: 257594

URL: https://gcc.gnu.org/viewcvs?rev=257594=gcc=rev
Log:
2018-02-12  Francois-Xavier Coudert  

PR fortran/35299
ChangeLog for r257566
* gfortran.dg/statement_function_3.f: New test.

2018-02-12  Francois-Xavier Coudert  

PR fortran/35299
ChangeLog for r257566
* resolve.c (resolve_formal_arglist): Update error message.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_3.f
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/54223] Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Feb 12 18:04:33 2018
New Revision: 257593

URL: https://gcc.gnu.org/viewcvs?rev=257593=gcc=rev
Log:
2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
in_statement_function.

2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_2.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_2.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/interface.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/84276] Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

--- Comment #16 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Feb 12 18:04:33 2018
New Revision: 257593

URL: https://gcc.gnu.org/viewcvs?rev=257593=gcc=rev
Log:
2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
in_statement_function.

2018-02-12  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_2.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_2.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/interface.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/84010] [sparc64] Problematic TLS code generation

[jrtc27 at jrtc27 dot com]

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

--- Comment #7 from James Clarke  ---
Eric, does the patch look fine to you? Do you want me to submit it to the
mailing list, or is here ok?

[Bug debug/84342] [8 Regression] Location views breaks cross builds of arm including gnueabihf

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, wrong-debug
   Target Milestone|--- |8.0
   Severity|normal  |critical

[Bug target/84343] Behavior of ARM register constraint 't' seems to be inconsistent with documentation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
 Target||arm
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-12
  Component|inline-asm  |target
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
>VFP floating-point registers s0-s31. Used for 32 bit values.

I think the "used for 32 bit values" is still correct as it can include odd
register number which cannot be used for d registers or q registers.

But I agree the documentation needs to be better worded here.

Confirmed as a target documentation issue.

[Bug fortran/84313] [F08] reject procedure pointers in COMMON blocks

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-12
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
This should do it:


Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 257589)
+++ gcc/fortran/symbol.c(working copy)
@@ -809,7 +809,7 @@ check_conflict (symbol_attribute *attr, const char
conf2 (threadprivate);
}

-  if (!attr->proc_pointer)
+  if (!attr->proc_pointer || (gfc_option.allow_std & GFC_STD_F2008))
conf2 (in_common);

   conf2 (omp_declare_target_link);

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=63893

--- Comment #19 from Eric Gallager  ---
bug 63893 is related

[Bug target/84336] [8 Regression] ICE in extract_insn, at recog.c:2304

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug inline-asm/84343] New: Behavior of ARM register constraint 't' seems to be inconsistent with documentation

[pablo.barrio at arm dot com]

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

Bug ID: 84343
   Summary: Behavior of ARM register constraint 't' seems to be
inconsistent with documentation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pablo.barrio at arm dot com
  Target Milestone: ---

Not sure if I am misunderstanding something here. The following code with
inline assembly:

typedef double Bar_t;
Bar_t bar(Bar_t a, Bar_t b) {
  Bar_t res;
__asm__ ("vadd.F32 %0, %1, %2": "=t" (res) : "t" (a), "t" (b));
return res;
}

generates the following assembly:

vadd.F32 s0, s0, s2

In order to make it use double registers, I am using operand identifier 'P' in
%0, %1, %2. Then, the instruction gets allocated to d0 & d1 instead of s0 & s2.
If I use a 128-bit vector datatype, I can also make the code select q registers
by using operand modifier 'q'.

The GNU documentation states the following:

ARM family—config/arm/constraints.md
...
t
VFP floating-point registers s0-s31. Used for 32 bit values.

First, should the "Used for 32 bit values" be dropped, since it can also be
used for 64-bit values (and for vectors with lanes of different values)?

Second, the fact that it mentions s0-s31 misled me a bit and I initially
thought that it *only* allowed 32-bit values. Would it be possible to mention
that this constraint is really selecting the lower vector registers, i.e.
s0-s31, d0-d15 or q0-q7, which I believe is what is really happening? I can't
think of a proper way to write this though.

I haven't added a preprocessed file here since I don't think there is a bug in
the source code.

Many thanks

[Bug c++/84318] [6/7/8 Regression] attribute deprecated on function templates different than class templates

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Testing a patch.

[Bug debug/84342] [8 Regression] Location views breaks cross builds of arm including gnueabihf

[tnfchris at gcc dot gnu.org]

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

--- Comment #1 from Tamar Christina  ---
native builds do seem to work, it's all the cross builds that seem to be
broken.

[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Ilya Palachev from comment #5)
> Created attachment 33725 [details]
> Patch that fixes the ICE (2nd version)
> 
> The 2nd version of patch was posted at
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01364.html

Does this still apply against current trunk?

[Bug debug/84342] [8 Regression] Location views breaks cross and native builds of arm

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|Location views breaks cross |[8 Regression] Location
   |and native builds of arm|views breaks cross and
   ||native builds of arm

[Bug debug/84342] New: Location views breaks cross and native builds of arm

[tnfchris at gcc dot gnu.org]

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

Bug ID: 84342
   Summary: Location views breaks cross and native builds of arm
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
Target: arm*-*-*

Commit r257510 breaks all cross and bootstrap builds of arm.

/tmp/ccf8XE3m.s: Assembler messages:
/tmp/ccf8XE3m.s:813: Error: view number mismatch

make[2]: ***
[/arm-none-linux-gnueabi/build/build-arm-none-linux-gnueabi/obj/glibc/iconv/gconv_conf.os]
Error 1

This breaks compiling with `-g` when compiling newlib or glibc.

[Bug c++/84341] New: [6/7/8 Regression] ICE with #pragma omp atomic

[reichelt at gcc dot gnu.org]

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

Bug ID: 84341
   Summary: [6/7/8 Regression] ICE with #pragma omp atomic
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, openmp
  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 (compiled with "-fopenmp")
triggers an ICE since GCC 4.9.0:


void foo(int i)
{
  #pragma omp atomic
i =  + 1;
}


bug.cc: In function 'void foo(int)':
bug.cc:4:14: internal compiler error: in build2, at tree.c:4682
 i =  + 1;
  ^
0x78d6b5 build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/gcc/tree.c:4681
0x911e31 build2_loc
../../gcc/gcc/tree.h:4112
0x911e31 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9333
0x932614 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9372
0x932614 cp_parser_omp_atomic
../../gcc/gcc/cp/parser.c:34277
0x9186ba cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:38030
0x919a97 cp_parser_pragma
../../gcc/gcc/cp/parser.c:38704
0x91c05c cp_parser_statement
../../gcc/gcc/cp/parser.c:10877
0x91cc30 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11255
0x91cd07 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11209
0x933460 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21747
0x933460 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21784
0x933d10 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26685
0x934a27 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26601
0x934a27 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19473
0x93bac8 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13038
0x93c8d8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12863
0x940832 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12761
0x940c41 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12637
0x940f34 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
Please submit a full bug report, [etc.]

[Bug testsuite/84094] several correctness issues in gfortran.dg

[janus at gcc dot gnu.org]

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

Bug 84273 Summary: [F03] Reject allocatable passed-object dummy argument 
(proc_ptr_47.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84273

   What|Removed |Added

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

[Bug fortran/84273] [F03] Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0
Summary|Reject allocatable  |[F03] Reject allocatable
   |passed-object dummy |passed-object dummy
   |argument (proc_ptr_47.f90)  |argument (proc_ptr_47.f90)

--- Comment #3 from janus at gcc dot gnu.org ---
Fixed with r257590. Closing.

[Bug fortran/84273] Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Feb 12 17:11:58 2018
New Revision: 257590

URL: https://gcc.gnu.org/viewcvs?rev=257590=gcc=rev
Log:
2018-02-12  Janus Weil  

PR fortran/84273
* resolve.c (resolve_component): Fix checks of passed argument in
procedure-pointer components.


2018-02-12  Janus Weil  

PR fortran/84273
* gfortran.dg/proc_ptr_47.f90: Fix invalid test case.
* gfortran.dg/proc_ptr_comp_pass_4.f90: Fix and extend test case.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_ptr_47.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_4.f90

[Bug sanitizer/84340] New: [8 regression] g++.dg/asan/use-after-scope-types-1.C (and others) fails after r257585

[seurer at gcc dot gnu.org]

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

Bug ID: 84340
   Summary: [8 regression] g++.dg/asan/use-after-scope-types-1.C
(and others) fails after r257585
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I saw this on powerpc64 both le and be

FAIL: g++.dg/asan/use-after-scope-types-1.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-1.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-2.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-3.C   -Os  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O1  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O2  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -O3 -g  execution test
FAIL: g++.dg/asan/use-after-scope-types-5.C   -Os  execution test

The failures all appear to be something like this:

=
==53100==ERROR: AddressSanitizer: stack-use-after-scope on address
0x3fffe6d3c880 at pc 0x1000103c bp 0x3fffe6d3c7c0 sp 0x3fffe6d3c7e0
WRITE of size 1 at 0x3fffe6d3c880 thread T0
#0 0x10001038 in Ptr::Access()
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/asan/use-after-scope-types.h:8
#1 0x1e6c in void test()
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/asan/use-after-scope-types.h:29
#2 0x1c74 in main
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/asan/use-after-scope-types-1.C:10
#3 0x3fffb38d3098  (/lib/powerpc64le-linux-gnu/libc.so.6+0x23098)

Address 0x3fffe6d3c880 is located in stack of thread T0 at offset 32 in frame
#0 0x1d60 in void test()
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/asan/use-after-scope-types.h:22

  This frame has 2 object(s):
[32, 33) 'x' <== Memory access at offset 32 is inside this variable
[96, 104) 'ptr'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/asan/use-after-scope-types.h:8
in Ptr::Access()
Shadow bytes around the buggy address:
  0x09fffcda78c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda78d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda78e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda78f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda7900: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x09fffcda7910:[f8]f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
  0x09fffcda7920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda7930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda7940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda7950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x09fffcda7960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone: 

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to xyzdr4gon333 from comment #3)
> (In reply to Paolo Carlini from comment #1)
> > This is already fixed in trunk. I'm adding a testcase and closing the bug.
> 
> What do you mean with trunk? 

[...snip..]

> 
> Ah okay this version does work:
> 
> g++-8 (Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk
> revision 257435]

That's trunk.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|7.4 |6.5

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org
   Target Milestone|--- |7.4

[Bug c++/84333] [6/7/8 Regression] ICE with ternary operator in template function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-12
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Seems doable.

[Bug target/84335] ICE on invalid code in copy_to_mode_reg, at explow.c:612

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/84338] [8 Regression] sizeof...() returns always 1 in variadic lambda inside a template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||rejects-valid, wrong-code
   Target Milestone|--- |8.0

[Bug tree-optimization/84339] [8 Regression] Wrong-code with optimizing strlen

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1

[Bug target/84336] [8 Regression] ICE in extract_insn, at recog.c:2304

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*
Version|unknown |8.0.1
   Target Milestone|--- |8.0

[Bug c++/84333] [6/7/8 Regression] ICE with ternary operator in template function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5