[Bug c++/79827] genautomata segmentation fault on NI-RT Linux

[pkrizek at tes dot cz]

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

--- Comment #8 from Petr Křížek  ---
I raised the stack to 32768 KiB.
Then the genautomata passed without segfault.

Also other GCC segfaults disappeared.

This is a bit non-intuitive behavior.

Maybe we should introduce a warning
telling the user that the stack is suspiciously small?

[Bug c++/79827] genautomata segmentation fault on NI-RT Linux

[pkrizek at tes dot cz]

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

Petr Křížek  changed:

   What|Removed |Added

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

[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()

[m.ostapenko at samsung dot com]

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

--- Comment #4 from Maxim Ostapenko  ---
(In reply to Michael Thayer from comment #3)
> Seems my mistake.  I think the ASAN library was still getting loaded
> dynamically.  Now I have the following problem, which I think means that
> code (constructors?) getting called before ASAN is initialised is getting
> hold of memory map areas which ASAN is hard-coded to use.  So probably no
> static ASAN for me.
> 
> ==10420==Shadow memory range interleaves with an existing memory mapping.
> ASan cannot proceed correctly. ABORTING.
> ==10420==ASan shadow was supposed to be located in the
> [0x7fff7000-0x10007fff7fff] range.
> ==10420==Process memory map follows:
>   0x7fff7000-0x8fff7000   
>   0x8fff7000-0x02008fff7000   
>   0x02008fff7000-0x10007fff8000   
> [...]

This usually happens when your executable isn't linked with libasan but some
shared library is. Check that your test binary is properly linked with libasan.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[tkoenig at gcc dot gnu.org]

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

--- Comment #30 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Mar 15 07:45:39 2017
New Revision: 246153

URL: https://gcc.gnu.org/viewcvs?rev=246153&root=gcc&view=rev
Log:
2017-03-15  Thomas Koenig  

PR libfortran/79956
* libgfortran.h (GFC_ASSERT):  New macro.
* m4/reshape.m4 (reshape_'rtype_ccode`):  Use GFC_ASSERT
to specify that sdim > 0 and rdim > 0.
* intrinsic/reshape_generic.c (reshape_internal):  Likweise.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_r8.c: Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/reshape_c10.c
trunk/libgfortran/generated/reshape_c16.c
trunk/libgfortran/generated/reshape_c4.c
trunk/libgfortran/generated/reshape_c8.c
trunk/libgfortran/generated/reshape_i16.c
trunk/libgfortran/generated/reshape_i4.c
trunk/libgfortran/generated/reshape_i8.c
trunk/libgfortran/generated/reshape_r10.c
trunk/libgfortran/generated/reshape_r16.c
trunk/libgfortran/generated/reshape_r4.c
trunk/libgfortran/generated/reshape_r8.c
trunk/libgfortran/intrinsics/reshape_generic.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/m4/reshape.m4

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #31 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug c/80036] Source line not printed for diagnostic if expanded from a macro

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
(In reply to Manuel López-Ibáñez from comment #2)
> Variable-uses don't have locations in GCC (yet, hopefully some day when the
> FEs get replaced by Clang)

I really don't know why you think we plan to replace our FEs with clang.

[Bug c++/80045] New: [cilkplus] The destruction of the temporary variable is not in the child

[ryxi at stu dot xidian.edu.cn]

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

Bug ID: 80045
   Summary: [cilkplus] The destruction of the temporary variable
is not in the child
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryxi at stu dot xidian.edu.cn
  Target Milestone: ---

The cilkplus spec

said:

[3.6] bullet [4]:
> Any unnamed temporary variables created prior to the spawn point are
> not destroyed until after the spawn point (i.e., their destructors are
> invoked in the child).

However currently GCC produces code that destroy the temporary in the
parent. Then following code fails with random SIGSEGVs:

~~~
#include 
#include 

void walk(std::vector v, unsigned size) {
  if (v.size() < size)
for (int i=0; i<8; i++) {
  std::vector vnew(v);
  vnew.push_back(i);
  cilk_spawn walk(vnew, size);
}
}

int main(int argc, char **argv) {
  std::vector v{};
  walk(v, 5);
}
~~~

While the thread sanitizer reports many data races about destroying
temporaries.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[tkoenig at gcc dot gnu.org]

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

--- Comment #32 from Thomas Koenig  ---
(In reply to Markus Trippelsdorf from comment #31)
> Fixed. Thanks.

Is the issue with the execute_command_line_* functions
also resolved?  The code could quite obviously be simplified to

void
execute_command_line_i4 (const char *command, GFC_LOGICAL_4 *wait,
 GFC_INTEGER_4 *exitstat, GFC_INTEGER_4 *cmdstat,
 char *cmdmsg, gfc_charlen_type command_len,
 gfc_charlen_type cmdmsg_len)
{
  bool w = wait ? *wait : true;
  int estat, cstat;

  if (exitstat)
estat = *exitstat;

  execute_command_line (command, w, &estat, cmdstat ? &cstat : NULL,
cmdmsg, command_len, cmdmsg_len);

  if (exitstat)
*exitstat = estat;
  if (cmdstat)
*cmdstat = cstat;
}

but I don't know if this fixes the issue.

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

[trippels at gcc dot gnu.org]

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

--- Comment #33 from Markus Trippelsdorf  ---
(In reply to Thomas Koenig from comment #32)
> (In reply to Markus Trippelsdorf from comment #31)
> > Fixed. Thanks.
> 
> Is the issue with the execute_command_line_* functions
> also resolved?  


No, but I wouldn't bother about these warnings, because they are obviously
pedantic and not performance related at all.

[Bug c++/72775] [6 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677

[mpolacek at gcc dot gnu.org]

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

--- Comment #18 from Marek Polacek  ---
I'll backport this to 6 too, testing looks good.

[Bug driver/79659] Provide valid values for integer options (e.g. -Wformat) with --help= option

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to Martin Liška from comment #1)
> > because we generate assert for optimization options:
> > 
> >   gcc_assert (IN_RANGE (opts->x_flag_lifetime_dse, -128, 127));
> > 
> > I'm wondering whether cutting values out of possible range to maximum (or
> > minimum) would be desired?
> 
> Even that range is too large for an option that only takes 0,1,2
> 
> It should simply emit an error that the value passed is not within the
> allowed values. Allowed values should be encoded in the .opt files.

Yes, I've prepared patch which does that:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00806.html

What remains to be added are better assert when an option is streamed out (in).
I'll do that incrementally.

[Bug c++/72775] [6 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677

[mpolacek at gcc dot gnu.org]

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

--- Comment #19 from Marek Polacek  ---
Author: mpolacek
Date: Wed Mar 15 10:22:19 2017
New Revision: 246155

URL: https://gcc.gnu.org/viewcvs?rev=246155&root=gcc&view=rev
Log:
PR c++/72775
* init.c (perform_member_init): Diagnose member initializer for
flexible array member. 

* g++.dg/ext/flexary12.C: Adjust dg-error.
* g++.dg/ext/flexary20.C: New.
* g++.dg/ext/flexary21.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary20.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary21.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/init.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/flexary12.C

[Bug c++/72775] [6 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #20 from Marek Polacek  ---
Done.

[Bug c++/80045] [cilkplus] The destruction of the temporary variable is not in the child

[florent.hivert at lri dot fr]

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

--- Comment #1 from Florent Hivert  ---
I'm not sure why you created a new report. I already created 80038. Should'nt
one be closed as a duplicate ?

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/80045] [cilkplus] The destruction of the temporary variable is not in the child

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #2 from Xi Ruoyao  ---
On 2017-03-15 10:50 +, florent.hivert at lri dot fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80045
> 
> --- Comment #1 from Florent Hivert  ---
> I'm not sure why you created a new report. I already created 80038. Should'nt
> one be closed as a duplicate ?

I'll close this.

I searched the bug list with keyword "cilkplus" instead of "cilk" and so didn't
find 80038 :(

[Bug c++/80045] [cilkplus] The destruction of the temporary variable is not in the child

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #3 from Xi Ruoyao  ---
Duplication of PR80038.

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

[Bug c++/80038] Random segfault using local vectors in Cilk function

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #9 from Xi Ruoyao  ---
*** Bug 80045 has been marked as a duplicate of this bug. ***

[Bug target/79939] [nvptx] gcc hangs in nvptx_assemble_value

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/80038] Random segfault using local vectors in Cilk function

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to Richard Biener from comment #3)
> which means the spawned copies use a shared vnew and a single destructor
> is run "afterwards".  If there's no synchronization then all threads will
> call the destructor I guess.  Not sure if cilk_sync will properly
> "merge" execution back to one thread or if there's another primitive that
> does that.

I don't think so.  I peeked into the assembly code generated.  A temp
copy of vnew is generated for "cilk_spawn walk(...)" just like there is
a simple walk(...) call.  However the temp is soon destroyed after
cilk_spawn returned.  And at the point the child is still running and
reading that temp copy.  It's easy to find out using -fsanitize=thread.

> Cilk+ and C++ is going to be "interesting" with these kind of issues.

It's clear in cilkplus spec

section 3.6 bullet [4]:

> Any unnamed temporary variables created prior to the spawn point are
> not destroyed until after the spawn point (i.e., their destructors are
> invoked in the child).

But GCC is invoking destructors in the *parent*.  That caused this issue.
In fact Florent's workaround in comment 5 is exactly doing what the spec
said.

We may let GCC generate code like this.  But then the temp would be in the
heap instead of stack.  To keep the temp living and the parent running, if
we want to use stack, we have to alloc this temp on the stack of the *child*.
Currently I have no idea how to do this.

[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Mar 15 13:38:51 2017
New Revision: 246161

URL: https://gcc.gnu.org/viewcvs?rev=246161&root=gcc&view=rev
Log:
PR target/80019
* config/i386/i386.c (ix86_vector_duplicate_value): Create
subreg of inner mode for values already in registers.

testsuite/ChangeLog:

PR target/80019
* gcc.target/i386/pr80019.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80019.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #13 from Francois-Xavier Coudert  ---
Can we apply this patch to trunk before 7.1 is released? It would allow to
build and run jit on Darwin:

diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
index 44d0750..4df2a9c 100644
--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -85,8 +85,7 @@ $(LIBGCCJIT_FILENAME): $(jit_OBJS) \
 $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \
 $(CPPLIB) $(LIBDECNUMBER) $(LIBS) $(BACKENDLIBS) \
 $(EXTRA_GCC_OBJS) \
--Wl,--version-script=$(srcdir)/jit/libgccjit.map \
--Wl,-soname,$(LIBGCCJIT_SONAME)
+-Wl,-install_name,$(LIBGCCJIT_SONAME)

 $(LIBGCCJIT_SONAME_SYMLINK): $(LIBGCCJIT_FILENAME)
ln -sf $(LIBGCCJIT_FILENAME) $(LIBGCCJIT_SONAME_SYMLINK)

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #11 from Jiong Wang  ---
I think the testcase "gcc.dg/tree-prof/pr66295.c" needs to be restricted on
x86_64-*-*, i?86-*-*.

I am seeing the following errors:

...tree-prof/pr66295.c:14:1: error: target attribute 'avx' is invalid

[Bug fortran/80046] New: Explicit interface required for at (1): pointer argument

[joachim.herb at gmx dot de]

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

Bug ID: 80046
   Summary: Explicit interface required for  at (1): pointer
argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joachim.herb at gmx dot de
  Target Milestone: ---

This is a sibling bug report to
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/720770

The following code does not compile with gfortran (and as reported above with
the newest versions of ifort). Nevertheless, I think it should be valid code.
Here it is:

module impl_list__
  implicit none

  type, public :: Node_t
integer :: val
procedure(), nopass, pointer :: cloneProc_int
  end type

  interface
subroutine NodeCloner( tgt, src )
  import Node_t
  type(Node_t), pointer, intent(out) :: tgt
  type(Node_t),   intent(in) :: src
end subroutine
  end interface

  procedure(), pointer :: cloneProc => null()
  type(Node_t) :: node

end module

  subroutine func()
use impl_list__
implicit none
procedure(NodeCloner), pointer :: cloneNode, cloneNode_int

cloneNode_int => node%cloneProc_int
cloneNode => cloneProc
  end subroutine

The compilation with gfortran results in the following error message (tested
with different versions: 5.2.0, 5.4.0, 7.0.0 20161030):

~/winhpc> gfortran --version
GNU Fortran (GCC) 7.0.0 20161030 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/winhpc> gfortran -c list_test_v2.f90
list_test_v2.f90:29:17:

 cloneNode => cloneProc
 1
Error: Explicit interface required for 'cloneproc' at (1): pointer argument

The code tests the use of two procedure pointers. One is stored inside a user
defined type, the other is defined within the module. gfortran in all version
accepts the pointer inside the user defined type but not the one defined
directly in the module. Ifort before version 17.0.0 accepts both pointers. The
compilation fails for both pointers if the version is 17.0.0 or newer (also
tested 17.0.2).

~/winhpc> ifort --version
ifort (IFORT) 17.0.0 20160721
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

~/winhpc> ifort -c list_test_v2.f90
list_test_v2.f90(28): error #6138: An explicit interface is required in this
context.   [CLONENODE_INT]
cloneNode_int => node%cloneProc_int
^
list_test_v2.f90(29): error #6138: An explicit interface is required in this
context.   [CLONENODE]
cloneNode => cloneProc
^
compilation aborted for list_test_v2.f90 (code 1)


Is this an intended behavior? If so, what would be the correct way to handle
such pointers? Otherwise, is this a bug?

[Bug other/80047] New: fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[khandeliants at viva64 dot com]

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

Bug ID: 80047
   Summary: fixincludes/fixincl.c: PVS-Studio: Improper Release of
Memory Before Removing Last Reference (CWE-401)
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khandeliants at viva64 dot com
  Target Milestone: ---

We have found a weakness (CWE-401) using PVS-Studio tool. PVS-Studio is a
static code analyzer for C, C++ and C#: https://www.viva64.com/en/pvs-studio/

Analyzer warning: V575 The null pointer is passed into 'getcwd' function.
Inspect the first argument. fixincl.c 1357

void process (void)
{
  
  if (access (pz_curr_file, R_OK) != 0)
  {
int erno = errno;
fprintf (stderr, 
 "Cannot access %s from %s\n\terror %d (%s)\n",
 pz_curr_file, 
 getcwd ((char *) NULL, MAXPATHLEN),   // <=
 erno, 
 xstrerror (erno));
return;
  }
  
}

As an extension to the POSIX.1-2001 standard, glibc's getcwd() allocates the
buffer dynamically using malloc if buf is NULL. In this case, the allocated
buffer has the length size unless size is zero, when buf is allocated as big as
necessary.  The caller should free the returned buffer.

[Bug other/80048] New: gcc/sese.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[khandeliants at viva64 dot com]

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

Bug ID: 80048
   Summary: gcc/sese.c: PVS-Studio: Improper Release of Memory
Before Removing Last Reference (CWE-401)
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khandeliants at viva64 dot com
  Target Milestone: ---

We have found a weakness (CWE-401) using PVS-Studio tool. PVS-Studio is a
static code analyzer for C, C++ and C#: https://www.viva64.com/en/pvs-studio/

Analyzer warning: V625 Consider inspecting the 'for' operator. Initial and
final values of the iterator are the same. sese.c 201

void free_sese_info (sese_info_p region)
{
  region->params.release ();
  region->loop_nest.release ();

  for (rename_map_t::iterator it = region->rename_map->begin();
   it != region->rename_map->begin (); ++it)// <=
(*it).second.release();
  
}

[Bug other/80049] New: gcc/genmodes.c: PVS-Studio: NULL Pointer Dereference (CWE-476)

[khandeliants at viva64 dot com]

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

Bug ID: 80049
   Summary: gcc/genmodes.c: PVS-Studio: NULL Pointer Dereference
(CWE-476)
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khandeliants at viva64 dot com
  Target Milestone: ---

We have found a weakness (CWE-476) using PVS-Studio tool. PVS-Studio is a
static code analyzer for C, C++ and C#: https://www.viva64.com/en/pvs-studio/

Analyzer warning: V595 The 'm->component' pointer was utilized before it was
verified against nullptr. Check lines: 399, 407. genmodes.c 399

static void complete_mode (struct mode_data *m)
{
  
  if (   m->cl == MODE_COMPLEX_INT 
  || m->cl == MODE_COMPLEX_FLOAT)
alignment = m->component->bytesize;// <=
  else
alignment = m->bytesize;

  m->alignment = alignment & (~alignment + 1);

  if (m->component)// <=
{
  m->next_cont = m->component->contained;
  m->component->contained = m;
}
}

[Bug other/80050] New: gcc/genmatch.c: PVS-Studio: V590

[khandeliants at viva64 dot com]

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

Bug ID: 80050
   Summary: gcc/genmatch.c: PVS-Studio: V590
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khandeliants at viva64 dot com
  Target Milestone: ---

We have found a bug using PVS-Studio tool. PVS-Studio is a static code analyzer
for C, C++ and C#: https://www.viva64.com/en/pvs-studio/

Analyzer warning: V590 Consider inspecting this expression. The expression is
excessive or contains a misprint. genmatch.c 3829

const cpp_token * parser::next ()
{
  const cpp_token *token;
  do
  {
token = cpp_get_token (r);
  }
  while (   token->type == CPP_PADDING
 && token->type != CPP_EOF);// <=
  return token;
}

[Bug other/80051] New: gcc/dwarf2out.c: PVS-Studio: V501

[khandeliants at viva64 dot com]

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

Bug ID: 80051
   Summary: gcc/dwarf2out.c: PVS-Studio: V501
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khandeliants at viva64 dot com
  Target Milestone: ---

We have found a bug using PVS-Studio tool. PVS-Studio is a static code analyzer
for C, C++ and C#: https://www.viva64.com/en/pvs-studio/

Analyzer warning: V501 There are identical sub-expressions
'!strcmp(a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1)' to the left and to
the right of the '&&' operator. dwarf2out.c 1434

static bool dw_val_equal_p (dw_val_node *a, dw_val_node *b)
{
  
  switch (a->val_class)
  {

  case dw_val_class_vms_delta:
return (   !strcmp (a->v.val_vms_delta.lbl1,
b->v.val_vms_delta.lbl1)
&& !strcmp (a->v.val_vms_delta.lbl1, // <=
b->v.val_vms_delta.lbl1));   // <=

  }
  
}

[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM

[yyc1992 at gmail dot com]

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

--- Comment #6 from Yichao Yu  ---
Anything new here?

[Bug c++/80045] [cilkplus] The destruction of the temporary variable is not in the child

[florent.hivert at lri dot fr]

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

--- Comment #4 from Florent Hivert  ---
I should have said first : thanks for analizing the problem !!!

I wasn't sure about the proper way to do thing and I was afraid that no one
Cilk aware was following gcc-help. Anyway I should have mentioned on the list
the number of the ticket. Sorry for the mess.

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[tschwinge at gcc dot gnu.org]

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

--- Comment #8 from Thomas Schwinge  ---
(In reply to myself from comment #6)
> This has been (with low priority) on my long TODO list
> for some time: ever since I started using -gsplit-dwarf and noticed that
> GCC's Internal Compiler Error (ICE) backtraces no longer were as useful as
> they used to be -- at least I suppose that's the very same underlying issue.

Well, as it turns out, reading the *.dwo files generated by -gsplit-dwarf is
actually a different issue than the "debuglink" case discussed here.  So,
that's to stay on my long TODO list for a little longer...  ;-)

[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Mar 15 15:27:28 2017
New Revision: 246166

URL: https://gcc.gnu.org/viewcvs?rev=246166&root=gcc&view=rev
Log:
PR target/80019
* config/i386/i386.c (ix86_vector_duplicate_value): Create
subreg of inner mode for values already in registers.

testsuite/ChangeLog:

PR target/80019
* gcc.target/i386/pr80019.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr80019.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[jiwang at gcc dot gnu.org]

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

--- Comment #10 from Jiong Wang  ---
Author: jiwang
Date: Wed Mar 15 15:33:12 2017
New Revision: 246167

URL: https://gcc.gnu.org/viewcvs?rev=246167&root=gcc&view=rev
Log:
[gcc, testsuite] Don't xfail on arm

PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Don't xfail on arm.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c

[Bug other/80051] gcc/dwarf2out.c: PVS-Studio: V501

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Mar 15 16:15:53 2017
New Revision: 246168

URL: https://gcc.gnu.org/viewcvs?rev=246168&root=gcc&view=rev
Log:
PR target/80019
* config/i386/i386.c (ix86_vector_duplicate_value): Create
subreg of inner mode for values already in registers.

testsuite/ChangeLog:

PR target/80019
* gcc.target/i386/pr80019.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr80019.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed everywhere.

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
Bug 80006 tracks the problem that's behind the failure discussed here.  It
looks as though it might be specific to the x86 target so perhaps rather than
listing all the targets where the xfail should not apply it might be simpler to
list x86 as the one where it does.

[Bug target/80052] New: typo in aarch64.opt: dummping

[roland.illig at gmx dot de]

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

Bug ID: 80052
   Summary: typo in aarch64.opt: dummping
   Product: gcc
   Version: 7.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 aarch64.opt:

Enables verbose cost model dummping in the debug dump files.

s/dummping/dumping/

In the same commit, a typo was introduced into ChangeLog, which is now
ChangeLog-2016: the file says "PInski", "which should be "Pinski".

[Bug target/80052] typo in aarch64.opt: dummping

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from James Greenhalgh  ---
Confirmed. A patch fixing this would be a welcome contribution.

[Bug middle-end/80053] New: Label with address taken should prevent duplication of containing basic block

[amonakov at gcc dot gnu.org]

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

Bug ID: 80053
   Summary: Label with address taken should prevent duplication of
containing basic block
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

Today, GCC considers all BBs clonable on GIMPLE, as indicated by
tree-cfg.c:gimple_can_duplicate_bb_p, but, at the same time, not all functions
are clonable: those functions that have labels with address taken and stored
into a static variable are considered non-clonable.  This seems inconsistent. 
Taking address of a label should generally prevent cloning of its BB.

Here's a testcase that is actually miscompiled at -O3, because after loop
unswitching one of the cloned loops will jump to a label in another clone:

#include 
static __attribute__((noinline,noclone))
void h(int n, int p)
{
  void *lp = &&l;
  asm("" : "+r"(lp));
  for (; n; n--) {
if (p)
  puts("p != 0");
else
  puts("p == 0");
asm goto("jmp *%0" : : "r"(lp) : : l);
l:;
  }
}
int main()
{
  h(2, 0);
  h(2, 1);
}

My understanding that this is an omission, and both
{gimple,cfgrtl}_can_duplicate_bb_p should return false when the BB has its
address taken.  Unless I'm missing something and this is not an oversight?

[Bug tree-optimization/80054] New: ICE in verify_ssa with -O3 -march=broadwell/skylake-avx512

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 80054
   Summary: ICE in verify_ssa with -O3
-march=broadwell/skylake-avx512
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Created attachment 40978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40978&action=edit
Reproducer.

ICE with -O3 -march=broadwell (and skylake-avx512). Everything works fine with
other optimization levels.

Error:
>$ g++ -O3 -march=broadwell -c repr.cpp
repr.cpp: In function ‘void foo()’:
repr.cpp:17:6: error: definition in block 7 does not dominate use in block 6
 void foo() {
  ^~~
for SSA_NAME: _133 in statement:
slsr_142 = PHI <_133(6), _133(16)>
PHI argument
_133
for PHI node
slsr_142 = PHI <_133(6), _133(16)>
repr.cpp:17:6: internal compiler error: verify_ssa failed
0xf84ad3 verify_ssa(bool, bool)
/home/vsevolod/workspace/gcc-dev/trunk/gcc/tree-ssa.c:1184
0xc98ea7 execute_function_todo
/home/vsevolod/workspace/gcc-dev/trunk/gcc/passes.c:1973
0xc99e0b execute_todo
/home/vsevolod/workspace/gcc-dev/trunk/gcc/passes.c:2016

Reproducer:
extern short var_2;
extern short var_4;
extern const bool var_32;
extern short var_36;
extern const bool var_37;
extern bool var_46;
extern unsigned int var_47;
extern short var_49;
extern unsigned int var_56;
extern unsigned int var_62;
extern unsigned int var_65;
extern bool var_831;
extern unsigned int var_843;
extern short var_846;
extern short var_889;

void foo() {
if (var_36 * var_37)
var_831 = var_56 = 0;
else
var_65 = 0;

if (var_46)
var_843 = 0;

var_846 = 0;

if ((var_4 == 0) >> (var_32 | -(var_37 < var_46 || var_36)) + 8)
var_49 = 2032651381 * bool(var_2 * var_37);
else {
var_62 = 0;
var_47 = (var_46 || var_36) * (var_2 * var_37);
}

var_889 = bool(var_2 * var_37);
}

GCC version:
gcc version 7.0.1 (today's trunk)

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
With constant arguments (or those whose value or range is known), GCC should
warn on the first declaration in comment #0 (copied below) not necessarily
because the addition doesn't append 'c' to "aa" (i.e., with -Wstring-plus-char
warns) but mainly because it results in an invalid pointer.

  const char *a = "aa" + 'c';

GCC should warn for a constant operand that results in an out-of-bounds pointer
regardless of its type, such as the following:

  const char *a = "aa" + 4;

GCC could (and, in my view, should) also warn on the following where the value
of i isn't known but where its range is such that the addition will never
result in a valid pointer:

  void f (int i)
  {
if (i < 4) return;
const char *a = "aa" + i;
...
  }

[Bug translation/80055] New: do not mark arguments of internal_error for i18n

[roland.illig at gmx dot de]

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

Bug ID: 80055
   Summary: do not mark arguments of internal_error for i18n
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Expanding on bug 79596 (mentions only gfc_internal_error), as well as a
discussion on a mailing list.

From https://gcc.gnu.org/ml/gcc/2017-03/msg00049.html:
> In my opinion, there is no point in having internal error messages
> translated, since their only purpose is to be sent back to the GCC
> developers, instead of being interpreted and acted upon by the GCC user.
> By not translating the internal errors, the necessary work for
> translators can be cut down by several hundred messages.

[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error

[roland.illig at gmx dot de]

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

--- Comment #8 from Roland Illig  ---
(In reply to Martin Liška from comment #7)
> I like your rules. My question was more about how practically do you
> distinguish between such strings? My plan is to create a new
> DK_INTERNAL_ERROR type, which I would like to ignore in the translations.

I don't know what you mean by "distinguish". As I suggested in
https://gcc.gnu.org/ml/gcc/2017-03/msg00049.html, I would solve this by having
two separate functions for errors: error() and error_no_i18n().

Can you elaborate a bit on what you meant?

[Bug tree-optimization/78687] inefficient code generated for eggs.variant

[jamborm at gcc dot gnu.org]

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

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

This patch addresses the issue and passes bootstrap and testing on
x86_64-linux.  It is definitely too late to submit it for GCC 7 but if
we do not come a more substantial overhaul of SRA in the GCC 8 time
frame, I will submit it on the mailing list.

[Bug fortran/79860] i18n: single-word translation in "Character-valued %s %qs"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar 15 18:05:06 2017
New Revision: 246170

URL: https://gcc.gnu.org/viewcvs?rev=246170&root=gcc&view=rev
Log:
Fix translation issue with character length * errors (PR fortran/79860)

gcc/fortran/ChangeLog:
PR fortran/79860
* resolve.c (resolve_contained_fntype): Make error messages more
amenable to translation.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[koenigni at student dot ethz.ch]

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

--- Comment #7 from Nicolas Koenig  ---
(In reply to Jerry DeLisle from comment #6)
>
> This falls into the PITA classification. Also known as simple enough,
> regression test and commit. (consider it approved)

I don't think I can submit patches yet (no write access to the repo, working on
it), so it would be great if you or someone else could commit for me :)

[Bug fortran/79860] i18n: single-word translation in "Character-valued %s %qs"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Resolved in source tree by r246170 for next time gcc.pot is regenerated.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

--- Comment #13 from Michael Meissner  ---
FWIW, it does not fail for -mcpu=power7 or -mcpu=power9.  If you use
-mcpu=power7, there is no direct move.  If you use -mcpu=power9, the MTVSRDD
instruction is generated which bypasses the part that is failing under reload.

[Bug other/80056] New: gcc.dg/tree-prof/pr66295.c fails on powerpc

[seurer at gcc dot gnu.org]

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

Bug ID: 80056
   Summary: gcc.dg/tree-prof/pr66295.c fails on powerpc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This new test case doesn't compile correct on powerpc.

spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fprofile-generate
-D_PROFILE_GENERATE -lm -o
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gcc/pr66295.x01
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx2"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx512f"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("default"))) is invalid
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx2"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("avx512f"))) is invalid
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c:14:1:
error: __attribute__((__target__("default"))) is invalid

FAIL: gcc.dg/tree-prof/pr66295.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
UNRESOLVED: gcc.dg/tree-prof/pr66295.c execution,-fprofile-generate
-D_PROFILE_GENERATE
UNRESOLVED: gcc.dg/tree-prof/pr66295.c compilation,  -fprofile-use
-D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr66295.c execution,-fprofile-use
-D_PROFILE_USE
UNSUPPORTED:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
-fauto-profile
testcase
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp
completed in 0 seconds

=== gcc Summary ===

# of unexpected failures1
# of unresolved testcases   3
# of unsupported tests  1

[Bug target/80057] New: typo in mips.opt: Virtualization Application Specific

[roland.illig at gmx dot de]

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

Bug ID: 80057
   Summary: typo in mips.opt: Virtualization Application Specific
   Product: gcc
   Version: 7.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 mips.opt:

mvirt
Target Report Var(TARGET_VIRT)
Use Virtualization Application Specific instructions.

The words "Virtualization Application Specific" are not the official name of an
instruction set extension, therefore they should not look like an abbreviation.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
I will take care of it. Thanks Nicolas

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/documentation/MD00849-2B-VZmicroMIPS64-AFP-01.06.pdf


"The Virtualization Application-Specific Extension (Module) requires the
following base architecture support:"

Or did I misunderstand your issue with it?

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #7 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #6)
> With constant arguments (or those whose value or range is known), GCC should
> warn on the first declaration in comment #0 (copied below) not necessarily
> because the addition doesn't append 'c' to "aa" (i.e., with
> -Wstring-plus-char warns) but mainly because it results in an invalid
> pointer.
> 
>   const char *a = "aa" + 'c';
> 
> GCC should warn for a constant operand that results in an out-of-bounds
> pointer regardless of its type, such as the following:
> 
>   const char *a = "aa" + 4;
> 

Clang-5.0 is doing this now for -Wstring-plus-int.  I'll try to do this.

> GCC could (and, in my view, should) also warn on the following where the
> value of i isn't known but where its range is such that the addition will
> never result in a valid pointer:
> 
>   void f (int i)
>   {
> if (i < 4) return;
> const char *a = "aa" + i;
> ...
>   }

We should make a new PR requesting for clang -Warray-bounds as well.  It's
a part of meta-bug PR30334.

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #8 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #7)

> We should make a new PR requesting for clang -Warray-bounds as well.  It's
> a part of meta-bug PR30334.

Sorry. We have -Warray-bounds, but not as well as clang's.  For example clang
warns for "aa"[4], but GCC doesn't.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[bernds at gcc dot gnu.org]

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

--- Comment #14 from Bernd Schmidt  ---
I can't reproduce this, but that's probably because of
  cc1plus: warning: will not generate power8 instructions because assembler
lacks power8 support

Binutils was just configured for ppc64le-linux - do I need any special options
on the configure command line there?

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Xi Ruoyao from comment #7)
> 
> > We should make a new PR requesting for clang -Warray-bounds as well.  It's
> > a part of meta-bug PR30334.
> 
> Sorry. We have -Warray-bounds, but not as well as clang's.  For example clang
> warns for "aa"[4], but GCC doesn't.

Right.  It only warns on arrays, and only with optimization.  That seems to be
because array_at_struct_end_p() in tree.c (called from check_array_ref() in
tree-vrp.c) doesn't handle ARRAY_REF with a STRING_CST operand correctly.  It
treats it as if it were a reference to an array at the end of a structure. 
This only superficially tested change lets GCC warn on that case as well (as
long as the result is used).  To detect this without optimization
-Warray-bounds would need to also do some checking much earlier.

diff --git a/gcc/tree.c b/gcc/tree.c
index 8f87e7c..5fcbf65 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -13229,6 +13229,9 @@ array_at_struct_end_p (tree ref, bool allow_compref)
   ref = TREE_OPERAND (ref, 0);
 }

+  if (TREE_CODE (ref) == STRING_CST)
+return false;
+
   tree size = NULL;

   if (TREE_CODE (ref) == MEM_REF

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Just a quick question: are you sure that removing 'gfc_release_symbol (p);'
does not cause a memory leak in the normal case?

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
You need to build GCC with a new enough binutils, 2.24 I believe.

[Bug translation/80055] do not mark internal compiler error messages for i18n

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  See also the related discussion in bug 79856.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

--- Comment #16 from Michael Meissner  ---
You need power8 support for the bug to show itself.  In order to have power8
(ISA 2.07) support, you need a binutils that supports at least the power8
instructions.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #38580|0   |1
is obsolete||

--- Comment #17 from Michael Meissner  ---
Created attachment 40980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40980&action=edit
Proposed patch to fix the problem

[Bug libstdc++/62045] [5/6/7 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Wed Mar 15 20:11:48 2017
New Revision: 246173

URL: https://gcc.gnu.org/viewcvs?rev=246173&root=gcc&view=rev
Log:
PR libstdc++/62045 fix O(N) insertion in pd_ds binary heap

2017-03-15  Xi Ruoyao  

PR libstdc++/62045
* include/ext/pb_ds/qdetail/binary_heap_/binary_heap_.hpp
(is_heap): Remove.
(push_heap): Remove the wrong checking using is_heap.
(make_heap): Remove the assertion using is_heap.
* include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
(modify): Ditto.
(resize_for_insert_if_needed): Add PB_DS_ASSERT_VALID after
calling make_heap.

2017-03-15  Jonathan Wakely  

PR libstdc++/62045
* testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc:
New test.
* testsuite/ext/pb_ds/regression/priority_queues.cc: Fix copy&paste
error in comment.

Added:
   
trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_binary_heap-62045.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp
trunk/libstdc++-v3/include/ext/pb_ds/detail/binary_heap_/insert_fn_imps.hpp
trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queues.cc

[Bug libstdc++/62045] [5/6 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5/6 Regression]
   |__gnu_pbds::priority_queue< |__gnu_pbds::priority_queue<
   |int, less, |int, less,
   |binary_heap_tag> is too |binary_heap_tag> is too
   |slow|slow

--- Comment #11 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug other/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Since the Glibc extension may not be provided by other systems I
think the portable solution is to avoid relying on it.  Since getcwd() may fail
by returning 0, the caller should also avoid assuming it succeeds.  Let me post
the following patch:

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6..6e6eb21 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1353,8 +1353,10 @@ process (void)
   if (access (pz_curr_file, R_OK) != 0)
 {
   int erno = errno;
+  char cwdbuf[MAXPATHLEN];
+  char *cwd = getcwd (cwdbuf, sizeof cwdbuf);
   fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
-   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
+   pz_curr_file, cwd ? cwd : "current working directory",
erno, xstrerror (erno));
   return;
 }

[Bug other/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>char cwdbuf[MAXPATHLEN];

This is not a GNU style thing.  GNU style mentions against using arbitrary
limits.

[Bug other/80058] New: fix double spaces is string literals everywhere

[roland.illig at gmx dot de]

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

Bug ID: 80058
   Summary: fix double spaces is string literals everywhere
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Searching the whole GCC source code for the following regular expression finds
a few places in the code:

[ ]"\n[ \t]+"[ ]

This expression finds concatenated string literals where the first ends with a
space and the second starts with a space, like these:

  gfc_warning_now (w, "Change of value in conversion from "
   " %qs to %qs at %L",
   gfc_typename (&src->ts), gfc_typename (&result->ts),
   &src->where);

The above code and all similar places should be fixed so that they only have a
single space character.

[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|other   |bootstrap

--- Comment #3 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00853.html

(In reply to Andrew Pinski from comment #2)
> >char cwdbuf[MAXPATHLEN];
> 
> This is not a GNU style thing.  GNU style mentions against using arbitrary
> limits.

There are existing uses of MAXPATHLEN to declare local arrays in this file
(create_file, quoted_file_exists) so this one doesn't make things any worse
than they already are.

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[segher at gcc dot gnu.org]

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

--- Comment #22 from Segher Boessenkool  ---
Author: segher
Date: Wed Mar 15 20:48:49 2017
New Revision: 246174

URL: https://gcc.gnu.org/viewcvs?rev=246174&root=gcc&view=rev
Log:
rs6000: Do not xfail nint_2.f90 on Linux systems

It was XFAILed because there was a bug in glibc, but that bug was fixed
nine years ago.  Nowadays everyone uses a version of glibc with the bug
fixed, so we should no longer XFAIL the test.


gcc/testsuite/
PR fortran/33271
* gfortran.dg/nint_2.f90: Do not xfail powerpc*-*-linux*.

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

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/80057] typo in mips.opt: Virtualization Application Specific

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
Citing from the PDF document:

> The Virtualization Application-Specific Extension (Module) requires the 
> following base architecture support:

The current GCC code split these words at the following boundaries:

> The "Virtualization Application Specific" "Module"

This would imply that there is a module called VAS.

The usual reading is different, though:

> The "Virtualization" "application-specific module"

This means there is an application-specific module called "Virtualization".

The words "Application-Specific Extension" are probably only capitalized
because they have been defined somewhere as a concept. In GCC, these words
should not be capitalized, and there should be a hyphen between
"application-specific", to be consistent with the grammar in other places.

[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|blocker |normal

--- Comment #8 from Martin Sebor  ---
Is this still a problem with any currently supported version of GCC?

Since there's been no update on this in almost 5 years and no other reports of
the same problem (AFAICS) I'm lowering Severity to Normal.  If the problem
persists and you feel like it meets the definition of Critical Severity
(https://gcc.gnu.org/bugs/management.html) please feel to bump it up.

[Bug target/79038] Improve PowerPC ISA 3.0 conversion between integers and hardware _Float128

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Mar 15 21:17:35 2017
New Revision: 246178

URL: https://gcc.gnu.org/viewcvs?rev=246178&root=gcc&view=rev
Log:
[gcc]
2017-03-15  Michael Meissner  

PR target/79038
* config/rs6000/rs6000.md (float2): Define
insns to convert from signed/unsigned char/short to IEEE 128-bit
floating point.
(floatuns2): Likewise.

[gcc/testsuite]
2017-03-15  Michael Meissner  

PR target/79038
* gcc.target/powerpc/pr79038-1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79038-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug regression/59608] Unable to build working poedit v.1.5.x using gcc 4.8.2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Martin Sebor  ---
There is insufficient information to know what's going on.  Please review the
Summarized bug reporting instructions in https://gcc.gnu.org/bugs and either
reopen this bug or open a new one with the requested details.

[Bug target/60808] Typo in definition of ATxmega256A3BU

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
Fixed in r209446.

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Mar 15 21:32:43 2017
New Revision: 246180

URL: https://gcc.gnu.org/viewcvs?rev=246180&root=gcc&view=rev
Log:
PR c++/80043 - ICE with -fpermissive

* typeck.c (convert_for_assignment): Handle instantiate_type
not giving an error.

Added:
trunk/gcc/testsuite/g++.dg/parse/ptrmem7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Very good question, maybe we do:


if (p)
  gfc_release_symbol (p);

I will try it.

[Bug bootstrap/47923] Errors when installing GCC 4.5.2 on AIX 6.1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #10 from Martin Sebor  ---
Based on comment #9 it sounds like the problems may have been caused by the
environment.  Regardless, GCC 4.5 is no longer supported and current trunk (GCC
7.0) has been reported to bootstrap successfully on AIX 7.2
(https://gcc.gnu.org/ml/gcc-testresults/2017-03/msg01700.html).  Please try a
more recent version of GCC and AIX and if the problems persist either open a
new bug or ask on gcc-h...@gcc.gnu.org.

[Bug c++/80059] New: [7 Regression] ICE with invalid noexcept for __transaction_atomic

[reichelt at gcc dot gnu.org]

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

Bug ID: 80059
   Summary: [7 Regression] ICE with invalid noexcept for
__transaction_atomic
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, trans-mem
  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 -fgnu-tm) triggers
an ICE on trunk:

=
template int foo(bool b)
{
  return __transaction_atomic noexcept(b) (0);
}

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

bug.cc: In function 'int foo(bool)':
bug.cc:3:45: internal compiler error: unexpected expression 'b' of kind
implicit_conv_expr
   return __transaction_atomic noexcept(b) (0);
 ^
0x83f890 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4575
0x842ece cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4633
0x776f2a build_must_not_throw_expr(tree_node*, tree_node*)
../../gcc/gcc/cp/except.c:274
0x7ac6ff build_transaction_expr(unsigned int, tree_node*, int, tree_node*)
../../gcc/gcc/cp/semantics.c:8747
0x72628f cp_parser_transaction_expression
../../gcc/gcc/cp/parser.c:37871
0x72628f cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7895
0x726c93 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:8780
0x7273e7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8881
0x727cb4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9168
0x72b9c8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9337
0x719f9a cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:12147
0x719f9a cp_parser_statement
../../gcc/gcc/cp/parser.c:10581
0x71a84d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11027
0x71a91f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10981
0x71aab3 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21428
0x71aab3 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21466
0x71b331 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26253
0x71c01d cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26165
0x71c01d cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19155
0x71c5ca cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:26711
Please submit a full bug report, [etc.]

This is a recent regression introduced between 2017-03-02 and 2017-03-06.

[Bug middle-end/50398] ICE when compiling openssl-1.0.0d with -O2 -floop-flatten

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Sebor  ---
The -floop-flatten functionality was removed in r84820 (the option does nothing
now).

[Bug middle-end/51769] bootstrap fails when using -O2 -funswitch-loops -floop-flatten

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Sebor  ---
The -floop-flatten functionality was removed in r84820 (the option does nothing
now).

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Always helps to double check.  The three original test cases do not ICE on
trunk and gfc_release_symbol is already NULL guarded internally.  I would not
chase this further on trunk for the first three cases.

Also, we don't care about the listed versions under "known to fail". especially
for invalid.  Its not worth our time on older gfortran releases. However, it is
worth investigating on trunk, especially for learning the internals

So which cases actually ICE or segfault on trunk currently? z4.f90 is
definitely something different.

[Bug target/33777] Crash during a build of zsh

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #6 from Martin Sebor  ---
In the absence of feedback nearly a decade and in light of comment #2 resolving
as WorksForSome.

[Bug bootstrap/52471] ICE bootstrapping GCC 4.7.0-20120302 on x86_64 OpenBSD

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
It's been a few years since this report.  Can you try a more recent/supported
version of GCC (preferably 6 or 7) and verify whether the problem has cleared
up?

[Bug c/80060] New: RFE: -Wformat knob to ignore same-width incorrect types

[eblake at redhat dot com]

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

Bug ID: 80060
   Summary: RFE: -Wformat knob to ignore same-width incorrect
types
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eblake at redhat dot com
  Target Milestone: ---

When porting from one machine to another, especially when porting from 32-bit
to 64-bit software, getting warnings about mismatches such as printf("%ld",
(uint32_t)1) is awesome.  But once something has been ported to a given
platform, if two types have the same size but different rank, getting warnings
about something that is not portable to other machines but which works in
practice on the given machine is very noisy.  And sometimes, the noise is
unavoidable - there are many situations in which different implementations can
pick a type that is consistent for their platform, but uses a different rank
than what another platform chose - not all the world uses the  types,
but has a variety of other typedefs in place.

Here's some examples: on 64-bit Linux, the header 
declares a struct with members specified with a typedef __u64:

struct uffd_msg msg;
struct uffd_msg {
..
union {
struct {
__u64   flags;
__u64   address;
} pagefault;
..
} arg;
}

Printing one of these values is obvious - the typedef name tells you it should
be an unsigned 64-bit quantity, so let's try printf("%"PRIx64,
msg.arg.pagefault.flags).  Oops, on 64-bit Linux, that fails under -Wformat,
because "%ld" is incompatible with 'unsigned long long'.  But since the kernel
headers typedef'd __u64 without any counterpart to something like PRIx64, there
is no sane way to print a __u64 without writing an extra cast at every caller,
which is prone to introduce more bugs than the warnings it silences:
printf("%"PRIx64, (uint64_t)msg.arg.pagefault.flags).

Another case: on 32-bit mingw, the declaration for ntohl() says that it returns
a 'u_long', which is a 32-bit type.  But POSIX says that ntohl() returns
'uint32_t'.  So the obvious printf("%"PRIx32, ntohl(1)) fails to compile on
mingw, because 'u_long' (which is 'unsigned long') is incompatible with
'uint32_t' (which is 'unsigned int') on that platform (arguably a bug in
mingw's headers, but such is life).  Again, the mismatch warning can be avoided
with a cast, but that does not scale well: printf("%"PRIx32,
(uint32_t)ntohl(1))

gcc recently introduced -Wformat-signedness (and it's counterpart
-Wno-format-signedness) to let developers fine-tune how MUCH verbosity they
want during warning checks.  Are you porting code to a platform where 'int' and
'unsigned int' have different widths? (Some weirdnix hardware might exist like
that, and C seems to make it possible, even though I can't name such a system)
- then turn the warning on. But if you really DON'T care about "%d" used with
'unsigned', or "%x" used with 'int' (because in the end, the 32-bit value
passed through varargs gets reinterpreted into the correct 32-bit value that
gets printed, regardless of intermediate sign-incorrectness), then turn it off.

So I'd love to have a new knob, maybe named -Wformat-same-rank, which controls
whether gcc warns about using the wrong format specifier EVEN THOUGH the type
passed to varargs has the same rank and therefore will print accurately; and
projects can then use -Wno-format-same-rank to silence __u64/uint64_t or
u_long/uint32_t differences while still getting warnings about real bugs of
32-bit vs. 64-bit mismatches.

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Martin Sebor  ---
Resolving as invalid based on comment #3.  The manual does seem to suggest that
this should work:

   "The priorities for constructor and destructor functions are the same as
those specified for namespace-scope C++ objects (see C++ Attributes)."

Let me add a blurb to make clear that the order between C++ ctors and functions
declared attribute constructor is unspecified.

Blurb posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00863.html

[Bug target/80017] [5/6/7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Mar 15 23:04:09 2017
New Revision: 246181

URL: https://gcc.gnu.org/viewcvs?rev=246181&root=gcc&view=rev
Log:
2017-03-15  Vladimir Makarov  

PR target/80017
* lra-constraints.c (process_alt_operands): Increase reject for
reloading an input/output operand.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug c/80060] RFE: -Wformat knob to ignore same-width incorrect types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78014,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77970
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Confirmed.  I think this request falls into the same class as bug 78014 and bug
77970.

[Bug c++/78014] -Wformat -vs- size_t

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-15
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
Confirmed on the same basis as bug 80060.

[Bug c/67479] Support for -Wformat-pedantic

[msebor at gcc dot gnu.org]

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

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=78014,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80060

--- Comment #7 from Martin Sebor  ---
See also bug 78014 and bug 80060.  They're not about exactly the same thing but
similarly to this report they also discuss adding a new -Wformat option to
subset the checker into two (or more) portability categories.

[Bug target/60515] Compiler crash with -g and -mpoke-function-name option combined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
I cannot reproduce the ICE with today's top of trunk (GCC 7.0) so it has
apparently been fixed.

[Bug bootstrap/57683] Parallel build failure: generated prerequisite header not built in time (insn-opinit.h)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Does the commit referenced in comment #1 fix the problem?

[Bug c/44943] Need documentation on the intended semantics of "volatile" (in C)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
I believe this request was largely resolved in r163400 by moving the C++
documentation of volatile accesses to the C manual.

The additional sentence (underlined in comment #0) wasn't added but to me the
text just before it implies it.  If you'd still like it added please reopen the
bug.

[Bug middle-end/68069] -fstack-protector does not protect from buffer overflow attack

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Resolving as invalid on the basis of comment #3 (and due to no
counterargument).  

The problem is caught by -fsanitize=undefined (although the handling isn't the
most elegant -- the program is stuck in the fscanf loop and never terminates).

$ gcc -fsanitize=undefined t.c && ./a.out 
t.c: In function ‘f’:
t.c:13:20: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
 printf("%d\n", (int) f2);
^
t.c:19:11: warning: assignment makes pointer from integer without a cast
[-Wint-conversion]
  arr[++i] = cur;
   ^
4196614
1
t.c:19:5: runtime error: index 2 out of bounds for type 'int *[1]'
t.c:19:11: runtime error: store to address 0x7ffe793c7f60 with insufficient
space for an object of type 'int *'
0x7ffe793c7f60: note: pointer points here
 02 00 00 00  00 00 00 00 00 00 00 00  10 08 40 00 00 00 00 00  80 7f 3c 79 fe
7f 00 00  37 0a 40 00
  ^ 
4196614

[Bug bootstrap/53731] [4.7] Bootstrap fails for libgfortran on Solaris 10 x86 with error "Where has __float128 gone?"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Sebor  ---
GCC 4.7 is no longer maintained.  Current trunk of GCC 7.0 has been reported to
successfully bootstrap on Solaris 11
(https://gcc.gnu.org/ml/gcc-testresults/2017-03/msg01380.html) and Solaris 12
(https://gcc.gnu.org/ml/gcc-testresults/2017-03/msg01377.html).  There are no
recent reports for older Solaris and I'm not sure it's supported/maintained
there.  Please try a more recent GCC (ideally on newer Solaris if you can). 
I'm closing this as won't fix due to 4 years with no activity.

[Bug c++/69054] g++ fails to diagnose ambiguous overload resolution when implicit conversions are involved

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.3, 4.2.2, 4.3.2, 4.6.0,
   ||5.4.0, 6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with today's top of trunk (GCC 7.0) and all released versions.

EDG eccp 4.13 reports:

"t.C", line 19: error: more than one operator "[]" matches these operands:
built-in operator "integer[pointer-to-object]"
function "Something::operator[](const foo &)"
operand types are: Something [ const char [3] ]
  d["32"];
   ^

1 error detected in the compilation of "t.C".

[Bug c++/39982] Fail to use constructor to initialize volatile declaration (no matching function for call)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.0, 5.3.0, 6.3.0, 7.0
 Resolution|--- |FIXED
  Known to fail||4.3.2

--- Comment #2 from Martin Sebor  ---
The code is accepted by GCC 7.0.  Looks like the bug was fixed in r210284 (gcc
4.10.0):

r210284 | jason | 2014-05-09 14:16:11 -0400 (Fri, 09 May 2014) | 4 lines

DR 5
PR c++/60019
* call.c (build_user_type_conversion_1): The copy-init temporary
is cv-unqualified.

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jason Merrill  ---
Fixed for gcc 7.