[Bug sanitizer/79168] [7 Regression] libtsan fails to link when cross compiling GCC tip for Aarch64 target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Assuming fixed.

[Bug libstdc++/79206] New: string_view operator== could do an early exit if sizes differ

[kalven at gmail dot com]

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

Bug ID: 79206
   Summary: string_view operator== could do an early exit if sizes
differ
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kalven at gmail dot com
  Target Milestone: ---

operator== for string_view has this implementation:

  template
inline bool
operator==(basic_string_view<_CharT, _Traits> __x,
   basic_string_view<_CharT, _Traits> __y) noexcept
{ return __x.compare(__y) == 0; }

If __x and __y differ in lengths, this will start a pointless comparison of up
to min(__x.size(), __y.size()) elements. This can be avoided with an early
exit.

FWIW, libc++ has this optmization.

[Bug c++/79205] New: ICE in create_tmp_var, at gimple-expr.c:473

[krister.walfridsson at gmail dot com]

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

Bug ID: 79205
   Summary: ICE in create_tmp_var, at gimple-expr.c:473
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krister.walfridsson at gmail dot com
  Target Milestone: ---

gcc version 7.0.1 20170124 (r244846) ICEs when compiling the following (using
the command line "g++ -c -std=c++1z bug.cpp")

#include 

int foo(std::tuple t)
{
  auto [x0] = t;
  return x0;
}

[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352

[ian at gcc dot gnu.org]

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

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Jan 24 03:34:14 2017
New Revision: 244852

URL: https://gcc.gnu.org/viewcvs?rev=244852=gcc=rev
Log:
PR go/78763

Backported from mainline:

compiler: call determine_types even for constant expressions

We need to call determine_types even for constant expressions, since a
constant expression may include code like unsafe.Sizeof(0).  Something
needs to determine the type of the untyped 0, and that should be the
determine_types pass.

Implementing that triggered a compiler crash on test/const1.go because
it permitted some erroneous constants to make it all the way to the
backend.  Catch that case by checking whether we get a constant
overflow error, and marking the expression invalid if we do.  This is
a good change in any case, as previously we reported the same constant
overflow error multiple times, and now we only report it once.

Fixes GCC PR 78763.

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

Modified:
branches/gcc-6-branch/gcc/go/gofrontend/expressions.cc
branches/gcc-6-branch/gcc/go/gofrontend/expressions.h

[Bug c/79204] New: improve -Woverflow by mentioning types and values

[msebor at gcc dot gnu.org]

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

Bug ID: 79204
   Summary: improve -Woverflow by mentioning types and values
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In a non-trivial program where types are "hidden" behind typedefs and constant
expressions by layers of macros and/or enums, diagnostics such as overflow
could be improved by mentioning the types of the operands and their (constant)
values.  For example, in the program below the typedefs and macros can be
defined in headers and far removed from initialization of x, and neither the
warning nor the note may give a clue as to what they expand to.

$ cat t.c && gcc -S -Wall t.c
typedef signed char T;
#define X 123
#define Y 234
#define N (X * Y)

T x = N;
t.c:4:11: warning: overflow in implicit constant conversion [-Woverflow]
 #define N (X * Y)
   ^
t.c:6:7: note: in expansion of macro ‘N’
 T x = N;
   ^

As an example of a possible improvement consider the Clang output for the same
test case:

t.c:6:7: warning: implicit conversion from 'int' to 'T' (aka 'signed char')
  changes value from 28782 to 110 [-Wconstant-conversion]
T x = N;
  ~   ^
t.c:4:14: note: expanded from macro 'N'
#define N (X * Y)
   ~~^~~

[Bug rtl-optimization/66669] FAIL: gcc.dg/loop-8.c

[kelvin at gcc dot gnu.org]

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

--- Comment #4 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Tue Jan 24 01:26:13 2017
New Revision: 244850

URL: https://gcc.gnu.org/viewcvs?rev=244850=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2017-01-23  Kelvin Nilsen  

PR target/9
* gcc.dg/loop-8.c: Modify dg-skip-if directive to exclude this
test on powerpc targets.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/loop-8.c

[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Tue Jan 24 01:10:10 2017
New Revision: 244847

URL: https://gcc.gnu.org/viewcvs?rev=244847=gcc=rev
Log:
PR middle-end/78703 - -fprintf-return-value floating point handling incorrect
in locales with a mulltibyte decimal point
* gimple-ssa-sprintf.c (warn_level): New global.
(format_integer): Use it here and throughout the rest of the file.
Use the same switch to compute sign as base.
(maybe_warn): New function.
(format_directive): Factor out warnings into maybe_warn.
Add debugging output.  Use warn_level.
(add_bytes): Use warn_level.
(pass_sprintf_length::compute_format_length): Add debugging output.
(try_substitute_return_value): Same.
(pass_sprintf_length::handle_gimple_call): Set and use warn_level.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Tue Jan 24 01:06:34 2017
New Revision: 244846

URL: https://gcc.gnu.org/viewcvs?rev=244846=gcc=rev
Log:
PR middle-end/78703 - -fprintf-return-value floating point handling incorrect
in locales with a mulltibyte decimal point
* gimple-ssa-sprintf.c (struct format_result): Remove constant member.
(struct fmtresult, format_integer, format_floating): Adjust.
(get_string_length, format_string,format_directive): Same.
(pass_sprintf_length::compute_format_length): Same.
(try_substitute_return_value): Simplify slightly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue Jan 24 00:55:19 2017
New Revision: 244845

URL: https://gcc.gnu.org/viewcvs?rev=244845=gcc=rev
Log:
PR middle-end/78703 - -fprintf-return-value floating point handling incorrect
in locales with a mulltibyte decimal point
* gimple-ssa-sprintf.c (pass_sprintf_length::gate): Adjust formatting.
(fmtresult::operator+=): Outlined.
(struct fmtresult): Add ctors.
(struct conversion_spec): Rename...
(struct directive): ...to this.  Add and remove data members.
(directive::set_width, directive::set_precision): New functions.
(format_percent): Use fmtresult ctor.
(get_width_and_precision): Remove.
(format_integer): Make naming changes.  Avoid computing width and
precision.
(format_floating): Same.  Adjust indentation.
(format_character, format_none): New functions.
(format_string): Moved character handling to format_character.
(format_directive): Remove arguments, change return type.
(parse_directive): New function.
(pass_sprintf_length::compute_format_length): Move directive
parsing to parse_directive.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug sanitizer/79168] [7 Regression] libtsan fails to link when cross compiling GCC tip for Aarch64 target

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 24 00:18:36 2017
New Revision: 244844

URL: https://gcc.gnu.org/viewcvs?rev=244844=gcc=rev
Log:
PR sanitizer/79168
* merge.sh (change_comment_headers): Don't remove 2nd and 3rd line
if the 3rd line doesn't contain 'The LLVM Compiler Infrastructure'
text.
* sanitizer_common/sanitizer_linux_mips64.S: Regenerated.
* sanitizer_common/sanitizer_linux_x86_64.S: Likewise.
* tsan/tsan_ppc_regs.h: Likewise.
* tsan/tsan_rtl_aarch64.S: Likewise.
* tsan/tsan_rtl_mips64.S: Likewise.
* tsan/tsan_rtl_ppc64.S: Likewise.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/merge.sh
trunk/libsanitizer/sanitizer_common/sanitizer_linux_mips64.S
trunk/libsanitizer/sanitizer_common/sanitizer_linux_x86_64.S
trunk/libsanitizer/tsan/tsan_interceptors.h
trunk/libsanitizer/tsan/tsan_ppc_regs.h
trunk/libsanitizer/tsan/tsan_rtl_aarch64.S
trunk/libsanitizer/tsan/tsan_rtl_mips64.S
trunk/libsanitizer/tsan/tsan_rtl_ppc64.S

[Bug target/79203] Update PowerPC double->int conversions to know about -mvsx-small-integer

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-23
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/79203] New: Update PowerPC double->int conversions to know about -mvsx-small-integer

