[Bug target/81909] Missing warning in gcc.dg/pr53037-{2,3}.c

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

Summary|[nvptx] Missing warning in  |Missing warning in
   |gcc.dg/pr53037-{2,3}.c  |gcc.dg/pr53037-{2,3}.c

--- Comment #2 from Tom de Vries  ---
The missing warnings are reported for sparc here (PR53037 comment 26), and
noted to be caused by STRICT_ALIGNMENT here (PR53037 comment c29).

nvptx is a STRICT_ALIGNMENT target, and so is arm.

[Bug fortran/81978] New: Passing component of a parameter array to a subroutine causes SIGBUS crash

[david.sagan at gmail dot com]

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

Bug ID: 81978
   Summary: Passing component of a parameter array to a subroutine
causes SIGBUS crash
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.sagan at gmail dot com
  Target Milestone: ---

Consider the following program:

module test_mod
contains
subroutine match_word (names)
implicit none
character(*) names(:)
end subroutine
end module

program test
use test_mod
implicit none

type pp_struct
  character(40) name
  real value
end type

type (pp_struct), parameter :: pp(2) = [ &
 pp_struct('pi', 3.1), &
 pp_struct('twopi', 6.3)]

print *, 'In'
call match_word(pp%name)
print *, 'Out'
end program



Compiling and running produces:

Davids-Mac-mini:~/Downloads> gfortran test.f90; ./a.out 
 In

Program received signal SIGBUS: Access to an undefined portion of a memory
object.

Backtrace for this error:
#0  0x105ff50bc
#1  0x105ff48aa
#2  0x7fffb3bd6b39
#3  0x105fecd68
#4  0x105fece2e
Bus error: 10

Note: If "parameter" is not used with the pp array, the program runs fine.

Davids-Mac-mini:~/Downloads> gcc --version
gcc (MacPorts gcc7 7-20170622_1) 7.1.1 20170622

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #17 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #15)
> (In reply to Xi Ruoyao from comment #14)
> 
> The symbols in your example are the result/ouput of demangling but the issue
> reported here is with the symbols that are input into GDB.  There is more
> than one way to represent the same specialization of a template (e.g.,
> B and B, or A<2> and A<2u>, or even A<1 + 1>).  GDB
> should be able to accept all of them and recognize they all refer to the
> same specialization.

Well, then GDB would have to own a C++ name parser!

Before GDB implement this, how about generate a "secondary" debug symbol with
type suffixes, along with the "normal" one without them?  It would give
backward
compatibility.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

--- Comment #16 from Paul Smith  ---
I'm not familiar with the implementations but I'm not sure we can expect GDB to
be able to handle this situation, at least not with any sort of efficiency. 
It's already a difficult part of GDB's job, looking up types quickly.  I filed
a bug a few years ago where GDB macros slowed down by over 94x (from a few
seconds to over 11 minutes) due to a symbol lookup issue: it's a very sensitive
area.

Adding more complexity to this and asking GDB to try one variation of a given
type after another until it finds one seems less than optimal.

Even if it's decided that a change does need to happen on the GDB side,
hopefully GCC will continue to generate the expected debugging symbols until
that change is made and published in GDB.

[Bug c++/81977] Possible issue with inline memcpy with packed structures

[vvarada at codeaurora dot org]

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

--- Comment #1 from vvarada at codeaurora dot org ---
FYI: The issue shows up on previous versions of GCC compiler as well, as early
as 4.9.2 (have not tried earlier versions). 

Also if the "buffer" in main is declared as a static uint8_t array, the issue
does not show up. For some reason it shows up only when buffer is a pointer as
shown in the source snippet.

[Bug c++/81977] New: Possible issue with inline memcpy with packed structures

[vvarada at codeaurora dot org]

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

Bug ID: 81977
   Summary: Possible issue with inline memcpy with packed
structures
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vvarada at codeaurora dot org
  Target Milestone: ---

g++ -DOUTER  bug.cc -Wall -Wextra -fno-strict-aliasing -fwrapv

The following source yields different results when building with and without
optimizations (-O2). Compiling source did not result in any warnings.

Without: optimizations it prints 0xabcd which is expected
With -O2 optimization it prints 0x1617 

The issue appears to be due to incorrect offsets being computed for the
relevant fields resulting from the inlining of memcpy. 

If you look at the disassembly with -O2 the %edi argument on X64 is set to a
constant 0x1617 (5655 decimal) indicating the bug is at the compiler optimizer
itself.

By changing the size of *uint16_t header_info[2];* one gets different results
with -O2 as it picks different portions of _prefz.z for _pref.x.   

Thanks,
-Vijay

---


#include 
#include 
#include 

using namespace std;

void printval(int x) __attribute__((noinline));
void printval(int x)
{
   cout << hex << x << endl;
}

#define PACKED __attribute__((packed, aligned(1)))

typedef struct
{
   uint16_t  x ;
   uint16_t  y ;
   uint64_t  z ;
} PACKED TestMsgType;


struct Payload
{
  uint16_t header_info[2];
  TestMsgType _pref;
  void Pack(uint8_t *buffer)
  {
 memcpy(buffer, &_pref, sizeof(_pref));
  }
  void UnPack(uint8_t *buffer)
  {
 memcpy(&_pref, buffer, sizeof(_pref));
  }
};


struct Msg
{
   Payload _payload;
   void Pack(uint8_t *buffer)
   {
  _payload.Pack(buffer);
   }

   void UnPack(uint8_t *buffer)
   {
  _payload.UnPack(buffer);
   }
};

int main()
{
   uint8_t * buffer = new uint8_t [30];
   Msg msg;
   Msg msg1;
   msg._payload._pref.x = 0xabcd;
   msg._payload._pref.y = 0xa;
   msg._payload._pref.z = 0x0001020304051617;
   msg.Pack([0]);
   msg1.UnPack([0]);
   printval(msg1._payload._pref.x);
   delete [] buffer;
}

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor  ---
(In reply to Xi Ruoyao from comment #14)

The symbols in your example are the result/ouput of demangling but the issue
reported here is with the symbols that are input into GDB.  There is more than
one way to represent the same specialization of a template (e.g., B
and B, or A<2> and A<2u>, or even A<1 + 1>).  GDB should be able
to accept all of them and recognize they all refer to the same specialization.

[Bug c++/81976] New: bad is_standard_layout/has_unique_object_representations results with a chain of empty bases

[oremanj at mit dot edu]

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

Bug ID: 81976
   Summary: bad
is_standard_layout/has_unique_object_representations
results with a chain of empty bases
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oremanj at mit dot edu
  Target Milestone: ---

The C++ program below defines structures that each contain a 1-byte char field
and inherit linearly from various numbers of empty bases (one empty base for X,
two for Y, three for Z). By my reading of the standard, all of these should be
considered to be standard-layout and to have unique object representations.
However, under gcc 7.1, only X is considered to have unique object
representations, and only X and Y are considered to be standard-layout. (It
looks like Y was incorrectly considered to not be standard-layout until PR
80605.)

$ cat t.cc
struct A {};
struct B : A {};
struct C : B {};
struct X : A { char c; };
struct Y : B { char c; };
struct Z : C { char c; };
static_assert(__has_unique_object_representations(X));
static_assert(__has_unique_object_representations(Y));
static_assert(__has_unique_object_representations(Z));
static_assert(__is_standard_layout(X));
static_assert(__is_standard_layout(Y));
static_assert(__is_standard_layout(Z));

$ g++-7 -Wall -Wextra -c t.cc -std=c++17
t.cc:8:1: error: static assertion failed
 static_assert(__has_unique_object_representations(Y));
 ^
t.cc:9:1: error: static assertion failed
 static_assert(__has_unique_object_representations(Z));
 ^
t.cc:12:1: error: static assertion failed
 static_assert(__is_standard_layout(Z));
 ^

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.1.0-7'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-initfini-array
Thread model: posix
gcc version 7.1.0 (Debian 7.1.0-7)

[Bug middle-end/81908] [8 Regression] FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g -m32

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Patch committed in r251347.

[Bug middle-end/81908] [8 Regression] FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g -m32

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Fri Aug 25 00:25:57 2017
New Revision: 251347

URL: https://gcc.gnu.org/viewcvs?rev=251347=gcc=rev
Log:
PR middle-end/81908 - FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g -m32

gcc/ChangeLog:

PR middle-end/81908
* gimple-fold.c (size_must_be_zero_p): New function.
(gimple_fold_builtin_memory_op): Call it.

gcc/testsuite/ChangeLog:

PR middle-end/81908
* gcc.dg/tree-ssa/builtins-folding-gimple-2.c: New test.
* gcc.dg/tree-ssa/builtins-folding-gimple-3.c: New test.
* gcc.dg/tree-ssa/pr81908.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81908.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70410] no uninitialized variable warning if 'offsetof' is used in expression

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
gcc8 warns for me:

$ /usr/local/bin/g++ -c -Wuninitialized 70410.cc
70410.cc: In function ‘int main()’:
70410.cc:12:12: warning: ‘a’ is used uninitialized in this function
[-Wuninitialized]
  int b = a + offsetof(C, y); // <= missing warning that 'a' is uninitialized
^
$

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[egallager at gcc dot gnu.org]

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

Bug 70410 Summary: no uninitialized variable warning if 'offsetof' is used in 
expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70410

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug c++/66256] noexcept evaluation done before end of class

