date:20171002

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Peter Bohning from comment #9)
> No.  I think you've misunderstood the problem and I mean I can't test it
> because I don't have a computer now but.. 

No I am not misunderstanding the problem.  You misconfigured the gcc.

> 
> Like I said I'm doing this to get the libstdc++ library for aarch64, I
> already am using the linaro toolchain to actually cross-compile things.

The linaro toolchain already includes a libstdc++ library so there is no reason
why you need to recompile GCC/libstdc++ here.

> 
> And as I recall, "target" defaults to "host".

It does not.  Read
https://gcc.gnu.org/install/configure.html


> By marking this bug "invalid" and "resolved" you're also neglecting that
> these various things I ran into are at the very least bad practice even if
> your claim that just using "target" and not "host" will somehow pick just
> the right defines to get this tangled mess of C++ code to compile.

No I have not.  You are misunderstanding GCC's configure options.  There are
three different triplets and I described them above (this is documented in the
configure/autoconf documentation; look for canadian cross).

You still did not describe what kind of cross compiler you want?  Do you want
one which runs on x86_64 (and built on x86_64) that targets aarch64 if so then
just --target= is needed.  If you want one which runs on aarch64 (was built on
x86_64 that targets aarch64), then --host= and --target= is needed but you
first need a cross that RUNS on x86_64 to be able to build the target libraries
like libstdc++.

Since you have the linaro toolchain you don't need to build glibc; you can use
that sysroot to build the full gcc.

Now compiling cross toolchains are not hard but require you to pay attention to
all three tiplets and understand what the uses are.

The problems you are running into are very simple, you are trying to build a
canadian cross compiler but using an older GCC (6) cross compiler to get the
target libraries built.  The target libraries require a cross compiler which is
the same version as the "canadian" cross compiler.

That is you need a GCC 7 cross compiler that targets aarch64 which is hosted on
x86_64 (and built on x86_64) to be able to build the target libraries for a
compiler which is hosted on aarch64 targeting aarch64 (but built on x86_64).

So again this is invalid because you are using the wrong cross compiler to
build the target libraries and not understanding the three triplets (build,
host and target).  I hope this long message allows you to understand the three
tiplets better than I explained before.

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #9 from Peter Bohning  ---
No.  I think you've misunderstood the problem and I mean I can't test it
because I don't have a computer now but.. 

Like I said I'm doing this to get the libstdc++ library for aarch64, I already
am using the linaro toolchain to actually cross-compile things.

And as I recall, "target" defaults to "host".

By marking this bug "invalid" and "resolved" you're also neglecting that these
various things I ran into are at the very least bad practice even if your claim
that just using "target" and not "host" will somehow pick just the right
defines to get this tangled mess of C++ code to compile.

[Bug middle-end/82394] Pointer imposes an optimization barrier

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |middle-end

--- Comment #3 from Andrew Pinski  ---
With GCC 7.1 on x86_64, they both produce:
my_sorted_array:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret

my_sorted_array1:
.LFB1:
.cfi_startproc
xorl%eax, %eax
ret


I have not tried the trunk yet.

[Bug c/82413] New: -O0 crash (ICE in decompose, at tree.h:5179)

2017-10-02 Thread babokin at gmail dot com

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

Bug ID: 82413
   Summary: -O0 crash (ICE in decompose, at tree.h:5179)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

GCC trunk, rev 253367, x86_64.

Rev 253307 works fine, so it's a fresh regression.

> cat f.cpp
bool a;
int b;
void c() { b & <= 0; }

> g++ -c f.cpp
f.cpp: In function ‘void c()’:
f.cpp:3:21: internal compiler error: in decompose, at tree.h:5179
 void c() { b & <= 0; }
 ^
0x6cbe00 wi::int_traits::decompose(long*, unsigned int,
tree_node const*)
../../gcc/gcc/tree.h:5179
0x6cbe00 wide_int_ref_storage::wide_int_ref_storage(tree_node const* const&, unsigned int)
../../gcc/gcc/wide-int.h:976
0x6cbe00 generic_wide_int::generic_wide_int(tree_node const* const&, unsigned int)
../../gcc/gcc/wide-int.h:753
0x6cbe00 bool wi::eq_p(generic_wide_int const&, tree_node const* const&)
../../gcc/gcc/wide-int.h:1760
0x6cbe00 bool
generic_wide_int::operator==(tree_node* const&)
const
../../gcc/gcc/wide-int.h:704
0x6cbe00 build_range_check(unsigned int, tree_node*, tree_node*, int,
tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:4854
0xcd4a08 build_range_check(unsigned int, tree_node*, tree_node*, int,
tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:4809
0xb4c404 warn_logical_operator(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node*)
../../gcc/gcc/c-family/c-warn.c:270
0x91af33 build_new_op_1
../../gcc/gcc/cp/call.c:5978
0x91b42e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6051
0xabf972 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3960
0xa03a2e cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9274
0xa04f74 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9407
0xa05678 cp_parser_expression
../../gcc/gcc/cp/parser.c:9576
0xa07388 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11091
0xa0d543 cp_parser_statement
../../gcc/gcc/cp/parser.c:10907
0xa0e5f0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11234
0xa0e6c7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11188
0xa2400a cp_parser_function_body
../../gcc/gcc/cp/parser.c:21669
0xa2400a cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21707
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/68230] Unused function parameters not reported by -Wunused-parameter when only used recursively.

2017-10-02 Thread j.fisher at digipen dot edu

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

--- Comment #8 from Joshua T, Fisher  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Joshua T, Fisher from comment #5)
> > and my blog where I first encountered this in a closed source codebase:
> > 
> > http://www.nullterminatedstrings.com/c++/recursive-warning
> 
> I'm a bit more persuaded having read this. If it points out you forgot to
> use it (for anything except the recursion) that could help find real bugs.

That's what I was hoping! I feel like it's definitely something that could hit
some real code bases. I find it unlikely I'm the only person ever to run into
this.

[Bug c/81854] weak alias of an incompatible symbol accepted

2017-10-02 Thread msebor at gcc dot gnu.org

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

--- Comment #17 from Martin Sebor  ---
Author: msebor
Date: Mon Oct  2 23:57:19 2017
New Revision: 253372

URL: https://gcc.gnu.org/viewcvs?rev=253372=gcc=rev
Log:
Clean up more fallout from r252976.

libatomic/ChangeLog:
2017-10-02  Martin Sebor  

PR c/81854
* acinclude.m4 (LIBAT_CHECK_IFUNC): Have ifunc resolver return
a function pointer rather than void* to avoid GCC 8 warnings.
* configure: Regenerate.
* libatomic_i.h: Declare ifunc resolvers to return function
pointers rather than void*.

Modified:
trunk/libatomic/ChangeLog
trunk/libatomic/acinclude.m4
trunk/libatomic/configure
trunk/libatomic/libatomic_i.h

[Bug c++/70570] Assembler error "symbol already defined" from nested lambdas and function-static variable

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|ndkrempel at gmail dot com |
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #5 from Paolo Carlini  ---
Fixed a while ago, in 6.2.0. I added the testcase.

[Bug c++/70570] Assembler error "symbol already defined" from nested lambdas and function-static variable

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct  2 22:21:16 2017
New Revision: 253370

URL: https://gcc.gnu.org/viewcvs?rev=253370=gcc=rev
Log:
2017-10-02  Paolo Carlini  

PR c++/70570
* g++.dg/cpp1y/lambda-generic-70570.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-70570.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/79590] ICE (internal compiler error) in nothrow_spec_p with generic lambda and `noexcept(noexcept(...))` expression

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.3 |7.0

--- Comment #5 from Paolo Carlini  ---
The released 7.1.0 is fine. I added the testcases, to be safe.

[Bug c++/79590] ICE (internal compiler error) in nothrow_spec_p with generic lambda and `noexcept(noexcept(...))` expression

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct  2 22:02:03 2017
New Revision: 253369

URL: https://gcc.gnu.org/viewcvs?rev=253369=gcc=rev
Log:
2017-10-02  Paolo Carlini  

PR c++/79590
* g++.dg/cpp1y/lambda-generic-noexcept1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-noexcept1.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/54367] [meta-bug] lambda expressions

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

Bug 79005 Summary: Use of a captured variable within nested generic lambdas 
provokes internal compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79005

   What|Removed |Added

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

[Bug c++/79005] Use of a captured variable within nested generic lambdas provokes internal compiler error.

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|mmccutcheon at nuvucameras dot com |
 Blocks||54367
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #6 from Paolo Carlini  ---
Fixed in trunk.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
[Bug 54367] [meta-bug] lambda expressions

[Bug testsuite/82412] New: [8 regression] gfortran.dg/graphite/pr42334-1.f fails starting with r253342

2017-10-02 Thread seurer at linux dot vnet.ibm.com

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

Bug ID: 82412
   Summary: [8 regression] gfortran.dg/graphite/pr42334-1.f fails
starting with r253342
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on both powerpc64 le and be.  The test case was updated for this
revision; perhaps there is a mistake in in?  The other updated test cases work
fine.

