[Bug middle-end/77594] double computation for __builtin_sub_overflow (0, ...)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 07:09:27 2016
New Revision: 240173

URL: https://gcc.gnu.org/viewcvs?rev=240173&root=gcc&view=rev
Log:
PR middle-end/77594
* internal-fn.c (expand_arith_overflow) : Don't fall
through into expand_addsub_overflow after expand_neg_overflow.

* gcc.target/i386/pr77594.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr77594.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77526] [7 Regression] ICE: in verify_dominators, at dominance.c:1039 with -mstringop-strategy=byte_loop

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 07:10:08 2016
New Revision: 240174

URL: https://gcc.gnu.org/viewcvs?rev=240174&root=gcc&view=rev
Log:
PR target/77526
* combine.c (rest_of_handle_combine): If any edges have been purged,
free dominators if available.

* gcc.target/i386/pr77526.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr77526.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77526] [7 Regression] ICE: in verify_dominators, at dominance.c:1039 with -mstringop-strategy=byte_loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/77425] Pointer test follows dereference in sched-int.h

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/77421] Bugs found in GCC with the help of PVS-Studio

[jakub at gcc dot gnu.org]

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

Bug 77425 Summary: Pointer test follows dereference in sched-int.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77425

   What|Removed |Added

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

[Bug middle-end/77475] unnecessary or misleading context in reporting command line problems

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/77549] [7 Regression] ICE on invalid C++ code that references undeclared variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/77454] [7 Regression] IMM ERROR w/ -O2 and above

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/77421] Bugs found in GCC with the help of PVS-Studio

[jakub at gcc dot gnu.org]

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

Bug 77444 Summary: Bogus assignments in cand_value_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77444

   What|Removed |Added

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

[Bug tree-optimization/77444] Bogus assignments in cand_value_at

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/77614] New: Missed optimisation with -O3 when passing integral type by constexpr using std::less(a,b) instead of b>a

[gcc at 4z2 dot de]

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

Bug ID: 77614
   Summary: Missed optimisation with -O3 when passing integral
type by constexpr using std::less(a,b) instead of b>a
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at 4z2 dot de
  Target Milestone: ---

Created attachment 39628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39628&action=edit
Output with -v

I'm implementing SuperScalar Sample Sort, a sorting algorithm using (e.g.) 127
splitters to partition the input into 128 buckets. Elements' destination
buckets are found using a search in an Eytzinger layout tree: index = 2*index +
(key > splitters[index]). This step is implemented as a constexpr.

This works fine when using operator>, but switching to a templatized Compare
object (in this case, std::less<> with reversed operands) results in a missed
optimisation opportunity. There is a discussion with the generated assembly in
https://github.com/lorenzhs/ort/pull/8

The workaround is to pass 'key' by value instead of const reference if it's an
integral type (it would probably be better to use it for POD types with size up
to x bytes, but I digress):
https://github.com/lorenzhs/ort/pull/8/commits/9668c9fd53911250b40507767afd32ed3fdd457a
. This results in the same code being emitted as when passing by const ref and
comparing with operator>.

I'm running Debian unstable, gcc version 6.2.0 20160901 (Debian 6.2.0-3).
Compilation flags are "-std=c++14 -Wall -Wextra -Werror -march=native -O3 -g
-DNDEBUG".

[Bug target/77614] Missed optimisation with -O3 when passing integral type by constexpr using std::less(a,b) instead of b>a

[gcc at 4z2 dot de]

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

--- Comment #1 from Lorenz  ---
Created attachment 39629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39629&action=edit
preprocessed file, exhibiting missed optimization -- gzipped because too large
otherwise

[Bug target/77614] Missed optimisation with -O3 when passing integral type by constexpr using std::less(a,b) instead of b>a

[gcc at 4z2 dot de]

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

--- Comment #2 from Lorenz  ---
Created attachment 39630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39630&action=edit
preprocessed file with workaround -- optimisation performed

[Bug middle-end/77475] unnecessary or misleading context in reporting command line problems

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 08:13:51 2016
New Revision: 240175

URL: https://gcc.gnu.org/viewcvs?rev=240175&root=gcc&view=rev
Log:
PR middle-end/77475
* gcc.target/i386/pr65990.c: Adjust dg-error regexp.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr65990.c

[Bug target/77614] Missed optimisation with -O3 when passing integral type by constexpr using std::less(a,b) instead of b>a

[gcc at 4z2 dot de]

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

Lorenz  changed:

   What|Removed |Added

  Attachment #39630|0   |1
is obsolete||

--- Comment #3 from Lorenz  ---
Created attachment 39631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39631&action=edit
preprocessed file with *actual* workaround -- optimisation performed

[Bug fortran/77604] ICE in get_frame_type, at tree-nested.c:208

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 CC||marxin at gcc dot gnu.org
  Known to work||4.5.4
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 4.6.0.

[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Heh, I have a similar issue with the assember knowing better (and even emitting
a warning!) when emitting a .gnu.lto_.debug_info section marked as mergeable
strings.

Please send patches to gcc-patc...@gcc.gnu.org

[Bug tree-optimization/77605] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug fortran/77612] [5/6 Regression] ICE on invalid character len in contained procedure

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 CC||kargl at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||5.2.0
   Target Milestone|--- |5.5
Summary|ICE on invalid character|[5/6 Regression] ICE on
   |len in contained procedure  |invalid character len in
   ||contained procedure
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.2.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r229287, which was also backported to GCC 5 branch.

[Bug c++/77615] New: Template specialization is resolved differently with and without optimizations turned on

[jan.bujak at nokia dot com]

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

Bug ID: 77615
   Summary: Template specialization is resolved differently with
and without optimizations turned on
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.bujak at nokia dot com
  Target Milestone: ---

Created attachment 39632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39632&action=edit
Reproduction testcase

Please consider the following code:

// shared.h
#include 

template 
void hello() {
printf( "generic\n" );
}

// specialization.cc
#include "shared.h"

template <>
void hello< int >() {
printf( "specialized\n" );
}

// usage.cc
#include "shared.h"

int main() {
hello< int >();
return 0;
}

Now, if we compile it like this:

g++ -Wall -Wextra -O0 specialization.cc usage.cc

then the specialized version will be called; if we compile like this:

g++ -Wall -Wextra -O1 specialization.cc usage.cc

then the generic version will be called.

The order of compilation doesn't seem to matter. The behavior is the same for
any other optimization level. When compiled on clang in both cases the
specialized version is called.

Tested on the following GCC versions on Arch Linux:
g++ (GCC) 6.2.1 20160830
g++ (GCC) 6.1.1 20160501