[david at doublewise dot net]

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

--- Comment #9 from David Stone  ---
Sorry, I misread the chain of comments, Jonathan Wakely's comment on gcc
correctly rejecting invalid code refers specifically to the decltype example.
Please ignore my previous comment, except that it captures the wording from the
standard that says that the test case for this bug should work.

[Bug c++/66256] noexcept evaluation done before end of class

[david at doublewise dot net]

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

David Stone  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #8 from David Stone  ---
I do not believe that gcc is correct to reject this code. Consider

http://eel.is/c++draft/basic.scope.class#1

"The potential scope of a name declared in a class consists not only of the
declarative region following the name's point of declaration, but also of all
function bodies, default arguments, noexcept-specifiers, and
brace-or-equal-initializers of non-static data members in that class (including
such things in nested classes)."

That seems to state that this variable is in scope and thus this code should be
allowed.

As a second test case, this should also be accepted (same code, but with e put
in an unevaluated context instead of being static):


struct test
{
test() noexcept(noexcept(e)) {}
const bool e = false;
};

int main() {}




And also



struct test
{
test() noexcept(noexcept(e())) {}
const bool e() { return false; }
};

int main() {}

[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda

[hacoo36 at gmail dot com]

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

Henry Cooney  changed:

   What|Removed |Added

 CC||hacoo36 at gmail dot com

--- Comment #1 from Henry Cooney  ---
I tested this behavior as of g++ 7.2.0; is_same still seems
to indicate that j is an int& inside the lambda. 

I think this behavior is probably incorrect WRT the language spec. For example,
the following code produces a compile-time error ('assignment of read-only
variable 'j''):


int main() {
  int i = 100;
  int  = i;
  cout << j;
  [=]() 
  {
cout << is_same::value
 << is_same::value;
cout << endl;
j = j + 1;
  }();

  cout << j;
}


That suggests that the correct type of j is indeed int const&, not int&!

[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses

[david at doublewise dot net]

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

David Stone  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #2 from David Stone  ---
Simpler test case:

struct S {
void f() noexcept(noexcept(this)) {}
};

int main() {}



Updated standard reference stating that this should be valid:
http://eel.is/c++draft/expr.prim.this#2

[Bug c++/81928] if(!this) optimization leads to possible errors without warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #23 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #22)
> Either explain more clearly what you're asking for, or accept it already
> warns about this.

The descriptive style of GCC's diagnostics is a recurrent problem for some
users who are not aware of the details of the language. We had countless of
discussions about it in the past. Clang's diagnostics tend to be more
prescriptive:

warning: 'this' pointer cannot be null in well-defined C++ code; pointer may be
assumed to always convert to true

Some other examples:

 $ gcc
error: invalid type argument of unary ‘*’ (have ‘int’)
 $ clang
error: indirection requires pointer operand ('int' invalid)

 $ gcc
warning: wrong type argument to increment [-Wpedantic]
 $ clang
warning: arithmetic on a pointer to void is a GNU extension [-Wpointer-arith]

 $ gcc
error: invalid operands to binary / (have 'float __vector__' and 'const int *')
 $ clang
error: can't convert between vector values of different size ('__m128' and 'int
const *')

[Bug c++/81975] New: Unpacking two packs via alias erroneously complains about mismatched argument packs

[barry.revzin at gmail dot com]

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

Bug ID: 81975
   Summary: Unpacking two packs via alias erroneously complains
about mismatched argument packs
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Example slightly reduced from http://lists.isocpp.org/core/2017/08/2827.php:

template 
struct is_same;

struct make_list
{
template  
using f = void;
};

template class F, typename... Ts> 
struct zip_with
{
#ifdef ALIAS
template  
using continuation_t = typename C::template f...>;
#else
template  
struct continuation {
using type = typename C::template f...>;
};  

template  
using continuation_t = typename continuation::type;
#endif

template 
using f = continuation_t;
};

using T = zip_with::f<>;
using U = zip_with::f;
using V = zip_with::f;

Compiling with -DALIAS works fine. Compiling without it leads to errors for T
and V  (but not U!) about mismatched argument pack lengths while expanding
F. The two formulations should be equivalent.

[Bug fortran/81974] New: ICE verify_gimple failed type mismatch in binary expression

[zeccav at gmail dot com]

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

Bug ID: 81974
   Summary: ICE verify_gimple failed  type mismatch in binary
expression
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

! ICE verify_gimple failed Error: type mismatch in binary expression
! must be compiled with -O option
  COMPLEX(kind=kind(0d0)), DIMENSION(10, 10) :: R
  REAL(kind=kind(0d0)), DIMENSION(10, 10):: M
  print *,MATMUL(TRANSPOSE(CONJG(R)), M)
  END
!/home/vitti/f95/gfbug143.f:3:0:

!   COMPLEX(kind=kind(0d0)), DIMENSION(10, 10) :: R

!Error: type mismatch in binary expression
!complex(kind=4)

!complex(kind=8)

!complex(kind=8)

!_26 = _19 * _25;
!/home/vitti/f95/gfbug143.f:3:0: Error: type mismatch in binary expression
!complex(kind=8)

!complex(kind=8)

!complex(kind=4)

!_32 = _12 + _26;
!/home/vitti/f95/gfbug143.f:3:0: internal compiler error: verify_gimple failed
!0xd8595d verify_gimple_in_seq(gimple*)
!   ../../gcc/gcc/tree-cfg.c:4978
!0xb41cad gimplify_body(tree_node*, bool)
!   ../../gcc/gcc/gimplify.c:12593
!0xb41e7c gimplify_function_tree(tree_node*)
!   ../../gcc/gcc/gimplify.c:12683
!0x9dce17 cgraph_node::analyze()
!   ../../gcc/gcc/cgraphunit.c:670
!0x9df5f3 analyze_functions
!   ../../gcc/gcc/cgraphunit.c:1131
!0x9e04b2 symbol_table::finalize_compilation_unit()
!   ../../gcc/gcc/cgraphunit.c:2609
!Please submit a full bug report,
!with preprocessed source if appropriate.
!Please include the complete backtrace with any bug report.
!See  for instructions.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[romain.services at mm dot st]

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

--- Comment #8 from Romain  ---
Hi Jack,

Thanks. My system is a Core i7 (HT enabled), so I have 8 cores, good catch!

Regards,
Romain

[Bug c++/71974] Warning: uninitialized variable with OpenMP nested loops

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, openmp
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-24
 CC||egallager at gcc dot gnu.org
 Blocks||24639
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Rafael Guglielmetti from comment #1)
> With gcc 6.1.1, the above code gives rise to the error:
> error: condition expression refers to iteration variable ‘i’
> 
> So I suppose my syntax was incorrect. It is annoying tough.

Do you have a version of your code that avoids that error? I get it, too, and
so I can't reproduce the warning with that error there... WAITING on a valid
testcase.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed that g++ prints 3 -Wsequence-point warnings on each testcase. 

(the followup one is missing an include for , but after that, it
behaves as reported)

[Bug libstdc++/81964] istream_iterator: unexpected read in ctor

[abominable-snowman at yandex dot ru]

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

--- Comment #2 from Petr Ovtchenkov  ---
https://gcc.gnu.org/ml/libstdc++/2017-08/msg00033.html

[Bug tree-optimization/81953] Code sinking increases register pressure

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen  ---
(In reply to Richard Biener from comment #3)

> The interesting part is also why RTL scheduling doesn't rectify things
> here?

If you're referring to -fsched-pressure, I believe the answer is that those
algorithms are concerned about the case where pressure is more than available
hard regs, which is not the case here.

[Bug c++/81236] Crash when calling a template member function from generic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Created attachment 42041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42041=edit
Patch under test

[Bug c++/81973] Aliased virtual methods are treated as undefined, so the vtable is not generated

[blaffablaffa at gmail dot com]

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

--- Comment #1 from Lorenzo Pistone  ---
It is possible to obtain the desired behavior defining in a compilation unit a
dummy s::f with weak attribute (and so generate the vtable), then in a separate
compilation the actual alias of s::f to s_f_alias, but this it is an
impractical workaround.

[Bug c++/71797] Spurious unused-variable warning with inline function and unrelated error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
I can't reproduce this bug; only the error is printed, with no warning for me:

$ /usr/local/bin/g++ -c -Wall -Wunused-const-variable=2 -Wextra -pedantic
71797.cc
71797.cc: In constructor ‘Foo::Foo()’:
71797.cc:8:13: error: ‘create_a_compile_error’ was not declared in this scope
 Foo() { create_a_compile_error; };
 ^~
$

[Bug c++/67906] Missing warning about std::move without effect

[egall at gwmail dot gwu.edu]

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

--- Comment #6 from Eric Gallager  ---
On 8/24/17, Mykola Orliuk  wrote:
> Hello
>
> Sure,
>
> struct Value {
> Value();
> Value(const Value&);
> Value(Value&&);
> };
>
> struct Frame {
> Value value; // previously mutable
> };
>
> Frame top;
> const Frame& x = top;
> Value y = std::move(x.value);
>
>
> https://godbolt.org/g/v24FfQ
>
> Thank you for looking into it. Yes, there should be better names than
> -Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.
>
> Such warning will help to identify places which become ineffecient after
> changing constness of something.
>
> P.S. By some reason I were not able to leave comment in Bugzilla and got
> message "User account creation filtered due to spam." though I were logged
> in.
>

No, your comment still went through, 3 times in fact. The "User
account creation filtered due to spam" message is pinned to the top
for display to everyone; it doesn't actually mean that anything is
wrong with your account.

> Thank you,
> Mykola
>
> On Thu, Aug 24, 2017 at 7:40 AM egallager at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
>>
>> Eric Gallager  changed:
>>
>>What|Removed |Added
>>
>> 
>>Keywords||diagnostic
>>  Status|UNCONFIRMED |WAITING
>>Last reconfirmed||2017-08-24
>>  CC||egallager at gcc dot
>> gnu.org
>>  Ever confirmed|0   |1
>>
>> --- Comment #1 from Eric Gallager  ---
>> Could you please provide a complete self-contained example? The snippet
>> you
>> posted looks like it's missing some declarations:
>>
>> $ /usr/local/bin/g++ -c 67906.cc
>> 67906.cc:1:7: error: ‘Frame’ does not name a type
>>  const Frame& x = stack.top();
>>^
>> 67906.cc:2:1: error: ‘Value’ does not name a type
>>  Value y = std::move(x.value); // x.value - non-mutable
>>  ^
>> $
>>
>> Anyways, bug 81159 is related, but that's about a different misuse of
>> std::move, so I'll keep the 2 separate.
>>
>> Oh, and also "-Wno-effect" would probably be a bad name for the option,
>> since
>> "-Wno-" is reserved for negative versions of warnings. i.e., is
>> "-Wno-effect"
>> the negative of "-Weffect"? That seems wrong. Or is it already in the
>> positive,
>> in which case the negative is "-Wno-no-effect"? That would seem
>> redundant.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>

[Bug c++/67906] Missing warning about std::move without effect

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Eric Gallager  ---
Thanks. Testcase still needs:

#include 

at the top, but once I've added that, confirmed that there's no warning about
the usage of std::move.

[Bug c++/81973] New: Aliased virtual methods are treated as undefined, so the vtable is not generated

[blaffablaffa at gmail dot com]

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

Bug ID: 81973
   Summary: Aliased virtual methods are treated as undefined, so
the vtable is not generated
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blaffablaffa at gmail dot com
  Target Milestone: ---

test case:


#include 
using namespace std;

struct b{
int a;
virtual void f(){
cout<<__PRETTY_FUNCTION__<<' '<

[Bug c++/67906] Missing warning about std::move without effect

[virkony at gmail dot com]

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

--- Comment #4 from Nikolay Orliuk  ---
Hello

Sure,

struct Value {
Value();
Value(const Value&);
Value(Value&&);
};

struct Frame {
Value value; // previously mutable
};

Frame top;
const Frame& x = top;
Value y = std::move(x.value);


https://godbolt.org/g/v24FfQ

Thank you for looking into it. Yes, there should be better names than
-Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.

Such warning will help to identify places which become ineffecient after
changing constness of something.

P.S. By some reason I were not able to leave comment in Bugzilla and got
message "User account creation filtered due to spam." though I were logged
in.

Thank you,
Mykola

On Thu, Aug 24, 2017 at 7:40 AM egallager at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
>
> Eric Gallager  changed:
>
>What|Removed |Added
>
> 
>Keywords||diagnostic
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2017-08-24
>  CC||egallager at gcc dot
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Eric Gallager  ---
> Could you please provide a complete self-contained example? The snippet you
> posted looks like it's missing some declarations:
>
> $ /usr/local/bin/g++ -c 67906.cc
> 67906.cc:1:7: error: ‘Frame’ does not name a type
>  const Frame& x = stack.top();
>^
> 67906.cc:2:1: error: ‘Value’ does not name a type
>  Value y = std::move(x.value); // x.value - non-mutable
>  ^
> $
>
> Anyways, bug 81159 is related, but that's about a different misuse of
> std::move, so I'll keep the 2 separate.
>
> Oh, and also "-Wno-effect" would probably be a bad name for the option,
> since
> "-Wno-" is reserved for negative versions of warnings. i.e., is
> "-Wno-effect"
> the negative of "-Weffect"? That seems wrong. Or is it already in the
> positive,
> in which case the negative is "-Wno-no-effect"? That would seem redundant.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/67906] Missing warning about std::move without effect

[virkony at gmail dot com]

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

--- Comment #3 from Nikolay Orliuk  ---
Sure,

struct Value {
Value();
Value(const Value&);
Value(Value&&);
};

struct Frame {
Value value; // previously mutable
};

Frame top;
const Frame& x = top;
Value y = std::move(x.value);

Thank you for looking into it. Yes, there should be better names than
-Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.

Such warning will help to identify places which become ineffecient after
changing constness of something.

[Bug c++/67906] Missing warning about std::move without effect

[virkony at gmail dot com]

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

--- Comment #2 from Nikolay Orliuk  ---
Sure,

struct Value {
Value();
Value(const Value&);
Value(Value&&);
};

struct Frame {
Value value; // previously mutable
};

Frame top;
const Frame& x = top;
Value y = std::move(x.value);


https://godbolt.org/g/v24FfQ

Thank you for looking into it. Yes, there should be better names than
-Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.

Such warning will help to identify places which become ineffecient after
changing constness of something.

[Bug c/57201] Using --save-temps affects whether warning is printed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||albert.astals at canonical dot 
com

--- Comment #14 from Eric Gallager  ---
*** Bug 71517 has been marked as a duplicate of this bug. ***

[Bug c++/71517] g++ gives different warnings if compiling a file directly or adding preprocess step

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
Dup of bug 57201

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

[Bug c++/70644] Warn about implicit conversion of 'this' to pointer to virtual base class during construction

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c++/79008] missing detail in -Wbuiltin-declaration-mismatch

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from Martin Sebor  ---
I think what I had in mind was incompatible attribute specifications rather
than missing ones but my description sounds a little confused. 
-Wbuiltin-declaration-mismatch also doesn't diagnose incompatible attributes
(maybe it should).

One example of an incompatibility is the following declaration:

  int __attribute__ ((pure)) abs (int);

where abs() the built-in is actually declared const.  GCC doesn't currently
diagnose this except with my patch for bug 81544 (yet to be reviewed).

Another, slightly different, example is declaring a standard library function
with the wrong attributes, like this one:

void* __attribute__ ((malloc, alloc_size (1))) realloc (void*, size_t);

This is wrong on two counts: first, realloc cannot be declared with attribute
malloc because it need not return a unique pointer.  Second, alloc_size
specifies the wrong argument (this is bug 78667).

Since many built-in functions are decorated with multiple attributes it seems
that rather than pointing out these kinds of issues one attribute at a time
(either when there are more than one or as the user adjusts their declaration)
it would be simpler and more user-friendly to include in the diagnostic all the
attributes the built-in is decorated with.  Hence the suggestion to introduce a
a new flag (and perhaps also a conversion specifier) to the pretty printer to
have it (optionally) print the whole attribute list, or parts of it.

E.g.,

  warning ("%#qD conflicts with built-in declaration %#qD", user_decl,
builtin_in_decl);

might print

  warning: ‘int abs(int) __attribute__ ((pure))’ conflicts with built-in
declaration ‘int abs(int) __attribute__ ((const))’

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #14 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #13)
> (In reply to Xi Ruoyao from comment #11)
> 
> The target demangler is (or can be) different on each target and, as I said,
> different producers use different strings (for example, neither Clang nor
> IBM XLC++ includes the suffix, and Oracle CC on Linux uses the cast
> notation).
> 
> The most natural representation of an integer in C++ (and in C) is a decimal
> literal with no suffix (unless its value doesn't fit in the signed integer
> with the greatest precision).
> 
> So my opinion that you asked for is that insisting on anything else is an
> inferior choice.  If you don't share it please do no feel compelled to
> convince me of yours.

See below:

a.cc:
~
template  struct a {int foo() {return -x;}};
template struct a<1>;
~

and b.cc:
~
template  struct a {int foo();};
int main() {return a<1>().foo();}
~

This error happens when a library's ABI changes, and someone tries to link old
object code to the new library.  With libiberty's demangle (in GNU ld), we have
error message:

/tmp/ccKFWvhT.o: In function `main':
b.cc:(.text+0x10): undefined reference to `a<1u>::foo()'
collect2: error: ld returned 1 exit status

But what would we get with "natural" expression?

b.cc:(.text+0x10): undefined reference to `a<1>::foo()'

It's hard to know what happened.  We have two different mangled name with the
same demangled name.  It's strange and could be a new example in "How not to
programming in C++".

[Bug c++/69864] Fix various Wnarrowing minor issues

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords|documentation   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #13 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Because int b{2.3} absolutely definitely loses precision, and since it's a
> > constant you can just fix the code.
> > 
> > For {u} the compiler doesn't know whether it really narrows or not, since it
> > depends on un time values, so it gives you the benefit of the doubt.
> 
> I updated the FAQ, but I actually agree with mgsergio that this behavior is
> inconsistent and not at all how other -Wflags behave. The fact that we have
> to do ugly kludges in the code to support this makes it only more obvious.
> 
> I'm actually going to reopen this to propose some improvements that perhaps
> someone would decide to tackle as easy hacks:
> 
> * Document that -Wnarrowing also emits errors in doc/invoke.texi
> 
> * Make the message for the error and the warning different, for example:
> 
> narrowing conversion of constant expression from 'double' to 'int' inside { }
> 
> * Do not pretty-print expressions! '2.2998e+0' is very ugly and
> I'm sure one can easily trick GCC to print absolute non-sense. That is,
> remove %qE and use proper locations/ranges.
> 
> * Create a new function in diagnostic.c, e.g., 
> 
> extern diagnostic_t pederror (location_t, int, const char *, ...)
>  ATTRIBUTE_GCC_DIAG(3,4);
> 
> and replace the kludge in cp/typeck2.c with it (possibly fixing PR69872
> along the way). Document when some warnings might be errors (like we have
> precise definitions for permerror/pedwarn).

Documentation part is done per comment #12, but I'm still confirming that some
of these other suggestions could still be done, too.

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Correction, the reconstruction happens *prior* to swap optimization so the
latter can't make the patterns unrecognizable.

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
OK, so the problem is in the swaps pass.  It's just that the add of 16 is
correctly placed in every prior optimization pass following ivopts, which has
shifted it around in the usual fashion.  Prior to swap optimization, the store
is performed to the address prior to the add of 16, but following swap
optimization, it is performed to the address following the add of 16.

This is a post-pass performed after the usual swap optimization to identify
patterns that should be turned into an lvx or stvx.  However, there appears to
be a bug wherein the source operand chosen is not checked for continued
availability at the point of the store.  The register chosen has been
overwritten, leading to incorrect code.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
(In reply to Xi Ruoyao from comment #11)

The target demangler is (or can be) different on each target and, as I said,
different producers use different strings (for example, neither Clang nor IBM
XLC++ includes the suffix, and Oracle CC on Linux uses the cast notation).

The most natural representation of an integer in C++ (and in C) is a decimal
literal with no suffix (unless its value doesn't fit in the signed integer with
the greatest precision).

So my opinion that you asked for is that insisting on anything else is an
inferior choice.  If you don't share it please do no feel compelled to convince
me of yours.

[Bug target/81909] [nvptx] Missing warning in gcc.dg/pr53037-{2,3}.c

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Target|nvptx   |nvptx, arm-none-eabi
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 CC||thopre01 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Preud'homme  ---
Same issue on arm-none-eabi targets

[Bug c++/70328] default generated destructors cause 'inlining failed' warnings.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Could you please provide a testcase so we can verify?

[Bug go/81966] runtime.inc:362:10: error: duplicate member ‘_’

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
I should add that parts of libgo are tied to parts of gcc/go, and I don't
actually know whether using the trunk libgo and the GCC 7 gcc/go will work at
all.  Sorry.

[Bug c++/81236] Crash when calling a template member function from generic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #4 from Jason Merrill  ---
(In reply to Jason Merrill from comment #3)
> (In reply to Guillaume Racicot from comment #0)
> > This code is valid and compiles under clang (3.8.0)
> 
> It isn't valid; with make_crash you're trying to use a function parameter
> as a non-type template argument.

Oops, I wasn't noticing the integral_constant type; the testcase isn't actually
trying to use i as an rvalue.  So it's more like

template  void f();
struct A { constexpr operator int() { return 24; } };
template  constexpr void g(T t)
{
  f();
}

int main()
{
  g(A());
}

[Bug go/81966] runtime.inc:362:10: error: duplicate member ‘_’

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
The patch is to a file in gcc/go/gofrontend, not to a file in libgo.  You
probably can not simply copy the gcc/go directory from trunk to GCC 7, as it
will expect other changes.  But you can apply the patch itself, which is small,
to gcc/go/gofrontend/types.cc.

[Bug c++/81236] Crash when calling a template member function from generic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jason Merrill  ---
(In reply to Guillaume Racicot from comment #0)
> This code is valid and compiles under clang (3.8.0)

It isn't valid; with make_crash you're trying to use a function parameter as
a non-type template argument.  A simplified version would be

template  void f();

template  constexpr void g(T t)
{
  f();
}

int main()
{
  g(42);
}

which gcc and clang both properly reject.

[Bug c++/81972] New: Improve data tracking for simple conditional code

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 81972
   Summary: Improve data tracking for simple conditional code
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

[code]
__attribute__((nonnull(1)))
void f1(int*);

void f2(int* n)
{
int* ptr = nullptr;
if (*n > 2)
ptr = n;
f1(ptr);
}

void f3(int* n)
{
if (*n > 2)
f1(n);
else
f1(nullptr);
}
[/code]

Functions f2 and f3 are equivalent. Above code compiled by gcc 7.2 (with -O3
-Wall -Wextra) generates following assembler code:

[code]
f2(int*):
  cmp DWORD PTR [rdi], 2
  mov eax, 0
  cmovle rdi, rax
  jmp f1(int*)
f3(int*):
  cmp DWORD PTR [rdi], 2
  jg .L7
  xor edi, edi
.L7:
  jmp f1(int*)
[/code]

There are two issues here:
- both functions contains bug, they try to pass NULL pointer to f1. However gcc
reports this for f3 only. gcc is able to track data for optimization purposes,
so it should be possible to generate warning for f2.
- f3 is compiled to code with branch, so most probably it will be slower a bit.
It could be optimized to get the same code as f2 (branchless).

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

--- Comment #12 from Paul Smith  ---
Xi Ruoyao (comment #9):
> This works for:

Excellent.

[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug go/81966] runtime.inc:362:10: error: duplicate member ‘_’

[mfe at live dot de]

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

--- Comment #2 from martin  ---
I copied the folder of svn://gcc.gnu.org/svn/gcc/trunk/libgo/ to the
gcc-7.2.0/libgo folder. When I'm using the trunk it should contain the patch?
Shouldn't that work?

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #11 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #10)
> Unless the exact format for non-type template arguments is specified in
> DWARF (I don't think it is) it seems that a more robust solution is to
> enhance GDB to be able to understand types with and without the suffix (and
> other equivalent forms).
> 
> In the type system there is no difference between A<2>, A<2U>, or
> A<(unsigned int)2> and all three are emitted as the DW_AT_name by compilers
> for A instantiated with the value 2.
> 
> But Jason is the DWARF expert so he should weigh in on this question.

DWARF 5 2.15(Identifier Names):

> Because the names of program objects described by DWARF are the names as
> they appear in the source program, implementations of language translators
> that use some form of mangled name (as do many implementations of C++)
> should use the unmangled form of the name in the DW_AT_name attribute...

And DWARF wiki :

> For template instantiations, the DW_AT_name attribute should contain both
> the source language name of the object and the template parameters that
> distinguish one instantiation from another. The resulting string should
> be in the natural form for the language, and should have a canonical
> representation (i.e., different producers should generate the same
> representation). For C++, the string should match that produced by the
> *target platform's canonical demangler*; spaces should only be inserted
> where syntactically required by the compiler.

Here our canonical demangler should be c++filt.  And c++filt produce names
with type suffix.

[Bug go/81970] carchive gotools tests fail

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu,
   ||powerpc64le-unknown-linux-g
   ||nu

--- Comment #1 from Uroš Bizjak  ---
Looks like powerpc64le is affected, too:

https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg01996.html

[Bug c++/81971] New: internal compiler error: in check_noexcept_r, at cp/except.c:1028

[rwdougla at gmail dot com]

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

Bug ID: 81971
   Summary: internal compiler error: in check_noexcept_r, at
cp/except.c:1028
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rwdougla at gmail dot com
  Target Milestone: ---

int foo(int) { return 0; }

template
struct Foo
{
bool val = requires {
{foo(T{})} -> int;
};
};

int main()
{
Foo f;
return 0;
}


using gcc 7.2 with --std=c++1z --concepts -Wall
https://godbolt.org/g/kC6QpW

[Bug bootstrap/81960] gcc doesn't compile on MAC OS X

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jürgen Reuter from comment #5)
> Is this fix committed to the gcc svn already?

https://gcc.gnu.org/ml/gcc-cvs/2017-08/msg00582.html

[Bug bootstrap/81960] gcc doesn't compile on MAC OS X

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter  ---
(In reply to Uroš Bizjak from comment #4)
> Fixed.

Is this fix committed to the gcc svn already?

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Unless the exact format for non-type template arguments is specified in DWARF
(I don't think it is) it seems that a more robust solution is to enhance GDB to
be able to understand types with and without the suffix (and other equivalent
forms).

In the type system there is no difference between A<2>, A<2U>, or A<(unsigned
int)2> and all three are emitted as the DW_AT_name by compilers for A
instantiated with the value 2.

But Jason is the DWARF expert so he should weigh in on this question.

[Bug rtl-optimization/81955] corrupted double-linked list (not small)

[adpc at riseup dot net]

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

--- Comment #6 from Ad PC  ---
Created attachment 42040
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42040=edit
preprocessed source -- used split -n 2 and bzip2 -- part 2

[Bug rtl-optimization/81955] corrupted double-linked list (not small)

[adpc at riseup dot net]

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

--- Comment #5 from Ad PC  ---
Created attachment 42039
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42039=edit
used split -n 2 and bzip2 -- part 1

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

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

> I'll try more -gxxx options to see if we need a new flag.

This works for:

-g
-g2
-g3
-ggdb
-ggdb2
-ggdb3
-gdwarf
-gdwarf-{2,3,4}
-gdwarf -gstrict-dwarf
-g -gz

Not works for:

-g1, -ggdb1 (GCC 7.2 also doens't work, say "no symbol tv")
-gstabs{,+} (Don't support templates at all)

Not tested:

-gvmx -gcoff -gxcoff (Don't support Linux target)
-gdwarf-5 (My GDB can't read it)

[Bug tree-optimization/81913] [8 Regression] wrong code at -O1

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Aug 24 15:38:39 2017
New Revision: 251337

URL: https://gcc.gnu.org/viewcvs?rev=251337=gcc=rev
Log:
PR tree-optimization/81913
* tree-ssa-loop-niter.c (number_of_iterations_cond): Skip niter
analysis when either IVs in condition can wrap.

gcc/testsuite
* gcc.c-torture/execute/pr81913.c: New test.
* gcc.dg/tree-ssa/loop-niter-1.c: New test.
* gcc.dg/tree-ssa/loop-niter-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr81913.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-niter-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-niter-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug go/81970] New: carchive gotools tests fail

[ubizjak at gmail dot com]

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

Bug ID: 81970
   Summary: carchive gotools tests fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ubizjak at gmail dot com
CC: cmang at google dot com
  Target Milestone: ---

Following carchive gotools tests fail in gccgo testsuite:

FAIL: TestCgoCallbackGC
FAIL: TestInstall
FAIL: TestEarlySignalHandler
FAIL: TestSignalForwarding
FAIL: TestSignalForwardingExternal
FAIL: TestOsSignal
FAIL: TestSigaltstack
FAIL: TestPIE

The problem can be seen from the gotools log dump:

=== RUN   TestInstall
FAIL: TestInstall
carchive_test.go:160: [gcc -fPIC -m64 -pthread
-fmessage-length=0
-fdebug-prefix-map=/tmp/go-build828417309=/tmp/go-build
-gno-record-gcc-switches -funwind-tables -I pkg/gccgo_linux_amd64_fPIC
-o ./testp1 main.c main_unix.c pkg/gccgo_linux_amd64_fPIC/liblibgo.a
-lgo]
carchive_test.go:162:
pkg/gccgo_linux_amd64_fPIC/liblibgo.a(a.out.a.o): In function
`__go_init_main':
/tmp/go-build/libgo/_obj/_cgo_gotypes.go:3: undefined
reference to `runtime.registerGCRoots'
pkg/gccgo_linux_amd64_fPIC/liblibgo.a(a.out.a.o): In
function `__go_init_main':

/home/uros/gcc-build/gotools/carchive-test-dir/misc/cgo/testcarchive/src/libgo/libgo.go:18:
undefined reference to `runtime.writeBarrier'

/home/uros/gcc-build/gotools/carchive-test-dir/misc/cgo/testcarchive/src/libgo/libgo.go:18:
undefined reference to `runtime.writebarrierptr'
pkg/gccgo_linux_amd64_fPIC/liblibgo.a(a.out.a.o): In
function `gostart':

/home/uros/gcc-build/x86_64-pc-linux-gnu/libgo/../../../git/gcc/libgo/runtime/go-libmain.c:111:
undefined reference to `runtime.schedinit'

/home/uros/gcc-build/x86_64-pc-linux-gnu/libgo/../../../git/gcc/libgo/runtime/go-libmain.c:112:
undefined reference to `runtime.main'
collect2: error: ld returned 1 exit status
carchive_test.go:163: exit status 1

The compiler in carchive_test.go:160 is called with the following command:

gcc -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build828417309=/tmp/go-build
-gno-record-gcc-switches -funwind-tables -I pkg/gccgo_linux_amd64_fPIC
-o ./testp1 main.c main_unix.c pkg/gccgo_linux_amd64_fPIC/liblibgo.a
-lgo

Please note that with -lgo, the default system-wide libgo shared
library is linked in. However, the test expects newly compiled library
from the libgo build directory. Manually adding correct -L path to the
above command builds functional executable.

 (The system-wide library in the above example is installed from the
current gcc-7 branch).

[Bug rtl-optimization/81955] corrupted double-linked list (not small)

[adpc at riseup dot net]

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

--- Comment #4 from Ad PC  ---
"The file you are trying to attach is 13217 kilobytes (KB) in size. Attachments
cannot be more than 1000 KB."

[Bug go/81966] runtime.inc:362:10: error: duplicate member ‘_’

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
This is already fixed on trunk by https://golang.org/cl/40701.  That patch was
not backported to the GCC 7 branch, but you could backport it yourself easily
enough.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #8 from Xi Ruoyao  ---
(In reply to Paul Smith from comment #7)
> I'm not sure what the impacts of "if (pp->flags & pp_c_flag_gnu_v3)" are;
> does this mean it only works if you specify -ggdb3?  Is that the right
> thing?  I don't know what the differences are between the different debug
> types.

I'm neither...  But this flag is set for -g, too.

I'll try more -gxxx options to see if we need a new flag.

[Bug other/81969] New: "el" escape sequence in coloring yields incorrect message in some terminals

[vincent-gcc at vinc17 dot net]

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

Bug ID: 81969
   Summary: "el" escape sequence in coloring yields incorrect
message in some terminals
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider a tst.c file:

int foo (void)
{
  int x, xx;
  return x + xx;
}

In a 80-column xterm, I get (where | represents the right border of the
terminal):

cventin% gcc-6 -Wall -c tst.c  
|
tst.c: In function ‘foo’:  
|
tst.c:4:12: warning: ‘x’ is used uninitialized in this function
[-Wuninitialize]|
   return x + xx;  
|
  ~~^~~~   
|
tst.c:4:12: warning: ‘xx’ is used uninitialized in this function
[-Wuninitialize|
d] 
|

i.e. the "d" of -Wuninitialized is missing in the first message.

In a 80-column rxvt, I get:

cventin% gcc-6 -Wall -c tst.c  
|
tst.c: In function ‘foo’:  
|
tst.c:4:12: warning: ‘x’ is used uninitialized in this function [-Wuninitialize
|
]  
|
   return x + xx;  
|
  ~~^~~~   
|
tst.c:4:12: warning: ‘xx’ is used uninitialized in this function
[-Wuninitialize|
d] 
|

Here the "d" is replaced by a space.

In the xterm logs, I see a \E[K ("el" escape sequence, which clears to the end
of the line) after the first 80 characters. Thus this may be the same bug as in
grep: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15444
I quote:

  The EL command (\E[K) is sent to clear the line. The VT100
  terminal autowraps when the 81th character is received and the
  EL command is not counted as a character. So if 80 characters
  are received, it waits on the 80th character and the following
  EL command erases characters from the current one to the end
  of line (i.e. the last character on the line).

[Bug bootstrap/81965] [8 Regression] ICE in stage 2 compiler while configuring libgcc in stage 2, during GIMPLE pass: cfg

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

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

--- Comment #4 from Rainer Emrich  ---
Ok, found it. That's an issue of binutils trunk from this morning, strange.
Using binutils-2.29 works as expected.
Will have an eye at binutils trunk. If the issue persist I will open an PR in
the binutils bugzilla.

Closing the PR as invalid.

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

[rguenther at suse dot de]

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

--- Comment #1 from rguenther at suse dot de  ---
On August 24, 2017 4:18:45 PM GMT+02:00, "ro at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
>Bug ID: 81968
>Summary: [8 regression] early lto debug objects make Solaris ld
>SEGV
>   Product: gcc
>   Version: 8.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: lto
>  Assignee: unassigned at gcc dot gnu.org
>  Reporter: ro at gcc dot gnu.org
>  CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
>  Target Milestone: ---
>Target: *-*-solaris2.11
>
>The Early LTO Debug patches caused a large number of testsuite
>regressions on
>Solaris when using /bin/ld:
>
>+UNRESOLVED: g++.dg/lto/20101010-4
>cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o
>execute  -std=c++0x -flto -g -r -nostdlib 
>+FAIL: g++.dg/lto/20101010-4
>cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link, 
>-std=c++0x -flto -g -r -nostdlib 
>
>They all are like
>
>FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c  -O3 -flto -g  (test for
>excess
>errors)
>Excess errors:
>collect2: fatal error: ld terminated with signal 11 [Segmentation
>Fault]
>compilation terminated.
>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [1] has
>invalid type [
>SHT_NULL ]
>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [5] contains
>both
>SHF_EXCLUDE and SHF_ALLOC flags: SHF_EXCLUDE ignored
>
>The same problem happens when gcc is configured to use gas and ld
>instead of
>as/ld, sparc and x86, 32 and 64-bit.
>
>Clearly a SEGV isn't the best error handling, and I'm not yet certain
>if the
>errors
>are benign.  OTOH, I don't yet know why the objects are created this
>way.

They are created that way to make my life easier. They are supposed to be valid
ELF objects and they are according to the specs and my interpretation. 

>
>  Rainer

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

--- Comment #7 from Paul Smith  ---
I'm not sure what the impacts of "if (pp->flags & pp_c_flag_gnu_v3)" are; does
this mean it only works if you specify -ggdb3?  Is that the right thing?  I
don't know what the differences are between the different debug types.

Thanks for picking up this issue so quickly!

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
I don't think this has anything to do with the swaps pass.  I see the same
wrong code generation with -mno-optimize-swaps.  I'll continue to investigate.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #6 from Xi Ruoyao  ---
Created attachment 42038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42038=edit
patch proposal

This patch turn on the type suffix of integer constants in debug info.

It's not tested well yet.

[Bug bootstrap/81960] gcc doesn't compile on MAC OS X

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|libgcc  |bootstrap
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from Uroš Bizjak  ---
Fixed.

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

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

[ro at gcc dot gnu.org]

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

Bug ID: 81968
   Summary: [8 regression] early lto debug objects make Solaris ld
SEGV
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

The Early LTO Debug patches caused a large number of testsuite regressions on
Solaris when using /bin/ld:

+UNRESOLVED: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o
execute  -std=c++0x -flto -g -r -nostdlib 
+FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link, 
-std=c++0x -flto -g -r -nostdlib 

They all are like

FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c  -O3 -flto -g  (test for excess
errors)
Excess errors:
collect2: fatal error: ld terminated with signal 11 [Segmentation Fault]
compilation terminated.
ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [1] has invalid type [
SHT_NULL ]
ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [5] contains both
SHF_EXCLUDE and SHF_ALLOC flags: SHF_EXCLUDE ignored

The same problem happens when gcc is configured to use gas and ld instead of
as/ld, sparc and x86, 32 and 64-bit.

Clearly a SEGV isn't the best error handling, and I'm not yet certain if the
errors
are benign.  OTOH, I don't yet know why the objects are created this way.

  Rainer

[Bug target/81921] [5/6/7 Regression] Fails to always-inline intrinsics with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[5/6/7/8 Regression] Fails  |[5/6/7 Regression] Fails to
   |to always-inline intrinsics |always-inline intrinsics
   |with -flto  |with -flto
  Known to fail|8.0 |

--- Comment #2 from Richard Biener  ---
Fixed on trunk sofar.

[Bug debug/81936] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.c:5543

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #19 from Richard Biener  ---
Fixed.

[Bug debug/81936] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.c:5543

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 24 13:41:51 2017
New Revision: 251332

URL: https://gcc.gnu.org/viewcvs?rev=251332=gcc=rev
Log:
2017-08-24  Richard Biener  

PR debug/81936
* dwarf2out.c (output_die): Handle flag_generate_offload like
flag_generate_lto.
(output_comp_unit): Likewise.
(gen_array_type_die): Likewise.
(dwarf2out_early_finish): Likewise.
(note_variable_value_in_expr): Likewise.
(dwarf2out_finish): Likewise.  Adjust assert.
* cgraphunit.c (symbol_table::compile): Move setting of
flag_generate_offload earlier ...
(symbol_table::finalize_compilation_unit): ... here, before
early debug finalization.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/dwarf2out.c

[Bug target/81921] [5/6/7/8 Regression] Fails to always-inline intrinsics with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 24 13:44:35 2017
New Revision: 251333

URL: https://gcc.gnu.org/viewcvs?rev=251333=gcc=rev
Log:
2017-08-23  Richard Biener  

PR target/81921
* targhooks.c (default_target_can_inline_p): Properly
use target_option_default_node when no DECL_FUNCTION_SPECIFIC_TARGET
is present and always compare.
* config/i386/i386.c (ix86_valid_target_attribute_tree): Do not
imply -mfpmath=sse from TARGET_SSE_P.
(ix86_can_inline_p): Properly use target_option_default_node when
no DECL_FUNCTION_SPECIFIC_TARGET is present and always compare.

* gcc.target/i386/pr81921.c: New testcase.

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

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #5 from Xi Ruoyao  ---
Martin said Clang doesn't output the suffix at all, so I tested Clang 4.0.
It also suffers this warning.

[Bug c++/80287] C++ crash with __attribute((may_alias))

[yroux at gcc dot gnu.org]

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

--- Comment #11 from Yvan Roux  ---
Author: yroux
Date: Thu Aug 24 13:20:22 2017
New Revision: 251331

URL: https://gcc.gnu.org/viewcvs?rev=251331=gcc=rev
Log:
PR c++/80287 C++ crash with __attribute((may_alias))

gcc/
2017-08-24  Yvan Roux  

Backport from mainline
2017-04-17  Bernd Edlinger  

PR c++/80287
* class.c (fixup_may_alias): Fix all type variants.

gcc/testsuite
2017-08-24  Yvan Roux  

Backport from mainline
2017-08-22  Yvan Roux  

PR c++/80287
* g++.dg/pr8028.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr80287.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cp/class.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org,
   ||ryxi at stu dot xidian.edu.cn

--- Comment #4 from Xi Ruoyao  ---
It starts form r243461:

PR c/78165 - avoid printing type suffix for constants in %E output

gcc/c-family/ChangeLog:

PR c/78165
   * c-pretty-print (pp_c_integer_constant): Avoid formatting type
 suffix.

Martin removed the type suffix for %E unconditionally.  I think it's wrong
for debug symbol of TreeVector since it's "official
name" (demangled C++ symbol name) HAS the type suffix.

CC Martin to know his opinion.

[Bug libstdc++/81967] New: No overload std::basic_string::erase(__const_iterator, __const_iterator) old ABI

[v.barinov at samsung dot com]

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

Bug ID: 81967
   Summary: No overload std::basic_string::erase(__const_iterator,
__const_iterator) old ABI
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.barinov at samsung dot com
  Target Milestone: ---

Created attachment 42037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42037=edit
Bug example

include/bits/basic_string.h lacks overload of
std::basic_string::erase(__const_iterator, __const_iterator) for old abi.

 g++ test.cxx -DGLIBCXX_USE_CXX11_ABI=1

is okay, but

 g++ test.cxx -DGLIBCXX_USE_CXX11_ABI=0

 test.cxx:7:15: error: no matching function for call to
‘std::basic_string::erase(const const_iterator&, const const_iterator&)’

[Bug middle-end/81908] [8 Regression] FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g -m32

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|i?86-*-*|i?86-*-*
   ||arm-none-linux-gnueabihf
 CC||clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
Also seen on arm-none-linux-gnueabihf targets --with-cpu=cortex-a9
--with-fpu=neon-fp16

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||chrisb2244 at gmail dot com

--- Comment #12 from Eric Gallager  ---
*** Bug 67960 has been marked as a duplicate of this bug. ***

[Bug c++/67960] Prefixing a function with [[deprecated]] produces multiple warnings

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Gallager  ---
Closing as a duplicate of bug 79078. Even though that one is newer, it's more
general, has more extensive discussion, and I saw it before I saw this one.

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

[Bug debug/81936] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.c:5543

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Created attachment 42036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42036=edit
patch

[Bug debug/81936] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.c:5543

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-24
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #16 from Richard Biener  ---
Ok, I think this isn't really offloading specific.  We emit locations with
DW_OP_GNU_variable_value optimistically as dw_val_class_decl_ref and later
either resolve those to a dw_val_class_die_ref or drop them
(resolve_addr_in_expr).

For early LTO we have the machinery in note_variable_value_in_expr to
workaround this early (until we find a better way).

Ah...

static void
note_variable_value_in_expr (dw_die_ref die, dw_loc_descr_ref loc)
{
  for (; loc; loc = loc->dw_loc_next)
if (loc->dw_loc_opc == DW_OP_GNU_variable_value
&& loc->dw_loc_oprnd1.val_class == dw_val_class_decl_ref)
  {
tree decl = loc->dw_loc_oprnd1.v.val_decl_ref;
dw_die_ref ref = lookup_decl_die (decl);
if (! ref && flag_generate_lto)
  {

|| flag_generate_offload missing...

and we run into:

> ./cc1 -quiet pr66714.c -fopenmp -g
pr66714.c:17:1: internal compiler error: in calc_die_sizes, at dwarf2out.c:9131
 }
 ^
0xa4c29f calc_die_sizes
/tmp/trunk2/gcc/dwarf2out.c:9130
0xa4c2f9 calc_die_sizes
/tmp/trunk2/gcc/dwarf2out.c:9135
0xa4f31c output_comp_unit
/tmp/trunk2/gcc/dwarf2out.c:10432
0xa81c71 dwarf2out_finish
/tmp/trunk2/gcc/dwarf2out.c:30022
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

more flag_generate-offload missing.

[Bug bootstrap/81965] [8 Regression] ICE in stage 2 compiler while configuring libgcc in stage 2, during GIMPLE pass: cfg

[rai...@emrich-ebersheim.de]

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

--- Comment #3 from Rainer Emrich  ---
(In reply to Rainer Emrich from comment #2)
> (In reply to Richard Biener from comment #1)
> > Just a wild guess... does
> > 
> > Index: gcc/dwarf2out.c
> > ===
> > --- gcc/dwarf2out.c (revision 251326)
> > +++ gcc/dwarf2out.c (working copy)
> > @@ -178,7 +178,7 @@ static GTY(()) section *debug_ranges_sec
> >  static GTY(()) section *debug_frame_section;
> >  
> >  /* Maximum size (in bytes) of an artificially generated label.  */
> > -#define MAX_ARTIFICIAL_LABEL_BYTES 30
> > +#define MAX_ARTIFICIAL_LABEL_BYTES 40
> >  
> >  /* According to the (draft) DWARF 3 specification, the initial length
> > should either be 4 or 12 bytes.  When it's 12 bytes, the first 4
> > 
> > fix it?
> 
> Unfortunately not.

I'm going to bisect.

[Bug bootstrap/81965] [8 Regression] ICE in stage 2 compiler while configuring libgcc in stage 2, during GIMPLE pass: cfg

[rai...@emrich-ebersheim.de]

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

--- Comment #2 from Rainer Emrich  ---
(In reply to Richard Biener from comment #1)
> Just a wild guess... does
> 
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c (revision 251326)
> +++ gcc/dwarf2out.c (working copy)
> @@ -178,7 +178,7 @@ static GTY(()) section *debug_ranges_sec
>  static GTY(()) section *debug_frame_section;
>  
>  /* Maximum size (in bytes) of an artificially generated label.  */
> -#define MAX_ARTIFICIAL_LABEL_BYTES 30
> +#define MAX_ARTIFICIAL_LABEL_BYTES 40
>  
>  /* According to the (draft) DWARF 3 specification, the initial length
> should either be 4 or 12 bytes.  When it's 12 bytes, the first 4
> 
> fix it?

Unfortunately not.

[Bug middle-end/81931] [8 regression] r251260 breaks many tests on powerpc64

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez  ---
Author: aldyh
Date: Thu Aug 24 11:42:24 2017
New Revision: 251329

URL: https://gcc.gnu.org/viewcvs?rev=251329=gcc=rev
Log:
Port from mainline:

2017-08-24  Aldy Hernandez  

PR middle-end/81931
* tree-ssanames.c (get_nonzero_bits): Use element_precision
instead of TYPE_PRECISION.

Modified:
branches/range-gen2/gcc/ChangeLog
branches/range-gen2/gcc/tree-ssanames.c

[Bug middle-end/81931] [8 regression] r251260 breaks many tests on powerpc64

[aldyh at gcc dot gnu.org]

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

--- Comment #11 from Aldy Hernandez  ---
Author: aldyh
Date: Thu Aug 24 11:40:55 2017
New Revision: 251328

URL: https://gcc.gnu.org/viewcvs?rev=251328=gcc=rev
Log:
PR middle-end/81931
* tree-ssanames.c (get_nonzero_bits): Use element_precision
instead of TYPE_PRECISION.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssanames.c

[Bug target/80993] [msp430] __attribute__((interrupt)) should imply __attribute__((used))

[jozef.l at somniumtech dot com]

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

 CC||jozef.l at somniumtech dot com

--- Comment #1 from Jozef Lawrynowicz  ---
Patch submitted: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01426.html

[Bug c++/81957] ICE decltype

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-24
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug go/81966] New: runtime.inc:362:10: error: duplicate member ‘_’

[mfe at live dot de]

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

Bug ID: 81966
   Summary: runtime.inc:362:10: error: duplicate member ‘_’
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mfe at live dot de
CC: cmang at google dot com
  Target Milestone: ---

Hi,

regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81946 I untared the last
gcc 7.2.0 source. I removed the libgo folder and replaced it with the libgo
folder from the svn trunk source.

the exact version of GCC:
gcc-7.1.0

the system type:
NetgearReadyNAS Duo
(http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS)

the options given when GCC was configured/built:
nas-02-90-38:/media/gcc-7.2.0-go# ../gcc-7.2.0/configure
CC=/opt/gcc-7.1/bin/gcc CXX=/opt/gcc-7.1/bin/g++ --enable-languages=c,c++,go
--prefix=/opt/gcc-7.2.0  --with-cpu=v7 --disable-libstdcxx-pch
--disable-linux-futex --disable-libsanitizer --enable-__cxa_atexit
--with-system-zlib --enable-nls --enable-clocale=gnu --enable-debug 
--disable-doc --disable-libcilkrts --disable-libitm


## - ##
## Platform. ##
## - ##

hostname = nas-02-90-38
uname -m = padre
uname -r = 2.6.17.14ReadyNAS
uname -s = Linux
uname -v = #1 Wed Jun 20 20:08:20 PDT 2012

the complete command line that triggers the bug;
/usr/local/bin/make

the compiler output (error messages, warnings, etc.);
[...]
time/write_err.go runtime_sysinfo.go sigtab.go -o runtime.o >/dev/null 2>&1
rm -f runtime.inc.tmp2 runtime.inc.tmp3
grep -v "#define _" runtime.inc.tmp | grep -v "#define [cm][01234] " | grep -v
"#define empty " > runtime.inc.tmp2
for pattern in '_[GP][a-z]' _Max _Lock _Sig _Trace _MHeap _Num; do \
  grep "#define $pattern" runtime.inc.tmp >> runtime.inc.tmp2; \
done
for TYPE in _Complex_lock _Reader_lock semt; do \
  sed -e '/struct '${TYPE}' {/,/^}/s/^.*$//' runtime.inc.tmp2 >
runtime.inc.tmp3; \
  mv runtime.inc.tmp3 runtime.inc.tmp2; \
done
sed -e 's/sigset/sigset_go/' runtime.inc.tmp2 > runtime.inc.tmp3
/bin/sh ../../../gcc-7.2.0/libgo/mvifdiff.sh runtime.inc.tmp3 runtime.inc
rm -f runtime.inc.tmp2 runtime.inc.tmp3
echo timestamp > s-runtime-inc
/media/gcc-7.2.0-go/./gcc/xgcc -B/media/gcc-7.2.0-go/./gcc/
-B/opt/gcc-7.2.0/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-7.2.0/sparc-unknown-linux-gnu/lib/ -isystem
/opt/gcc-7.2.0/sparc-unknown-linux-gnu/include -isystem
/opt/gcc-7.2.0/sparc-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I.
-I../../../gcc-7.2.0/libgo  -I ../../../gcc-7.2.0/libgo/runtime
-I../../../gcc-7.2.0/libgo/../libffi/include -I../libffi/include -pthread 
-fexceptions -fnon-call-exceptions -fplan9-extensions  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Werror   -D_GNU_SOURCE -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I ../../../gcc-7.2.0/libgo/../libgcc -I
../../../gcc-7.2.0/libgo/../libbacktrace -I ../../gcc/include -fPIC -g -O2 -MT
libgobegin_a-go-main.o -MD -MP -MF .deps/libgobegin_a-go-main.Tpo -c -o
libgobegin_a-go-main.o `test -f 'runtime/go-main.c' || echo
'../../../gcc-7.2.0/libgo/'`runtime/go-main.c
In file included from ../../../gcc-7.2.0/libgo/runtime/runtime.h:108:0,
 from ../../../gcc-7.2.0/libgo/runtime/go-main.c:17:
./runtime.inc:362:10: error: duplicate member ‘_’
  uint8_t _[64];
  ^
Generated runtime.inc from line 347 to 363:

struct gcControllerState {
int64_t scanWork;
int64_t bgScanCredit;
int64_t assistTime;
int64_t dedicatedMarkTime;
int64_t fractionalMarkTime;
int64_t idleMarkTime;
int64_t markStartTime;
int64_t dedicatedMarkWorkersNeeded;
double assistWorkPerByte;
double assistBytesPerWork;
double fractionalUtilizationGoal;
double triggerRatio;
uint8_t _[64];
int64_t fractionalMarkWorkersNeeded;
uint8_t _[64];
};

[Bug ada/81961] [7 regression] an imported unsized C array in the auto-translated binding raises Storage_Error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |7.3

[Bug bootstrap/81965] [8 Regression] ICE in stage 2 compiler while configuring libgcc in stage 2, during GIMPLE pass: cfg

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Just a wild guess... does

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 251326)
+++ gcc/dwarf2out.c (working copy)
@@ -178,7 +178,7 @@ static GTY(()) section *debug_ranges_sec
 static GTY(()) section *debug_frame_section;

 /* Maximum size (in bytes) of an artificially generated label.  */
-#define MAX_ARTIFICIAL_LABEL_BYTES 30
+#define MAX_ARTIFICIAL_LABEL_BYTES 40

 /* According to the (draft) DWARF 3 specification, the initial length
should either be 4 or 12 bytes.  When it's 12 bytes, the first 4

fix it?

[Bug ada/81956] [7 regression] calling a null procedure is not skipped

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |7.3

[Bug rtl-optimization/81955] corrupted double-linked list (not small)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-24
 Ever confirmed|0   |1

--- Comment #2 from Ad PC  ---
Created attachment 42034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42034=edit
source

--- Comment #3 from Richard Biener  ---
Please atttach _preprocessed_ source (or provide a link where to download it),
non-preprocessed source cannot be used as a testcase as it includes files we do
not have available.