gfortran.dg/graphite/pr42334-1.fExecuting on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O  -O2
-floop-interchange -fdump-tree-graphite-details --param
graphite-allow-codegen-errors=1 -S   -o pr42334-1.s(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -O2 -floop-interchange
-fdump-tree-graphite-details --param graphite-allow-codegen-errors=1 -S -o
pr42334-1.s
PASS: gfortran.dg/graphite/pr42334-1.f   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr42334-1.f   -O   scan-tree-dump-times graphite
"code generation error" 1
testcase
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/graphite.exp
completed in 1 seconds

=== gfortran Summary ===

# of expected passes1
# of unexpected failures1

[Bug c++/79005] Use of a captured variable within nested generic lambdas provokes internal compiler error.

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct  2 21:44:55 2017
New Revision: 253368

URL: https://gcc.gnu.org/viewcvs?rev=253368=gcc=rev
Log:
2017-10-02  Paolo Carlini  

PR c++/79005
* g++.dg/cpp1y/lambda-generic-79005.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-79005.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/82411] const is not always read-only

2017-10-02 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-02
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
To access this as sdata is faster and smaller than as rodata (one
instruction instead of two).

You can use -G0 as Andrew says, or -mno-sdata (or -msdata=none).

[Bug target/81357] Extra mov for zero extend of add

2017-10-02 Thread qing.zhao at oracle dot com

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

--- Comment #12 from Qing Zhao  ---
> Well it is not wrong, just non-optimal. It is possible to use a single 
> register
> here but it means teaching GCC that these values are identical, which is
> non-trivial as it likely affects various places in the mid-end (this issue is
> target-independent).

does “these values are identical” mean that the value “fParm + 1” and its
zero_extension “unsigned long long (fParm +1)”
are identical?
I don’t think so.
However, I do agree that there is opportunity for more compact code:
these two values  can be stored in the same register on some of the target.
(for example, aarch64 or ia64).
but Not on all the targets (for example, all 32bit targets).

So, if we really want this additional optimization, this looks like a
target-dependent one. we might add a new target-depend
hook on whether two values with different width can be stored in the same
register (one is the other one’s zero-extension), and
then enhance register allocation with this hook?

[Bug target/82411] const is not always read-only

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

--- Comment #1 from Andrew Pinski  ---
Actually it is just undefined what happens when a write to a const variable. 

So a trap or the write happened for a const both are valid thing.

Now const really should be put in the read only section if possible.

Putting it in the sdata section is valid thing to do but I doubt some people
want it there. 

Powerpc should have an option which disabled this optimization for const
variables.

Right now there is a way to disable all of sdata by -G0 option which is a good
workaround.

[Bug c/82411] New: const is not always read-only

2017-10-02 Thread kees at outflux dot net

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

Bug ID: 82411
   Summary: const is not always read-only
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

On powerpc, a const variable may end up in the .sdata section, which is
writable. This means authors cannot depend on the "const" marking to mean
"read-only", as is required for sane Linux kernel memory protection security.

Thread here:
https://lkml.org/lkml/2017/10/2/488

At the very least, there should be a way to request never putting a const
variable into a writable section.

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #8 from Peter Bohning  ---
Well I guess, that seems strange that one would ever actually want to do that. 
But it sounds great that it supports such things.

Anyway, I will try --target but my laptop just completely died.  Says there's
no power when it's plugged in and the other day there was some kind of early
boot "spin lock" freeze so... bad things always come in hundreds.

Thanks for your advice and I will see if --target makes any difference with
these various C++ errors and such when I can.

[Bug c++/82410] ICE in replace_placeholders_r

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|tomilovanatoliy at yandex dot ru   |mpolacek at gcc dot 
gnu.org

--- Comment #1 from Paolo Carlini  ---
Marek, is this PR79937 ?

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
.

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

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

--- Comment #11 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Oct  2 19:38:06 2017
New Revision: 253366

URL: https://gcc.gnu.org/viewcvs?rev=253366=gcc=rev
Log:
PR ada/82384
* libgnarl/s-linux__x32.ads (suseconds_t): New subtype.
(time_t): Change from derived type to subtype.
(timeval): Use suseconds_t for tv_usec.
* libgnarl/s-osinte__x32.adb (To_Timespec): Remove use type clause.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/libgnarl/s-linux__x32.ads
trunk/gcc/ada/libgnarl/s-osinte__x32.adb

[Bug c++/82410] New: ICE in replace_placeholders_r

2017-10-02 Thread tomilovanatoliy at yandex dot ru

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

Bug ID: 82410
   Summary: ICE in replace_placeholders_r
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomilovanatoliy at yandex dot ru
  Target Milestone: ---

Internal compiler error on valid code. -std=c++14,17. Known to work in 5.*,
6.*. Known to not work in 7.1, 7.2, 8 HEAD.

int main()
{
struct A {};
struct S
{

int & p;
int x = p;
operator A () { return {}; }

};
int l;
[] (A) {} (S{l});
}


# Error message:

prog.cc: In function 'int main()':
prog.cc:13:20: internal compiler error: in replace_placeholders_r, at
cp/tree.c:2795
 [] (A) {} (S{l});
^
0x6952e9 replace_placeholders_r
../../gcc-7.2.0/gcc/cp/tree.c:2795
0xcf18b5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-7.2.0/gcc/tree.c:11822
0xcf1e5e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-7.2.0/gcc/tree.c:12139
0x69521b replace_placeholders_r
../../gcc-7.2.0/gcc/cp/tree.c:2825
0xcf18b5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-7.2.0/gcc/tree.c:11822
0xcf1d34 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-7.2.0/gcc/tree.c:12049
0x6953a1 replace_placeholders(tree_node*, tree_node*, bool*)
../../gcc-7.2.0/gcc/cp/tree.c:2861
0x6c74ce cp_gimplify_init_expr
../../gcc-7.2.0/gcc/cp/cp-gimplify.c:500
0x6c74ce cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../gcc-7.2.0/gcc/cp/cp-gimplify.c:659
0x8d4245 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-7.2.0/gcc/gimplify.c:11149
0x8ddb1c gimplify_target_expr
../../gcc-7.2.0/gcc/gimplify.c:6418
0x8d54ce gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-7.2.0/gcc/gimplify.c:11620
0x8d7b68 gimplify_stmt(tree_node**, gimple**)
../../gcc-7.2.0/gcc/gimplify.c:6497
0x8d828b gimplify_compound_expr
../../gcc-7.2.0/gcc/gimplify.c:5726
0x8d551f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-7.2.0/gcc/gimplify.c:11230
0x8dd324 gimplify_expr
../../gcc-7.2.0/gcc/gimplify.c:12241
0x8de6ce gimplify_call_expr
../../gcc-7.2.0/gcc/gimplify.c:3262
0x8d6137 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-7.2.0/gcc/gimplify.c:11212
0x8d7b68 gimplify_stmt(tree_node**, gimple**)
../../gcc-7.2.0/gcc/gimplify.c:6497
0x8d6086 gimplify_cleanup_point_expr
../../gcc-7.2.0/gcc/gimplify.c:6241
Please submit a full bug report,

[Bug target/82409] Superflous pxor instructions in the generated assembly.

2017-10-02 Thread ubizjak at gmail dot com

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #2 from Uroš Bizjak  ---
This is by design, to break partial SSE reg dependency on:

/* X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY: This knob promotes all store
   destinations to be 128bit to allow register renaming on 128bit SSE units,
   but usually results in one extra microop on 64bit SSE units.
   Experimental results shows that disabling this option on P4 brings over 20%
   SPECfp regression, while enabling it on K8 brings roughly 2.4% regression
   that can be partly masked by careful scheduling of moves.  */
DEF_TUNE (X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY, "sse_partial_reg_dependency",
  m_PPRO | m_P4_NOCONA | m_CORE_ALL | m_BONNELL | m_AMDFAM10
  | m_BDVER | m_ZNVER1 | m_GENERIC)

[Bug target/82409] Superflous pxor instructions in the generated assembly.

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
>Note pxor instructions in there to zero out the unused upper bits of xmm 
>registers.

It could be done to avoid false dependencies on previous instructions which
touched xmm0/1 register.

[Bug fortran/82312] [7/8 Regression] Pointer assignment to component of class variable results wrong vptr for the variable.

2017-10-02 Thread pault at gcc dot gnu.org

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Mon Oct  2 18:17:39 2017
New Revision: 253362

URL: https://gcc.gnu.org/viewcvs?rev=253362=gcc=rev
Log:
2017-10-02  Paul Thomas  

PR fortran/82312
* resolve.c (gfc_resolve_code): Simplify condition for class
pointer assignments becoming regular assignments by asserting
that only class valued targets are permitted.
* trans-expr.c (trans_class_pointer_fcn): New function using a
block of code from gfc_trans_pointer_assignment.
(gfc_trans_pointer_assignment): Call the new function. Tidy up
a minor whitespace issue.

2017-10-02  Paul Thomas  