[meissner at gcc dot gnu.org]

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

Bug ID: 79203
   Summary: Update PowerPC double->int conversions to know about
-mvsx-small-integer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In looking at PR 79038, I noticed that the double/float conversions to
int/unsigned int were never modified when SImode (32-bit integers) were allowed
in vector registers.  On power8 and above where SImode can go in vector
registers, we should just generate:

(set (match_operand:SI 0 "vsx_register_operand" "=wa")
 (fix:SI (match_operand:DF 1 "vsx_register_operand" "wa")))

instead of:

(set (match_operand:DI 0 "vsx_register_operand" "=wa")
 (unspec:DI [(fix:SI (match_operand:DF 1 "vsx_register_operand" "wa"))]
UNSPEC_FCTIWZ))

to hide the SImode from the register allocator.  For power7 and earlier, we
need the current code, but where SImode can go in the vector registers, we
should generate the appropriate code.

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[law at redhat dot com]

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

--- Comment #22 from Jeffrey A. Law  ---
In response to c#19.  Yes, a thread path which is cold except for a hot block
in the middle might be profitable to thread as it will sometimes expose path
specific redundancies/simplifications in the hot block.

Whether or not it does is mostly a function of the PHI nodes in the hot block. 
ISTM that these opportunities are most likely to arise if threading results in
a degenerate PHI in the hot block.  Which is something we ought to be able to
test for.

Not sure if that helps this testcase or not.

[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug target/79202] New: On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[meissner at gcc dot gnu.org]

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

Bug ID: 79202
   Summary: On Power8, consider using vupkhsw/xxpermdi to sign
extend an int in a vector register instead of
mfvsrwz/mtvsrwa
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I was looking at the code generated for:

double x, y;
/* ... */
x = (double)(int)y;

On Power9, we use the vextsw2d instruction, but that isn't available on Power8
(or Power7).

For example, the test ppc-round2.c has:

double
round_double_int (double a)
{
  return (double)(int)a;
}

This generates the following on power8:

xscvdpsxws 32,1
mfvsrd 9,32
mtvsrwa 1,9
fcfid 1,1

It may be more optimal to generate something like:

xscvdpsxws 32,1
vupkhsw 1,0
xxpermdi 2,33,33,3
fcfid 3,2

And on power9 it generates:

xscvdpsxws 32,1
vextsw2d 0,0
xscvsxddp 1,32