[Bug tree-optimization/77605] wrong code at -O3 on x86_64-linux-gnu

[setsunakun0 at hotmail dot com]

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

byuu  changed:

   What|Removed |Added

 CC||setsunakun0 at hotmail dot com

--- Comment #2 from byuu  ---
This bug is caused by tree-loop-vectorize, and it affects non-Linux platforms
as well (gcc version 5.1.0 (tdm64-1) Windows here.) It works correctly with -O3
-fno-tree-loop-vectorize. I've run into improperly generated code several times
due to this optimization, but was unable to produce such a succinct test case
for a bug report.

[Bug c++/77615] Template specialization is resolved differently with and without optimizations turned on

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Please read: https://isocpp.org/wiki/faq/templates

* Why can’t I separate the definition of my templates class from its
declaration and put it inside a .cpp file?

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Ramana Radhakrishnan  ---
Confirmed then.



Ramana

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/77597] GCC 6.2 / LLVM 3.9 name mangling discrepancy for function with instantiated template in signature whose template argument involves an ABI tag.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
If I read the mangled names correctly, the difference is in the compression of
the arguments of
art::ExceptionDetail::translate[abi:cxx11]
from which the address is taken, and the demangling doesn't show those
arguments at all.
GCC encodes them as S5_, i.e. 7th substitution, which is I belive
N3art6errors10ErrorCodesE
while LLVM emits
NS6_6errors10ErrorCodesE
where S6_ stands for I belive
3art
so those two are equivalent in what they expand to after substitution
expansion.
So the question is what the ABI exactly says, if different implementations have
to agree, I'd thought it should have chosen longest matching substitution, so
GCC would be correct.

[Bug tree-optimization/71354] [7 Regression] gcc.dg/vect/vect-23.c FAILs

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

[Bug c++/77597] GCC 6.2 / LLVM 3.9 name mangling discrepancy for function with instantiated template in signature whose template argument involves an ABI tag.

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Ah, maybe I'm wrong what S6_ stands for.  Anyway:
https://llvm.org/bugs/show_bug.cgi?id=30401#c1
has more details.  So NOTABUG?

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[amker at gcc dot gnu.org]

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

Bug 56625 Summary: After if-conversion vectorizer doesn't recognize similar 
loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56625

   What|Removed |Added

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

[Bug tree-optimization/56625] After if-conversion vectorizer doesn't recognize similar loads

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Fixed.

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:34:02 2016
New Revision: 240177

URL: https://gcc.gnu.org/viewcvs?rev=240177&root=gcc&view=rev
Log:
Backported from mainline
2016-09-05  Jakub Jelinek  

PR sanitizer/77396
* asan/asan_globals.cc: Cherry-pick upstream r280657.

* g++.dg/asan/pr77396-2.C: New test.

2016-09-02  Jakub Jelinek  

PR sanitizer/77396
* g++.dg/asan/pr77396.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/asan/pr77396-2.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/asan/pr77396.C
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libsanitizer/ChangeLog
branches/gcc-6-branch/libsanitizer/asan/asan_globals.cc

[Bug target/69255] ICE on x86_64-linux-gnu in "emit_move_insn"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:34:44 2016
New Revision: 240178

URL: https://gcc.gnu.org/viewcvs?rev=240178&root=gcc&view=rev
Log:
Backported from mainline
2016-09-06  Jakub Jelinek  

PR target/69255
* config/i386/i386.c (ix86_expand_builtin): For builtin with
unsupported or unknown ISA, use expand_call.

* gcc.target/i386/pr69255-1.c: New test.
* gcc.target/i386/pr69255-2.c: New test.
* gcc.target/i386/pr69255-3.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr69255-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr69255-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr69255-3.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/77615] Template specialization is resolved differently with and without optimizations turned on

[jan.bujak at nokia dot com]

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

--- Comment #2 from Jan Bujak  ---
(In reply to Markus Trippelsdorf from comment #1)
> Please read: https://isocpp.org/wiki/faq/templates
> 
> * Why can’t I separate the definition of my templates class from its
> declaration and put it inside a .cpp file?

Yes, I was aware of that, and it does make sense from a *technical* standpoint,
but I reported the bug anyway because this is a potential landmine waiting to
go off. You'll probably disagree, but for me changing the optimization level
should *not* subtly change the behavior of the code without even a warning!

If doing this is incorrect then the compiler should at least generate a warning
instead of silently generating wrong code. The compiler knows that the template
was defined in a header file, and it knows that the specialization was defined
in a .cpp file, so it could tell the user that "hey, that probably won't work
as you think it should; if you know what you're doing then feel free to silence
this warning".

[Bug fortran/77516] ICE in is_gimple_min_invariant, at gimple-expr.c:706

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:35:23 2016
New Revision: 240179

URL: https://gcc.gnu.org/viewcvs?rev=240179&root=gcc&view=rev
Log:
Backported from mainline
2016-09-08  Jakub Jelinek  

PR fortran/77516
* omp-low.c (lower_rec_simd_input_clauses): Use max_vf for non-positive
OMP_CLAUSE_SAFELEN_EXPR.

* gfortran.dg/gomp/pr77516.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr77516.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/77500] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:36:05 2016
New Revision: 240180

URL: https://gcc.gnu.org/viewcvs?rev=240180&root=gcc&view=rev
Log:
Backported from mainline
2016-09-08  Jakub Jelinek  

PR fortran/77500
* trans-openmp.c (gfc_trans_omp_atomic): For atomic write or
swap, don't try to look through GFC_ISYM_CONVERSION.  In other cases,
check that value.function.isym is non-NULL before dereferencing it.

* gfortran.dg/gomp/pr77500.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/pr77500.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-openmp.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:37:08 2016
New Revision: 240181

URL: https://gcc.gnu.org/viewcvs?rev=240181&root=gcc&view=rev
Log:
Backported from mainline
2016-09-13  Jakub Jelinek  

PR c++/77553
* constexpr.c (cxx_fold_pointer_plus_expression): New function.
(cxx_eval_binary_expression): Use it for POINTER_PLUS_EXPR.
(cxx_eval_pointer_plus_expression): Remove.
(cxx_eval_constant_expression) : Don't
call cxx_eval_pointer_plus_expression.

* g++.dg/cpp1y/constexpr-77553.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-77553.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:37:50 2016
New Revision: 240182

URL: https://gcc.gnu.org/viewcvs?rev=240182&root=gcc&view=rev
Log:
Backported from mainline
2016-09-14  Jakub Jelinek  