PR fortran/82312
* gfortran.dg/typebound_proc_36.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_proc_36.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82337] [5/6/7/8 Regression] ICE: SSA corruption at tree-ssa-coalesce.c:1010

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #16 from Bill Schmidt  ---
Now fixed everywhere, closing.

[Bug tree-optimization/82337] [5/6/7/8 Regression] ICE: SSA corruption at tree-ssa-coalesce.c:1010

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

--- Comment #15 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct  2 18:10:40 2017
New Revision: 253361

URL: https://gcc.gnu.org/viewcvs?rev=253361=gcc=rev
Log:
[gcc]

2017-10-02  Bill Schmidt  

Backport from mainline
2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gimple-ssa-strength-reduction.c (find_phi_def): Don't record a
phi definition if the PHI result appears in an abnormal PHI.
(find_basis_for_base_expr): Don't record a basis if the LHS of the
basis appears in an abnormal PHI.

[gcc]

2017-10-02  Bill Schmidt  

Backport from mainline
2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gcc.c-torture/compile/pr82337.c: New file.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr82337.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/82408] cross-compiling for arm64 problems

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
(In reply to Peter Bohning from comment #6)
> Well I can't say I understand why the host and the target would ever be
> different, but are you saying that I need to add another flag for something?

I can think of one.
You are building a cross compiler that will run on windows targeting an
embedded target but you are building on a linux box.


> I mean I never set the target, so it can't determine the target from the
> host?  All the other packages seemed to be fine with just "--host"?

Just use --target= and not --host here.


So the question now becomes do you want a compiler that runs on x86_64 or
aarch64?

If you want one that runs on x86_64 just use --target.
If you want one that runs on aarch64 that targets aarch64, you need to first
build a (new) cross compiler that runs on x86_64 [because the target libraries
can only be built with the newer version of the compiler(7)] and then build one
that is configured with
--target= --host= .

[Bug tree-optimization/82337] [5/6/7/8 Regression] ICE: SSA corruption at tree-ssa-coalesce.c:1010

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

--- Comment #14 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct  2 18:09:20 2017
New Revision: 253360

URL: https://gcc.gnu.org/viewcvs?rev=253360=gcc=rev
Log:
[gcc]

2017-10-02  Bill Schmidt  

Backport from mainline
2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gimple-ssa-strength-reduction.c (find_phi_def): Don't record a
phi definition if the PHI result appears in an abnormal PHI.
(find_basis_for_base_expr): Don't record a basis if the LHS of the
basis appears in an abnormal PHI.

[gcc]

2017-10-02  Bill Schmidt  

Backport from mainline
2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gcc.c-torture/compile/pr82337.c: New file.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/pr82337.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/82337] [5/6/7/8 Regression] ICE: SSA corruption at tree-ssa-coalesce.c:1010

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct  2 18:07:45 2017
New Revision: 253359

URL: https://gcc.gnu.org/viewcvs?rev=253359=gcc=rev
Log:
[gcc]

2017-10-02  Bill Schmidt  

Backport from mainline
2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gimple-ssa-strength-reduction.c (find_phi_def): Don't record a
phi definition if the PHI result appears in an abnormal PHI.
(find_basis_for_base_expr): Don't record a basis if the LHS of the
basis appears in an abnormal PHI.

[gcc]

2017-10-02  Bill Schmidt  

Backport from mainline
2017-09-29  Bill Schmidt  

PR tree-optimization/82337
* gcc.c-torture/compile/pr82337.c: New file.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/compile/pr82337.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/82358] [8 regression] i386/stack-check-11.c fail

2017-10-02 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
?!?

First, I don't get this failure.  Andrey, what is your precise target
configuration?

Martin -- the code you show is exactly what is should be.

In the "before" case we have a stack allocation of 13768 bytes, then probes
into that allocation.  That is not safe WRT stack-clash as you could get an
async signal between the allocation and probing points and the async handler
would be running with a clashed stack/heap.

The "after" case we see 4 distinct allocations and probes, which is exactly
what we want.

[Bug c++/82409] New: Superflous pxor instructions in the generated assembly.

2017-10-02 Thread maxim.yegorushkin at gmail dot com

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

Bug ID: 82409
   Summary: Superflous pxor instructions in the generated
assembly.
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

For the following function:

double f(int a, int b) {
   return static_cast(a - b) / (a + b);
}

g++-7.2 with flags "-O3 -std=c++14" generates the following code:

f(int, int):
pxor%xmm0, %xmm0
movl%edi, %eax
pxor%xmm1, %xmm1
subl%esi, %eax
addl%esi, %edi
cvtsi2sd%eax, %xmm0
cvtsi2sd%edi, %xmm1
divsd   %xmm1, %xmm0
ret

Note pxor instructions in there to zero out the unused upper bits of xmm
registers. Are they necessary?

clang++-3.5 and newer generates similar code but without these pxor
instructions.

[Bug testsuite/82390] gcc.dg/torture tests run with same optimization level

2017-10-02 Thread joseph at codesourcery dot com

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

--- Comment #5 from joseph at codesourcery dot com  ---
dg-options is absolutely fine in torture directories, as long as the 
options specified are not among the -O options that the test should be 
looping over.  For example, it's fine for a torture test to specify a -std 
option, or -D_GNU_SOURCE, or -fsignaling-nans.  I don't see any advantage 
to using dg-additional-options, except in the cases where you have a base 
set of dg-options and then some target-specific dg-additional-options.

[Bug fortran/25829] [F03] Asynchronous IO support

2017-10-02 Thread tkoenig at gcc dot gnu.org

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

--- Comment #28 from Thomas Koenig  ---
(In reply to Nicolas Koenig from comment #27)

> program main
> implicit none
> open (10, file='foo.dat', asynchronous='yes')
> call s()
> close(10)
> contains
> subroutine s()
> integer, dimension (3)::i !presumably on the stack
> i = [0, 1]
> write(10,*) i
> !Now the stack frame is dropped and the pointer that previously
> !pointed to the array now points to nowhere, but it is still enqueued
> end subroutine
> end program

This program is illegal (J3/09-007r3, 9.6.4.1, paragraph 4),
so you do not have to do anything about it.

An interesting case is mixing of synchronous and
asynchronous I/O for the same unit, which is permitted.
I think this is like an implicit WAIT, same as a BACKSPACE,
FLUSH, ...

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #6 from Peter Bohning  ---
Well I can't say I understand why the host and the target would ever be
different, but are you saying that I need to add another flag for something?  I
mean I never set the target, so it can't determine the target from the host? 
All the other packages seemed to be fine with just "--host"?

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

2017-10-02 Thread bergner at gcc dot gnu.org

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #19 from Peter Bergner  ---
Fixed on trunk.  I will back port this to the GCC 6 and 7 release branches
after it has had some burn in time on trunk.

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #5 from Andrew Pinski  ---
Gcc has three different triplets.
Host
Build
Target

Host is where the newly compiled compiler will run on.
Build is where you are building
Target is what processor the compiler is targeting.

[Bug tree-optimization/82363] [8 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2017-10-02 Thread jamborm at gcc dot gnu.org

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

--- Comment #4 from Martin Jambor  ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00070.html

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #4 from Peter Bohning  ---
Is that really it?  I saw a warning about that but... I assumed BUILD was the
build machine and HOST was the target?

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #3 from Andrew Pinski  ---
So you are trying to compile a compiler that is hosted on aarch64-linux-gnu but
targeting the target on what you are building on?

[Bug target/82408] cross-compiling for arm64 problems

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

--- Comment #2 from Peter Bohning  ---
export CFLAGS="-Wl,--sysroot=$SYSROOT -I$SYSROOT/../gcc-7.2.0/include
-I$SYSROOT/include -I$SYSROOT/usr/include"
export CC_FOR_TARGET="$CROSS_COMPILE"gcc
export GCC_FOR_TARGET="$CROSS_COMPILE"gcc
export CXX_FOR_TARGET="$CROSS_COMPILE"g++
export AR_FOR_TARGET="$CROSS_COMPILE"ar
export AS_FOR_TARGET="$CROSS_COMPILE"as
export NM_FOR_TARGET="$CROSS_COMPILE"nm
export LD_FOR_TARGET="$CROSS_COMPILE"ld
export STRIP_FOR_TARGET='"$CROSS_COMPILE"strip'
export RANLIB_FOR_TARGET="$CROSS_COMPILE"ranlib
export READELF_FOR_TARGET="$CROSS_COMPILE"readelf
export OBJCOPY_FOR_TARGET="$CROSS_COMPILE"objcopy
export OBJDUMP_FOR_TARGET="$CROSS_COMPILE"objdump
if ! [ -e system/usr/bin/gcc ] ; then
if ! [ -e gcc-7.2.0 ] ; then
if ! [ -e gcc-7.2.0.tar.xz ] ; then
if ! `curl -O
ftp.gnu.org/gnu/gcc/gcc-7.2.0/gcc-7.2.0.tar.xz` ; then
die "Can't get gcc source"
fi
fi
tar xJf gcc-7.2.0.tar.xz
fi
cd gcc-7.2.0 
patch gcc/Makefile.in < $PATCHDIR/gcc-7.2.0-no-selftest.patch
patch libgcc/soft-fp/half.h < $PATCHDIR/gcc-7.2.0-half-HFType.patch
patch libstdc++-v3/include/bits/move.h <
$PATCHDIR/gcc-7.2.0-builtin_addressof.patch
patch libstdc++-v3/include/std/type_traits <
$PATCHDIR/gcc-7.2.0-type_traits.patch
# really unsure about this one... maybe something unnecessary
# and this should have worked... 
patch libstdc++-v3/libsupc++/new < $PATCHDIR/gcc-7.2.0-new.patch
mkdir -p build
 cd build
../configure --host=aarch64-linux-gnu \
--enable-languages=c,c++ --enable-__cxa_atexit
--enable-c99 --enable-long-long \
--enable-threads=posix \
--with-mpfr=$SYSROOT/usr --with-mpc=$SYSROOT/usr
--with-gmp=$SYSROOT/usr \
--with-sysroot=$SYSROOT \
--prefix=/usr || die "Can't configure gcc"
make -j4 || die "Can't compile gcc"
$FTINSTALL $SYSROOT make install || die "Can't install gcc"
cd ../../
fi

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

2017-10-02 Thread bergner at gcc dot gnu.org

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

--- Comment #18 from Peter Bergner  ---
Author: bergner
Date: Mon Oct  2 16:56:58 2017
New Revision: 253358

URL: https://gcc.gnu.org/viewcvs?rev=253358=gcc=rev
Log:
gcc/
PR target/80210
* config/rs6000/rs6000.c (rs6000_option_override_internal): Rewrite
function to not use the have_cpu variable.  Do not set cpu_index,
rs6000_cpu_index or rs6000_tune_index if we end up using TARGET_DEFAULT
or the default cpu.
(rs6000_valid_attribute_p): Remove duplicate initializations of
old_optimize and func_optimize.
(rs6000_pragma_target_parse): Call rs6000_activate_target_options ().
(rs6000_activate_target_options): Make global.
* config/rs6000/rs6000-protos.h (rs6000_activate_target_options): Add
prototype.

gcc/testsuite/
PR target/80210
* gcc.target/powerpc/pr80210-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80210-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82408] cross-compiling for arm64 problems

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-10-02
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I have no problems doing cross compilers to aarch64-linux-gnu or aarch64-elf
with a combined build.

Can you describe your configure options/build env?

[Bug tree-optimization/82381] [8 Regression] internal compiler error: qsort checking failed

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #42286|0   |1
is obsolete||

--- Comment #6 from Jakub Jelinek  ---
Created attachment 42290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42290=edit
gcc8-pr82381.patch

Actually better like this.  The case when one SSA_NAME is (D) and the other is
not still could result in transitivity problems.

[Bug target/82408] New: cross-compiling for arm64 problems

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

Bug ID: 82408
Summary: cross-compiling for arm64 problems
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: peter.bohning at gmx dot com
Target Milestone: ---

Hi,
I'm trying to compile gcc-7.2.0 for arm64, mostly for libstdc++ being
required by libcrypt being required by glib. Probably I'm just doing something
wrong, but nevertheless, I feel this should be far easier and cleaner.

I do not want a compiler on the target system, I cannot chroot or reboot.
It seems to me I should be able to install to whatever sysroot I choose.

I am using linaro gcc 6.3.1-20017.05-x84_64_aarch64-linux-gnu toolchain.

The first issue is no support "mode (HF)" in half.h... I changed this to be
a simple float? soft-fp/half.h ... I tried removing the soft-fp targets from
the target files for arm under the assumption that if there was a hard float,
the soft-fp was simply unnecessary. But the targets didn't seem to affect the
usage of soft-fp so eventually I just changed that mode line in half.h to
float.

Second issue, __builtin_addressof was not declared in scope, so I replaced
it with: { return
reinterpret_cast<_Tp*>(_cast(reinterpret_cast(__r))); } This is in bits/move.h in libstdc++

Third issue, std/type_traits has all these "inline" definitions and they
wouldn't compile, so I removed all the "inline" qualifiers.

This recent issue though has me a bit tired and stumped, and I worry that it
was the type_traits inline removal somehow causing this problem. To start
with, there are duplicate definitions of the "new, new[], delete, delete[]
operators, and then there's this strange "expected declaration before } token"
error on include/ccomplex... I tried to find out what it was from, it might be
from sstream? I'm not sure. The error messages are just really unhelpful and
it's hard for me to imagine that gcc-7.2.0 has a missing bracket somewhere, so
I assume it's a combination of defines that aren't working but... I'm stumped
as to what to do.

Hopefully someone can help me out with this and then maybe it would be some
bug for some arm64/toolchain combination.

Thanks
Peter

PS: I also removed the "selftest" target which seemed like cross compiling
should have disabled?

[Bug middle-end/82407] [8 Regression][meta-bug] qsort_chk fallout tracking

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||meta-bug
  Component|other   |middle-end
   Target Milestone|--- |8.0

[Bug rtl-optimization/82396] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

2017-10-02 Thread egallager at gcc dot gnu.org

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Eric Gallager  ---
(In reply to Wilco from comment #2)
> I've got a simple patch that fixes the AArch64 bootstrap failure. This
> should fix ARM as well.

Remember when adding yourself as an assignee to change the status to ASSIGNED
too.

[Bug testsuite/82390] gcc.dg/torture tests run with same optimization level

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #42279|0   |1
is obsolete||

--- Comment #4 from Tom de Vries  ---
Created attachment 42289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42289=edit
v2 Patch disallowing dg-options for dg-torture.exp

[Bug target/82386] [8 Regression] internal compiler error: Segmentation fault on 32-bit powerpc BE targets

2017-10-02 Thread segher at gcc dot gnu.org

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

--- Comment #4 from Segher Boessenkool  ---
I like that last patch.  Pre-approved if it works :-)

Thanks!

[Bug ada/82384] [8 Regression] s-taprop.adb failed to compile for x32

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #42277|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #9 from Eric Botcazou  ---
Created attachment 42288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42288=edit
Better fix

Let's use this one instead to avoid future problems.

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

2017-10-02 Thread law at redhat dot com

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

--- Comment #8 from Jeffrey A. Law  ---
Understood on your hardware limitations.

You could certainly do bisection work on the compile farm.

Again, thanks for your work on cleaning up some of this old stuff.

[Bug tree-optimization/82387] [8 Regression] wrong code at -O1 and -Os on x86_64-linux-gnu in 64-bit mode

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct  2 15:44:10 2017
New Revision: 253356

URL: https://gcc.gnu.org/viewcvs?rev=253356=gcc=rev
Log:
PR tree-optimization/82387
PR tree-optimization/82388
PR tree-optimization/82389
* tree-ssa-dse.c (dse_classify_store): Test byte_tracking_enabled
instead of live_bytes non-NULL.

* gcc.c-torture/compile/pr82389.c: New test.
* gcc.c-torture/execute/pr82387.c: New test.
* gcc.c-torture/execute/pr82388.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82389.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr82387.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr82388.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug tree-optimization/82389] [8 Regression] ICE on valid code on x86_64-linux-gnu: Segmentation fault

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct  2 15:44:10 2017
New Revision: 253356

URL: https://gcc.gnu.org/viewcvs?rev=253356=gcc=rev
Log:
PR tree-optimization/82387
PR tree-optimization/82388
PR tree-optimization/82389
* tree-ssa-dse.c (dse_classify_store): Test byte_tracking_enabled
instead of live_bytes non-NULL.

* gcc.c-torture/compile/pr82389.c: New test.
* gcc.c-torture/execute/pr82387.c: New test.
* gcc.c-torture/execute/pr82388.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82389.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr82387.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr82388.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug tree-optimization/82388] [8 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 32-bit mode

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct  2 15:44:10 2017
New Revision: 253356

URL: https://gcc.gnu.org/viewcvs?rev=253356=gcc=rev
Log:
PR tree-optimization/82387
PR tree-optimization/82388
PR tree-optimization/82389
* tree-ssa-dse.c (dse_classify_store): Test byte_tracking_enabled
instead of live_bytes non-NULL.

* gcc.c-torture/compile/pr82389.c: New test.
* gcc.c-torture/execute/pr82387.c: New test.
* gcc.c-torture/execute/pr82388.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82389.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr82387.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr82388.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug testsuite/82390] gcc.dg/torture tests run with same optimization level

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

--- Comment #3 from Tom de Vries  ---
Created attachment 42287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42287=edit
tentative patch

[Bug other/82407] New: [8 Regression][meta-bug] qsort_chk fallout tracking

2017-10-02 Thread amonakov at gcc dot gnu.org

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

Bug ID: 82407
   Summary: [8 Regression][meta-bug] qsort_chk fallout tracking
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
Depends on: 82381, 82395, 82396, 82397, 82398, 82401
  Target Milestone: ---

Checking qsort comparator validity (transitivity and anti-commutativity
properties) reveals some inconsistent comparators. This meta-bug depends on
bugs filed for individual issues.