since it knows it can do a SIGN_EXTEND:DI in the Altivec register file.

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
(In reply to Jens Maurer from comment #16)
> That means the standard library needs to do its homework to clearly specify
> under which circumstances (which argument types) it expects a constexpr
> function to be valid in a constant expression.

That's LWG 2833.

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---
In response to c#20.  We have to be careful about fixing up the loop after
rotation and avoid repeatedly peeling.  The old threader dealt with those by
being fairly conservative in passes before the loop optimizer and much more
aggressive later.

Zdenek's general argument was that peeling in the threader is fundamentally
wrong because we really only know general loop structure, but not iteration
information, data dependencies, etc (which directly affect vectorization).  If
peeling a loop inhibits vectorization, then we've most likely lost in a big
way.

I think the backward threader punts all these issues, which is probably the
better choice than aggressively trying to handle them right now.

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[jens.maurer at gmx dot net]

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

--- Comment #18 from Jens Maurer  ---
Then you should cheat on [dcl.constexpr] p5 by carving out the nullptr case:

constexpr void less_than(int *p1, int *p2)
{
  if (p1 == nullptr && p2 == nullptr)
return false;
  return (size_t)p1 < (size_t)p2;
}

This should sidestep [dcl.constexpr] p5, since "less_than(0,0)" seems to be, in
fact, a constant expression.

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[ville.voutilainen at gmail dot com]

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

--- Comment #17 from Ville Voutilainen  ---
(In reply to Jens Maurer from comment #16)
> I'd like to point out that there is no prohibition against writing
> reinterpret_cast inside a constexpr function. It's just if you call that
> function and actually evaluate the reinterpret_cast does the expression turn
> into an expression that is not a constant expression.

In this case, it violates [dcl.constexpr]/5, so the function definition
would be ill-formed NDR.

[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from sandra at gcc dot gnu.org ---
What is "it" that I'm supposed to change?

Note that things are going wrong in the libstdc++-v3/configure script well
before this comment (which appears at line 21812).

The initial empty-program link test is at line 3972.  The link test for
checking C99 stdio.h support is at line 16961.

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[jens.maurer at gmx dot net]

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

Jens Maurer  changed:

   What|Removed |Added

 CC||jens.maurer at gmx dot net

--- Comment #16 from Jens Maurer  ---
I'd like to point out that there is no prohibition against writing
reinterpret_cast inside a constexpr function. It's just if you call that
function and actually evaluate the reinterpret_cast does the expression turn
into an expression that is not a constant expression.

And there is no requirement that calling a constexpr function with arbitrary
arguments is, in fact, a constant expression in the sense of C++ section 5.20. 
There seems to be a tacit understanding that a standard library function marked
as "constexpr" may, in fact, appear in a constant expression if the "obvious"
operations on the arguments are suitable (copy constructor, destructor at
least), but I couldn't find a statement that would make this expectation
explicit.

That means the standard library needs to do its homework to clearly specify
under which circumstances (which argument types) it expects a constexpr
function to be valid in a constant expression.  Absent that, simply performing
the reinterpret_cast is the right answer for std::less, and seems to be
fully conforming with the letter of the current standard.

[Bug tree-optimization/79088] [7 Regression] wrong code at -O2 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Fixed by Richi's patch that I just committed.

[Bug tree-optimization/79188] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed by Richi's patch that I just installed.

[Bug tree-optimization/79188] [7 Regression] wrong code at -O3 on x86_64-linux-gnu

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 23 22:29:17 2017
New Revision: 244837

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

PR tree-optimization/79088
PR tree-optimization/79188
* tree-ssa-threadupdate.c (mark_threaded_blocks): Move code
resetting loop bounds after last path deletion.  Reset loop
bounds of the target loop, make code match the comments.
* tree-ssa-threadbackwards.c (pass_early_thread_jumps::execute):
Make sure loops need no fixups.

* gcc.dg/torture/pr79088.c: New testcase.
* gcc.dg/torture/pr79188.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79088.c
trunk/gcc/testsuite/gcc.dg/torture/pr79188.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadbackward.c
trunk/gcc/tree-ssa-threadupdate.c

[Bug tree-optimization/79088] [7 Regression] wrong code at -O2 on x86_64-linux-gnu

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 23 22:29:17 2017
New Revision: 244837

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

PR tree-optimization/79088
PR tree-optimization/79188
* tree-ssa-threadupdate.c (mark_threaded_blocks): Move code
resetting loop bounds after last path deletion.  Reset loop
bounds of the target loop, make code match the comments.
* tree-ssa-threadbackwards.c (pass_early_thread_jumps::execute):
Make sure loops need no fixups.

* gcc.dg/torture/pr79088.c: New testcase.
* gcc.dg/torture/pr79188.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79088.c
trunk/gcc/testsuite/gcc.dg/torture/pr79188.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadbackward.c
trunk/gcc/tree-ssa-threadupdate.c

[Bug testsuite/79071] Add test case for PR/65618

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org
  Component|rtl-optimization|testsuite

--- Comment #2 from Maciej W. Rozycki  ---
I somehow understood PR rtl-optimization/65618 only addressed the
bootstrap failure somehow and not the actual code generation bug.  Given
that the actual bug has been fixed, any test case can only serve a
verification rather than debugging purpose.

I think it would still be good if it did that and was integrated with our
test suite so that we are alerted in the future with regular testing if
the problem has reappeared, without having to go through a native
bootstrap.  Moving to the testsuite component then.

Sorry about the confusion.

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to Ville Voutilainen from comment #14)
> Not in general, no, it doesn't have to always give a compile-time answer.
> But I believe the library intent is that when it compares compile-time
> constant pointers, it should give that answer at compile-time, and it should
> be a total order.

Right.

> What seems to be suggested by that comment is that since
> it's possible to compare compile-time constant pointers and run-time values
> with this function, and it can't know (definition-wise) whether the incoming
> arguments are constants or not, we could just as well drop the constexpr
> completely from the pointer specialization of std::less, as that will then
> open the door to simply reinterpret_cast in it. None of that has been
> confirmed by LWG, though.

I think this is an example of the prohibition of reinterpret_cast being too
broad.

On the other hand, compile-time constant pointers aren't of much use.

On the third hand, using std::less within an array defined in a constexpr
function seems entirely reasonable and likely to come up regularly.

I wonder about instead relaxing the total order requirement somewhat, to
something like saying that repeated comparisons must be consistent.

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot

[ma...@linux-mips.org]

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

--- Comment #6 from Maciej W. Rozycki  ---
Fixed in binutils now:

commit 65060a78866f374e25f4668d12efc783235d19d1
Author: Maciej W. Rozycki 
Date:   Wed Jan 18 18:18:21 2017 +

PR gas/20649: MIPS: Fix GOT16/LO16 reloc pairing with comdat sections

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[ville.voutilainen at gmail dot com]

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

--- Comment #14 from Ville Voutilainen  ---
Not in general, no, it doesn't have to always give a compile-time answer. But I
believe the library intent is that when it compares compile-time constant
pointers, it should give that answer at compile-time, and it should be a toral
order. What seems to be suggested by that comment is that since it's possible
to compare compile-time constant pointers and run-time values with this
function, and it can't know (definition-wise) whether the incoming arguments
are constants or not, we could just as well drop the constexpr completely from
the pointer specialization of std::less, as that will then open the door to
simply reinterpret_cast in it. None of that has been confirmed by LWG, though.

[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
(In reply to Ville Voutilainen from comment #11)
> Ah, the plot thickens. Jens Maurer wrote:
> 
> "Regarding the std::less issue, it seems a bug in the standard
> to require that it be constexpr and deliver a total order.  After
> all, the addresses of global objects are defined by the linker,
> so it doesn't seem plausible to get a compile-time answer for
> std::less that is the same as a later run-time answer."

That doesn't make sense to me; you can call a constexpr function with
non-constant arguments and get a non-constant result.  There's no requirement
that it give a total order at compile time, is there?

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
And based on the IRC discussion I had earlier today with Markus, I
have also added the following to the patch I'm bootstrapping, even
though it is not strictly necessary to prevent OOM in the testcase
from comment #1.

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 22cd61f3b18..834c27d100e 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3743,6 +3743,8 @@ ipa_node_params_t::insert (cgraph_node *, ipa_node_params
*info)
 {
   info->lattices = NULL;
   info->ipcp_orig_node = NULL;
+  info->known_csts = vNULL;
+  info->known_contexts = vNULL;
   info->analysis_done = 0;
   info->node_enqueued = 0;
   info->do_clone_for_all_contexts = 0;

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

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Well, if my argument is correct, then GCC generates wrong code for the very
first example in comment #0. If that is deliberate as a compromise even though
otherwise GCC suppresses optimizations to honor possible ELF interposition, I
think this ought to be documented?  To my knowledge, that is the sole instance
where optimization doesn't fully honor ELF interposition possibility.

[Bug target/78936] Interprocedural constant propagation miscompiles C++ methods on i686 Windows

[rnk at google dot com]

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

--- Comment #3 from Reid Kleckner  ---
The compiled code still fails at runtime during an LLVM build in the same way.

[Bug sanitizer/79200] Race-Condition in Address Santitizer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Can't reproduce on OpenSUSE Tumbleweed with 6.2.1 and 5.4.1.

$ uname -a
Linux biewercreek 4.9.0-2-default #1 SMP PREEMPT Fri Dec 16 19:51:27 UTC 2016
(6fbc0c0) x86_64 x86_64 x86_64 GNU/Linux

[Bug c++/79192] Angle bracket following typename is treated as template argument delimiter even if the name is not a template name

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 Ever confirmed|0   |1

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
I am about to test the following, which fixes the test from comment
#1.  It does fix a clear bug in the patch I committed today, without
it there we multitudes of identical cgraph duplication hooks active at
the same time.

What worries me is that I cannot ggc_free the memory the structure
sits on without getting a seemingly random segfault later.  But
yesterday the structure was not allocated from GC and was freed here,
so its address shouldn't really escape anywhere...


diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 512bcbed0cb..22cd61f3b18 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3574,6 +3574,7 @@ ipa_free_all_edge_args (void)
 void
 ipa_free_all_node_params (void)
 {
+  ipa_node_params_sum->~ipa_node_params_t ();
   ipa_node_params_sum = NULL;
 }

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #13 from David Malcolm  ---
What's the purpose of the linemap_add call at line 4761?

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

--- Comment #12 from David Malcolm  ---
Looking at the line maps, we have a sane list of ordinary linemaps, but then
the linemap_add call at line 4761 here:

4758tree
4759build_translation_unit_decl (tree name)
4760{
4761  linemap_add (line_table, LC_ENTER, false, main_input_filename, 1);
4762  location_t loc = linemap_line_start (line_table, 1, 0);
4763  linemap_add (line_table, LC_LEAVE, false, NULL, 0);
4764  tree tu = build_decl (loc, TRANSLATION_UNIT_DECL,
4765name, NULL_TREE);

adds an ordinary linemap at the end:

Map #112 [0x7189ce00] - LOC: 338750656 - REASON: LC_ENTER - SYSP: no
File: /home/david/coding-3/benchmarking/pb11/lin/source/aermod.f90:1
Included from: [-1] None

Hence in input.c:total_lines_num (called when input.c first access the file):

static size_t
total_lines_num (const char *file_path)
{
  size_t r = 0;
  source_location l = 0;
  if (linemap_get_file_highest_location (line_table, file_path, ))
{
  gcc_assert (l >= RESERVED_LOCATION_COUNT);
  expanded_location xloc = expand_location (l);
  r = xloc.line;
}
  return r;
}

...highest location effectively is for line 1, due to that final linemap being
for line 1.

Hence c->total_lines is set to 1, and then this conditional fires within every
call to get_next_line (apart from when we read line 1):

  /* Before we update our line record, make sure the hint about the
 total number of lines of the file is correct.  If it's not, then
 we give up recording line boundaries from now on.  */
  bool update_line_record = true;
  if (c->line_num > c->total_lines)
{
  update_line_record = false;
}

and hence we never populate c->line record, and hence the input.c cache is
effectively turned off: every access is a cache miss.

[Bug c++/79192] Angle bracket following typename is treated as template argument delimiter even if the name is not a template name

[ricilake at gmail dot com]

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

--- Comment #1 from ricilake at gmail dot com ---
Thanks to Johannes Schaub-litb (via SO), the problem appears to be at around
line 16781 of cp/parser.c:

  /* There is no valid C++ program where a non-template type is
 followed by a "<".  That usually indicates that the user thought
 that the type was a template.  */
  cp_parser_check_for_invalid_template_id (parser, type, none_type,
   token->location);

I believe this comment (and the subsequent call to
cp_parser_check_for_invalid_template_id) is incorrect; the above program is
valid.

As Johannes points out, there are other valid C++ programs in which a less than
sign can follow a non-template type, such as the following, which also triggers
the same error: (condensed from Johannes'
http://coliru.stacked-crooked.com/a/f35c1aa5b3f9832d)

struct A { operator A(); };
void operator<(A (A::*)(), A);
int main() { ::operator A < A(); }

[Bug c++/71710] [7 Regression] ICE on valid C++11 code with decltype and alias template: in lookup_member, at cp/search.c:1255

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jan 23 20:24:32 2017
New Revision: 244833

URL: https://gcc.gnu.org/viewcvs?rev=244833=gcc=rev
Log:
PR c++/71710 - template using directive of field
* pt.c (tsubst_copy_and_build [COMPONENT_REF]): Move FIELD_DECL
check earlier.

PR C++/71710
* g++.dg/template/pr71710.C: New.

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

[Bug c++/71710] [7 Regression] ICE on valid C++11 code with decltype and alias template: in lookup_member, at cp/search.c:1255

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed r244833.

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #11 from David Malcolm  ---
(In reply to Richard Biener from comment #7)
[...]
> Tentatively remembering an error like above is of course quite broken (read:
> expensive).
> 
> So somehow with the tree.c hunk of the patch location_get_source_line
> (inclusive callees) gets 90 times more expensive (when using callgrind on
> aermod).

Even if we fixed that, this seems to have uncovered an issue with input.c: if I
add some logging to input.c, there seems to be something going badly wrong with
the caching of reading source lines, for this case at least.

get_next_line is being called many more times that I would have expected given
the pattern of calls to location_get_source_line.  For some reason, the cache
isn't working, and it's re-reading large chunks of the source file each time a
diagnostic_show_locus is called (even on repeated calls to access the same
line).

I'm investigating why the cache in input.c is failing.

[Bug c++/71406] [7 Regression] ICE on valid C++ code on x86_64-linux-gnu: in finish_class_member_access_expr, at cp/typeck.c:2782

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r244832.

[Bug c++/77508] [7 Regression] ICE on valid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed r244832.

[Bug c++/77508] [7 Regression] ICE on valid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jan 23 20:19:07 2017
New Revision: 244832

URL: https://gcc.gnu.org/viewcvs?rev=244832=gcc=rev
Log:
PR c++/71406 - ICE with scope-ref'd template id exprs
PR c++/77508
* typeck.c (finish_class_member_access_expr): Break up SCOPE_REF
before breaking up TEMPLATE_ID_EXPR.

PR c++/71406
PR c++/77508
* g++.dg/template/pr71406.C: New.

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

[Bug c++/71406] [7 Regression] ICE on valid C++ code on x86_64-linux-gnu: in finish_class_member_access_expr, at cp/typeck.c:2782

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jan 23 20:19:07 2017
New Revision: 244832

URL: https://gcc.gnu.org/viewcvs?rev=244832=gcc=rev
Log:
PR c++/71406 - ICE with scope-ref'd template id exprs
PR c++/77508
* typeck.c (finish_class_member_access_expr): Break up SCOPE_REF
before breaking up TEMPLATE_ID_EXPR.

PR c++/71406
PR c++/77508
* g++.dg/template/pr71406.C: New.

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

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
On i686-linux it breaks bootstrap even without PGO.
/home/jakub/src/gcc/obj07/./prev-gcc/xg++
-B/home/jakub/src/gcc/obj07/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-nostdinc++
-B/home/jakub/src/gcc/obj07/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/jakub/src/gcc/obj07/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/jakub/src/gcc/obj07/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
 -I/home/jakub/src/gcc/obj07/prev-i686-pc-linux-gnu/libstdc++-v3/include 
-I/home/jakub/src/gcc/libstdc++-v3/libsupc++
-L/home/jakub/src/gcc/obj07/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/jakub/src/gcc/obj07/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace  
-o gimple-ssa-strength-reduction.o -MT gimple-ssa-strength-reduction.o -MMD -MP
-MF ./.deps/gimple-ssa-strength-reduction.TPo
../../gcc/gimple-ssa-strength-reduction.c
virtual memory exhausted: Cannot allocate memory

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
> case 3.  You can see that in the dump created by the -ftree-dump-vrp option
> where the argument is assumed to include the negative subrange:
> 
>   Value ranges after VRP:
>   ...
>   iftmp.0_11: [-99, 99]
^^
That should have been iftmp.0_5:

  iftmp.0_5: [-99, 99]

>   ...
> 
> snprintf (buffer_8(D), 3, "%2d", iftmp.0_5);

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Except for #8, none of the sprintf calls in the extended testcase in attachment
40566 can be handled as accurately at -O0 as with optimization because the
arguments to the format directives are treated as if they had the full range of
int.

The question in my mind is whether, in the absence of any other hints or
constraints (see below), -Wformat-truncation should warn if truncation is
possible (again, given that at -O0 (val & 0xfff) is no different than val) but
not inevitable, or whether it should only warn when truncation certain.  Put
another way, should the set of warnings at -O0 be a strict subset of those with
optimization?  I think you are suggesting that it should be and I tend to
agree.  With my latest patch for bug 78703 (still under review), GCC doesn't
issue any warnings for this test case at -O0.  I suspect trunk warns not so
much as a feature but more by accident.

With optimization enabled, GCC can determine the values (or ranges) of some
non-constant arguments.  The warning pass can then use those to give more
accurate warnings.  It's important to keep in mind that a) due to limitations
or bugs the range information is not available for every expression (e.g., bug
78969 or bug 79191), and b) sometimes these limitations affect the range
information available for unrelated expressions in the same function (e.g., bug
79054).  Your test case unfortunately happens to trigger (b) and as a result
ends up with a false positive for case 3.  You can see that in the dump created
by the -ftree-dump-vrp option where the argument is assumed to include the
negative subrange:

  Value ranges after VRP:
  ...
  iftmp.0_11: [-99, 99]
  ...

snprintf (buffer_8(D), 3, "%2d", iftmp.0_5);

With the other snprintf calls removed or moved into their own function the
false positive goes away and the test case produces warnings for just the first
two cases with the "should warn" comment.  These cases are diagnosed for two
reasons: 1) given the right value of the argument the directive can overflow,
and 2) the argument conversion has been constrained to some subrange of its
full range.  (2) is important because it suggests that the programmer may have
made an effort to constrain the output to avoid the truncation but didn't go
quite far enough to prevent it.  A common mistake is to forget that the
argument is signed and can be negative (as in assuming that (val % 100) results
in at most 2 bytes).

The last case (#8) isn't diagnosed because it doesn't meet condition (2). 
Since the argument appears completely unconstrained, the conservative level 1
of the warning assumes that may be constrained elsewhere (in the caller of
function test).  The warning should be issued at level 2 but on trunk isn't. 
That's a bug that's also fixed by my latest patch.

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

[tetra2005 at gmail dot com]

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

--- Comment #7 from Yuri Gribov  ---
(In reply to Alexander Monakov from comment #6)
> Note that even without symbol aliases, such calls are not necessarily
> self-recursive when 'f' is first called via dlsym with RTLD_NEXT or a
> specific module as the first argument.

Right.  It seems -fno-semantic-interposition is the only option to disable
strict interposition rules.

So could someon close this as wontfix?

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #4 from Bill Schmidt  ---
Created attachment 40568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40568=edit
Proposed patch

Attaching proposed patch.  Iain, would you be able to test this on Darwin 32-
and 64-bit and see whether it makes sense?

[Bug target/78936] Interprocedural constant propagation miscompiles C++ methods on i686 Windows

[rnk at google dot com]

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

--- Comment #2 from Reid Kleckner  ---
That option does not appear to affect the linked portions of the assembly. The
" [clone .constprop.544]" transform still appears to fire.

I will run the complete build and get back soon.

[Bug middle-end/79176] [6/7 Regression] ICE in mangle_decl with LTO and Os

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
To me this sounds like a mismatch between the middle-end type_with_linkage_p
and the C++ FE no_linkage_check.  Perhaps the former should call the latter
using a langhook?

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
It looks to me like vect_alignment_reachable is the wrong test to be using
here.  This is equivalent to vect_aligned_arrays || natural_alignment_32. 
vect_aligned_array is always 0 for powerpc*-*-*.  natural_alignment_32 is
always 1 for powerpc*-*-*, except for 64-bit Darwin.

I think the intent may be that peeling will occur for 64-bit Darwin, but
otherwise versioning for alignment will occur.  So I think that
vect_alignment_reachable should be replaced by ! natural_alignment_32, and !
vect_alignment_reachable should be replaced by natural_alignment_32.  I.e., for
whatever reason these tests appear to be backward.

This change should make the testcase succeed on ppc64 BE and LE, but the
success is misleading for P8 and P9, as we are no longer truly testing for
versioning on those.  So we probably still need to exclude models with
efficient support for unaligned vectors.

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yeah, or -mcpu=power8 -mno-popcntd -mvsx -mvsx-scalar-double even if gas has
power7/power8 support.

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Ah I can reproduce it now...  -mcpu=power7 -mno-popcntd

[Bug target/78936] Interprocedural constant propagation miscompiles C++ methods on i686 Windows

[alexandre.nunes at gmail dot com]

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

Alexandre Pereira Nunes  changed:

   What|Removed |Added

 CC||alexandre.nunes at gmail dot 
com

--- Comment #1 from Alexandre Pereira Nunes  
---
Can you please try with -fno-delete-null-pointer-checks ?

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #13 from Ian Lance Taylor  ---
Fixed.

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[trippels at gcc dot gnu.org]

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

--- Comment #27 from Markus Trippelsdorf  ---
(In reply to James Greenhalgh from comment #26)
> (In reply to dhowe...@redhat.com from comment #21)
> > (In reply to Markus Trippelsdorf from comment #20)
> > > *** Bug 78879 has been marked as a duplicate of this bug. ***
> > 
> > Kernel bug or not, it should be noted that this means that you cannot use
> > gcc from r236831 to compile any kernel from the introduction and use of
> > ilog2() to the current day - and these kernel versions cannot be
> > retroactively fixed.
> 
> This is really the crux of the issue. Even if we were to agree that this is
> a kernel bug, and even if that kernel bug has a fix, there is a lot of
> kernel code out there that won't ever carry that patch.
> 
> As far as I can see the patch from Will Dacon you've linked above hasn't
> made it to a mainline tree, so the kernel bug continues to propagate around
> mainline and stable versions.
> 
> If this were a clear case of GCC being right, I'd agree with the bug being
> closed, but GCC's documentation of __builtin_constant_p doesn't make clear
> just how unintuitive __builtin_constant_p semantics are.
> 
> At best this is a grey area in need of documentation clarification, at worst
> this is GCC being "weird" for the sake of it.
> 
> Pragmatically, the question is whether we think path specialization which
> turns a previously FALSE __b_c_p call TRUE is more likely to confuse our
> users than improve the code generation. Personally, I think it is confusing,
> but I appreciate we've not all agreed on that position.

As far as I can tell the kernel is the only project where this issue ever
popped up. The fix is straightforward. It just needs to be send to the correct
kernel maintainer.
Why do you think this case is any different from any other buggy application
code that needs adjustments as gcc improves?

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Actually, it ICEs for me only if auto-host.h doesn't have HAVE_POPCNTD defined.
And the problem is in mismatch of the conditions:
(define_expand "fixuns_truncdi2"
  [(set (match_operand:DI 0 "register_operand" "")
(unsigned_fix:DI (match_operand:SFDF 1 "register_operand" "")))]
  "TARGET_HARD_FLOAT && (TARGET_FCTIDUZ || VECTOR_UNIT_VSX_P (mode))"
  "")

(define_insn "*fixuns_truncdi2_fctiduz"
  [(set (match_operand:DI 0 "gpc_reg_operand" "=d,wi")
(unsigned_fix:DI (match_operand:SFDF 1 "gpc_reg_operand"
",")))]
  "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT && TARGET_FPRS
&& TARGET_FCTIDUZ"
  "@
   fctiduz %0,%1
   xscvdpuxds %x0,%x1"
  [(set_attr "type" "fp")])

If TARGET_FCTIDUZ is 0, then the second insn isn't enabled at all, while
VECTOR_UNIT_VSX_P (DFmode) can still be true and then there is no insn to
actually satisfy that.  So, shall there be another define_insn like
*fixuns_truncdi2_fctiduz for the !TARGET_FCTIDUZ case that will handle
the VECTOR_UNIT_VSX_P (mode) cases otherwise?  Or just enable it under
the same condition as the expander and if not TARGET_FCTIDUZ disable the first
alternative?  Also, why doesn't the define_expand have && TARGET_DOUBLE_FLOAT
&& TARGET_FPRS conditions?

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[ian at gcc dot gnu.org]

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

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Jan 23 18:15:22 2017
New Revision: 244824

URL: https://gcc.gnu.org/viewcvs?rev=244824=gcc=rev
Log:
PR go/79037
compiler, runtime: align gc data for m68k

The current GC requires that the gc data be aligned to at least a 4
byte boundary, because it uses the lower two bits of the address for
flags (see LOOP and PRECISE in runtime/mgc0.c).  As the gc data is
stored as a [...]uintptr, that is normally always true.  However, on
m68k, that only guarantees 2 byte alignment.  Fix it by forcing the
alignment.

The parfor code used by the current GC requires that the parfor data
be aligned to at least an 8 byte boundary.  The code in parfor.c
verifies this.  This is normally true, as the data uses uint64_t
values, but, again, this must be enforced explicitly on m68k.

Fixes GCC PR 79037.

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

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/types.cc
trunk/libgo/runtime/go-unsafe-pointer.c
trunk/libgo/runtime/parfor.c
trunk/libgo/runtime/runtime.h

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #26 from James Greenhalgh  ---
(In reply to dhowe...@redhat.com from comment #21)
> (In reply to Markus Trippelsdorf from comment #20)
> > *** Bug 78879 has been marked as a duplicate of this bug. ***
> 
> Kernel bug or not, it should be noted that this means that you cannot use
> gcc from r236831 to compile any kernel from the introduction and use of
> ilog2() to the current day - and these kernel versions cannot be
> retroactively fixed.

This is really the crux of the issue. Even if we were to agree that this is a
kernel bug, and even if that kernel bug has a fix, there is a lot of kernel
code out there that won't ever carry that patch.

As far as I can see the patch from Will Dacon you've linked above hasn't made
it to a mainline tree, so the kernel bug continues to propagate around mainline
and stable versions.

If this were a clear case of GCC being right, I'd agree with the bug being
closed, but GCC's documentation of __builtin_constant_p doesn't make clear just
how unintuitive __builtin_constant_p semantics are.

At best this is a grey area in need of documentation clarification, at worst
this is GCC being "weird" for the sake of it.

Pragmatically, the question is whether we think path specialization which turns
a previously FALSE __b_c_p call TRUE is more likely to confuse our users than
improve the code generation. Personally, I think it is confusing, but I
appreciate we've not all agreed on that position.

[Bug c++/77508] [7 Regression] ICE on valid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Looks like my in-testing 71406 patch also gets this one ...

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
I also saw this on Linux/i686.

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #25 from Markus Trippelsdorf  ---
see the following thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/462224.html

[Bug sanitizer/79168] [7 Regression] libtsan fails to link when cross compiling GCC tip for Aarch64 target

[brzycki at gmail dot com]

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

--- Comment #2 from Brian Rzycki  ---
Hello Jakub. Thank you for the fast response. We have verified that gcc with
your patch successfully compiles. We haven't done any real testing on the
compiler itself though.

I think it'd be good to push that patch and if we encounter any new issues to
address them in a new ticket.

Thanks!

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #24 from ktkachov at gcc dot gnu.org ---
I still see this when building an allmodconfig 4.9 Linux kernel for aarch64
(arm64 in kernel-speak).

Just do:

make ARCH=arm64 allmodconfig
make ARCH=arm64 -j

Does anyone know of a kernel patch in flight to fix this in the kernel?
If not, should GCC work around this somehow? (perhaps by making jump-threading
less aggressive when __builtin_constant_p is involved?)

[Bug c++/71406] [7 Regression] ICE on valid C++ code on x86_64-linux-gnu: in finish_class_member_access_expr, at cp/typeck.c:2782

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c/79201] New: issed optimization: gcc fails to cut out unnecessary loop.

[drraph at gmail dot com]

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

Bug ID: 79201
   Summary: issed optimization: gcc fails to cut out unnecessary
loop.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drraph at gmail dot com
  Target Milestone: ---

Consider this code:

int f(int n) {
  int i,j=0;
  for (i = 0; i < 32; i++) {
j = __builtin_ffs(i);
  }
  return j;
}

With gcc -O3 you get

f:
xor eax, eax
xor edx, edx
mov ecx, -1
jmp .L3
.L5:
bsf eax, edx
cmove   eax, ecx
add eax, 1
.L3:
add edx, 1
cmp edx, 32
jne .L5
rep ret


However with clang you get

f:  # @f
mov eax, 1
ret


A similar difference occurs if you replace the limit 32 with the variable n.

gcc is unable to detect that the loop can be omitted.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to amker from comment #5)
> (In reply to amker from comment #4)
> > Discussed with richi, and conclusion is that vrp issue is hard to fix at the
> > moment.  Easy way out is to investigate why cunrolli peels one additional
> > 
> > There are two possible fixes here. One is to investigate why evrp doesn't
> > compute correct range for j_11:
> > 
> > _1: VARYING
> > _3: VARYING
> > i_4: [0, +INF]
> > j_5: [j_13, +INF]
> > n_12(D): ~[0, 0]
> > j_13: VARYING    > j_15: [-2147483647, +INF]
> > 
> Looks like evrp only computes vrp for parameters or like?

Testing a patch in tree-ssa-loop-niter.c.

[Bug rtl-optimization/71724] [5/6 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[5/6/7 Regression] ICE: |[5/6 Regression] ICE:
   |Segmentation fault, deep|Segmentation fault, deep
   |recursion between   |recursion between
   |combine_simplify_rtx and|combine_simplify_rtx and
   |subst   |subst

--- Comment #8 from Jeffrey A. Law  ---
So I believe the consensus was we want both patches, or variants thereof, so
I'm leaving this open, but removing the regression marker.

[Bug tree-optimization/56049] [7 Regression] Simplification to constants not done

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #19 from Jeffrey A. Law  ---
OK.  Changing milestone to gcc-8.  I think we can reasonably allow guality to
regress here.  Waiting until gcc-8 also gives the updated gdb more time to get
deployed in the wild.

[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
For POWER8 or later, this test isn't useful as we just go ahead and vectorize
the loop.  In these processors we have better performance of misaligned vector
loads and stores, so we are more aggressive under the cost model.  At a minimum
we need to skip this test when TARGET_EFFICIENT_UNALIGNED_VSX = 1.

I note from the automated testers that we fail this test on POWER7 BE also,
though, so there must be more to it than that.  I'll go poke at that next.

Confirmed, btw.

[Bug rtl-optimization/56069] [5/6/7 Regression] RA pessimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #25 from Jeffrey A. Law  ---
Sorry, I thought all the issues had been fixed.  Reopening.

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The C++17 draft requires aligned-delete to be used for memory obtained from
aligned-new (and not otherwise):

"Requires: If the alignment parameter is not present, ptr shall have been
returned by an allocation function without an alignment parameter. If present,
the alignment argument shall equal the alignment argument passed to the
allocation function that returned ptr."

So for aligned-new we can over-allocate and return a suitably aligned pointer
within the allocated region, storing a cookie before that pointer that tells us
the address originally obtained from malloc. For aligned-delete we read the
cookie.

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
 Blocks||79061
Summary|[7 Regression] 100% |100% compile-time increase
   |compile-time increase for   |for polyhedron aermod by
   |polyhedron aermod by|r244581
   |r244581 |

--- Comment #10 from Jeffrey A. Law  ---
I think we should keep this open and have 79061 depend on it.  We should remove
the regression marker though.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
[Bug 79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with
"AddressSanitizer: initialization-order-fiasco"

[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||jakub at gcc dot gnu.org
   Target Milestone|7.0 |5.5
Summary|[7 Regression] ICE in   |[5/6/7 Regression] ICE in
   |extract_insn in |extract_insn in
   |gcc/recog.c:2311|gcc/recog.c:2311
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r217590 (with -mcpu=power8).

[Bug tree-optimization/70754] [5/6 Regression] ICE during predictive commoning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE during
   |during predictive commoning |predictive commoning

--- Comment #12 from Jeffrey A. Law  ---
Confirmed Bin's patch fixes the regression on the trunk, so removing gcc-7
regression marker.

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K, even with --std=c99 -pedantic

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
OK, but as the reporter of 64526 said, we should warn at least. We know the
number of parameters (even if there isn't a prototype) and we know the number
of arguments doesn't match it. That warrants a warning.

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
The tree.c hunk has been reverted, so can we close this PR (the other PR has
been reopened)?

[Bug tree-optimization/70754] [5/6/7 Regression] ICE during predictive commoning

[pthaugen at gcc dot gnu.org]

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

--- Comment #11 from Pat Haugen  ---
(In reply to amker from comment #10)
> Author: amker
> Date: Mon Jan 23 15:59:19 2017
> New Revision: 244815

This fixes the problem on powerpc.

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Verified Martin's patch fixes the problem.

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Author: bernds
Date: Mon Jan 23 16:30:55 2017
New Revision: 244817

URL: https://gcc.gnu.org/viewcvs?rev=244817=gcc=rev
Log:
PR rtl-optimization/71724
* combine.c (if_then_else_cond): Look for situations where it is
beneficial to undo the work of one of the recursive calls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bernd Schmidt  ---
Fixed.

[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K, even with --std=c99 -pedantic

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Keywords|accepts-invalid |

--- Comment #7 from Joseph S. Myers  ---
This is valid code (or at least the version with the call inside if (0) or
otherwise not known to be executed unconditionally for all executions of the
program is).  See what I said in bug 64526 and DR#317 linked therefrom.

[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Mon Jan 23 16:17:33 2017
New Revision: 244816

URL: https://gcc.gnu.org/viewcvs?rev=244816=gcc=rev
Log:
PR rtl-optimization/78634
* config/i386/i386.c (ix86_max_noce_ifcvt_seq_cost): New function.
(TARGET_MAX_NOCE_IFCVT_SEQ_COST): Define.
* ifcvt.c (noce_try_cmove): Add missing cost check.

testsuite/
PR rtl-optimization/78634
* gcc.target/i386/funcspec-11.c: Also pass -mtune=i686.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/funcspec-11.c

[Bug bootstrap/79198] [7 Regression] r244802 causes out of memory during PGO bootstrap

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #3 from David Edelsohn  ---
This revision causes out of memory when bootstrapping on AIX without PGO.

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[redi at gcc dot gnu.org]

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

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

[Bug tree-optimization/70754] [5/6/7 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Jan 23 15:59:19 2017
New Revision: 244815

URL: https://gcc.gnu.org/viewcvs?rev=244815=gcc=rev
Log:
PR tree-optimization/70754
* tree-predcom.c (stmt_combining_refs): New parameter INSERT_BEFORE.
(reassociate_to_the_same_stmt): New parameter INSERT_BEFORE.  Insert
combined stmt before it if not NULL.
(combine_chains): Process refs reversely and compute dominance point
for root ref.

gcc/testsuite
PR tree-optimization/70754
* gfortran.dg/pr70754.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr70754.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug rtl-optimization/79194] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #2 from Bernd Schmidt  ---
Oh well, guess I know how to fix those by now.

[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
A simple patch would be to check for __ARM_FEATURE_SAT in all those macros in
exch_n.c along with HAVE_STREXB etc .. 

Confirmed by code inspection.

A fix to the macro is pre-approved for all release branches with appropriate
testing.

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 23 15:56:05 2017
New Revision: 244813

URL: https://gcc.gnu.org/viewcvs?rev=244813=gcc=rev
Log:
PR libstdc++/79195 fix make_array type deduction

PR libstdc++/79195
* include/experimental/array (__make_array_elem): New class template
and partial specialization.
(__is_reference_wrapper): Move into __make_array_elem specialization.
(make_array): Use __make_array_elem to determine element type and move
static assertion into specialization. Qualify std::forward call.
(to_array): Add exception specifiation.
* testsuite/experimental/array/make_array.cc: Test argument types
without a common type.
* testsuite/experimental/array/neg.cc: Adjust expected error message.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/array
trunk/libstdc++-v3/testsuite/experimental/array/make_array.cc
trunk/libstdc++-v3/testsuite/experimental/array/neg.cc

[Bug sanitizer/79200] New: Race-Condition in Address Santitizer

[tommapson at gmx dot de]

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

Bug ID: 79200
   Summary: Race-Condition in Address Santitizer
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tommapson at gmx dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Multiple concurrent executables hang when being built by gcc-6.3.0 (as well as
gcc-5.3.0) with -fsanitize=address.

To reproduce this bug, you may use the following trivial C program:

- main.c 
int main(int ac, char** av)
{
  return 0;
}
-

Compile with
  gcc -fsanitize=address main.c -o main

Run multiple instances concurrently (bash on Debian Wheezy or Jessie):
  for i in $(seq 2) ; do ( ./main >/dev/null 2>&1 & ) ; done ; echo
"SLEEPING..." ; sleep 120

Some of the executables hang as can be seen using ps or top. The processes are
reported to have state "T" (stopped, either by a job control signal or because
it is being traced).

If compiled without -fsanitize=address, the above loop does not cause any of
the processes to hang.

[Bug rtl-optimization/56069] [5/6/7 Regression] RA pessimization

[bernds at gcc dot gnu.org]

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

--- Comment #16 from Bernd Schmidt  ---
I retested again with a few different combinations of things. With an older
gdb, I can still reproduce the issue that sra-1 becomes UNSUPPORTED (presumably
through a gdb crash). With gdb-7.12 installed the patch now causes sra-1.c to
fail (apparently a value becomes optimized out). If we consider the guality
testsuite in some way meaningful we still can't apply this patch.
Also, Vlad's reasoning for waiting until gcc-7 last time now holds for waiting
until gcc-8.

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
https://gcc.opensuse.org/c++bench-czerny/pb11/ has this link:

 
http://www.polyhedron.com/fortran-compiler-comparisons/polyhedron-benchmark-suite

which is a 404.

An updated link seems to be:
 
http://www.fortran.uk/fortran-compiler-comparisons-2015/the-polyhedron-solutions-benchmark-suite/

from which a zipfile containing aermod.f90 can be seen (am looking at it now).

[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #27 from Martin Liška  ---
(In reply to anthonyfk from comment #26)
> Thank you very much for the fix! I've tried the patch as applied to
> gcc-6-branch with an otherwise fresh tarball of gcc 6.3.0. When compiling
> lapack-3.6.1 I no longer get the original bug, but I do get:
> 
> lto1: internal compiler error: resolution sub id 0x7485cad21ad62861 not in
> object file
> 0x54e61b lto_resolution_read
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:1929
> 0x54e61b lto_file_read
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2092
> 0x54e61b read_cgraph_and_symbols
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2806
> 0xc9045a lto_main()
>   /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:3310
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> lto-wrapper: fatal error: /usr/local/solido/tools/20170120/bin/gfortran
> returned 1 exit status
> compilation terminated.
> /usr/local/solido/tools/20170120/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:129: ../xeigtsts] Error 1
> 
> I tried searching the bug tracker to see if this was fixed already but
> didn't have any luck. I'll try to put together a reduced test case in the
> next week, but it's unfortunately a busy time of year for me so that may
> take longer. At the very least, I can try with the latest tarball from the 6
> branch easily.

Reduce test-case would be handy. Can you please re-test that also on trunk?

Thanks

[Bug tree-optimization/79196] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
Summary|[7 Regression] Probably |Probably invalid folding of
   |invalid folding of  |strstr(x, "foo") eq x to
   |strstr(x, "foo") eq x to|memcmp (x, "foo",
   |memcmp (x, "foo",   |strlen("foo"))
   |strlen("foo"))  |

--- Comment #5 from Martin Liška  ---
Fixed.

[Bug tree-optimization/79196] [7 Regression] Probably invalid folding of strstr(x, "foo") eq x to memcmp (x, "foo", strlen("foo"))

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Mon Jan 23 14:57:43 2017
New Revision: 244812

URL: https://gcc.gnu.org/viewcvs?rev=244812=gcc=rev
Log:
Fix strstr folding (PR tree-optimization/79196).

2017-01-23  Martin Liska  

PR tree-optimization/79196
* tree-ssa-strlen.c (fold_strstr_to_memcmp): Rename to ...
(fold_strstr_to_strncmp): ... this.  Fold the pattern to strncmp
instead of memcmp.
(strlen_optimize_stmt): Call the renamed function.
2017-01-23  Martin Liska  

PR tree-optimization/79196
* gcc.dg/asan/pr79196.c: New test.
* gcc.dg/strlenopt-30.c: Update scanned pattern.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr79196.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strlenopt-30.c
trunk/gcc/tree-ssa-strlen.c

[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[anthonyfk at gmail dot com]

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

--- Comment #26 from anthonyfk at gmail dot com ---
Thank you very much for the fix! I've tried the patch as applied to
gcc-6-branch with an otherwise fresh tarball of gcc 6.3.0. When compiling
lapack-3.6.1 I no longer get the original bug, but I do get:

lto1: internal compiler error: resolution sub id 0x7485cad21ad62861 not in
object file
0x54e61b lto_resolution_read
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:1929
0x54e61b lto_file_read
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2092
0x54e61b read_cgraph_and_symbols
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2806
0xc9045a lto_main()
/tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/local/solido/tools/20170120/bin/gfortran
returned 1 exit status
compilation terminated.
/usr/local/solido/tools/20170120/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:129: ../xeigtsts] Error 1

I tried searching the bug tracker to see if this was fixed already but didn't
have any luck. I'll try to put together a reduced test case in the next week,
but it's unfortunately a busy time of year for me so that may take longer. At
the very least, I can try with the latest tarball from the 6 branch easily.