PR sanitizer/68260
* tsan.c: Include target.h.
(enum tsan_atomic_action): Add bool_clear and bool_test_and_set.
(BOOL_CLEAR, BOOL_TEST_AND_SET): Define.
(tsan_atomic_table): Add BUILT_IN_ATOMIC_CLEAR and
BUILT_IN_ATOMIC_TEST_AND_SET entries.
(instrument_builtin_call): Handle bool_clear and bool_test_and_set.

* c-c++-common/tsan/pr68260.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/tsan/pr68260.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tsan.c

[Bug middle-end/77594] double computation for __builtin_sub_overflow (0, ...)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 09:38:31 2016
New Revision: 240183

URL: https://gcc.gnu.org/viewcvs?rev=240183&root=gcc&view=rev
Log:
PR middle-end/77594
* internal-fn.c (expand_arith_overflow) : Don't fall
through into expand_addsub_overflow after expand_neg_overflow.

* gcc.target/i386/pr77594.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr77594.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/internal-fn.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/77616] New: A variadic polymorphic lambda call fails with zero arguments

[ville.voutilainen at gmail dot com]

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

Bug ID: 77616
   Summary: A variadic polymorphic lambda call fails with zero
arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test:

int main()
{
[](auto...){}();
}

prog.cc: In function 'int main()':
prog.cc:3:19: error: no match for call to '(main()::) ()'
 [](auto...){}();
   ^
prog.cc:3:15: note: candidate: template main()operator decltype (((const main()::*)((const
main()::*
const)0u))->operator()(static_cast())) (*)(auto:1, ...)()
const 
 [](auto...){}();
   ^
prog.cc:3:15: note:   template argument deduction/substitution failed:
prog.cc:3:19: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^
prog.cc:3:15: note: candidate: template main()::
 [](auto...){}();
   ^
prog.cc:3:15: note:   template argument deduction/substitution failed:
prog.cc:3:19: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[petschy at gmail dot com]

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

--- Comment #5 from petschy at gmail dot com ---
Some more details, hope this helps. Preprocessed one of the oddly behaving
files with 5.4.1, 6.2.1 and 7.0.0, then tried to compile each preprocessed file
with each compiler version. 5.4.1 warned for all preprocessed files, 6.2.1 and
7.0.0 didn't warn for any of them. This doesn't mean that 6.2.1 and 7.0.0 is
not affected, just for this particular file they didn't warn. 

Diffing the files revealed that there is no difference in the user code, only
in the system headers included, eg  comes from
/usr/local/include/c++/5.4.1/string for 5.4.1, etc.

All of the problematic lines are assignments of the form
  var = NULL;
or
  var1 = var2 = NULL;

ALL of the NULL assignments in the file are reported.
NONE of the == or != tests are reported.

Eg: this code warns:

AbstractImage::AbstractImage()
{
 pixels=
# 124 "common/src/AbstractImage.cpp" 3 4
   __null
# 124 "common/src/AbstractImage.cpp"
   ;
 channels_n=0;
 mode=255;
 width=-1;
 height=-1;
}

But if I replace 'pixels =' with 'bool b = pixels ==' above, the warning
disappears, which is strange, I think.

The flags are the same for the != and == tests, ie 
#  "common/src/AbstractImage.cpp" 3 4
is everywhere.

[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls

[nicolas.cavallari at lri dot fr]

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

--- Comment #8 from nicolas.cavallari at lri dot fr ---
While your minimal test case seems to be fixed, my test case still fails on GCC
6.2.0 (Debian):

The output is now:

Base ctor is called at 0x7fff79b27a14
A1::Base is at 0x7fff79b27a14
B1::Base is at 0x7fff79b27a14
Base ctor is called at 0x7fff79b27a10
A2::Base is at 0x7fff79b27a10
C::Base is at 0x7fff79b27a14
2 2 3


There is one less base constructor call, so we are getting there.

[Bug middle-end/77606] abort in __memcpy_chk on an in-bounds copy with type-2 builtin_object_size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The only bug is in the testcase, using __builtin_object_size (, 2) for this is
just wrong, 0 is completely valid return value for that builtin, it is the
"don't know" value that is returned whenever the code doesn't figure it out.
__builtin_object_size (, 0) in this case also returns -1, "don't know" value.

So, if anything, this can be treated as an enhancement request.  Right now for
malloc-like calls, including calls with alloc_size argument, we do:
  if (arg1 < 0 || arg1 >= (int)gimple_call_num_args (call)
  || TREE_CODE (gimple_call_arg (call, arg1)) != INTEGER_CST
  || (arg2 >= 0
  && (arg2 >= (int)gimple_call_num_args (call)
  || TREE_CODE (gimple_call_arg (call, arg2)) != INTEGER_CST)))
return unknown[object_size_type];
So, the enhancement request would be for gimple_call_arg (call, argN) here
being an SSA_NAME instead of INTEGER_CST to try to prove some range instead
(and for the multiplication case do it with extra care because of possible
overflows).
I have reservations about using get_range_info for that though, the VRP stuff
is computed from many sources, including assumptions that undefined behavior
will not happen etc.  But, these builtins are primarily used for security
purposes, and the stuff it is guarding is also undefined behavior, so if
anything, it should do some cheap short walk of the operands and compute range
more conservatively (perhaps only allow SSA_NAME copies, perhaps casts, and
PHIs with all constant arguments or something similar?).

[Bug inline-asm/77607] Aarch64 LDP operand rejected incorrectly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/77615] Template specialization is resolved differently with and without optimizations turned on

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
The compiler only sees single compilation units and it doesn't keep 
a database of previously seen units. 
When it compiles usage.cc it doesn't know anything about specialization.cc.

So there really is nothing that the compiler could do here.
And clang and other compilers also don't warn and behave exactly like
gcc once you use -O2.

[Bug c/77617] New: Miscompilation n &= 0x1F ? x+n : x;

[obilaniu at yahoo dot com]

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

Bug ID: 77617
   Summary: Miscompilation n &= 0x1F ? x+n : x;
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: obilaniu at yahoo dot com
  Target Milestone: ---

Created attachment 39633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39633&action=edit
Demonstration file minimal.c

GCC has been miscompiling on Linux, since at least 4.8.5, the following
function fail():


static   unsigned good(unsigned x, unsigned n){
n &= 0x1F;
return n ? x+n : x;
}
static   unsigned fail(unsigned x, unsigned n){
return n &= 0x1F ? x+n : x;
}


int main(){
return fail(0xDEADBEEFU, 16U) == 0xDEADBEFFU;
}


The program should return an exit status of 1. When main() calls good() it does
return an exit code of 1, but when it calls fail() it returns an exit code of
0.

