[Bug c++/36566] Cannot bind packed field

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
I was thinking that
struct __attribute__((packed)) A { int i; };
should be handled like
typedef int int_unaligned __attribute__((aligned(1)));
struct A { int_unaligned i; };
but it appears that for the aligned attribute as well we ignore the attribute
when forming pointers or references. Depending on the uses, the compiler can
print things like "int_unaligned* {aka int*}" or "ignoring attributes on
template argument" etc. It seems to me that we should not drop the
alignment-reducing attribute in those cases (it is still fine to remove it when
deducing a pass-by-copy type, as in templatevoid f(T);int_unaligned i;
f(i); which could safely deduce T=int. Return types may be more tricky when
they end up passed as invisible reference). The C/C++ standard only consider
_Alignas/alignas to increase alignment, so I don't think changes to the case
that decreases alignment would be a conformance issue.

[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/77659] [5/6 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] internal |[5/6 Regression] internal
   |compiler error: in  |compiler error: in
   |gimplify_expr, at   |gimplify_expr, at
   |gimplify.c:8858 |gimplify.c:8858

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 7 so far.

[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Sun Feb 12 03:34:11 2017
New Revision: 245373

URL: https://gcc.gnu.org/viewcvs?rev=245373=gcc=rev
Log:
PR c++/78908 - template ops and bitfields

* tree.c (build_min_non_dep): Use unlowered_expr_type.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/template/bitfield3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/tree.c

[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Sun Feb 12 03:31:02 2017
New Revision: 245372

URL: https://gcc.gnu.org/viewcvs?rev=245372=gcc=rev
Log:
PR c++/77659 - ICE with new and C++14 aggregate NSDMI

* init.c (build_new): Make backups of any CONSTRUCTORs in init.
(build_new_1): Use replace_placeholders.
* tree.c (replace_placeholders_t): Also track whether we've seen a
placeholder.
(replace_placeholders, replace_placeholders_r): Adjust.
* cp-tree.h: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/tree.c

[Bug tree-optimization/79472] New: x86-64: Switch table generation fails if default case has different code

[yuriks at yuriks dot net]

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

Bug ID: 79472
   Summary: x86-64: Switch table generation fails if default case
has different code
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yuriks at yuriks dot net
  Target Milestone: ---

Consider the following code, compiled at -O2: (Compiler explorer link:
https://godbolt.org/g/GljuJt)

#include 
#include 
#include 

void frobulate(uint32_t v) {
  const char* s;

  switch (v) {
case 0:
  s = "foo";
  break;
case 1:
  s = "bar";
  break;
case 2:
  s = "spam";
  break;
default:
  abort();
  break;
  }

  printf("%s\n", s);
}

void frobulate_for_gcc(uint32_t v) {
  const char* s;

  switch (v) {
case 0:
  s = "foo";
  break;
case 1:
  s = "bar";
  break;
case 2:
  s = "spam";
  break;
default:
  s = nullptr;
  break;
  }

  if (s == nullptr) {
abort();
  }

  printf("%s\n", s);
}
--


gcc 6.3 produces the following code. It fails to generate a data table in
"frobulate", even though it it doing a branch beforehand that could be used to
insert the abort into. If I add the indirection of checking for the null
pointer instead then the check is actually hoisted up into the range check for
the table:

frobulate(unsigned int):
cmp edi, 1
je  .L3
jb  .L4
cmp edi, 2
jne .L12
mov edi, OFFSET FLAT:.LC2
jmp puts
.L12:
sub rsp, 8
callabort
.L4:
mov edi, OFFSET FLAT:.LC0
jmp puts
.L3:
mov edi, OFFSET FLAT:.LC1
jmp puts
frobulate_for_gcc(unsigned int):
cmp edi, 2
jbe .L18
.L14:
sub rsp, 8
callabort
.L18:
mov edi, edi
mov rdi, QWORD PTR CSWTCH.2[0+rdi*8]
testrdi, rdi
je  .L14
jmp puts
CSWTCH.2:
.quad   .LC0
.quad   .LC1
.quad   .LC2
--


gcc 7 (20170211) appears to regress further, it fails to generate a table in
both cases:

frobulate(unsigned int):
cmp edi, 1
je  .L3
jb  .L4
cmp edi, 2
jne .L12
mov edi, OFFSET FLAT:.LC2
jmp puts
.L4:
mov edi, OFFSET FLAT:.LC0
jmp puts
.L3:
mov edi, OFFSET FLAT:.LC1
jmp puts
.L12:
sub rsp, 8
callabort
--


For comparison, clang 3.9.1 generates optimal code in both instances:

frobulate(unsigned int):  # @frobulate(unsigned int)
cmp edi, 3
jae .LBB0_1
movsxd  rax, edi
mov rdi, qword ptr [8*rax + .Lswitch.table.4]
jmp puts# TAILCALL
.LBB0_1:
pushrax
callabort

frobulate_for_gcc(unsigned int): # @frobulate_for_gcc(unsigned
int)
cmp edi, 3
jae .LBB1_1
movsxd  rax, edi
mov rdi, qword ptr [8*rax + .Lswitch.table.4]
jmp puts# TAILCALL
.LBB1_1:
pushrax
callabort

[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
If the patch fixes the problem, it's OK.  But please add a comment where the
line is removed as a hint of what's going on there.

[Bug c++/79452] Provide builtin to detect compile-time execution

[eric at efcs dot ca]

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

--- Comment #9 from Eric Fiselier  ---
I think it would be nice to be able to dispatch differently depending on being
called at compile time or runtime. However the ability to dispatch on that
condition doesn't have to be usable in "if constexpr". That way we don't run
into any instantiation problems.

If that behavior is desireable enough I think it could be simply implemented as
an invented __ctfe__ function local variable that changes value.

[Bug c++/79452] Provide builtin to detect compile-time execution

[gonzalobg88 at gmail dot com]

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

--- Comment #8 from gnzlbg  ---
Eric your concerns and suggestions make sense. Changing the signature of the
functions using something like __ctfe__ and probably anything that would use
those sounds like a major ABI breaking change though. I do not think we can
find a better solution though, but it makes me reconsider whether we really
need this. We do need something like this, but i don't know at what cost.

[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #3 from Kazumoto Kojima  ---
I've tested the patch with the top "make -k check" on sh4-unknown-linux-gnu
and there are no regressions.

[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-11
 CC||danglin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from John David Anglin  ---
Also fails on hppa*-*-hpux*.

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Sat Feb 11 21:49:51 2017
New Revision: 245366

URL: https://gcc.gnu.org/viewcvs?rev=245366=gcc=rev
Log:

PR ipa/79224
* params.def (inline-min-speedup) Change from 10 to 8.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def

[Bug c/79471] New: valgrind error for gcc.c-torture/compile/limits-fnargs.c

[dcb314 at hotmail dot com]

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

Bug ID: 79471
   Summary: valgrind error for
gcc.c-torture/compile/limits-fnargs.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just built a valgrind version of gcc trunk and tried
out the gcc testsuite on it. 

For testcase gcc.c-torture/compile/limits-fnargs.c, I got

./gcc.c-torture/compile/limits-fnargs.c
==21687== Invalid write of size 8
==21687==at 0x6F33B9: expand_call(tree_node*, rtx_def*, int) (calls.c:3266)
==21687==by 0x7DFF36: expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) (expr.c:10785)
==21687==by 0x703E54: expand_expr (expr.h:276)
==21687==by 0x703E54: expand_call_stmt (cfgexpand.c:2658)

Admittedly an extreme case, but I think gcc shouldn't be doing
invalid writes.

[Bug libstdc++/79467] [7 Regression] incorrect static assertion in shared_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/79467] [7 Regression] incorrect static assertion in shared_ptr

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Sat Feb 11 21:08:11 2017
New Revision: 245363

URL: https://gcc.gnu.org/viewcvs?rev=245363=gcc=rev
Log:
PR libstdc++/79467 use lvalues in is_callable check

PR libstdc++/79467
* include/bits/shared_ptr_base.h (__shared_ptr(_Yp*, _Deleter))
(__shared_ptr(_Yp*, _Deleter, _Alloc)): Use lvalue types in
__is_callable check.
* testsuite/20_util/shared_ptr/cons/79467.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/79467.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug web/79468] Clarify createaccount.cgi

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-11
 CC||LpSolit at netscape dot net
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Also, it says:

"User account creation has been restricted. Contact your administrator or the
maintainer (overse...@gcc.gnu.org) for information about creating an account."

This also confuses people, who wonder "who is my administrator"?

Their local sysadmins can't help, so it's a confusing statement. It should just
tell them to contact overseers.

[Bug web/79468] New: Clarify createaccount.cgi

[glisse at gcc dot gnu.org]

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

Bug ID: 79468
   Summary: Clarify createaccount.cgi
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Hello,

with the spam situation, bugzilla account creation currently consists in
sending an email to overseers. However, createaccount.cgi does not reflect
this, it says to fill in a one-field web form and only contact overseers if
that doesn't work for some unspecified amount of time (sounds like contacting
webmaster to report a bug, not like contacting an admin to create the account).
I very regularly see people on stackoverflow give up on reporting bugs because
of this.

[Bug libstdc++/79467] [7 Regression] incorrect static assertion in shared_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-11
  Known to work||6.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0.1

[Bug libstdc++/79467] New: [7 Regression] incorrect static assertion in shared_ptr

[redi at gcc dot gnu.org]

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

Bug ID: 79467
   Summary: [7 Regression] incorrect static assertion in
shared_ptr
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct X { };

struct D {
  void operator()(X*&) {}
};
std::shared_ptr p(new X(), D());

Fails on trunk with:

/home/jwakely/gcc/7/include/c++/7.0.1/bits/shared_ptr_base.h:1088:4: error:
static assertion failed: deleter expression d(p) is well-formed
static_assert(__is_callable<_Deleter(_Yp*)>::value,


The __is_callable expression should be using lvalues not rvalues.

[Bug c++/79466] strange varargs warnings on superflous paranthesises

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
C++14 changed the rules slightly about paranthesises which is why you are
seeing the difference here.

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #50 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb 11 18:38:11 2017
New Revision: 245361

URL: https://gcc.gnu.org/viewcvs?rev=245361=gcc=rev
Log:
PR sanitizer/79341
* g++.dg/asan/deep-stack-uaf-1.C: New test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #49 from Jakub Jelinek  ---
On the other side, we don't turn -fno-omit-frame-pointer or
-mno-omit-leaf-frame-pointer for -fsanitize=address on other targets either,
perhaps this is just a documentation issue.  I'll add -mbackchain to this
testcase.  Perhaps we should just mention those flags in -fsanitize=address
documentation in invoke.texi.

[Bug sanitizer/79341] Many Asan tests fail on s390

[uweigand at gcc dot gnu.org]

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

--- Comment #48 from Ulrich Weigand  ---
s390(x) has -fasynchronous-unwind-tables on by default anyway, and .eh_frame
based DWARF unwinding is the only way to create stack backtraces that always
works.

However, I understood that asan deliberately doesn't want to use DWARF
unwinding for the the malloc/free case since it can be slow.  That's why Marcin
actually added -mbackchain to LLVM in the first place.  (We've had -mbackchain
in GCC forever, but it has defaulted to off for a very long time.)

I don't think we should switch to *always* using backchain unwinding in asan,
since system libraries on s390 will be built without backchain.  However,
switching -mbackchain on by default when building for asan might make sense.

[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Author: hubicka
Date: Sat Feb 11 17:56:02 2017
New Revision: 245359

URL: https://gcc.gnu.org/viewcvs?rev=245359=gcc=rev
Log:

PR tree-ssa/56727
* gcc.dg/tree-ssa/pr56727.c: New testcase.
* ipa-utils.c (recursive_call_p): Be more careful about interposition.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr56727.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-utils.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77790] [5/6 Regression] ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P2  |P4
Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |valid C++14 code when   |valid C++14 code when
   |compiling with  |compiling with
   |"-std=c++11": in|"-std=c++11": in
   |push_access_scope, at   |push_access_scope, at
   |cp/pt.c:227 |cp/pt.c:227

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

[Bug c++/77790] [5/6/7 Regression] ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Sat Feb 11 17:29:45 2017
New Revision: 245358

URL: https://gcc.gnu.org/viewcvs?rev=245358=gcc=rev
Log:
PR c++/77790 - ICE with auto function in C++11 mode

* decl.c (undeduced_auto_decl): Remove C++14 limitation.
(require_deduced_type): Add complain parm, return bool.
* cp-tree.h: Adjust.
* decl2.c (mark_used): Use require_deduced_type.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/g++.dg/cpp0x/auto41.C

[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32

[segher at gcc dot gnu.org]

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

--- Comment #30 from Segher Boessenkool  ---
Trying to combine the load+add+store, combine is trying insns like

Failed to match this instruction:
(parallel [
(set (mem:SI (reg/v/f:SI 90 [ x ]) [1 *x_5(D)+0 S4 A32])
(plus:SI (mem:SI (reg/v/f:SI 90 [ x ]) [1 *x_5(D)+0 S4 A32])
(const_int -1 [0x])))
(set (reg:SI 88 [ _2 ])
(plus:SI (mem:SI (reg/v/f:SI 90 [ x ]) [1 *x_5(D)+0 S4 A32])
(const_int -1 [0x])))
])

and it does not know how to split that into two (make the second SET
just a load).  If it could do that -- and costs work out for the target --
all would work fine as far as I see.  Alternatively, the target could
use a define_split for this pattern.

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Sat Feb 11 16:11:57 2017
New Revision: 245357

URL: https://gcc.gnu.org/viewcvs?rev=245357=gcc=rev
Log:

PR ipa/79224
* ipa-inline-analysis.c (get_minimal_bb): New function.
(record_modified): Use it.
(remap_edge_change_prob): Handle also ancestor functions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c

[Bug c++/79466] New: strange varargs warnings on superflous paranthesises

[martin at netbsd dot org]

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

Bug ID: 79466
   Summary: strange varargs warnings on superflous paranthesises
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org
  Target Milestone: ---

Created attachment 40719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40719=edit
Simple example triggering the warning

When compiled with g++ -std=gnu++14 the expression

  __builtin_va_start ((ap), (fmt));

triggers a strange warning:

example.cc:4:37: warning: second parameter of 'va_start' not last named
argument [-Wvarargs]
 __builtin_va_start ((ap), (fmt));
 ^

Removing the extra paranthesis makes it work. This does not happen with
-std=gnu++11.

Sample attached, compile with:

g++ -Wall -O2 -std=gnu++14 -c -o example.o example.cc

(warning and optimization settings do not make a difference, only std= is
important)

[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32

[law at redhat dot com]

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

--- Comment #29 from Jeffrey A. Law  ---
Right.  I think the test is xfailed, but I don't think the issue has been
resolved.  It requires some rethinking of how the combiner works IIRC.

[Bug preprocessor/79465] New: infinite #include cycle is not detected

[valsiterb at gmail dot com]

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

Bug ID: 79465
   Summary: infinite #include cycle is not detected
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valsiterb at gmail dot com
  Target Milestone: ---

I was working on a 20 years old codebase and in order to increase compilation
speed, I've converted all header guards to #ifdef ... #error to go on and
change things around, but there was a cycle somewhere in the headers (a.h
includes b.h but b.h also includes a.h) cpp does not detect this case and goes
on unil it gets killed.
I don't know if cycle detection is even supposed to part of the preprocessor,
but I expected that #error would make it stop there. I know that there is
-Wfatal-errors directive. Shouldn't #error be be fatal or am I missing
something?

[Bug tree-optimization/79460] gcc fails to optimise out a trivial additive loop for seemingly arbitrary numbers of iterations

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-11
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  ---
Don't we still XFAIL the gcc.target/i386/pr49095.c test?

[Bug sanitizer/78267] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

--- Comment #58 from Dominique d'Humieres  ---
> > --- Comment #56 from Jakub Jelinek  ---
> > So, is this resolved now?
>
> The bootstrap failures are AFAIK, but perhaps we should keep it open for
> the fixinclude fix backports discovered?

Any need to keep this PR open?

[Bug middle-end/61225] [5/6/7 Regression] Several new failures after r210458 on x86_64-*-* with -m32

[dominiq at lps dot ens.fr]

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

--- Comment #27 from Dominique d'Humieres  ---
AFAICT this PR seems fixed. Can I close it?

[Bug target/71017] libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
It should be fixed now. Closing.

[Bug c++/79464] New: new ice in ipa_modify_formal_ parameters

[dcb314 at hotmail dot com]

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

Bug ID: 79464
   Summary: new ice in ipa_modify_formal_ parameters
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I tried to compile gcc/testsuite/g++.dg/cpp1z/inh-ctor23.C
with flag -O2 and recent gcc and it said this:

./g++.dg/cpp1z/inh-ctor23.C:10:7: internal compiler error: in
ipa_modify_formal_parameters, at ipa-prop.c:3979
 Z z(0); // OK: initialization of Y does not invoke default constructor of X
   ^
0xc7c97b ipa_modify_formal_parameters(tree_node*, vec)
../../trunk/gcc/ipa-prop.c:3979
0xfa6f19 modify_function
../../trunk/gcc/tree-sra.c:5179
0xfb1acd ipa_early_sra
../../trunk/gcc/tree-sra.c:5410
0xfb1acd execute
../../trunk/gcc/tree-sra.c:5457

This bug seems to have appeared between gcc revision 245132
and 245341.

[Bug c++/79463] New: ice for -g with ./g++.dg/cpp1y/pr79435.C

[dcb314 at hotmail dot com]

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

Bug ID: 79463
   Summary: ice for -g with ./g++.dg/cpp1y/pr79435.C
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I tried to compile gcc/testsuite/g++.dg/cpp1y/pr79435.C
with compiler flag -g on current gcc trunk and got:

./g++.dg/cpp1y/pr79435.C:5:10: internal compiler error: Segmentation fault
 extern A a; // { dg-error "'a' has incomplete type" }
  ^
0xeab417 crash_signal
../../trunk/gcc/toplev.c:333
0x734b77 check_abi_tags
../../trunk/gcc/cp/class.c:1616
0x874ea3 write_mangled_name
../../trunk/gcc/cp/mangle.c:770
0x881533 mangle_decl_string
../../trunk/gcc/cp/mangle.c:3757

This code seems ok on gcc revision 245132 and seems
to go wrong on gcc revision 245341.

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #47 from Jakub Jelinek  ---
Seems clang doesn't default to -mbackchain for -fsanitize=address, they just
force it on when testing:
if config.target_arch == 's390x':
  clang_asan_static_cflags.append("-mbackchain")

So, if we just want to go that route, we could add to deep-stack-uaf-1.C
// { dg-additional-options "-mbackchain" { target { s390*-*-* } } }

It is of course not very kind to users that would need to add it manually if
they want accurate backtraces for malloc/free.

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #46 from Jakub Jelinek  ---
Or shall we use -mbackchain for -fsanitize=address by default and tweak the
unwinding code sanitizer_common/sanitizer_stacktrace.{cc,h} to use the
backchain?
AFAIK libsanitizer uses the .eh_frame unwinding for printing error dumps but
the fast unwinding (through frame pointer) by default when capturing backtraces
of malloc and free.  Always using .eh_frame would be done by defining
SANITIZER_CAN_FAST_UNWIND to 0 in sanitizer_common/sanitizer_stacktrace.h if
__s390__ (e.g. sparc and mips do this).  Wonder if LLVM emits backchain by
default or what.

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #45 from Jakub Jelinek  ---
deep-stack-uaf*.C failure is presumably because the fast unwind (one that
doesn't use .eh_frame unwind info) isn't working properly.
But I'm afraid I don't know enough about s390{,x} to debug that.
E.g. on following testcase with -O2 -fno-omit-frame-pointer I get:
void foo (char *);

int
bar (char *p)
{
  foo (p);
  return 1;
}

int
baz (char *p)
{
  char a[64];
  foo (a);
  return 1;
}

stmg%r11,%r15,88(%r15)
aghi%r15,-160
lgr %r11,%r15
brasl   %r14,foo
lg  %r4,272(%r11)
lghi%r2,1
lmg %r11,%r15,248(%r11)
br  %r4

for bar and

stmg%r11,%r15,88(%r15)
aghi%r15,-224
lgr %r11,%r15
la  %r2,160(%r11)
brasl   %r14,foo
lg  %r4,336(%r11)
lghi%r2,1
lmg %r11,%r15,312(%r11)
br  %r4

for baz.  Frame pointer is $r15, stack pointer is $r11, if say in foo I ask for
frame pointer, I can easily get at $r15 from the caller (foo or bar), but how
do I get from there to the location where the outer function's $r15 is stored
at?  It is at offset 160+120 in one function and 224+120 in another (and the
stored memory value doesn't tell much, it can be always computed from the
memory location where it is stored.
So, is non-unwind info backtrace not possible on s390{,x}?  If yes, we should
disable the fast unwinding and maybe enable -fasynchronous-unwind-tables by
default on s390{,x}-linux at least when using -fsanitize=address?

[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/79454] [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/52898] SH Target: Inefficient DImode comparisons

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
(In reply to Oleg Endo from comment #11)
> Author: olegendo
> Date: Mon May  2 05:25:46 2016
> New Revision: 235698
> 
> URL: https://gcc.gnu.org/viewcvs?rev=235698=gcc=rev
> Log:
> gcc/
>   PR target/52898
>   * config/sh/sh.c (sh_option_override): Remove TARGET_CBRANCHDI4,
>   TARGET_CMPEQDI_T.
>   (prepare_cbranch_operands): Don't use scratch register.  Assume that
>   function is used when pseudos can be created.
>   (expand_cbranchdi4): Likewise.  Remove unused TARGET_CMPEQDI_T paths.
>   * config/sh/sh.md (cbranchsi4): Allow only when pseudos can be created.
>   (cbranchdi4, cbranchdi4_i): Simplify to single cbranchdi4
>   define_expand.  Allow it only when pseudos can be created.
>   * config/sh/sh.opt (mcbranchdi, mcmpeqdi): Delete.
> 
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/sh/sh.c
> trunk/gcc/config/sh/sh.md
> trunk/gcc/config/sh/sh.opt

This caused PR79462.

[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  I believe the bug has been introduced in r235698 aka PR52898
fix, when the clobbers have been removed from expanders calling
expand_cbranchdi4.  operands[4] used to be that clobber, but now when it has
only 4 operands, it overwrites random memory after it.
I don't have access to SH hw nor any experience with cross-compilers to SH, so
I'd appreciate if somebody could actually test it.

[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|sh: Stack smashing detected |[7 Regression] sh: Stack
   |when building __ashrdi3 in  |smashing detected when
   |libgcc  |building __ashrdi3 in
   ||libgcc
 Ever confirmed|0   |1

[Bug middle-end/79454] [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb 11 08:15:30 2017
New Revision: 245354

URL: https://gcc.gnu.org/viewcvs?rev=245354=gcc=rev
Log:
PR middle-end/79454
* internal-fn.c (expand_vector_ubsan_overflow): Use piece-wise
result computation whenever lhs doesn't have vector mode, not
just when it has BLKmode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c