[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Jan 26 09:53:33 2016
New Revision: 232817

URL: https://gcc.gnu.org/viewcvs?rev=232817=gcc=rev
Log:
PR 69400: Invalid 128-bit modulus result

As described in the PR, wi::divmod_internal was sign- rather than
zero-extending a modulus result in cases where the result has fewer
HWIs than the precision and the upper bit of the upper HWI was set.

This patch tries to make things more robust by getting wi_pack
to handle the canonicalisation step itself.

Tested on x86_64-linux-gnu.  I added tests to the wide-int
plugin since that seemed more direct.

gcc/
PR tree-optimization/69400
* wide-int.cc (wi_pack): Take the precision as argument and
perform canonicalization here rather than in the callers.
Use the main loop to handle all full-width HWIs.  Add a
zero HWI if in_len isn't a full result.
(wi::divmod_internal): Update accordingly.
(wi::mul_internal): Likewise.  Simplify.

gcc/testsuite/
PR tree-optimization/69400
* gcc.dg/plugin/wide-int_plugin.c (test_wide_int_mod_trunc): New
function.
(plugin_init): Call it.
* gcc.dg/torture/pr69400.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69400.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/wide-int_plugin.c
trunk/gcc/wide-int.cc

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #3 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Tue Jan 26 10:04:46 2016
New Revision: 232818

URL: https://gcc.gnu.org/viewcvs?rev=232818=gcc=rev
Log:
[PATCH] Do not set structural equality on polynomial types

gcc/ChangeLog:

PR target/67896
* config/aarch64/aarch64-builtins.c
(aarch64_init_simd_builtin_types): Do not set structural
equality to __Poly{8,16,64,128}_t types.

gcc/testsuite/ChangeLog:

PR target/67896
* gcc.target/aarch64/simd/pr67896.C: New.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
But it is for a relatively uncommon case (-mpreferred-stack-boundary lower than
default) and furthermore, you need to have something spilled to trigger it. 
Hopefully the most commonly used regs in loops will not be spilled...

[Bug target/69442] [6 Regression] wrong code with -Og and 64bit modulo @ armv7a

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 26 11:12:03 2016
New Revision: 232819

URL: https://gcc.gnu.org/viewcvs?rev=232819=gcc=rev
Log:
PR target/69442
* combine.c (combine_instructions): For REG_EQUAL note with
SET_DEST being ZERO_EXTRACT, also temporarily set SET_DEST
to the underlying register.
* doc/rtl.texi (REG_EQUAL): Document the behavior of
REG_EQUAL/REG_EQUIV notes if SET_DEST is ZERO_EXTRACT.

* gcc.dg/pr69442.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69442.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/doc/rtl.texi
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug libstdc++/69486] New: Strange behaviour of bitset and c++11

[boris at dolgov dot name]

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

Bug ID: 69486
   Summary: Strange behaviour of bitset and c++11
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at dolgov dot name
  Target Milestone: ---

Hello!

When I try to compile the following program

#include 
std::bitset<2147483648> b;
int main() {}

cc1plus tries to eat all available memory and hangs.

Compilation command is g++ -o test test.cpp -std=c++11

When I use -std=c++98, everything works fine.

[Bug lto/69408] LD crashes with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to night_ghost from comment #4)
> I can attach script which GCC has been built, and ZIP of the project tree
> which cause crash.

Hi.

That would be beneficial!

[Bug tree-optimization/69483] [6 Regression] gcc ICE on x86_64-linux-gnu with "expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/69484] New: documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

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

Bug ID: 69484
   Summary: documentation issue: -Wtabs and -Wall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

There is an inconsistency in the documentation at
https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html.

The description of -Wall claims that it includes -Wno-tabs, while the
description of -Wtabs claims that -Wtabs is active for -Wall (and others).

One of the two must be wrong. From the behaviour of gfortran it seems that
-Wall does imply -Wtabs.

[Bug target/69442] [6 Regression] wrong code with -Og and 64bit modulo @ armv7a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Created attachment 37474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37474=edit
patch for SSA name management

This patch changes SSA name freelist management to keep the freelist sorted
and at flush_ssaname_freelist shrink num_ssa_names as much as possible.

The goal is to make used SSA names as dense as possible.

Does this patch fix the Coremark regression by chance?  (I'll note that a
proper fix would change the important coalesce cost so it is carried out
regardless of SSA name order).

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

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

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

--- Comment #25 from Rainer Emrich  ---
I'm testing rev. 232815, proposed patch applied, on x86_64-w64-mingw32 atm.
Will take some time.

[Bug tree-optimization/69483] New: gcc ICE on x86_64-linux-gnu with "expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p"

[helloqirun at gmail dot com]

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

Bug ID: 69483
   Summary: gcc ICE on x86_64-linux-gnu with "expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160125 (experimental) [trunk revision 232792] (GCC)


$ gcc-trunk abc.c
abc.c:4:13: error: storage size of 'b' isn't known
 struct str1 b;
 ^

cc1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:83
0xdd9de7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9656
0x8cbe60 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3129
0x8cbe60 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc/gcc/gimple-expr.c:83
0x8d2255 canonicalize_constructor_val(tree_node*, tree_node*)
../../gcc/gcc/gimple-fold.c:211
0x7807ca record_reference
../../gcc/gcc/cgraphbuild.c:54
0xdfcfd2 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/gcc/tree.c:11498
0xdfd4b7 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/gcc/tree.c:11575
0x781b04 record_references_in_initializer(tree_node*, bool)
../../gcc/gcc/cgraphbuild.c:404
0xe3cec7 varpool_node::analyze()
../../gcc/gcc/varpool.c:526
0x787e1a analyze_functions
../../gcc/gcc/cgraphunit.c:1129
0x788d98 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2535
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.





---
$ cat abc.c
struct str3 {
  struct str1 *a;
};
struct str1 b;
struct str3 c = {};

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Introduced by r204615 for PR 58982

[Bug ada/69476] accept size clause for 2-level discriminated record types with fixed sizes

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 CC||ebotcazou at gcc dot gnu.org
Summary|Fail to reconize types with |accept size clause for
   |an unrejected static size   |2-level discriminated
   |attribute as compile time   |record types with fixed
   |known size type |sizes
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Botcazou  ---
The measure used to evaluate the minimality of the testcase is far from being
trivial because the following testcase trounces it if a simple character count
is used:

package P is

   type Rec1 (D : Boolean) is record
  B : Boolean; 
   end record;

   type Rec2 (D : Boolean) is record
  R : Rec1 (D);
   end record;
   for Rec2'Size use 24;

end P;

p.ads:10:04: size clause not allowed for variable length type

This has always been rejected historically by GNAT.  The clause is confirming
so this ought to be accepted.

[Bug tree-optimization/69467] [6 Regression] Pattern X * C1 CMP 0 to X CMP 0 causes performance drop on 32-bit x86.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 26 12:05:22 2016
New Revision: 232821

URL: https://gcc.gnu.org/viewcvs?rev=232821=gcc=rev
Log:
2016-01-26  Richard Biener  