The program exhibits no UB; A sequence point occurs after the evaluation of the
condition of the ternary operator and before the evaluation of either of its
arms.


My system is OpenSuSE 42.1 Leap with Linux kernel 4.4.5 and the CPU is an Intel
Haswell Core i7. I am using the stock compilers and an SVN checkout.


The miscompilation occurs for the following GCC versions I have access to:
- GCC 4.8.5
- GCC 5.3.1
- GCC 7.0.0 20160916 (svn r240176)



They were configured as follows:

> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux)

> gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran,ada,go --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp
--disable-libvtv --enable-libmpx --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-5 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)

> ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/tmp/ramdisk/build/lib/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/tmp/ramdisk/build
--disable-bootstrap --disable-nls --enable-languages=c
Thread model: posix
gcc version 7.0.0 20160916 (experimental) (GCC)



The program minimal.c was compiled at both -O0 and -O3 and using both gcc and
g++ with identical effects:
  gcc   minimal.c -o minimal
  gcc   -O3 minimal.c -o minimal
  g++   minimal.c -o minimal
  g++   -O3 minimal.c -o minimal
  gcc-5 minimal.c -o minimal
  gcc-5 -O3 minimal.c -o minimal
  g++-5 minimal.c -o minimal
  g++-5 -O3 minimal.c -o minimal
  ./gcc minimal.c -o minimal
  ./gcc -O3 minimal.c -o minimal
No compilations gave any warnings whatsoever during compilation. All
compilations above exhibit the bug when the fail() function is called and don't
when the good() function is called.

An ideone link to a related problem is here:
https://ideone.com/djOB6g

[Bug c++/77618] New: warn for explicit instantiation that occurs after an explicit specialization

[trippels at gcc dot gnu.org]

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

Bug ID: 77618
   Summary: warn for explicit instantiation that occurs after an
explicit specialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

clang has a nice warning:

 % cat foo.ii
template  void foo() {}
template <> void foo() {}
template void foo();

 % clang++ -c foo.ii
foo.ii:3:15: warning: explicit instantiation of 'foo' that occurs after an
explicit specialization has no effect [-Winstantiation-after-specialization]
template void foo();
  ^
foo.ii:2:18: note: previous template specialization is here
template <> void foo() {}
 ^
1 warning generated.

Would be nice to have in gcc, too.

[Bug c++/77618] warn for explicit instantiation that occurs after an explicit specialization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.2.4
   Target Milestone|--- |5.5
Summary|wrong code at -O3 on|[5/6/7 Regression] wrong
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
  Known to fail||4.3.6, 4.5.4

--- Comment #3 from Richard Biener  ---
Non-surprisingly found a working version.  This is outer loop vectorization at
play and it looks like a dependence analysis issue to me:

  :
  # a.1_26 = PHI <0(2), _14(7)>
  # ivtmp_32 = PHI <8(2), ivtmp_7(7)>

  :
  # b.0_27 = PHI <0(3), _12(5)>
  # ivtmp_34 = PHI <2(3), ivtmp_33(5)>
  _8 = b.0_27 + 6;
  _9 = c[b.0_27][_8];
  _10 = _9 ^ 1;
  c[b.0_27][a.1_26] = _10;
  _12 = b.0_27 + 1;
  ivtmp_33 = ivtmp_34 - 1;
  if (ivtmp_33 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  _14 = a.1_26 + 1;
  ivtmp_7 = ivtmp_32 - 1;
  if (ivtmp_7 != 0)
goto ;
  else
goto ;

  :
  goto ;

(compute_affine_dependence
  stmt_a: _9 = c[b.0_27][_8];
  stmt_b: c[b.0_27][a.1_26] = _10;
(analyze_overlapping_iterations
  (chrec_a = {6, +, 1}_2)
  (chrec_b = {0, +, 1}_1)
(analyze_miv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = no dependence)
  (overlaps_b = no dependence))
)
  (overlap_iterations_a = no dependence)
  (overlap_iterations_b = no dependence))
) -> no dependence

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/69255] ICE on x86_64-linux-gnu in "emit_move_insn"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/77500] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Fixed for 6.3+ so far.

[Bug fortran/77516] ICE in is_gimple_min_invariant, at gimple-expr.c:706

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Fixed for 6.3+ so far.

[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.1, 7.0
 Resolution|--- |FIXED
  Known to fail|6.2.1, 7.0  |6.2.0

--- Comment #5 from Jakub Jelinek  ---
Fixed for 6.3+.

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Fixed for 6.3+ so far.

[Bug middle-end/77594] double computation for __builtin_sub_overflow (0, ...)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r145494.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
And the reason is IMHO

/* Determines the overlapping elements due to accesses CHREC_A and
   CHREC_B, that are affine functions.  This function cannot handle
   symbolic evolution functions, ie. when initial conditions are
   parameters, because it uses lambda matrices of integers.  */

static void
analyze_subscript_affine_affine (tree chrec_a,
 tree chrec_b,
 conflict_function **overlaps_a,
 conflict_function **overlaps_b,
 tree *last_conflicts)
{
...
  if (i1 > 0 && j1 > 0)
{
  HOST_WIDE_INT niter_a
= max_stmt_executions_int (get_chrec_loop (chrec_a));
  HOST_WIDE_INT niter_b
= max_stmt_executions_int (get_chrec_loop (chrec_b));
  HOST_WIDE_INT niter = MIN (niter_a, niter_b);
^^^
...
  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
  if (x1 >= niter || y1 >= niter)

we compute the conflict iteration pair to 0, 6 but niter is two here
(minimum of two and eight).

Changing the above tests to use niter_a and niter_b fixes the issue but we have
other niter uses above that.  And the question is of course how to represent
"last_conflict" here -- it is supposed to be an iteration number which
hopefully is in-range for both loops (fixing the above code to properly
use niter_a/b makes it so for _this_ case).  "last_conflicts" is not very
well documented ("This field stores the information about the iteration domain
validity of the dependence relation.").

Patch that needs testing (and a 2nd eye):

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 240176)
+++ gcc/tree-data-ref.c (working copy)
@@ -2686,13 +2682,13 @@ analyze_subscript_affine_affine (tree ch

  if (niter > 0)
{
- HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter - i0, i1),
-   FLOOR_DIV (niter - j0, j1));
+ HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter_a - i0, i1),
+   FLOOR_DIV (niter_b - j0, j1));
  HOST_WIDE_INT last_conflict = tau2 - (x1 - i0)/i1;

  /* If the overlap occurs outside of the bounds of the
 loop, there is no dependence.  */
- if (x1 >= niter || y1 >= niter)
+ if (x1 >= niter_a || y1 >= niter_b)
{
  *overlaps_a = conflict_fn_no_dependence ();
  *overlaps_b = conflict_fn_no_dependence ();


with this patch we get

(compute_affine_dependence
  stmt_a: _2 = c[b.5_22][_1];
  stmt_b: c[b.5_22][a.7_23] = _3;
(analyze_overlapping_iterations
  (chrec_a = {6, +, 1}_2)
  (chrec_b = {0, +, 1}_1)
(analyze_miv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = [0 + 1 * x_1])
  (overlaps_b = [6 + 1 * x_1]))
)
  (overlap_iterations_a = [0 + 1 * x_1])
  (overlap_iterations_b = [6 + 1 * x_1]))
(analyze_overlapping_iterations
  (chrec_a = {0, +, 1}_2)
  (chrec_b = {0, +, 1}_2)
  (overlap_iterations_a = [0])
  (overlap_iterations_b = [0]))
(Dependence relation cannot be represented by distance vector.)
)