This is not strictly a gcc-8 regression, issues could have been present for a
long time, they just started causing a non-release-checking ICE.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82381
[Bug 82381] [8 Regression] internal compiler error: qsort checking failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82395
[Bug 82395] [8 Regression] qsort comparator non-negative on sorted output: 1 in
color_allocnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396
[Bug 82396] qsort comparator non-negative on sorted output: 4 in
ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397
[Bug 82397] qsort comparator non-negative on sorted output: 1 in
vect_analyze_data_ref_accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82398
[Bug 82398] error: qsort comparator non-negative on sorted output: 2 in
fill_vec_av_set at gcc/sel-sched.c:3725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82401
[Bug 82401] error: qsort comparator non-negative on sorted output: 1 in
insert_late_enum_def_bindings on an invalid code

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2017-10-02 Thread bunk at stusta dot de

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

Adrian Bunk  changed:

   What|Removed |Added

Summary|[7 Regression] Enormous |[7 Regression] Enormous
   |memory usage when building  |memory usage when building
   |on 32bit i386 with >= -O1   |for 32bit i386 with >= -O1

--- Comment #2 from Adrian Bunk  ---
(In reply to Richard Biener from comment #1)
> Can you provide output of the compile command with -v appended so we can see
> the different default flags passed for both the 32bit compile and the 64bit
> -m32 compile?

Thanks for asking, looking at the output I realized that I made the stupid
mistake of running gcc 6 in the 64bit -m32 compile.

The 64bit -m32 compile succeeds with gcc-7, but it actually has 5.5 GB memory
usage.

[Bug tree-optimization/82381] [8 Regression] internal compiler error: qsort checking failed

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 42286
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42286=edit
gcc8-pr82381.patch

Something like this.

[Bug tree-optimization/82397] qsort comparator non-negative on sorted output: 1 in vect_analyze_data_ref_accesses

2017-10-02 Thread amonakov at gcc dot gnu.org

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
This is because operand_equal_p is "smarter" than data_ref_compare_tree. We
have something like

A: (long)_1 + (_2 + _3)
B: (_2 + _4) + (long)_1
C: (_2 + _3) + (long)_1

with A == C != B according to operand_equal_p (and A < B < C according to
data_ref_compare_tree), making comparison steps like this non-transitive:

  if (!operand_equal_p (DR_BASE_ADDRESS (dra), DR_BASE_ADDRESS (drb), 0))
{
  cmp = data_ref_compare_tree (DR_BASE_ADDRESS (dra),
   DR_BASE_ADDRESS (drb));


Perhaps additive chains in compared operands should be canonicalized first so
that if two items are equal according to operand_equal_p they're also
guaranteed to be equal according to data_ref_compare_tree?

[Bug c++/82406] [7 Regression] Rejects a valid snippet

2017-10-02 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.4.0, 8.0
Version|unknown |7.2.1
 Ever confirmed|0   |1
  Known to fail||7.2.1

[Bug tree-optimization/82381] [8 Regression] internal compiler error: qsort checking failed

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

--- Comment #4 from Jakub Jelinek  ---
Richard, this is something you've suggested in:
http://gcc.gnu.org/ml/gcc-patches/2016-05/msg01871.html
To answer my question from:
http://gcc.gnu.org/ml/gcc-patches/2016-05/msg01873.html
the bb_rank can be the same for different bbs, if we have more than 65536 basic
blocks on 32-bit hosts.

So, I think we should go for reversion of msg01871.html and instead apply the
other patch.

[Bug target/81357] Extra mov for zero extend of add

2017-10-02 Thread wilco at gcc dot gnu.org

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

--- Comment #11 from Wilco  ---
(In reply to Qing Zhao from comment #10)
> the following is my conclusion on this bug based on previous discussion and
> study, for this testing case:
> 
>   1. due to the fact that  "mov" and "uxtw" are the same instruction, the
> assembly generated by -O1 and -O2 are exactly the same except 
>  A. the order of the instructions (this is due to the instruction
> scheduling applied in -O2). 
>  B. the registers used in difference instructions. 
> 
>   2. I agree with Wilco's comments in comment 7:
> "The compiler believes there are 2 distinct values so it uses 2 registers
> irrespectively of the order"
> 
> i.e, for the testing case:
> 
>  1 unsigned long long d;
>  2 unsigned int test1(unsigned int fParm)
>  3 {
>  4   d = fParm + 1;
>  5   return fParm + 1;
>  6 }
> 
> at line 4 and 5,  the result of fparm + 1 has two different usages:
>   * one is at line 4,  convert to unsigned long long first,  and then 
> assign
> to the global d;
>   * the other is at line 5, directly return as the return result of the
> routine. 
> 
> the compiler has to use 2 different registers for these two different
> values. 
> 
> So, I think that the compiler does NOT do anything wrong for this testing
> case.
> the additional "mov" or "uxtw" instruction that is claimed in comment 1
> actually is necessary and should NOT be deleted. 
> 
> I think that this bug could be closed as not a bug.

Well it is not wrong, just non-optimal. It is possible to use a single register
here but it means teaching GCC that these values are identical, which is
non-trivial as it likely affects various places in the mid-end (this issue is
target-independent).

[Bug translation/80188] calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

2017-10-02 Thread xerofoify at gmail dot com

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

nik  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #2 from nik  ---
I am working on this but the tester was breaking for me.

[Bug c++/82406] [7 Regression] Rejects a valid snippet

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-10-2
   Target Milestone|--- |7.3

[Bug c++/82406] New: [7 Regression] Rejects a valid snippet

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

Bug ID: 82406
   Summary: [7 Regression] Rejects a valid snippet
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Following code snippet (reduced from Chromium) is rejected with GCC 7.x:

$ cat error.ii
class a
{
public:
  template  void operator() (b &&);
};
void c () throw () __attribute__ ((__nonnull__));
void
d ()
{
  a e;
  e (c);
}

$ g++-7 -std=c++17 -c error.ii
error.ii: In function ‘void d()’:
error.ii:11:7: error: no match for call to ‘(a) (void (&)() noexcept)’
   e (c);
   ^
error.ii:4:30: note: candidate: void a::operator()(b&&) [with b = void (&)()
noexcept]
   template  void operator() (b &&);
  ^~~~
error.ii:4:30: note:   no known conversion for argument 1 from ‘void()
noexcept’ to ‘void (&)() noexcept’

It's accepted on trunk since r251911 and started to be rejected with r241944.

[Bug rtl-optimization/82396] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

2017-10-02 Thread wilco at gcc dot gnu.org

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

--- Comment #2 from Wilco  ---
I've got a simple patch that fixes the AArch64 bootstrap failure. This should
fix ARM as well.

[Bug rtl-optimization/82396] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

2017-10-02 Thread sch...@linux-m68k.org

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

Andreas Schwab <sch...@linux-m68k.org> changed:

   What|Removed |Added

   Keywords||build
 Target|arm-linux-gnueabi-gcc   |arm-*-*, aarch64-*-*
   Host|x86_64-pc-linux-gnu |
   Target Milestone|--- |8.0

--- Comment #1 from Andreas Schwab <sch...@linux-m68k.org> ---
This also fails on aarch64, during boostrap:

In file included from
/opt/gcc/gcc-20171002/Build/aarch64-suse-linux/libstdc++-v3/include/deque:66:0,
 from
/opt/gcc/gcc-20171002/Build/aarch64-suse-linux/libstdc++-v3/include/stack:60,
 from ../../../../../libstdc++-v3/src/filesystem/ops.cc:32:
/opt/gcc/gcc-20171002/Build/aarch64-suse-linux/libstdc++-v3/include/bits/deque.tcc:
In member function 'void std::deque<_Tp,
_Alloc>::_M_range_insert_aux(std::deque<_Tp, _Alloc>::iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = std::experimental::filesystem::v1::__cxx11::path::iterator;
_Tp = std::experimental::filesystem::v1::__cxx11::path; _Alloc =
std::allocator]':
/opt/gcc/gcc-20171002/Build/aarch64-suse-linux/libstdc++-v3/include/bits/deque.tcc:626:7:
error: qsort comparator non-negative on sorted output: 8
   }
   ^
during RTL pass: sched2
/opt/gcc/gcc-20171002/Build/aarch64-suse-linux/libstdc++-v3/include/bits/deque.tcc:626:7:
internal compiler error: qsort checking failed
0x5c2cf3 qsort_chk_error
../../gcc/vec.c:222
0x15242f3 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
../../gcc/vec.c:274
0x1433717 ready_sort_real
../../gcc/haifa-sched.c:3087
0x143af53 schedule_block(basic_block_def**, void*)
../../gcc/haifa-sched.c:6749
0xd84a5b schedule_region
../../gcc/sched-rgn.c:3174
0xd84a5b schedule_insns()
../../gcc/sched-rgn.c:3513
0xd84f03 schedule_insns()
../../gcc/sched-rgn.c:3498
0xd84f03 rest_of_handle_sched2
../../gcc/sched-rgn.c:3737
0xd84f03 execute
../../gcc/sched-rgn.c:3873

[Bug target/81357] Extra mov for zero extend of add

2017-10-02 Thread qing.zhao at oracle dot com

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

--- Comment #10 from Qing Zhao  ---
the following is my conclusion on this bug based on previous discussion and
study, for this testing case:

  1. due to the fact that  "mov" and "uxtw" are the same instruction, the
assembly generated by -O1 and -O2 are exactly the same except 
 A. the order of the instructions (this is due to the instruction
scheduling applied in -O2). 
 B. the registers used in difference instructions. 

  2. I agree with Wilco's comments in comment 7:
"The compiler believes there are 2 distinct values so it uses 2 registers
irrespectively of the order"

i.e, for the testing case:

 1 unsigned long long d;
 2 unsigned int test1(unsigned int fParm)
 3 {
 4   d = fParm + 1;
 5   return fParm + 1;
 6 }

at line 4 and 5,  the result of fparm + 1 has two different usages:
* one is at line 4,  convert to unsigned long long first,  and then
assign to the global d;
* the other is at line 5, directly return as the return result of the
routine. 

the compiler has to use 2 different registers for these two different values. 

So, I think that the compiler does NOT do anything wrong for this testing case.
the additional "mov" or "uxtw" instruction that is claimed in comment 1
actually is necessary and should NOT be deleted. 

I think that this bug could be closed as not a bug.

[Bug target/82386] [8 Regression] internal compiler error: Segmentation fault on 32-bit powerpc BE targets

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 42285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42285=edit
gcc8-pr82386.patch

This patch implements the latter option.

[Bug rtl-optimization/82396] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

2017-10-02 Thread wilco at gcc dot gnu.org

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-02
 CC||wilco at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/82405] New: Function not inlined for switch and suboptimal assembly is generated

2017-10-02 Thread antoshkka at gmail dot com

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

Bug ID: 82405
   Summary: Function not inlined for switch and suboptimal
assembly is generated
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following code 

enum class eShape { eSquare, eCircle, eShpere, eTetraeder };

static inline double eval_square(double r) { return 4 * r*r; }
static inline double eval_circle(double r) { return 3.1415 * r * r; }
static inline double eval_sphere(double r) { return 4 * 3.1415 * r * r; }
static inline double eval_tetraeder(double r) { return 24 * 1.73205 * r*r; }

double test_switch_native(eShape shape, double r) {
switch(shape) {
case eShape::eSquare:return eval_square(r);
case eShape::eCircle:return eval_circle(r);
case eShape::eShpere:return eval_sphere(r);
case eShape::eTetraeder: return eval_tetraeder(r);
}
}

Produces very long suboptimal assembly output with -O2 and -O3.

Clang inlines the functions and merges the common `r*r` part:

test_switch_native(eShape, double): # @test_switch_native(eShape,
double)
movsxd  rax, edi
movsd   xmm1, qword ptr [8*rax +
.Lswitch.table._Z18test_switch_native6eShaped] # xmm1 = mem[0],zero
mulsd   xmm1, xmm0
mulsd   xmm0, xmm1
ret
.Lswitch.table._Z18test_switch_native6eShaped:
.quad   4616189618054758400 # double 4
.quad   4614256447914709615 # double 3.14150002
.quad   4623263647169450607 # double 12.5660001
.quad   4631047162110439693 # double 41.5692002

[Bug middle-end/82404] Unnecessary instructions in switch table

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

--- Comment #2 from Andrew Pinski  ---
Oh this has to be c++ because of enum class.  


So gcc just does not use the undefinedness here.

[Bug middle-end/82404] Unnecessary instructions in switch table

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #1 from Andrew Pinski  ---
Is this c or c++ code?  The rules for enum are different between c and c++.

[Bug tree-optimization/82363] [8 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2017-10-02 Thread jamborm at gcc dot gnu.org

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

--- Comment #3 from Martin Jambor  ---
I'm testing the following fix:

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index f5675edc7f1..bac593951e7 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2691,7 +2691,7 @@ propagate_subaccesses_across_link (struct access *lacc,
struct access *racc)
}
  else
{
- if (rchild->grp_write && !lacc->grp_write)
+ if (!lacc->grp_write)
{
  ret = true;
  subtree_mark_written_and_enqueue (lacc);

[Bug target/82386] [8 Regression] internal compiler error: Segmentation fault on 32-bit powerpc BE targets

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

--- Comment #2 from Jakub Jelinek  ---
So one option is to defer the splitting after we've processed the whole
this_basic_block, like:
--- combine.c.jj2017-09-15 17:53:28.0 +0200
+++ combine.c   2017-10-02 15:43:53.102116326 +0200
@@ -1498,6 +1498,36 @@ combine_instructions (rtx_insn *f, unsig
 retry:
  ;
}
+  if ((new_direct_jump_p & 2) != 0)
+   {
+ /* Some conditional traps were turned into unconditional ones.
+Split basic block after them.  */
+ new_direct_jump_p = 1;
+ for (insn = BB_HEAD (this_basic_block);
+  insn != NEXT_INSN (BB_END (this_basic_block));
+  insn = next)
+   {
+ next = NEXT_INSN (insn);
+ if (NONDEBUG_INSN_P (insn)
+ && GET_CODE (PATTERN (insn)) == TRAP_IF
+ && XEXP (PATTERN (insn), 0) == const1_rtx)
+   {
+ if (insn == BB_END (this_basic_block)
+ && EDGE_COUNT (this_basic_block->succs) == 0)
+   {
+ emit_barrier_after_bb (this_basic_block);
+ break;
+   }
+ basic_block bb = BLOCK_FOR_INSN (insn);
+ gcc_assert (bb == this_basic_block);
+ edge e = split_block (bb, insn);
+ this_basic_block = e->dest;
+ remove_edge (e);
+ emit_barrier_after_bb (bb);
+ next = BB_HEAD (this_basic_block);
+   }
+   }
+   }
 }

   default_rtl_profile ();
@@ -4659,7 +4689,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
  has been created.  Adjust the CFG accordingly.  */
   if (returnjump_p (i3) || any_uncondjump_p (i3))
 {
-  *new_direct_jump_p = 1;
+  *new_direct_jump_p |= 1;
   mark_jump_label (PATTERN (i3), i3, 0);
   update_cfg_for_uncondjump (i3);
 }
@@ -4668,7 +4698,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   && (returnjump_p (undobuf.other_insn)
  || any_uncondjump_p (undobuf.other_insn)))
 {
-  *new_direct_jump_p = 1;
+  *new_direct_jump_p |= 1;
   update_cfg_for_uncondjump (undobuf.other_insn);
 }

@@ -4676,10 +4706,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   && XEXP (PATTERN (i3), 0) == const1_rtx)
 {
   basic_block bb = BLOCK_FOR_INSN (i3);
-  gcc_assert (bb);
-  remove_edge (split_block (bb, i3));
-  emit_barrier_after_bb (bb);
-  *new_direct_jump_p = 1;
+  gcc_assert (bb && this_basic_block == bb);
+  *new_direct_jump_p |= 2;
 }

   if (undobuf.other_insn
@@ -4687,10 +4715,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   && XEXP (PATTERN (undobuf.other_insn), 0) == const1_rtx)
 {
   basic_block bb = BLOCK_FOR_INSN (undobuf.other_insn);
-  gcc_assert (bb);
-  remove_edge (split_block (bb, undobuf.other_insn));
-  emit_barrier_after_bb (bb);
-  *new_direct_jump_p = 1;
+  gcc_assert (bb && this_basic_block == bb);
+  *new_direct_jump_p |= 2;
 }

   /* A noop might also need cleaning up of CFG, if it comes from the
@@ -4700,7 +4726,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   && SET_SRC (newpat) == pc_rtx
   && SET_DEST (newpat) == pc_rtx)
 {
-  *new_direct_jump_p = 1;
+  *new_direct_jump_p |= 1;
   update_cfg_for_uncondjump (i3);
 }

@@ -4710,7 +4736,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   && SET_SRC (PATTERN (undobuf.other_insn)) == pc_rtx
   && SET_DEST (PATTERN (undobuf.other_insn)) == pc_rtx)
 {
-  *new_direct_jump_p = 1;
+  *new_direct_jump_p |= 1;
   update_cfg_for_uncondjump (undobuf.other_insn);
 }

Another option I'm going to try next is ignore any try_combine in basic blocks
without predecessors, those are necessarily dead and going to be purged
afterwards, so I fail to see why we should be wasting time to combine anything
in there.

[Bug fortran/82375] PDT components in PDT declarations fail to compile

2017-10-02 Thread pault at gcc dot gnu.org

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

--- Comment #4 from Paul Thomas  ---
Created attachment 42284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42284=edit
Provisional patch for the PR

I need to do a bit more to complete this fix in order that allocatable
components are treated correctly.

It is regtesting right now.

Paul

[Bug target/82404] New: Unnecessary instructions in switch table

2017-10-02 Thread antoshkka at gmail dot com

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

Bug ID: 82404
   Summary: Unnecessary instructions in switch table
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following code

enum class eShape { eSquare, eCircle, eShpere, eTetraeder };

double test_switch_native(eShape shape, double r) {
switch(shape) {
case eShape::eSquare:return 17;
case eShape::eCircle:return 16;
case eShape::eShpere:return 21;
case eShape::eTetraeder: return 0;
}
}

with flags -O2 and -O3 produces assembly:

test_switch_native(eShape, double):
  cmp edi, 3   <== do not need this
  ja .L2   <== do not need this
  mov edi, edi <== do not need this
  movsd xmm0, QWORD PTR CSWTCH.0[0+rdi*8]
  ret
.L2:
  rep ret  <== do not need this
CSWTCH.0:
  .long 0
  .long 1076953088
  .long 0
  .long 1076887552
  .long 0
  .long 1077215232
  .long 0
  .long 0


Clang produces much sorter assembly:

test_switch_native(eShape, double): # @test_switch_native(eShape,
double)
movsxd  rax, edi
movsd   xmm0, qword ptr [8*rax +
.Lswitch.table._Z18test_switch_native6eShaped] # xmm0 = mem[0],zero
ret
.Lswitch.table._Z18test_switch_native6eShaped:
.quad   4625478292286210048 # double 17
.quad   4625196817309499392 # double 16
.quad   4626604192193052672 # double 21
.quad   0   # double 0

[Bug rtl-optimization/82398] error: qsort comparator non-negative on sorted output: 2 in fill_vec_av_set at gcc/sel-sched.c:3725

2017-10-02 Thread amonakov at gcc dot gnu.org

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
This might be a typo in treatment of EXPR_USEFULNESS in comparator, adding
Andrey.

Tentative patch:
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 87a483a231e..88d8c50b508 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -3369,6 +3369,8 @@ sel_rank_for_schedule (const void *x, const void *y)
   if (VINSN_UNIQUE_P (tmp_vinsn) && VINSN_UNIQUE_P (tmp2_vinsn))
 return SCHED_GROUP_P (tmp2_insn) ? 1 : -1;

+  gcc_checking_assert (VINSN_UNIQUE_P (tmp_vinsn)
+   || VINSN_UNIQUE_P (tmp2_vinsn));
   /* Now uniqueness means SCHED_GROUP_P is set, because schedule groups
  cannot be cloned.  */
   if (VINSN_UNIQUE_P (tmp2_vinsn))
@@ -3397,7 +3399,7 @@ sel_rank_for_schedule (const void *x, const void *y)
 return 1;

   /* Prefer an expr with greater priority.  */
-  if (EXPR_USEFULNESS (tmp) != 0 && EXPR_USEFULNESS (tmp2) != 0)
+  if (EXPR_USEFULNESS (tmp) != 0 || EXPR_USEFULNESS (tmp2) != 0)
 {
   int p2 = EXPR_PRIORITY (tmp2) + EXPR_PRIORITY_ADJ (tmp2),
   p1 = EXPR_PRIORITY (tmp) + EXPR_PRIORITY_ADJ (tmp);

[Bug tree-optimization/82402] [5/6/7/8 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set

2017-10-02 Thread edlinger at gcc dot gnu.org

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

--- Comment #3 from Bernd Edlinger  ---
The leaf attribute seems to make a difference,
before my patch the compiler assumed returns_twice + leaf,
but that may be unsafe for free standing environment.
the crash goes away if the header file adds leaf attribute.

I asked glibc-people to add that to their header file,
but nothing happened so far.

[Bug tree-optimization/82402] [5/6/7/8 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set

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

--- Comment #2 from Martin Liška  ---
(In reply to Bernd Edlinger from comment #1)
> Martin, try this modified test case:
> 
> cat ice.c
> typedef int jmp_buf[1];
> 
> extern exit(int) __attribute__((__noreturn__));
> extern int setjmpx(jmp_buf) __attribute__((__returns_twice__));
> 
> jmp_buf jbAnagram;
> int a[6];
> int d;
> int b () { exit (1); }
> int c () { b (); }
> int e ()
> {
>   int f = 0;
>   for (; f < 6; f++)
> a[f] = d;
>   c ();
>   setjmpx (jbAnagram);
> }

Thanks, fails with GCC 4.9.0+.

[Bug target/82386] [8 Regression] internal compiler error: Segmentation fault on 32-bit powerpc BE targets

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
The problem is that try_combine has two spots where it calls split_block:
  remove_edge (split_block (bb, i3));
and
  remove_edge (split_block (bb, undobuf.other_insn));
When LOG_LINKS are created, they point only within the same basic block, so
without those two calls, combine_instruction calls to try_combine should have
all insns belonging to the same basic block - this_basic_block.
But when the bb is split, we reach end of that bb earlier, then start
processing perhaps the new basic block created from there and through LOG_LINKS
reach back the old basic block, so this_basic_block doesn't necessarily mean
the bb of all the instructions that are being combined anymore.
this_basic_block is used in multiple spots, in some (e.g. calls to
propagate_for_debug) we use its BB_END, in other cases (e.g. in
distribute_notes) we use its BB_HEAD.
Makes me wonder if it wouldn't be better to defer the splitting until later,
then we'd restore the invariant that this_basic_block is the bb of i[3210].

[Bug tree-optimization/82402] [5/6/7/8 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set

2017-10-02 Thread edlinger at gcc dot gnu.org

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

--- Comment #1 from Bernd Edlinger  ---
Martin, try this modified test case:

cat ice.c
typedef int jmp_buf[1];

extern exit(int) __attribute__((__noreturn__));
extern int setjmpx(jmp_buf) __attribute__((__returns_twice__));

jmp_buf jbAnagram;
int a[6];
int d;
int b () { exit (1); }
int c () { b (); }
int e ()
{
  int f = 0;
  for (; f < 6; f++)
a[f] = d;
  c ();
  setjmpx (jbAnagram);
}

[Bug tree-optimization/82363] [8 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2017-10-02 Thread jamborm at gcc dot gnu.org

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
For some reasons the contains_data (well, actually grp_write) SRA flag is not
copied over from q.k.h.c to p.k.h.c.  Mine.

[Bug c++/71386] Wrong code on c++14 (GCC trunk)

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #10 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/54367] [meta-bug] lambda expressions

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

Bug 71386 Summary: Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386

   What|Removed |Added

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

[Bug c++/54367] [meta-bug] lambda expressions

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

Bug 79180 Summary: Nested lambda-capture causes segfault for parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180

   What|Removed |Added

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

[Bug c++/79180] Nested lambda-capture causes segfault for parameter pack

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #6 from Paolo Carlini  ---
Fixed in trunk, I added testcases.

[Bug c++/82394] Pointer imposes an optimization barrier

2017-10-02 Thread antoshkka at gmail dot com

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

--- Comment #2 from Antony Polukhin  ---
Used -O2 flag

[Bug c++/71386] Wrong code on c++14 (GCC trunk)

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct  2 12:40:26 2017
New Revision: 253350

URL: https://gcc.gnu.org/viewcvs?rev=253350=gcc=rev
Log:
2017-10-02  Paolo Carlini  

PR c++/79180
* g++.dg/cpp0x/lambda/lambda-nested8.C: New.
* g++.dg/torture/pr79180.C: Likewise.

PR c++/71386
* g++.dg/cpp1y/lambda-generic-nested1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested8.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nested1.C
trunk/gcc/testsuite/g++.dg/torture/pr79180.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/79180] Nested lambda-capture causes segfault for parameter pack

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct  2 12:40:26 2017
New Revision: 253350

URL: https://gcc.gnu.org/viewcvs?rev=253350=gcc=rev
Log:
2017-10-02  Paolo Carlini  

PR c++/79180
* g++.dg/cpp0x/lambda/lambda-nested8.C: New.
* g++.dg/torture/pr79180.C: Likewise.

PR c++/71386
* g++.dg/cpp1y/lambda-generic-nested1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested8.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nested1.C
trunk/gcc/testsuite/g++.dg/torture/pr79180.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/82403] New: [openacc, nvptx] Optimize binary shuffle tree

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

Bug ID: 82403
   Summary: [openacc, nvptx] Optimize binary shuffle tree
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In nvptx_goacc_reduction_fini we find the following todo:
...
  if (level == GOMP_DIM_VECTOR)
{
  /* Emit binary shuffle tree.  TODO. Emit this as an actual loop,  
 but that requires a method of emitting a unified jump at the   
 gimple level.  */
...

A fix for this was committed to the gomp4 branch in august 2016 (submitted
here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02147.html ), but it's not
yet present on trunk.

[Bug tree-optimization/82402] New: [5/6/7/8 Regression] error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set

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

Bug ID: 82402
   Summary: [5/6/7/8 Regression] error:
SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
   Product: gcc
   Version: unknown
   URL: https://raw.githubusercontent.com/byronh/school-simple
scalar/master/tests/src/anagram.c
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: edlinger at gcc dot gnu.org
  Target Milestone: ---

Starting with GCC 4.9, we ICE on anagram.c:

$ gcc anagram.c -O3 -c --param max-inline-insns-auto=1352250387
anagram.c: In function ‘BuildMask’:
anagram.c:315:5: warning: implicit declaration of function ‘bzero’
[-Wimplicit-function-declaration]
 bzero(alPhrase, sizeof(Letter)*ALPHABET);
 ^
anagram.c:315:5: warning: incompatible implicit declaration of built-in
function ‘bzero’
anagram.c: In function ‘BuildWord’:
anagram.c:406:5: warning: incompatible implicit declaration of built-in
function ‘bzero’
 bzero(cchFrequency, sizeof(unsigned char)*ALPHABET);
 ^
anagram.c: In function ‘GetPhrase’:
anagram.c:603:9: warning: implicit declaration of function ‘gets’; did you mean
‘fgets’? [-Wimplicit-function-declaration]
 if (gets(pch) == NULL) {
 ^~~~
 fgets
anagram.c:603:19: warning: comparison between pointer and integer
 if (gets(pch) == NULL) {
   ^~
anagram.c: In function ‘main’:
anagram.c:623:20: warning: implicit declaration of function ‘isatty’
[-Wimplicit-function-declaration]
 fInteractive = isatty(1);
^~
anagram.c:615:11: error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
 int Cdecl main(int cpchArgc, char **ppchArgv) {
   ^~~~
for SSA_NAME: .MEM_184 in statement:
.MEM_17(ab) = PHI <.MEM_20(D)(ab)(3), .MEM_24(ab)(6), .MEM_27(ab)(7),
.MEM_36(ab)(10), .MEM_34(ab)(12), .MEM_218(ab)(27), .MEM_204(ab)(35),
.MEM_33(ab)(67), .MEM_38(ab)(68), .MEM_40(ab)(72), .MEM_197(ab)(77),
.MEM_207(ab)(57), .MEM_184(54), .MEM_195(ab)(76), .MEM_196(ab)(75)>
PHI argument
.MEM_184
for PHI node
.MEM_17(ab) = PHI <.MEM_20(D)(ab)(3), .MEM_24(ab)(6), .MEM_27(ab)(7),
.MEM_36(ab)(10), .MEM_34(ab)(12), .MEM_218(ab)(27), .MEM_204(ab)(35),
.MEM_33(ab)(67), .MEM_38(ab)(68), .MEM_40(ab)(72), .MEM_197(ab)(77),
.MEM_207(ab)(57), .MEM_184(54), .MEM_195(ab)(76), .MEM_196(ab)(75)>
during GIMPLE pass: vect
anagram.c:615:11: internal compiler error: verify_ssa failed
0xdd382b verify_ssa(bool, bool)
.././../gcc/tree-ssa.c:1188
0xabe537 execute_function_todo
.././../gcc/passes.c:1999
0xabf462 execute_todo
.././../gcc/passes.c:2046

I have a reduced test-case that started to ICE with r239092:

$ cat ice.c
#include 
#include 

jmp_buf jbAnagram;
int a[6];
int d;
int b () { exit (1); }
int c () { b (); }
int e ()
{
  int f = 0;
  for (; f < 6; f++)
a[f] = d;
  c ();
  setjmp (jbAnagram);
}

$ gcc ice.c -O3 -c --param max-inline-insns-auto=1352250387
ice.c: In function ‘e’:
ice.c:9:5: error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
 int e ()
 ^
for SSA_NAME: .MEM_12 in statement:
.MEM_4(ab) = PHI <.MEM_12(8), .MEM_6(ab)(9)>
PHI argument
.MEM_12
for PHI node
.MEM_4(ab) = PHI <.MEM_12(8), .MEM_6(ab)(9)>
during GIMPLE pass: vect
ice.c:9:5: internal compiler error: verify_ssa failed
0xdd382b verify_ssa(bool, bool)
.././../gcc/tree-ssa.c:1188
0xabe537 execute_function_todo
.././../gcc/passes.c:1999
0xabf462 execute_todo
.././../gcc/passes.c:2046

But it's probably just path of original problem.

[Bug rtl-optimization/82398] error: qsort comparator non-negative on sorted output: 2 in fill_vec_av_set at gcc/sel-sched.c:3725

2017-10-02 Thread sch...@linux-m68k.org

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

Andreas Schwab <sch...@linux-m68k.org> changed:

   What|Removed |Added

 Target|ppc64le-linux-gnu   |ppc64le-*-*, ia64-*-*
   Host|x86_64-pc-linux-gnu |

--- Comment #1 from Andreas Schwab <sch...@linux-m68k.org> ---
This is probably the same bug (on ia64):

FAIL: gcc.c-torture/execute/pr57861.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)

/usr/local/gcc/gcc-20171002/gcc/testsuite/gcc.c-torture/execute/pr57861.c:33:1:
error: qsort comparator non-negative on sorted output: 1
during RTL pass: mach
/usr/local/gcc/gcc-20171002/gcc/testsuite/gcc.c-torture/execute/pr57861.c:33:1:
internal compiler error: qsort checking failed
0x401b2d9f qsort_chk_error
../../gcc/vec.c:222
0x4209cecf qsort_chk(void*, unsigned long, unsigned long, int (*)(void
const*, void const*))
../../gcc/vec.c:274
0x41015d9f vec<_expr*, va_heap, vl_embed>::qsort(int (*)(void const*,
void const*))
../../gcc/vec.h:973
0x41015d9f vec<_expr*, va_heap, vl_ptr>::qsort(int (*)(void const*,
void const*))
../../gcc/vec.h:1735
0x41015d9f fill_vec_av_set
../../gcc/sel-sched.c:3725
0x4101be4f fill_ready_list
../../gcc/sel-sched.c:4022
0x4101be4f find_best_expr
../../gcc/sel-sched.c:4382
0x4101be4f fill_insns
../../gcc/sel-sched.c:5539
0x4101be4f schedule_on_fences
../../gcc/sel-sched.c:7356
0x4101be4f sel_sched_region_2
../../gcc/sel-sched.c:7494
0x410252cf sel_sched_region_1
../../gcc/sel-sched.c:7536
0x410252cf sel_sched_region(int)
../../gcc/sel-sched.c:7637
0x4102666f run_selective_scheduling()
../../gcc/sel-sched.c:7713
0x4190fd7f ia64_reorg
../../gcc/config/ia64/ia64.c:9854
0x40f85acf execute
../../gcc/reorg.c:3947

[Bug c++/82401] New: error: qsort comparator non-negative on sorted output: 1 in insert_late_enum_def_bindings on an invalid code

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

Bug ID: 82401
   Summary: error: qsort comparator non-negative on sorted output:
1 in insert_late_enum_def_bindings on an invalid code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

After Alexander's commit (r253295) I see:

$ cat ice.cpp
template  struct A
{
  enum E : T;
  void h ();
};
template  enum A::E : T { e1, e2 };
template <> enum A::E : long long {};
template  struct C
{
  enum class E : T;
};
C::E c3 = C::E::e6;

$ g++-7 ice.cpp
ice.cpp:12:27: error: ‘e6’ is not a member of ‘C::E’
 C::E c3 = C::E::e6;
   ^~
$ g++-trunk ice.cpp
ice.cpp:7:47: error: qsort comparator non-negative on sorted output: 1
 template <> enum A::E : long long {};
   ^
ice.cpp:7:47: internal compiler error: qsort checking failed
0x5ee434 qsort_chk_error
.././../gcc/vec.c:222
0x16207c5 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
.././../gcc/vec.c:274
0x7287ef insert_late_enum_def_bindings(tree_node*, tree_node*)
.././../gcc/cp/name-lookup.c:1727
0x6923d1 finish_enum_value_list(tree_node*)
.././../gcc/cp/decl.c:14322
0x76058c cp_parser_enum_specifier
.././../gcc/cp/parser.c:18222
0x76058c cp_parser_type_specifier
.././../gcc/cp/parser.c:16644
0x76e156 cp_parser_decl_specifier_seq
.././../gcc/cp/parser.c:13568
0x773355 cp_parser_single_declaration
.././../gcc/cp/parser.c:26972
0x774467 cp_parser_explicit_specialization
.././../gcc/cp/parser.c:16564
0x77a426 cp_parser_declaration
.././../gcc/cp/parser.c:12669
0x77a6eb cp_parser_declaration_seq_opt
.././../gcc/cp/parser.c:12599
0x77a9fa cp_parser_translation_unit
.././../gcc/cp/parser.c:4390
0x77a9fa c_parse_file()
.././../gcc/cp/parser.c:38907
0x8c0df6 c_common_parse_file()
.././../gcc/c-family/c-opts.c:1113

[Bug target/82400] [openacc, nvptx] Use ptx atomic operators for reductions

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

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> The scheme is the same for all operators, using the compare-and-swap atomic
> ptx instruction (atom.cas).
> 
> However, some of the operators are supported natively for the ptx:
> ...
> .op = { .and, .or, .xor, .cas, .exch, .add, .inc, .dec, .min, .max };
> ...
> so for f.i. addition we could use an atom.add instead.

[ As implied by the nvptx_reduction_update todo: optimize for atomic ops and
independent complex ops. ]

[Bug target/82400] New: [openacc, nvptx] Use ptx atomic operators for reductions