PR middle-end/69467
* match.pd: Guard X * CST CMP 0 pattern with single_use.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from vehre at gcc dot gnu.org ---
Patch proposed in:

https://gcc.gnu.org/ml/fortran/2016-01/msg00080.html

Awaiting approval/comments.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

--- Comment #26 from Nick Clifton  ---
Hi Roger,

> I've tried the patch (applied to 232400 as trunk seems to have other
> problems on cygwin) and the build now completes successfully.

Including libstdc++-v3 ?

> Additionally, the test case no longer crashes.

Hooray.

Now all we need is for Rainer to confirm that the patch works for mingw32 and
we are good to go.

Oh actually - Roger - could you check one more thing for me please ?  Does the
patched compiler compile the test case in PR 68601 correctly ?

Cheers
  Nick

[Bug tree-optimization/69483] [6 Regression] gcc ICE on x86_64-linux-gnu with "expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|gcc ICE on x86_64-linux-gnu |[6 Regression] gcc ICE on
   |with "expected class|x86_64-linux-gnu with
   |'type', have 'exceptional'  |"expected class 'type',
   |(error_mark) in |have 'exceptional'
   |useless_type_conversion_p"  |(error_mark) in
   ||useless_type_conversion_p"
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r232622.

[Bug tree-optimization/69400] [5 Regression] wrong code with -O and int128

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 Regression] wrong code |[5 Regression] wrong code
   |with -O and int128  |with -O and int128

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

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #13 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #5)
> Already during the expansion TARGET_STV makes quite a big difference, won't
> just disabling the stv pass cause performance regression to -mno-stv?
There is a difference on how code is expanded but we didn't observe significant
code regressions because of it so far.

> Also, I'm surprised you are checking INCOMING_STACK_BOUNDARY, I'd have
> expected
> || ix86_preferred_stack_boundary >= 128
> instead.
I check INCOMING_STACK_BOUNDARY because that's what expand_stack_alignment
checks to determine if realignment and DRAP register are needed.

> 
> I had in mind either:
> 
> --- gcc/config/i386/i386.c.jj 2016-01-25 12:10:57.0 +0100
> +++ gcc/config/i386/i386.c2016-01-25 16:54:28.662713284 +0100
> @@ -5453,6 +5453,11 @@ ix86_option_override_internal (bool main
>  opts->x_target_flags |= MASK_VZEROUPPER;
>if (!(opts_set->x_target_flags & MASK_STV))
>  opts->x_target_flags |= MASK_STV;
> +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
> + stack realignment will be extra cost the pass doesn't take into
> + account and the pass does not ensure DRAP is created either.  */
> +  if (ix86_preferred_stack_boundary < 128)
> +opts->x_target_flags &= ~MASK_STV;
>if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
>&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
>  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
> 
> (i.e. force -mno-stv for -mpreferred-boundary={2,3}), but that will likely
> disable the pass altogether for the -miamcu (but your patch in most cases
> will too), not sure if that is a big deal or not).
IAMCU doesn't have SSE, thus it's not an issue.  But here we disable STV even
if we are going to align stack anyway (e.g. have vector code).

> Another alternative is if the STV pass changes anything and creates possible
> need for aligned vector spills, create drap rtx during that pass.

I like this option, but I wonder if it's safe to do that at STV pass. 
expand_stack_alignment calls fixup_tail_calls and invalidates some notes if
DRAP is allocated.  Can it be too late to do that in STV?

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[ktkachov at gcc dot gnu.org]

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

--- Comment #13 from ktkachov at gcc dot gnu.org ---
We can look at the impact of enabling ree for arm for GCC 7 then.

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
  Known to work|4.8.2   |4.8.4
 Ever confirmed|0   |1
  Known to fail|4.9.2, 5.2.0|4.9.3, 5.3.0

[Bug fortran/69484] [5/6 Regression] documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|documentation issue: -Wtabs |[5/6 Regression]
   |and -Wall   |documentation issue: -Wtabs
   ||and -Wall

--- Comment #1 from janus at gcc dot gnu.org ---
I guess this issue is related to the change of behaviour regarding -Wtabs from
4.9 to 5.

Also, the documentation bug is a regression: The documentation is correct in
4.9, but wrong for versions 5 and 6.

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|WAITING |NEW

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #15 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #14)
> Thanks.  This is definitely an issue with the changing version #s changing
> the ordering in which particular coalescing pairs are tried.
> 
> This is most likely coming from this (and related) code in
> tree-ssa-coalesce.c:
> 
> case GIMPLE_ASSIGN:
>   {
> tree lhs = gimple_assign_lhs (stmt);
> tree rhs1 = gimple_assign_rhs1 (stmt);
> if (gimple_assign_ssa_name_copy_p (stmt)
> && gimple_can_coalesce_p (lhs, rhs1))
>   {
> v1 = SSA_NAME_VERSION (lhs);
> v2 = SSA_NAME_VERSION (rhs1);
> cost = coalesce_cost_bb (bb);
> add_coalesce (cl, v1, v2, cost);
> bitmap_set_bit (used_in_copy, v1);
> bitmap_set_bit (used_in_copy, v2);
>   }
> 
> Note how the version #s are passed into add_coalesce.
> 
> Those are then used to order the coalesce pair for hashing in
> find_coalesce_pair as well as in the qsort function compare_pairs.  They
> could easily be used elsewhere.
> 
> So while we do pull pairs out in a priority order, once the priorities are
> the same, the order selected is based on the SSA_NAME_VERSION, which, due to
> SSA_NAME recycling is effectively random.  You can see this by looking at
> the Sorted Coalesce list in the dumps.The format is
> 
> (cost) obj1 <->obj2
> 
> If you compare the dumps you'll see that we have certain coalescing
> opportunities with the same cost, but which are ordered differently because
> of the SSA_NAME_VERSION differences.
> 
> The biggest obvious downside to coalescing  being dependent on
> SSA_NAME_VERSION is that a change in how names as returned to the name
> manager can affect code generation -- essentially causing code to improve or
> degrade in a random fashion.
> 
> One approach to fixing this problem might be to recompute the
> SSA_NAME_VERSION #s just prior to coalescing.
> 
> Essentially do a domwalk or some other walk of the IL reassigning version #s
> for the LHS operand.   This won't be 100% foolproof, but would probably be
> more stable than what we're doing now.  That may be possible in the gcc-6
> timeframe, I'm not really sure right now.

I think the easier solution is to preserve the order we created the coalesce
pairs by adding a "coalesce number" to sort against of the costs are equal.
coalesce_pair has three ints so on 64bit hosts there isn't any memory
wasted if adding another one given we go via glibc malloc for allocating
them (ugh).

Of course if that produces the desired order for the benchmark is another
question ;)  (it's really random before as well)

But comment #8 also still holds (keep the free ssa name list we allocate
from sorted to pack names dense).

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #15 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #14)
> Have you tried H.J's patch?  If I understand it right, IMHO at least the
> *mov_internal changes look desirable to me after the recent changes
> where misaligned_operand matters even for pre-AVX, and the result could be
> that if the stack can't be realigned and -mpreferred-stack-boundary is low,
> worst case there will be unaligned loads/stores to the stack slots instead
> of aligned ones.

I don't like it aligns stack if we vectorize in GIMPLE (even if preferred
alignment is lower) but don't align stack if we "vectorize" in rtl.  But I
don't see how to align stack properly at STV so I'm trying H.J.'s patch now.

[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags

[wavexx at thregr dot org]

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

--- Comment #4 from wavexx at thregr dot org ---
Since I couldn't find documentation for it either, doesn't
-march=haswell by itself imply all associated ISA features?

If so, why -march=native expands to all individual features explicitly?

[Bug c++/69510] segfault in write_template_prefix while compiling C++ template code

[vapier at gcc dot gnu.org]

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

Mike Frysinger  changed:

   What|Removed |Added

  Known to work||4.7.4, 4.8.5
Version|unknown |4.9.3
   Target Milestone|--- |4.9.4
  Known to fail||4.9.3, 5.1.0, 5.2.0, 5.3.0

[Bug c++/69510] segfault in write_template_prefix while compiling C++ template code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup. Already fixed.

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

[Bug c++/67337] [4.9/5 Regression] Segmentation fault on a template class

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||vapier at gcc dot gnu.org

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 69510 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/69399] [5/6 Regression] wrong code with -O and int128

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|WAITING |NEW
   Target Milestone|--- |5.4

[Bug tree-optimization/69336] Constant value not detected

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #10 from Dominik Vogt  ---
The new test fails on s390x; what should I do about it?
(see https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01359.html )

[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Richard Henderson  ---
Further archaeology suggests that PR 66424 is related,
and had an incomplete fix applied.

The fix for PR 66424 prevents an insn being moved if
it contains a subreg of a multi-word pseudo.  But the
same problem exists if one moves a complete multi-word
pseudo if any of its subregs have ever been accessed.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Created attachment 37483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37483=edit
Proposed patch.

Attaching a proposed patch tested on x86_64-linux.  Since GCC is in stage 4
(regression fixes only) and this is no a regression it will probably have to
wait until after the 6.0 release.

[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #17 from Jeffrey A. Law  ---
Per c#16.

[Bug fortran/69484] [5/6 Regression] documentation issue: -Wtabs and -Wall

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug rtl-optimization/69482] Writing through pointers to volatile not always preserved

[wipedout at yandex dot ru]

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

--- Comment #4 from wipedout at yandex dot ru ---
Okay, suppose we have the following scenario. There's a third party library
with an encryption function like this:

void encrypt( void* data, void* key );

That function is compiled into as a static library and we cannot recompile it.
We know that the function copies the key onto the stack and fails to overwrite
it.

So we want to overwrite the stack after that function. Here's what we could do:


 void overwrite()
 {
  char array[SIZE];
  memset_s( array, SIZE );
 }

 void usefulFunction()
 {
 encrypt( something, key );
 overwrite();
 }

This would work the following way: first, `encrypt()` runs and leaves data on
the stack. Then `overwrite()` runs, allocates an array which very likely
overlaps with the area where `encrypt()` left the data and overwrites that
array.

This "array is not used" optimization heuristic equally applies to the array in
overwrite() and a later version of gcc may decide that no matter how the array
is allocated it's not used and therefore no need to overwrite it.

Yes, I know that the trick relies on undefined behavior in the first place.

[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

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

--- Comment #9 from Richard Henderson  ---
Created attachment 37484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37484=edit
proposed patch

Fixes the test case, in that it prevents the remat.

Starting overnight bootstraps for armv7hf, i686, and x86_64...

[Bug c++/69510] New: segfault in write_template_prefix while compiling C++ template code

[vapier at gcc dot gnu.org]

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

Bug ID: 69510
   Summary: segfault in write_template_prefix while compiling C++
template code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vapier at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

Created attachment 37485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37485=edit
test.ii reduced testcase

the attached test case (by Philippe Marti) crashes g++ starting with 4.9 (and
including 5.3).  4.8 and older work.


$ g++ -c test.ii -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/g++
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/python
--enable-languages=c,c++,java,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.3.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=mx32,m32,m64
--disable-altivec --disable-fixed-point --with-abi=m64 --enable-targets=all
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5) 
COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'test.o' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.ii -mtune=generic -march=x86-64 -auxbase-strip test.o
-version -fstack-protector-strong -o /tmp/ccxZdwTF.s
GNU C++ (Gentoo 5.3.0 p1.0, pie-0.6.5) version 5.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Gentoo 5.3.0 p1.0, pie-0.6.5) version 5.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 542af32c761d4d0725ea4eab192ccd39

test.ii: In instantiation of 'void Test::func(typename TClass::Type)
[with TClass = A; int TID = 1; typename TClass::Type = double]':

test.ii:2:54: internal compiler error: Segmentation fault
  public: template  class TClass> void func(typename
TClass::Type x) {};
  ^
Please submit a full bug report,
with preprocessed source if appropriate.


here's the gdb output:
$ gdb --args g++ test.ii 
Reading symbols from /usr/bin/g++...(no debugging symbols found)...done.
(gdb) set follow-fork-mode child 
(gdb) r
Starting program: /usr/bin/g++ test.ii
process 4832 is executing new program:
/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/x86_64-pc-linux-gnu-g++
[New process 4836]
process 4836 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1plus

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 4836]
write_template_prefix (node=node@entry=0x765a6be0) at
.../gcc-5.3.0/gcc/cp/mangle.c:1163
1163.../gcc-5.3.0/gcc/cp/mangle.c: No such file or directory.
(gdb) bt
#0  write_template_prefix (node=node@entry=0x765a6be0) at
.../gcc-5.3.0/gcc/cp/mangle.c:1163
#1  0x006e6f0c in write_prefix (node=0x765acb28) at
.../gcc-5.3.0/gcc/cp/mangle.c:1078
#2  0x006e7171 in write_nested_name (decl=0x765a6c78) at
.../gcc-5.3.0/gcc/cp/mangle.c:1009
#3  0x006e37c9 in write_type (type=0x765acbd0) at
.../gcc-5.3.0/gcc/cp/mangle.c:2017
#4  0x006e5c72 in write_method_parms (parm_types=0x765a3a00,
method_p=, decl=) at
.../gcc-5.3.0/gcc/cp/mangle.c:2540
#5  0x006e5d8d in write_bare_function_type (type=0x765acd20,
include_return_type_p=0x1, decl=) at
.../gcc-5.3.0/gcc/cp/mangle.c:2482
#6  0x006e8acc in mangle_decl_string (decl=decl@entry=0x765ad510)
at .../gcc-5.3.0/gcc/cp/mangle.c:3449
#7  0x006e8c37 in get_mangled_id (decl=0x765ad510) at

[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7->4.8

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #5 from Andrew Pinski  ---
Fixed so closing.

[Bug target/60818] ICE in validate_condition_mode on powerpc-e500v2-linux-gnuspe

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Target|powerpc-e500v2-linux-gnuspe |powerpc-e500v2-linux-gnuspe
   ||, powerpc-e300c3-linux-gnu
  Known to fail|4.9.0, 5.1.0, 5.2.0 |4.9.3, 5.3.0, 6.0

--- Comment #4 from Arseny Solokha  ---
The state of things is currently as follows:

1. Snippets from comment 0 and comment 1 cannot be reproduced anymore w/ gcc
5.3.0 and 6.0.0-alpha20160110.

2. Snippet from comment 3 can be further reduced to

unsigned int vz, tr, c, fr;

void
gi(void)
{
  if (vz < 1)
vz = ((fr < tr) >= (fr > tr));
}

and fails w/ 4.8.5, 4.9.3, 5.3.0 at -Os, -O2, -O3, and -Ofast.

3. The following snippet fails w/ 5.3.0 and 6.0.0-alpha20160110 at -O1, -O2,
-O3, -Ofast, and -Og:

unsigned int ou;

int
jv(void)
{
  unsigned int rg;
  return rg < ou;
}

[Bug lto/69408] LD crashes with LTO

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> Waiting for a testcase.  See https://gcc.gnu.org/bugs.html

I *think* I have seen this problem recently on x86_64 Fedora 23 when testsuite
was run with RUNTESTFLAGS="--target_board=unix/-fno-use-linker-plugin"

I'll re-run the testsuite and report here.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #19)
> (In reply to H.J. Lu from comment #17)
> > Do you have a testcase to show that you need to realign stack for STV?
> 
> Reproducer for this tracker is such test, right?

Not really.  We only ask for 128-bit aligned stack only if we have 128-bit
aligned variable on stack.  Please do

# git grep stack_alignment_needed

to see how stack alignment is tracked.

[Bug c++/69487] New: Unexpected VLA initialization of char[] from ""

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69487
   Summary: Unexpected VLA initialization of char[] from ""
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

The initialization of a VLA char array from a string literal in C++ mode is
surprising: the code appears to copy a string literal starting with the NUL
character into the dynamically-sized buffer.

This is different from the (standard C/C++) treatment of the same syntax for a
fixed-size array.

--- vla-init.cxx ---
#include 
#include 
#include 
#include 

void testfixed()
{
const int size = 6;
char buffer[size] = "";
for (int i = 0; i != size; ++i)
{
printf("Fixed: buffer[%i] = %2.2x\n", i, buffer[i] & 0xff);
}
}

int size = 6;

void testvariable()
{
char buffer[size] = "";
for (int i = 0; i != size; ++i)
{
printf("Variable: buffer[%i] = %2.2x\n", i, buffer[i] & 0xff);
}
}


int main()
{
testfixed();
testvariable();
}
--- ends ---

Sample output:

Fixed: buffer[0] = 00
Fixed: buffer[1] = 00
Fixed: buffer[2] = 00
Fixed: buffer[3] = 00
Fixed: buffer[4] = 00
Fixed: buffer[5] = 00
Variable: buffer[0] =00
Variable: buffer[1] =00
Variable: buffer[2] =00
Variable: buffer[3] =00
Variable: buffer[4] =01
Variable: buffer[5] =1b

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #16 from Bernd Schmidt  ---
Will post patch to remove -fshort-double.

[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
It looks like a patch was committed - can this be closed?

[Bug fortran/69485] oddity with -Wtabs

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to janus from comment #0)
> So, the odd thing is that only for one of these tabs I am actually told that
> it's in the include file, for all others that unfortunately does not happen.
> 
> Ideally the style of the last of these warnings should be used for the
> others as well!

To do that, this

gfc_warning_now (OPT_Wtabs,
   "Nonconforming tab character in column %d "
   "of line %d", i+1, linenum);

has to be replaced by this

gfc_warning_now (OPT_Wtabs, "Nonconforming tab character at %C");

or this

gfc_warning_now (OPT_Wtabs, "Nonconforming tab character at %L", where);

or

gfc_warning_now_at (location, OPT_Wtabs, "Nonconforming tab character at (1)");

Of course, the tricky part is how to set-up things such that one of those calls
will work.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
(In reply to H.J. Lu from comment #20)
> (In reply to Ilya Enkovich from comment #19)
> > (In reply to H.J. Lu from comment #17)
> > > Do you have a testcase to show that you need to realign stack for STV?
> > 
> > Reproducer for this tracker is such test, right?
> 
> Not really.  We only ask for 128-bit aligned stack only if we have 128-bit
> aligned variable on stack.

In another word, STV needs 128-bit aligned stack only when it generates
12-bit vector instructions.

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Does this affect other branches as well?

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

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

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

--- Comment #27 from Rainer Emrich  ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 26.01.2016 um 10:30 schrieb nickc at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
> 
> --- Comment #26 from Nick Clifton  --- Hi
> Roger,
> 
>> I've tried the patch (applied to 232400 as trunk seems to have
>> other problems on cygwin) and the build now completes
>> successfully.
> 
> Including libstdc++-v3 ?
I did a full bootstrap including all working languages for
x86_64-w64-mingw32 and a full testsuite run. You may find the results
at gcc-testresults:
https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02541.html

> 
>> Additionally, the test case no longer crashes.
The test case does and did PASS.

> 
> Hooray.
> 
> Now all we need is for Rainer to confirm that the patch works for
> mingw32 and we are good to go.

Yeah, we good to go, congratulations, thank you.

Cheers

Rainer

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWp3V1AAoJEB3HOsWs+KJb1KkH/ApsmUJNHLIRIsdA9ayLgW2J
qoIFobCZSJWNzEPMv/a92zhC/9JJqh7HqkrCdb46Dmlm3FGZjIuhzfyreeI+xyNj
PNuXJoXV2US7s5ywhE2DbiOmsEkboe/vYBTUvsA7179YmZdBm3718tJU0U/IBeim
AB3rmtHIs0F8Ousho8kfwiF8fGY4KA0pF9i7PT1gyXpFyNTbljXom8nUhP/gZDJU
2V6/GPpu0kuP/0KLydBSDGUZYuujs/HZ7BMBfJRmpWyy4YDcSFikaroTSr3XXjad
oBZySKt/DuuRvnEhrOll4xVJTg6bfQhNhf0hS3L/BRG/IdhELrJvnpT/8WjtFL0=
=pSyU
-END PGP SIGNATURE-

[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
.

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[afomin.mailbox at gmail dot com]

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

--- Comment #17 from Alexander Fomin  ---
Unfortunately, it doesn't. Moreover, it causes another perf loss (about 1.2%).

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Ilya Enkovich from comment #6)
> (In reply to amker from comment #5)
> > Not sure if stage4 is a good time for a new hook either.
> > 
> > Any ideas?
> 
> We can try to improve i386 address recognition to ignore operands order. 
> With this patch:
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 34b57a4..b13d3f6 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -14111,8 +14111,16 @@ ix86_decompose_address (rtx addr, struct
> ix86_address *out)
> {
>   if (n >= 4)
> return 0;
> - addends[n++] = XEXP (op, 1);
> - op = XEXP (op, 0);
> + if (GET_CODE (XEXP (op, 1)) == PLUS)
> +   {
> + addends[n++] = XEXP (op, 0);
> + op = XEXP (op, 1);
> +   }
> + else
> +   {
> + addends[n++] = XEXP (op, 1);
> + op = XEXP (op, 0);
> +   }
> }
>while (GET_CODE (op) == PLUS);
>if (n >= 4)
> 
> I get following ASM:
> 
> .L5:
> movlind@GOTOFF(%ebx,%esi,4), %eax
> movl12(%esp), %edi
> movl%ebp, (%edi,%eax,4)

According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html,
hook is probably not wanted in this case.
Bernd gave another proposal by moving combine before loop transforms is also
interesting, but it can be for GCC6.
So a backend fix would be nice.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #22 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #21)
> In another word, STV needs 128-bit aligned stack only when it generates
> 12-bit vector instructions.

STV never generates such instructions.  But RA may spill SSE registers and
aligned moves are used for that.  I actually expected RA to fix-up alignment
requirements or even use DI spills/fills (since we never use full register for
STV) but it doesn't happen.

[Bug libstdc++/65434] Memory leak in pool constructor

[emil.styrke at gmail dot com]

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

Emil Styrke  changed:

   What|Removed |Added

 CC||emil.styrke at gmail dot com

--- Comment #4 from Emil Styrke  ---
I just discovered that this will become a real leak if dlopen/dlclose:ing a
library that has been statically linked to libstdc++.  Each time the library is
opened a new pool object is created, and after dlclose it will not have any
references left. Valgrind shows this (after looping the dlopen/dlsym/dlclose
part a few times):

==3679== 3,707,904 bytes in 51 blocks are definitely lost in loss record 106 of
106
==3679==at 0x4C2BBCF: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3679==by 0x77335EF: _GLOBAL__sub_I_eh_alloc.cc (in
[...]/libmock_di_plugin.so)
==3679==by 0x40105B9: call_init.part.0 (dl-init.c:72)
==3679==by 0x40106CA: call_init (dl-init.c:30)
==3679==by 0x40106CA: _dl_init (dl-init.c:120)
==3679==by 0x4015586: dl_open_worker (dl-open.c:579)
==3679==by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==by 0x40149A2: _dl_open (dl-open.c:663)
==3679==by 0x6B94FC8: dlopen_doit (dlopen.c:66)
==3679==by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==by 0x6B9562C: _dlerror_run (dlerror.c:163)
==3679==by 0x6B95060: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3679==by 0x4F303E6: load_library (dipluginhandlerimpl.cpp:60)

I'm not sure if anything could be done about this, but it might be prudent to
add a warning to the documentation for -lstatic-libstdc++ explaining this.

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
Unconditionally generating toc_label_name is okay with me, but I thought that
Alan commented it was not sufficient in Comment #2.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #22)
> (In reply to H.J. Lu from comment #21)
> > In another word, STV needs 128-bit aligned stack only when it generates
> > 12-bit vector instructions.
> 
> STV never generates such instructions.  But RA may spill SSE registers and
> aligned moves are used for that.  I actually expected RA to fix-up alignment
> requirements or even use DI spills/fills (since we never use full register
> for STV) but it doesn't happen.

RA should be OK.  We have addressed all RA issues on Linux when we
implemented stack realignment.  RA should only spill/fill the part
of registers which is used.

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The dumped trees show a memcpy from "" with the length as the length of the
array:

  __builtin_memcpy (buffer.1_23, "", _15);

That should presumably use strnlen("", _15 - 1) or just be consistent with the
C front-end and reject it:

vla.c:20:5: error: variable-sized object may not be initialized

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[gang.chen.5i5j at gmail dot com]

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

--- Comment #19 from Chen Gang  ---
I build linux kernel with allyesconfig under x86_64 for linux-next tree
20160122. I can find some related cases for BUG28901 (but they are not quite
much), one case is below:

  CC  drivers/acpi/sbshc.o
In file included from drivers/acpi/sbshc.c:17:0:
drivers/acpi/sbshc.h:17:17: warning: ‘SMBUS_PEC’ defined but not used
[-Wunused-const-variable]
 static const u8 SMBUS_PEC = 0x80;
 ^

For me, I dislike -Wno-unused-const-variable option, the reason is "when C
programmers use static const int variable, in most cases, they want to use them
instead of #define".

So for me, -Wunused-variable need skip static const int variable warning. If
anyone wants to warn about it, they can add additional option (e.g.
-Wunused-const-int-variable) to let C compiler report warning for it.

Thanks.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #24 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #23)
> (In reply to Ilya Enkovich from comment #22)
> > (In reply to H.J. Lu from comment #21)
> > > In another word, STV needs 128-bit aligned stack only when it generates
> > > 12-bit vector instructions.
> > 
> > STV never generates such instructions.  But RA may spill SSE registers and
> > aligned moves are used for that.  I actually expected RA to fix-up alignment
> > requirements or even use DI spills/fills (since we never use full register
> > for STV) but it doesn't happen.
> 
> RA should be OK.  We have addressed all RA issues on Linux when we
> implemented stack realignment.  RA should only spill/fill the part
> of registers which is used.

Well, I'll try to just remove alignment code from STV and see what happens.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

--- Comment #28 from Nick Clifton  ---
Author: nickc
Date: Tue Jan 26 14:02:11 2016
New Revision: 232828

URL: https://gcc.gnu.org/viewcvs?rev=232828=gcc=rev
Log:
PR target/66655
* config/i386/winnt.c (i386_pe_binds_local_p): If a function has
been marked as DECL_ONE_ONLY but we do not the means to make it
so, then do not allow it to bind locally.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/winnt.c

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[gang.chen.5i5j at gmail dot com]

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

--- Comment #20 from Chen Gang  ---
(In reply to Chen Gang from comment #19)
> I build linux kernel with allyesconfig under x86_64 for linux-next tree
> 20160122. I can find some related cases for BUG28901 (but they are not quite
> much), one case is below:
> 
>   CC  drivers/acpi/sbshc.o
> In file included from drivers/acpi/sbshc.c:17:0:
> drivers/acpi/sbshc.h:17:17: warning: ‘SMBUS_PEC’ defined but not used
> [-Wunused-const-variable]
>  static const u8 SMBUS_PEC = 0x80;
>  ^

Oh, sorry, this case is not suitable, it is -Wunused-const-variable.


But my opinion still like what I said in comment #19.

Thanks.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #29 from Nick Clifton  ---
New patch applied.  This time it works, and no-one will have to be nailed to
anything...

[Bug libstdc++/69486] Strange behaviour of bitset and c++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I can't reproduce this, please provide the missing information you were asked
to include: https://gcc.gnu.org/bugs/

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[amonakov at gcc dot gnu.org]

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

--- Comment #30 from Alexander Monakov  ---
Nick, can you please post the patch to gcc-patches too, to avoid confusing
future people who wouldn't be able to find the explanation of the patch in the
archives?

(did you get approval for this patch offline?)

[Bug rtl-optimization/69482] Writing through pointers to volatile not always preserved

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Tue, 26 Jan 2016, wipedout at yandex dot ru wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482
> 
> wipedout at yandex dot ru changed:
> 
>What|Removed |Added
> 
>  CC||wipedout at yandex dot ru
> 
> --- Comment #2 from wipedout at yandex dot ru ---
> I also found that this code
> 
>   int x[4];
>   memset_s(x, 6);
> 
> also emits no writes. Is this because of undefined behavior or is it for any
> other reason?

Well, x is not used so all the code is dead (independent on whether
the memset invokes undefined behavior).

[Bug libstdc++/69486] Strange behaviour of bitset and c++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|WAITING |NEW

--- Comment #2 from Jonathan Wakely  ---
OK< I do see it use a lot more memory with -std=c++11, just not enough to start
swapping on my machine.

Probably some of the constexpr functions used in C++11 mode.

[Bug testsuite/69488] New: tests in gnat/sso give a lot of incorrect FAIL results, output pattern matching goes wrong on mingw host

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

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

Bug ID: 69488
   Summary: tests in gnat/sso give a lot of incorrect FAIL
results, output pattern matching goes wrong on mingw
host
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

Two examples from about 300 in gnat/sso:

Setting LD_LIBRARY_PATH to
:/opt/devel/SCRATCH/tmp.FDPvU82tbA/gcc-6.0.0/gcc-6.0.0/gcc::/opt/devel/SCRATCH/tmp.FDPvU82tbA/gcc-6.0.0/gcc-6.0.0/gcc:.
spawn [open ...]^M
X_L = (S => 12345, C => 'a')^M
X_H = (S => 23456, C => 'b')^M
X_H = (S => 12345, C => 'a')^M
PASS: gnat.dg/sso/conv1.adb   -Og -g  execution test
FAIL: gnat.dg/sso/conv1.adb   -Og -g  output pattern test
Output was:
X_L = (S => 12345, C => 'a')^M
X_H = (S => 23456, C => 'b')^M
X_H = (S => 12345, C => 'a')^M

Should match:
X_L = \(S => 12345, C => 'a'\)
X_H = \(S => 23456, C => 'b'\)
X_H = \(S => 12345, C => 'a'\)

Here we have an issue with escaping and line endings unix versus dos.


Setting LD_LIBRARY_PATH to
:/opt/devel/SCRATCH/tmp.FDPvU82tbA/gcc-6.0.0/gcc-6.0.0/gcc::/opt/devel/SCRATCH/tmp.FDPvU82tbA/gcc-6.0.0/gcc-6.0.0/gcc:.
spawn [open ...]^M
My_R1: 78 56 34 12^M
My_R2: 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
PASS: gnat.dg/sso/p1.adb   -O0  execution test
FAIL: gnat.dg/sso/p1.adb   -O0  output pattern test
Output was:
My_R1: 78 56 34 12^M
My_R2: 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M
Local_R1 : 78 56 34 12^M
Local_R2 : 12 34 56 78^M

Should match:
My_R1: 78 56 34 12
My_R2: 12 34 56 78
Local_R1 : 78 56 34 12
Local_R2 : 12 34 56 78
Local_R1 : 78 56 34 12
Local_R2 : 12 34 56 78
Local_R1 : 78 56 34 12
Local_R2 : 12 34 56 78

Line endings issue.

Does somebody know how to fix this?

Cheers

Rainer

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at redhat dot com]

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

--- Comment #31 from Nick Clifton  ---
Hi Alexander,

> Nick, can you please post the patch to gcc-patches too, to avoid confusing
> future people who wouldn't be able to find the explanation of the patch in the
> archives?
> (did you get approval for this patch offline?)

Oh foo - no I did not.  I will post to gcc-patches now.  If approval is
forthcoming quickly then I will leave things as they are.  Otherwise I will
revert my patch and wait for proper authorisation.  Sorry about mucking up.

Cheers
   Nick

[Bug tree-optimization/69489] New: missed vectorization for boolean loop

[jtaylor.debian at googlemail dot com]

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

Bug ID: 69489
   Summary: missed vectorization for boolean loop
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com
  Target Milestone: ---

following (abbreviated) code does not vectorize with gcc 5.2.1:

gcc file.c -O2 -ftree-vectorize -c

double
yule_bool_distance_char2(const char *u, const char *v, long n)
{
long i;
long ntt = 0, nff = 0, nft = 0, ntf = 0;

for (i = 0; i < n; i++) {
ntf += (u[i] && !v[i]);
nft += (!u[i] && v[i]);
}   
return (2.0 * ntf * nft);
} 

but if one replaces the loop body with this:

char x = u[i], y = v[i];
ntf += x && (!y);
nft += (!x) && y;

gcc will vectorize it.
As I understand it both code is equivalent, so it would be great if gcc could
vectorize both variants.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jamborm at gcc dot gnu.org]

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

--- Comment #19 from Martin Jambor  ---
Because the reduced testcase from comment #10 does not fail for me (on
revision 232662), I have tried to use creduce myself but have never
ended up with anything useful (I got source with undefined behavior
that would be passing and failing on different x86_64 machines).

So I looked at the situation and created the following C artificial
testcase that "fails" even on the current mainline.  However, it
breaks at least the aliasing rules, if not more, so I am not sure
whether we actually want it in the testcase (perhaps with
-fno-strict-aliasing as a QoI test?).

To be clear, even though this testcase is ugly, it is exactly what
actually happens in the original one.  A scalar field is type-punned
and a structure gets stored in its place and consequently the data
there are forgotten when the scalarized structure is being copied to
the result_decl.


struct S
{
  void *a;
  long double b;
};

struct Z
{
  long l;
  short s;
} __attribute__((packed));

struct S __attribute__((noclone, noinline))
foo (void *v, struct Z *z)
{
  struct S t;
  t.a = v;
  *(struct Z *)  = *z;
  return t;
}

struct Z gz;

int
main (int argc, char **argv)
{
  struct S s;

  gz.l = 0xbeef;
  gz.s = 0xab;

  s = foo ((void *) 0, );

  if struct Z *) )->l != gz.l)
  || (((struct Z *) )->s != gz.s))
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
(In reply to Bernd Schmidt from comment #12)
> It looks like a patch was committed - can this be closed?

There is still PR62263, so not all cases are handled, but if all those
mentioned in this PR are fixed, then it is enough to keep the other one open.

[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 26 14:25:56 2016
New Revision: 232829

URL: https://gcc.gnu.org/viewcvs?rev=232829=gcc=rev
Log:
PR lto/69254
* lto-wrapper.c (merge_and_complain): Handle -fcilkplus.
(append_compiler_options): Handle -fcilkplus.
(append_linker_options): Ignore -fno-{openmp,openacc,cilkplus}.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-wrapper.c

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #25 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #24)
> Well, I'll try to just remove alignment code from STV and see what happens.

Please add -mpreferred-stack-boundary=2 to your tests.  Otherwise,
you just remove a nop.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
(In reply to Martin Jambor from comment #19)
> Because the reduced testcase from comment #10 does not fail for me (on
> revision 232662), I have tried to use creduce myself but have never
> ended up with anything useful (I got source with undefined behavior
> that would be passing and failing on different x86_64 machines).

Strange.

> whether we actually want it in the testcase (perhaps with
> -fno-strict-aliasing as a QoI test?).

With -fno-strict-aliasing it should be (as a GNU extension) well defined.
Guess you want to return 0 early in main if sizeof (long double) < sizeof
(struct Z); and probably also use long long instead of long field in struct Z.

> struct S
> {
>   void *a;
>   long double b;
> };
> 
> struct Z
> {
>   long l;
>   short s;
> } __attribute__((packed));
> 
> struct S __attribute__((noclone, noinline))
> foo (void *v, struct Z *z)
> {
>   struct S t;
>   t.a = v;
>   *(struct Z *)  = *z;
>   return t;
> }
> 
> struct Z gz;
> 
> int
> main (int argc, char **argv)
> {
>   struct S s;
> 
>   gz.l = 0xbeef;
>   gz.s = 0xab;
> 
>   s = foo ((void *) 0, );
> 
>   if struct Z *) )->l != gz.l)
>   || (((struct Z *) )->s != gz.s))
> __builtin_abort ();
>   return 0;
> }

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
(In reply to Alexander Fomin from comment #17)
> Unfortunately, it doesn't. Moreover, it causes another perf loss (about
> 1.2%).

Heh.  What about testcases?

[Bug jit/69490] New: jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu

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

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

Bug ID: 69490
   Summary: jit testsuite failures (segmentation fault) on
x86_64-unknown-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

> FAIL: test-accessing-struct.c.exe killed: 29233 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-accessing-union.c.exe killed: 20033 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-arith-overflow.c.exe killed: 20178 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-array-as-pointer.c.exe killed: 20347 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-arrays.c.exe killed: 20448 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-benchmark.c.exe killed: 20586 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-calling-external-function.c.exe killed: 20686 exp9 0 0 CHILDKILLED 
> SIGSEGV {segmentation violation}
> FAIL: test-calling-function-ptr.c.exe killed: 20850 exp9 0 0 CHILDKILLED 
> SIGABRT SIGABRT
> FAIL: test-combination.c.exe killed: 21074 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-compile-to-assembler.c.exe killed: 23057 exp9 0 0 CHILDKILLED 
> SIGSEGV {segmentation violation}
> FAIL: test-compile-to-dynamic-library.c.exe killed: 23175 exp9 0 0 
> CHILDKILLED SIGSEGV {segmentation violation}
> FAIL: test-compile-to-executable.c.exe killed: 23369 exp9 0 0 CHILDKILLED 
> SIGABRT SIGABRT
> FAIL: test-compile-to-object.c.exe killed: 23517 exp9 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-compound-assignment.c.exe: non-zero exit code: 23669 exp9 0 4
> FAIL: test-debug-strings.c.exe killed: 705 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-dot-product.c.exe killed: 957 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
> FAIL: test-empty.c.exe killed: 1268 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-error-gcc_jit_timer_pop-mismatch.c.exe killed: 1922 exp10 0 0 
> CHILDKILLED SIGSEGV {segmentation violation}
> FAIL: test-error-gcc_jit_timer_pop-too-many.c.exe killed: 2176 exp10 0 0 
> CHILDKILLED SIGSEGV {segmentation violation}
> FAIL: test-error-pr63969-missing-driver.c.exe killed: 5148 exp10 0 0 
> CHILDKILLED SIGABRT SIGABRT
> FAIL: test-error-unrecognized-dump.c.exe killed: 5746 exp10 0 0 CHILDKILLED 
> SIGSEGV {segmentation violation}
> FAIL: test-expressions.c.exe killed: 6349 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-extra-options.c.exe killed: 7200 exp10 0 0 CHILDKILLED SIGABRT 
> SIGABRT
> FAIL: test-factorial.c.exe killed: 7459 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
> FAIL: test-fibonacci.c.exe killed: 7698 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
> FAIL: test-functions.c.exe killed: 8025 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-hello-world.c.exe killed: 8846 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-linked-list.c.exe killed: 9083 exp10 0 0 CHILDKILLED SIGABRT 
> SIGABRT
> FAIL: test-long-names.c.exe killed: 9337 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-nested-contexts.c.exe killed: 9603 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-nested-loops.c.exe killed: 9830 exp10 0 0 CHILDKILLED SIGABRT 
> SIGABRT
> FAIL: test-operator-overloading.cc.exe killed: 10584 exp10 0 0 CHILDKILLED 
> SIGABRT SIGABRT
> FAIL: test-pr66700-observing-write-through-ptr.c.exe killed: 10946 exp10 0 0 
> CHILDKILLED SIGSEGV {segmentation violation}
> FAIL: test-pr66779.c.exe killed: 11203 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
> FAIL: test-quadratic.c.exe killed: 11884 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
> FAIL: test-quadratic.cc.exe killed: 12542 exp10 0 0 CHILDKILLED SIGABRT 
> SIGABRT
> FAIL: test-reading-struct.c.exe: non-zero exit code: 12847 exp10 0 4
> FAIL: test-string-literal.c.exe killed: 13167 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-sum-of-squares.c.exe killed: 13395 exp10 0 0 CHILDKILLED SIGABRT 
> SIGABRT
> FAIL: test-switch.c.exe killed: 13667 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-switch.cc.exe killed: 14319 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-threads.c.exe killed: 14692 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
> FAIL: test-types.c.exe killed: 14931 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-using-global.c.exe killed: 15163 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation violation}
> FAIL: test-validly-unreachable-block.c.exe killed: 15386 exp10 0 0 
> CHILDKILLED SIGSEGV {segmentation violation}
> FAIL: test-volatile.c.exe killed: 15585 exp10 0 0 CHILDKILLED SIGSEGV 
> {segmentation 

[Bug tree-optimization/32306] [4.9/5/6 Regression] redundant && || not eliminated

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #29 from Bernd Schmidt  ---
(In reply to Richard Biener from comment #19)
> Shorter testcase, compilable and to the point.  We are not able to CSE
> the b1 && ... && b8 sequence because we produce control-flow for it
> during gimplification.
> 
> void bar (short *array,
>   short b1, short b2, short b3, short b4,
>   short b5, short b6, short b7, short b8)
> {
>   array[0] = b1 && b2 && b3 && b4 && b5 && b6 && b7 && b8;
>   array[1] = b1 && b2 && b3 && b4 && b5 && b6 && b7 && b8;
> }

This seems to be optimized as of 4.7, but the original testcase still needs
work. Maybe sccvn could be taught to recreate the conditionals?

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|5.3.0   |6.0
   Target Milestone|--- |6.0

[Bug jit/69490] jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks for reporting this.

Which exact version are you testing with?  This looks a lot like PR 68446,
which was fixed in r232567.

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 Blocks||53947
Summary|missed vectorization for|missed vectorization for
   |boolean loop|boolean loop, missed
   ||if-conversion
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Ok, so the trick here is to see that v[i] is always loaded (and thus it may
not be NULL or otherwise trapping) because either u[i] or !u[i] will be true.

This is a missed if-conversion opportunity.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
And in the end it is also related to PR23286, the inability to hoist the v[i]
load out of

  if (u[i])
... = v[i];
  else
... = v[i];

which would also enable the if-conversion.

[Bug tree-optimization/69282] [6 Regression] aarch64/armhf ICE on SPEC2006 464.h264ref at -O3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|aarch64-linux-gnu   |aarch64-linux-gnu,
   ||arm-none-linux-gnueabihf
   Priority|P3  |P1
   Last reconfirmed|2016-01-14 00:00:00 |2016-1-26
 CC||ktkachov at gcc dot gnu.org
  Known to work||5.3.1
  Known to fail||6.0

[Bug c++/69486] Strange behaviour of bitset and c++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #3 from Jonathan Wakely  ---
Trunk only uses 4GB not 5GB, but that's still far too much. Generating the
array initialization for this constexpr constructor is the problem:

  constexpr _Base_bitset(unsigned long long __val) noexcept
  : _M_w{ _WordT(__val)
   } { }


I think we have an existing bug report about this.

Reduced:

namespace std
{
  typedef decltype(sizeof(0)) size_t;

  template
struct _Base_bitset
{
  typedef unsigned long _WordT;

  _WordT _M_w[_Nw];

  constexpr _Base_bitset() noexcept
  : _M_w() { }

  constexpr _Base_bitset(unsigned long long __val) noexcept
  : _M_w{ _WordT(__val)
   } { }
};

  template
class bitset
: private _Base_bitset<((_Nb) / (8 * 8) + ((_Nb) % (8 * 8) == 0 ? 0 : 1))>
{
public:
  constexpr bitset() noexcept
  { }
};
}

std::bitset<2147483648> b;
int main() {}

[Bug jit/69490] jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu

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

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

--- Comment #2 from Rainer Emrich  ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 26.01.2016 um 15:50 schrieb dmalcolm at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490
> 
> --- Comment #1 from David Malcolm 
> --- Thanks for reporting this.
> 
> Which exact version are you testing with?  This looks a lot like PR
> 68446, which was fixed in r232567.
> 
Ok, I'm a little bit behind, that's rev. 232504. I will retest with
current trunk!

Cheers

Rainer

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWp4viAAoJEB3HOsWs+KJbE8gIAKo2w64H/d7v0RX8ozYyX4gA
5slFuCDZWpAn8SACFW3S2Ujosi9xqTJg1QGvKnbaCa+x0cckiu99OfKkdk5NKHcB
BhQzc7xiRaM4ofcKkd3s98Ajt8rT8oLnw7jpa8ZOPuKJaxPgotXNduhCIarYFQtb
5lloc6VwGIrZIeDyw17qWkA4pS0dPY1oDOLUuc4c4T5mhui40lNK0j37svaLf8sS
eSAWBsTLCdxJCo+ZwCPQ99U5T6YZoY6jO6QwTAmbuXqpSMzxm2iPEH/U47OKGhmv
59YU7ksl7EfVudu4NcVSy09jInPgRXscvGyK9Zj7jp/1AbOk5nKz69LSgXRDFbo=
=Ysra
-END PGP SIGNATURE-

[Bug c++/69486] Strange behaviour of bitset and c++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
dup

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

[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||boris at dolgov dot name

--- Comment #3 from Jonathan Wakely  ---
*** Bug 69486 has been marked as a duplicate of this bug. ***

[Bug c++/68399] c++11 default initialization of a large array: slow compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
One of many dups of 56671

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

[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kcc at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
*** Bug 68399 has been marked as a duplicate of this bug. ***

[Bug lto/68685] LTO build hits ICE in copy_to_mode_reg, at explow.c:595

[anton at samba dot org]

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

Anton Blanchard  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Anton Blanchard  ---
The original testcase now makes it past the failure.

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

[clyon at gcc dot gnu.org]

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

--- Comment #8 from Christophe Lyon  ---
Author: clyon
Date: Tue Jan 26 15:17:00 2016
New Revision: 232832

URL: https://gcc.gnu.org/viewcvs?rev=232832=gcc=rev
Log:
2016-01-26  Christophe Lyon  

gcc/
PR target/68620
* config/arm/arm.c (neon_valid_immediate): Handle FP16 vectors.
* config/arm/arm_neon.h (__ARM_NUM_LANES, __arm_lane, arm_lanq):
New helper macros.
(vget_lane_f16): Handle big-endian.
(vgetq_lane_f16): Likewise.
(vset_lane_f16): Likewise.
(vsetq_lane_f16): Likewise.
* config/arm/iterators.md (VQXMOV): Add V8HF.
(VDQ): Add V4HF and V8HF.
(V_reg): Handle V4HF and V8HF.
(Is_float_mode): Likewise.
* config/arm/neon.md (movv4hf, movv8hf, neon_vdup_nv4hf,
neon_vdup_nv8hf): New patterns.
(vec_set_internal, vec_extract, neon_vld1_dup):
Use VD_LANE iterator.
(neon_vld1_dup): Use VQ2 iterator.

testsuite/
PR target/68620
* gcc.target/arm/pr68620.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr68620.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm_neon.h
trunk/gcc/config/arm/iterators.md
trunk/gcc/config/arm/neon.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/68203] Аbout infinite compilation time on struct with nested array of pairs with -std=c++11

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Probably PR 56671

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
For if-conversion this triggers the three-argument PHI case which is only
handled
for force_vectorize loops.  Similar to the masked-load-store case we should
simply trigger versioning if that happens.  We still run into

_14 = *_13;
tree could trap...

then of course.  The fix for that is for ref_DR_map to hash/compare
DR_BASE_ADDRESS, DR_OFFSET, DR_INIT and DR_STEP instead of a somewhat
stripped DR_REF.

[Bug c++/55402] Compiling large initializer lists never finishes

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Similar to PR 56671 but -fno-exceptions doesn't help there, the issue is that
the initializer-list is in a constexpr constructor.

[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
Generating the array initialization for this constexpr constructor is the
problem:

  constexpr _Base_bitset(unsigned long long __val) noexcept
  : _M_w{ _WordT(__val)
   } { }

Reduced example from PR 69486:

namespace std
{
  typedef decltype(sizeof(0)) size_t;

  template
struct _Base_bitset
{
  typedef unsigned long _WordT;

  _WordT _M_w[_Nw];

  constexpr _Base_bitset() noexcept
  : _M_w() { }

  constexpr _Base_bitset(unsigned long long __val) noexcept
  : _M_w{ _WordT(__val)
   } { }
};

  template
class bitset
: private _Base_bitset<((_Nb) / (8 * 8) + ((_Nb) % (8 * 8) == 0 ? 0 : 1))>
{
public:
  constexpr bitset() noexcept
  { }
};
}

std::bitset<2147483648> b;
int main() {}

[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
-fno-lra-remat makes the testcase pass.
Could this be a dup of PR 69124?

[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #13 from Bernd Schmidt  ---
Investigating a bit.