The issue was likely introduced by r129797 (not sure if we vectorized the loop
immediately after that change).

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #2 from peien luo  ---
(In reply to Dmitry Vyukov from comment #1)
> Hello,
> 
> Shadow stack size was increased several times, and as far as I remember we
> now have a guard page at the end. Please retest with latest gcc/clang, or
> provide a reproducer.

I moved to another box (a virtual machine) to test the new gcc 4.9.4 (because
the other environment is a shared server I can't make many changes on it.)

What I observed is: without tsan, the process runs fine. With tsan turned on,
then it got fully stuck at some point. (D state, cannot attach or trace). I
haven't yet figured out what caused that. Here is a /proc stack when it got
stuck:

$ cat syscall 
35 0x7ffca05f77e0 0x7ffca05f77e0 0x0 0x8 0x7ffca05f78f0 0x7ffca05f7730
0x7ffca05f77d0 0x7f24ff6f349d

$ cat stack 
[] do_exit+0x1e4/0xa60
[] do_group_exit+0x3f/0xa0
[] get_signal_to_deliver+0x1d0/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] int_signal+0x12/0x17
[] 0x

[Bug c++/77509] [5/6/7 Regression] ICE on invalid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|ICE on invalid C++ code: in |[5/6/7 Regression] ICE on
   |finish_class_member_access_ |invalid C++ code: in
   |expr, at cp/typeck.c:2783   |finish_class_member_access_
   ||expr, at cp/typeck.c:2783

--- Comment #2 from Jakub Jelinek  ---
Started with r154223, before that it has been rejected without ICE:
pr77509.C:3:17: warning: direct base ‘A’ inaccessible in ‘C’ due to ambiguity
pr77509.C: In function ‘void foo()’:
pr77509.C:8:8: error: request for member ‘m’ is ambiguous
pr77509.C:1:40: error: candidates are: template void A::m()
pr77509.C:1:40: error: template void A::m()
pr77509.C:8:12: error: expected primary-expression before ‘int’
pr77509.C:8:12: error: expected ‘;’ before ‘int’

[Bug c/77617] Miscompilation n &= 0x1F ? x+n : x;

[obilaniu at yahoo dot com]

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

Olexa Bilaniuk  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |x86_64-suse-linux   |x86_64-linux-gnu,
   ||x86_64-suse-linux
   Host|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |x86_64-suse-linux   |x86_64-linux-gnu,
   ||x86_64-suse-linux
  Known to fail||4.9.2
  Build|x86_64-pc-linux-gnu,|x86_64-pc-linux-gnu,
   |x86_64-suse-linux   |x86_64-linux-gnu,
   ||x86_64-suse-linux

--- Comment #1 from Olexa Bilaniuk  ---
Confirmed with -m32 flag on all situations above I've tested so far.
Confirmed on a Debian system with distro stock GCC 4.9.2 and Linux kernel
3.6.7:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

Just like everything else: Same flags, no warnings and silent miscompilation of
function fail() but no miscompilation of function good().

[Bug c/77617] Miscompilation n &= 0x1F ? x+n : x;

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
The &= operator has the same precedence as the ternary operator.
So you have to use parentheses in this case.

[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

[dje at gcc dot gnu.org]

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

--- Comment #15 from David Edelsohn  ---
The AIX Subroutine Linkage Convention states:

"The address value in the stack pointer must be quadword-aligned. (The address
value must be a multiple of 16.)" - Stack Layout, Note 2.

https://www.ibm.com/support/knowledgecenter/en/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/linkage_convent.htm

http://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.alangref/idalangref_stack_layout.htm

I believe that requires the change that I proposed to STACK_DYNAMIC_OFFSET in
comment #10.  I will push that patch.

I'm not sure how this should be addressed for the SVR4 ELF ABI when Altivec is
not enabled.

[Bug c/65452] strcmp (foo, foo) could give a warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
strncmp, memcmp, strcasecmp, strncasecmp are other functions we should treat
similarly.

[Bug c/65452] strcmp (foo, foo) could give a warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
This warning could have prevented .

Hopefully I'll get to this in this stage1.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #1 from Bill Schmidt  ---
Mine.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
And confirmed.

[Bug libstdc++/77619] New: uninitialized_meow_construct and friends not exception safe

[rs2740 at gmail dot com]

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

Bug ID: 77619
   Summary: uninitialized_meow_construct and friends not exception
safe
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

The new uninitialized_{default,value}_construct(_n)? and
uninitialized_move(_n)? implementations are not exception safe: previously
constructed objects are leaked if a subsequent construction throws.

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

[vogt at linux dot vnet.ibm.com]

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

--- Comment #16 from Dominik Vogt  ---
There's nothing wrong with applying that change, but it does not fix the
problem.  I'm still debugging this and have it narrowed down to being related
with functions that use alloca() and call another function using varargs.

This code extracted from gencfn-macros:
--
#include 
#include 
#include 

char *gs;

char * concat_copy2 (const char *first, ...)
{
  va_list args;
  va_start (args, first);
  {
char *end = gs;
const char *arg;

for (arg = first; arg ; arg = va_arg (args, const char *))
  {
unsigned long length = strlen (arg);
memcpy (end, arg, length);
end += length;
  }
*end = '\000';
  }
  va_end (args);

  return gs;
}

bool contains (char *k)
{
  fprintf(stderr, "!!!contains: %p '%s'\n", (void *)&k, (char *)k);
  return false;
}

int main(int argc, char **argv)
{
  char *tmp;

  gs = (char *) __builtin_alloca(14);
  tmp = concat_copy2 ("BUILT_IN_", "blab", 0);

  return contains(tmp) ? 0 : 1;
}
--

This somehow overwrites the string concatenated in tmp/gs with some pointer.

[Bug target/77613] Powerpc64le: redundant swaps in autovectorised loop

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
This is simple enough.  We have code to allow splats in pure-SIMD ranges, but
we are missing a pattern that performs a splat and a truncate in the same
operation.  Should have a patch to submit today.

[Bug c++/77597] GCC 6.2 / LLVM 3.9 name mangling discrepancy for function with instantiated template in signature whose template argument involves an ABI tag.

[greenc at fnal dot gov]

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

--- Comment #4 from Chris Green  ---
(In reply to Jakub Jelinek from comment #3)
> Ah, maybe I'm wrong what S6_ stands for.  Anyway:
> https://llvm.org/bugs/show_bug.cgi?id=30401#c1
> has more details.  So NOTABUG?

See particularly https://llvm.org/bugs/show_bug.cgi?id=30401#c1. While the
c++filt provided with binutils on Ubuntu 16.04 demangles both symbols to the
same (correct) function, LLVM's libc++abi demangler demonstrates an apparent
erroneous backreference in LLVM's mangled symbol name. Until new evidence
suggests otherwise, I'd be willing to accept a determination that this is
LLVM's bug, not GCC's.

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

[spop at gcc dot gnu.org]

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

--- Comment #6 from Sebastian Pop  ---
The proposed change looks good to me.

"last_conflicts" is the max index in the conflicting functions for which there
is a dependence:

mem_access_a (conflicting_iterations_in_a (last_conflicts)) is in dependence
with
mem_access_b (conflicting_iterations_in_b (last_conflicts)).

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #3 from peien luo  ---
The process stuck can be reproduced, the kernel call trace is like:

Sep 16 09:38:37 localhost kernel: test_metaserver D 8803f9307300 0 
4250   3896 0x0080
Sep 16 09:38:37 localhost kernel: 880424b4bcd0 0082
8803f9307300 880424b4bfd8
Sep 16 09:38:37 localhost kernel: 880424b4bfd8 880424b4bfd8
8803f9307300 8803f9307300
Sep 16 09:38:37 localhost kernel: 880421c29f40 880421c29fb8
8803faf06c40 8803f9307300
Sep 16 09:38:37 localhost kernel: Call Trace:
Sep 16 09:38:37 localhost kernel: [] schedule+0x29/0x70
Sep 16 09:38:37 localhost kernel: [] do_exit+0x1e4/0xa60
Sep 16 09:38:37 localhost kernel: [] ? update_curr+0xcc/0x150
Sep 16 09:38:37 localhost kernel: [] ?
account_entity_dequeue+0xae/0xd0
Sep 16 09:38:37 localhost kernel: [] do_group_exit+0x3f/0xa0
Sep 16 09:38:37 localhost kernel: []
get_signal_to_deliver+0x1d0/0x6d0
Sep 16 09:38:37 localhost kernel: [] do_signal+0x57/0x6c0
Sep 16 09:38:37 localhost kernel: [] ? ktime_get+0x4c/0xd0
Sep 16 09:38:37 localhost kernel: [] ?
hrtimer_nanosleep+0xd3/0x170
Sep 16 09:38:37 localhost kernel: [] ?
hrtimer_get_res+0x50/0x50
Sep 16 09:38:37 localhost kernel: []
do_notify_resume+0x5f/0xb0
Sep 16 09:38:37 localhost kernel: [] int_signal+0x12/0x17

[Bug c++/77620] New: Generic compile time regression of 7.0

[petschy at gmail dot com]

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

Bug ID: 77620
   Summary: Generic compile time regression of 7.0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

I noticed that compiling my C++ project with 7.0 at -O3 took twice as much time
as before with earlier major versions. First I thought that it might be that
7.0 used more optimizations, but a significant time difference remained even
with -O0:

 5.4.1  6.2.1  7.0.0
-O0  2m10   2m18   3m43
-O1  2m45   2m51   5m38
-O2  3m24   3m26   6m46
-O3  3m25   3m34   7m05

Also did measurements with the gcc source, compiling the master branch
(b55f1f4) with

for o in 0 1 2 3; do for v in 4.9.2 5.4.1 6.2.1 7.0.0; do rm -Rf *;
../configure CC=gcc-$v CXX=g++-$v --enable-languages=c,c++ --disable-multilib
--program-suffix=-`cat ../gcc/BASE-VER` --disable-bootstrap CFLAGS="-O$o
-march=native" CXXFLAGS="-O$o -march=native"; time make -j8; echo "-O$o $v";
echo hit enter to continue; read x; done; done

 4.9.2   5.4.1   6.2.1   7.0.0
-O0  7m157m127m28 8m18
-O1  7m117m137m02 9m11
-O2  8m198m178m2410m57
-O3  8m538m579m0512m03

The tests were done on a PC with Debian Jessie 64bit, AMD FX-8150 @ 4GHz, 16GB
RAM, XFS on SSD.

$ gcc-4.9.2 -v
Using built-in specs.
COLLECT_GCC=gcc-4.9.2
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-4.9.2
Thread model: posix
gcc version 4.9.2 20140808 (prerelease) (GCC)

$ gcc-5.4.1 -v
Using built-in specs.
COLLECT_GCC=gcc-5.4.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.4.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 5.4.1 20160829 (GCC)

$ gcc-6.2.1 -v
Using built-in specs.
COLLECT_GCC=gcc-6.2.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-6.2.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 6.2.1 20160831 (GCC)

$ gcc-7.0.0 -v
Using built-in specs.
COLLECT_GCC=gcc-7.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-7.0.0 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 7.0.0 20160831 (experimental) (GCC)

[Bug target/66947] [5 only] Bootstrap error: Extraneous text after `else' directive

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
  Component|bootstrap   |target
   Target Milestone|--- |5.5
Summary|Bootstrap error: Extraneous |[5 only] Bootstrap error:
   |text after `else' directive |Extraneous text after
   ||`else' directive

[Bug c++/77620] Generic compile time regression of 7.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What happens if you configure gcc trunk with --enable-checking=release ?  The
released versions default to that already and when GCC 7 is released, it will
also be that default too.

[Bug bootstrap/68663] Build failure on AIX 7.1

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
Group Bull, Perzl, and I have been able to build it.  Are you using an up to
date AIX Assembler?

[Bug target/77349] AIX DWARF debugging offset in 64 bit mode

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Author: dje
Date: Fri Sep 16 14:42:54 2016
New Revision: 240188

URL: https://gcc.gnu.org/viewcvs?rev=240188&root=gcc&view=rev
Log:
2016-09-16  David Edelsohn  

Backported from mainline
2016-08-26  David Edelsohn  

PR target/77349
* config/rs6000/xcoff.h (DWARF_OFFSET_SIZE): Define as PTR_SIZE.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/xcoff.h

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-16
 CC||ville at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libgcc/66939] build error gcc-5.2.0/libgcc/libgcc2.c:1955:6 internal compiler error: in real_from_string, at real.c:2078

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does this work now?  Also have you tried a newer version of GMP/MPFR to make
sure it is not a bug in those?

[Bug bootstrap/70838] internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Andrew Pinski  ---
No feedback in 3 months and this works for many other people so closing as
works for me.

[Bug c++/77621] Internal compiler error for mtune=atom + msse2

[marcin.bajor at gmail dot com]

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

--- Comment #2 from Marcin Bajor  ---
Created attachment 39636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39636&action=edit
Build log

[Bug c++/77621] Internal compiler error for mtune=atom + msse2

[marcin.bajor at gmail dot com]

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

--- Comment #1 from Marcin Bajor  ---
Created attachment 39635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39635&action=edit
Build log with Q flag

[Bug c++/77621] New: Internal compiler error for mtune=atom + msse2

[marcin.bajor at gmail dot com]

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

Bug ID: 77621
   Summary: Internal compiler error for mtune=atom + msse2
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.bajor at gmail dot com
  Target Milestone: ---

Created attachment 39634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39634&action=edit
Preprocessed rawimage.cc

Hi,
I'm a maintainer of Rawtherapee packages. I'm using Open Build Service
(https://build.opensuse.org/package/show/home:rawtherapee/rawtherapee)
I have a problem with build the project for Fedora 24 (i686 + msse2) (gcc
6.1.1) with standard set of CXX flags recommended for building packages on OBS:

-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables

+ flag added by me: -msse2

Build finished with "internal compiler error: Segmentation fault"

There is no problem with build for Fedora 23 (gcc 5.1.1) where the same flags
are used.

I've noticed too that there is no problem if I remove -mtune=atom.

To build the project locally use Open Build Service commander:
$ osc co home:rawtherapee rawtherapee
$ cd home\:rawtherapee/rawtherapee/
(optional) modify rawherapee.spec file
$ osc build  --no-verify Fedora_24 i586 rawtherapee.spec --clean

Regards
Marcin Bajor

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #4 from Dmitry Vyukov  ---
Unkillable processed in D state usually mean kernel bugs (and there are lots of
them: https://github.com/google/syzkaller/wiki/Found-Bugs).

Please post results of 'cat /proc/PID/task/*/stack` and `cat
/proc/PID/task/*/status`. Sometimes hangs happen due to secondary threads in
the process. Maybe we will be able to figure out something from that info.
However, I am not sure what we can do about a process hanged in D state,
generally user must not be able to create them.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Tim, can you grab a clean copy of trunk (from a Linux box or from whereever),
cooy that to your Windows machine and try again?

[Bug middle-end/77622] New: __builtin_object_size incorrect for an out-of-bounds pointer prior to destination object

[msebor at gcc dot gnu.org]

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

Bug ID: 77622
   Summary: __builtin_object_size incorrect for an out-of-bounds
pointer prior to destination object
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When the __builtin_object_size intrinsic is passed a pointer that's derived
from the address of an object but points past its end it returns zero in all
types.  This makes it possible for _FORTIFY_SOURCE to detect writing past the
end of the destination buffer.

However, when the function is passed a similarly derived pointer that points
before the beginning of the object it instead returns a positive value,
preventing GCC from emitting the checking calls, and allowing buffer overflows
to go undetected.

The test case below shows these two cases.

$ cat x.c && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -O2
-Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout x.c && ./a.out
#define bos(dest) __builtin_object_size (dest, 0)
#define memcpy(dest, src, n)\
  __builtin___memcpy_chk (dest, src, n, bos (dest))

#define P(x) \
__builtin_printf ("%2zd %2zd %2zd %2zd\n", \
  __builtin_object_size (x, 0), \
  __builtin_object_size (x, 1), \
  __builtin_object_size (x, 2), \
  __builtin_object_size (x, 3)) \

int main (void)
{
  char d [3];
  int i = 10;
  char *p;

  {
p = &d[3] - i;

P (p);

memcpy (p, "abcdef", 5);

__builtin_printf ("%.0s", p);
  }

  { 
p = &d[3] + i;

P (p);

memcpy (p, "abcdef", 5);

__builtin_printf ("%.0s", p);
  }
}
x.c: In function ‘main’:
x.c:19:7: warning: array subscript is below array bounds [-Warray-bounds]
 p = &d[3] - i;
 ~~^~~
x.c:19:7: warning: array subscript is below array bounds [-Warray-bounds]
x.c:29:7: warning: array subscript is above array bounds [-Warray-bounds]
 p = &d[3] + i;
 ~~^~~
x.c:29:7: warning: array subscript is above array bounds [-Warray-bounds]

;; Function main (main, funcdef_no=0, decl_uid=1791, cgraph_uid=0,
symbol_order=0) (executed once)

main ()
{
  char d[3];

  :
  __builtin_printf ("%2zd %2zd %2zd %2zd\n", 10, 10, 10, 10);
  __builtin_memcpy (&MEM[(void *)&d + -7B], "abcdef", 5);
  __builtin_printf ("%.0s", &MEM[(void *)&d + -7B]);
  __builtin_printf ("%2zd %2zd %2zd %2zd\n", 0, 0, 0, 0);
  __builtin___memcpy_chk (&MEM[(void *)&d + 13B], "abcdef", 5, 0);
  __builtin_printf ("%.0s", &MEM[(void *)&d + 13B]);
  d ={v} {CLOBBER};
  return 0;

}


x.c:3:3: warning: call to __builtin___memcpy_chk will always overflow
destination buffer
   __builtin___memcpy_chk (dest, src, n, bos (dest))
   ^
x.c:33:5: note: in expansion of macro ‘memcpy’
 memcpy (p, "abcdef", 5);
 ^~
10 10 10 10
 0  0  0  0
*** buffer overflow detected ***: ./a.out terminated

[Bug fortran/77612] [5/6 Regression] ICE on invalid character len in contained procedure

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Sep 16 17:55:38 2016
New Revision: 240191

URL: https://gcc.gnu.org/viewcvs?rev=240191&root=gcc&view=rev
Log:
2016-09-16  Steven G. Kargl  

PR fortran/77612
* decl.c (char_len_param_value): Check parent namespace for 
seen_implicit_none.


2016-09-16  Steven G. Kargl  

PR fortran/77612
* gfortran.dg/pr77612.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77612.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77612] [5/6 Regression] ICE on invalid character len in contained procedure

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|5.5 |7.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #5 from Matthias Klose  ---
I think it's wrong to have HAVE_LD_PUSHPOPSTATE_SUPPORT baked into the driver
while it can be easily changed with -fuse-ld=bfd.  It would be very nice to
have these push/pop options implemented in gold as well and avoid this kind of
work arounds.

[Bug middle-end/77606] abort in __memcpy_chk on an in-bounds copy with type-2 builtin_object_size

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #2)
> The only bug is in the testcase, using __builtin_object_size (, 2) for this
> is just wrong

Unless the manual does a better job explaining things it's hard to guess how to
use the feature, even for someone who has been working with this feature for
years.  Here's what I see there now:

  The intended use can be e.g.

 #undef memcpy
 #define bos0(dest) __builtin_object_size (dest, 0)
 #define memcpy(dest, src, n) \
   __builtin___memcpy_chk (dest, src, n, bos0 (dest))

Given this example of intended use it seems that another such example is one
where the bos macro is defined like so:

 #define bos2(dest) __builtin_object_size (dest, 2)
 #define memcpy(dest, src, n) \
   __builtin___memcpy_chk (dest, src, n, bos2 (dest))

If this isn't meant to be a valid example then the manual needs to be clarified
and explain what some of the other examples might be (and also what would not
be valid examples).  I can appreciate that passing 0 as the object size to
__builtin___memcpy_chk and interpreting it as "unknown size" in the absence of
any other information is tricky.  But that's a problem with (defect in) the
design of the builti-ins that needs to highlighted in the manual so users know
to avoid it.  This was also one point of the test case in comment #0.  My bad
for not articulating it more clearly.

> 0 is completely valid return value for that builtin, it is
> the "don't know" value that is returned whenever the code doesn't figure it
> out.

Exactly.  Overloading the return value this way is the problem that either
needs to be solved or that needs to be documented in the manual (i.e., the
manual needs to explain that the use of the bos2() macro may lead to false
positives in some cases and give examples of some of them).

> __builtin_object_size (, 0) in this case also returns -1, "don't know" value.
> 
> So, if anything, this can be treated as an enhancement request.  Right now
> for malloc-like calls, including calls with alloc_size argument, we do:
>   if (arg1 < 0 || arg1 >= (int)gimple_call_num_args (call)
>   || TREE_CODE (gimple_call_arg (call, arg1)) != INTEGER_CST
>   || (arg2 >= 0
>   && (arg2 >= (int)gimple_call_num_args (call)
>   || TREE_CODE (gimple_call_arg (call, arg2)) != INTEGER_CST)))
> return unknown[object_size_type];
> So, the enhancement request would be for gimple_call_arg (call, argN) here
> being an SSA_NAME instead of INTEGER_CST to try to prove some range instead
> (and for the multiplication case do it with extra care because of possible
> overflows).

I haven't studied the implementation in enough detail to comment on the
suggestion above but I can say what my expectation is from a user's point of
view: since there is no practical difference between an object allocated by
'__builtin_malloc (1 < argc ? 40 : 80)' and one allocated by '1 < argc ?
__builtin_malloc (40) : __builtin_malloc (80)', then since writing past the end
of one such object is detected so should be writing past the end of the other. 
When it isn't, users don't care if it's due to some inherent limitation in the
GCC representation of the two expressions, or what changes in GCC might be
required to make it so.  To them, the feature simply doesn't work the way they
expect and the way it's documented to.  In most users' minds that's also not an
enhancement but a deficiency.

> I have reservations about using get_range_info for that though, the VRP
> stuff is computed from many sources, including assumptions that undefined
> behavior will not happen etc.  But, these builtins are primarily used for
> security purposes, and the stuff it is guarding is also undefined behavior,
> so if anything, it should do some cheap short walk of the operands and
> compute range more conservatively (perhaps only allow SSA_NAME copies,
> perhaps casts, and PHIs with all constant arguments or something similar?).

I don't necessarily insist on using VRP here.  If there's a different/better
way to do it I'm all for it.  But if there isn't, I don't think that just
because VRP assumes the absence of undefined behavior it can't or shouldn't be
used to help detect its absence in calls to memcpy et al., unless it causes
false positives.

[Bug lto/67111] ld -plugin segmentation fault

[dilyan.palauzov at aegee dot org]

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

--- Comment #2 from Дилян Палаузов  ---
I do not have the environment anymore.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 19:17:47 2016
New Revision: 240193

URL: https://gcc.gnu.org/viewcvs?rev=240193&root=gcc&view=rev
Log:
PR libgcc/71744
* unwind-dw2-fde.c (ATOMIC_FDE_FAST_PATH): Define if __register_frame*
is not the primary registry and atomics are available.
(any_objects_registered): New variable.
(__register_frame_info_bases, __register_frame_info_table_bases):
Atomically store 1 to any_objects_registered after registering first
unwind info.
(_Unwind_Find_FDE): Return early if any_objects_registered is 0.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/unwind-dw2-fde.c

[Bug c++/77620] Generic compile time regression of 7.0

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
Thanks, --enable-checking=release did the trick. Those unreleased checks
definitely have some runtime cost :)

My project was built in 3m35 with -O3, and the gcc master branch:

 7.0.0
-O0  7m30
-O1  7m00
-O2  8m23
-O3  9m02

These are effectively the same as with 6.2.1.

Sorry for the noise.

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
Created attachment 39637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39637&action=edit
A patch candidate

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Sorry for delay with the answer.  I had a long vacation.

LRA remat sub-pass did not check relation between the hard coded insn
registers.  It checked only relations between operand registers and other
operands and hard coded insn registers.

The attached patch should solve the problem.  If it works for you.  I'll commit
it on the next week.

[Bug c++/77375] [5/6/7 Regression] constant object with mutable subobject allocated in read-only memory

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 20:21:29 2016
New Revision: 240195

URL: https://gcc.gnu.org/viewcvs?rev=240195&root=gcc&view=rev
Log:
PR c++/77375
* class.c (check_bases): Set CLASSTYPE_HAS_MUTABLE if any
TYPE_HAS_MUTABLE_P
for any bases.

* g++.dg/cpp0x/mutable1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/mutable1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77338] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 16 20:22:35 2016
New Revision: 240196

URL: https://gcc.gnu.org/viewcvs?rev=240196&root=gcc&view=rev
Log:
PR c++/77338
* constexpr.c (cxx_eval_constant_expression) : Only
call is_really_empty_class on complete types.

* g++.dg/cpp0x/decltype-77338.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-77338.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog