[Bug c/69480] Bad error message on assigning to read-only

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
This error happens after lhs is c_fully_fold()-ed, thus what %qE prints is a
symbolic representation of GCC's IR and no what the user wrote. Pretty-printing
is the root of all evil (PR35441, PR49152).

[Bug c/69480] Bad error message on assigning to read-only

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, the C++ front-end is much better though the location is not so good.

t6.c: In function ‘fail’:
t6.c:13:28: error: assignment of read-only location
‘*__builtin_memcpy(&, &({...}))’
 ACCESS_ONCE(*s->p) = p;
^

apinski@arm64:~/src/local/gcc/objdir/gcc$ g++ t6.c
t6.c: In function ‘void fail(fail*, uint32_t)’:
t6.c:13:30: error: assignment of read-only location ‘*({...})’
 ACCESS_ONCE(*s->p) = p;
  ^

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

[rogero at howzatt dot demon.co.uk]

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

--- Comment #24 from Roger Orr  ---
Thanks Nick.

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

Additionally, the test case no longer crashes.

$ /usr/share/gcc-trunk/bin/g++ -O2 -fno-inline pr66655.C pr66655_1.cc
$ ./a.exe
$ /usr/share/gcc-trunk/bin/g++ -O2 -fno-inline pr66655_1.cc pr66655.C
$ ./a.exe

$ /usr/share/gcc-trunk/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/share/gcc-trunk/bin/g++
COLLECT_LTO_WRAPPER=/usr/share/gcc-trunk/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lto-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: ../gcc-trunk-232400/configure --enable-languages=c,c++
--prefix=/usr/share/gcc-trunk
Thread model: single
gcc version 6.0.0 20160115 (experimental) (GCC)

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

[wipedout at yandex dot ru]

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

Bug ID: 69482
   Summary: Writing through pointers to volatile not always
preserved
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wipedout at yandex dot ru
  Target Milestone: ---

I'm trying this on http://gcc.godbolt.org/ The compiler selected is "x86 gcc
5.3.0", the command line option string is "-x c -std=c99 -O3"

This is the code (note pointer to volatile):

#include 

static void memset_s(void* s, size_t n) {
  volatile unsigned char * p = s;
  for(size_t i = 0; i < n; ++i) {
p[i] = 0;
  }
}

void test() {
  unsigned char x[4];
  memset_s(x, sizeof x);
}

This is the emitted assembly:

test:
rep ret

Same happens when size of array is 1 and 2. With all other array sizes writes
are preserved. For example, this is emitted for array of size 3:

test:
movb$0, -24(%rsp)
movb$0, -23(%rsp)
movb$0, -22(%rsp)
ret

and this is emitted for array of size 5:

test:
movb$0, -24(%rsp)
movb$0, -23(%rsp)
movb$0, -22(%rsp)
movb$0, -21(%rsp)
movb$0, -20(%rsp)
ret

This is not reproduced in "x86 gcc 4.5.3" but is reproduced in "x86 gcc 4.6.4"
and later. This isn't reproduced in clang.

"secure memset" implementation as above is widely used to overwrite memory
previously used to store encryption keys, passwords and the like. Cases with
size hardcoded and being 1, 2 or 4 look dumb but I have no idea what exactly
causes this unexpected code emission and how serious the real impact is.

[Bug lto/69408] LD crashes with LTO

[night_ghost at ykoctpa dot ru]

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

--- Comment #4 from night_ghost at ykoctpa dot ru ---
I can attach script which GCC has been built, and ZIP of the project tree which
cause crash.

[Bug c/69480] New: Bad error message on assigning to read-only

[segher at gcc dot gnu.org]

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

Bug ID: 69480
   Summary: Bad error message on assigning to read-only
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
CC: hector at marcansoft dot com
  Target Milestone: ---

This testcase from Hector


#include 

struct fail {
uint32_t *p;
};

#define __ACCESS_ONCE(x) ({ \
 typeof(x) __var = ( typeof(x)) 0; \
 (volatile const typeof(x) *)&(x); })
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))

void fail(struct fail *s, uint32_t p) {
ACCESS_ONCE(*s->p) = p;
}


results in

fail.c: In function 'fail':
fail.c:13:21: error: assignment of read-only location
'*__builtin_memcpy(&, &({...}))'
  ACCESS_ONCE(*s->p) = p;
 ^

There is no __builtin_memcpy in the program source, but the  is
even more worrying (the number is different on different runs).

[Bug c++/49152] pretty printer cannot handle iterators and other complex expressions

[manu at gcc dot gnu.org]

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

--- Comment #49 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #13)
> Re Gaby's point about the error appearing in a sub-expression of a larger
> full expression, that's true

Now that the caret has been the default for several years and GCC 6 has range
info thanks to dmalcom, this argument in favour of pretty-printing is not true
anymore: %qE must die! :)

[Bug c++/69481] New: ICE with C++11 alias using with templates

[pinskia at gcc dot gnu.org]

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

Bug ID: 69481
   Summary: ICE with C++11 alias using with templates
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
   template  struct tt{
 using ut = tt;
 ut& operator++();
};
template  tt& tt::operator++() {}

 CUT 
This causes an ICE with the trunk and GCC 5.3:
t.cc:5:48: internal compiler error: same canonical type node for different
types tt and tt::ut
template  tt& tt::operator++() {}
^

0x725dcb comptypes(tree_node*, tree_node*, int)
/home/apinski/src/local/gcc/gcc/cp/typeck.c:1435
0x724503 structural_comptypes
/home/apinski/src/local/gcc/gcc/cp/typeck.c:1357
0x725d23 comptypes(tree_node*, tree_node*, int)
/home/apinski/src/local/gcc/gcc/cp/typeck.c:1420
0x6ac31f check_classfn(tree_node*, tree_node*, tree_node*)
/home/apinski/src/local/gcc/gcc/cp/decl2.c:726
0x57fa9f grokfndecl
/home/apinski/src/local/gcc/gcc/cp/decl.c:8176
0x600277 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/apinski/src/local/gcc/gcc/cp/decl.c:11332
0x6033db start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/apinski/src/local/gcc/gcc/cp/decl.c:14136
0x70b5e3 cp_parser_function_definition_from_specifiers_and_declarator
/home/apinski/src/local/gcc/gcc/cp/parser.c:25133
...

So far I tracked down the main difference between C++11 alias and typedef in
this case is TYPE_ALIAS_P being check somewhere to cause a different type being
created.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That means we need #define USE_ALGORITHM before #include "system.h" in
genmodes.c with a comment.

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/69466] ICE: Invalid PHI argument after vectorization (on -O2)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
No testcase attached.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ard.biesheuvel at linaro dot org]

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

--- Comment #50 from ard.biesheuvel at linaro dot org ---
(In reply to Ramana Radhakrishnan from comment #49)
> (In reply to ard.biesheuvel from comment #48)
> > (In reply to Richard Earnshaw from comment #47)
> > > (In reply to ard.biesheuvel from comment #46)
> > > > One issue that this causes, which I did not see mentioned anywhere in 
> > > > the
> > > > thread, is that the use of adrp/add and adrp/ldr imposes a 4 KB section
> > > > alignment. In EDK2 Tianocore (UEFI reference implementation), we
> > > > deliberately use -mcmodel=large to get around this requirement, since 
> > > > code
> > > > size is a big deal when executing from NOR flash, and the architecture 
> > > > of
> > > > EDK2 (lots and lots of small separately linked binaries) makes
> > > > the overhead of 4 KB section alignment prohibitive. (It uses 32 byte 
> > > > section
> > > > alignment unless there are objects like a vector table that require 
> > > > more)
> > > 
> > > Huh?  It imposes a 4k *SEGMENT* alignment.  It doesn't impose a section
> > > alignment.
> > 
> > Indeed, apologies for mixing up the lingo.
> > 
> > But my point is that -mcmodel=large did not use to impose such a minimum
> > alignment, and with this change, it now does. Would it perhaps make sense to
> > default enable this feature only for -mcmodel=small (which already uses
> > adrp/add anyway)
> 
> 
> -mcmodel=large allows for images > 1MiB to be compiled, this change enables
> functions > 1MiB in size to exist in images compiled and linked with
> -mcmodel=large.
> 

AIUI the small model allows images up to 4 GB (since that is the range of
adrp+lo12), and the large model allows any size, by emitting cross section
references as literals containing absolute addresses (rather than movz/movk
sequences). This relies on the literals themselves being in range, which is
usually the case, of course, if they are emitted into the same section, modulo
the uses cases that caused this bug in the first place. (BTW my GCC man page
erroneously lists the tiny model as having a 1 GB range but this should
obviously be 1 MB)

So by enabling this feature by default, you are now imposing a 4 GB image limit
on the large model as well, since the literals are moved to a different section
(which, given our choice for the large model, is not guaranteed to be within 4
GB in the final image), and referenced via instructions that only have a 4 GB
range.

> As of now, if you really want to use -mcmodel=large for working around this,
> you already have -mpc-relative-literal-loads to allow this.

I am arguing that enabling this feature essentially breaks the large model, so
it should not be enabled by default, and perhaps be made mutually exclusive.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/65356] [meta-bug] Port tail-merge fixes to 4.9

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2016-01-25
 Resolution|FIXED   |---
 Ever confirmed|0   |1

[Bug tree-optimization/69468] New: tail merge should ignore private edge flags

[vries at gcc dot gnu.org]

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

Bug ID: 69468
   Summary: tail merge should ignore private edge flags
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01880.html
...
> One reason is that an edge_flag EDGE_EXECUTABLE happens to be set, which
> prevents tail-merge from doing a merge.

> Using first attached patch, which:
> - clears EDGE_EXECUTABLE in tail-merge, and

this shows a latent issue in tail-merging that it doesn't ignore
edge flags that are "private" (that is, they have random state upon
pass entry).
...

[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #13 from Ilya Enkovich  ---
Fixed

[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug other/69453] unrecognized command line option suggestions should take negation into account

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Although it's not a duplicate, I believe that the patch I posted for PR 69265
covers this:
  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00871.html

I can add the testcases suggested in this bug.

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 25 14:42:39 2016
New Revision: 232795

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

PR testsuite/69380
* g++.dg/tree-ssa/pr69336.C: Restrict to x86_64 and i?86.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr69336.C

[Bug tree-optimization/69465] ICE: Invalid PHI argument after vectorization (on -O2)

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

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

--- Comment #1 from Kirill Yukhin  ---
Duplicate w/ 69465

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[matz at gcc dot gnu.org]

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

--- Comment #8 from Michael Matz  ---
Please try https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01875.html
if possible.

[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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
To restore the state before the move from fold to match.pd we'd need to mark
any such pattern involving compares as the outermost expr (and thus match
on GIMPLE_CONDs) with an explicit && single_use () check.  Fix for this one:

Index: gcc/match.pd
===
--- gcc/match.pd(revision 232792)
+++ gcc/match.pd(working copy)
@@ -1821,12 +1821,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (for cmp (simple_comparison)
  scmp (swapped_simple_comparison)
  (simplify
-  (cmp (mult @0 INTEGER_CST@1) integer_zerop@2)
+  (cmp (mult@3 @0 INTEGER_CST@1) integer_zerop@2)
   /* Handle unfolded multiplication by zero.  */
   (if (integer_zerop (@1))
(cmp @1 @2)
(if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
-   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
+   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
+   && single_use (@3))
 /* If @1 is negative we swap the sense of the comparison.  */
 (if (tree_int_cst_sgn (@1) < 0)
  (scmp @0 @2)

[Bug target/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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Started with r219646:

Author: ienkovich 
Date:   Thu Jan 15 11:39:20 2015 +

gcc/

PR tree-optimization/64434
* cfgexpand.c (reorder_operands): New function.
(expand_gimple_basic_block): Insert call of reorder_operands if
optimized is true.

gcc/testsuite/

PR tree-optimization/64434
* gcc.dg/torture/pr64434.c: New test.

[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 #15 from Jakub Jelinek  ---
Created attachment 37463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37463=edit
gcc6-pr69254.patch

Updated untested patch, tested so far just on simple testcases (with
-fsanitize=undefined, -fopenmp and -fcilkplus).  Absolutely no idea what to do
for the testsuite, I'm afraid this can be only tested in the lto.exp framework,
but for the interesting cases needs to know if -fopenmp, -fopenacc, -fcilkplus
or -fsanitize= etc. can be used.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
The failre was introduced by r232736 [1]:

[1] https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01643.html

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> That means we need #define USE_ALGORITHM before #include "system.h" in
> genmodes.c with a comment.

But std::swap is used in many places. IMO, a configure check what to include
would be the best solution here.

[Bug tree-optimization/65356] [meta-bug] Port tail-merge fixes to 4.9

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |4.9.5

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to vries from comment #0)
> - Fix PR64091
>   https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03397.html

Posted 4.9 fix: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01877.html

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #2)
> This looks like a latent bug in tree-ssa-loop-im.c introduced by Richi a few
> years ago when he added handling of invariant PHIs.
> 
> It appears that the code assumes that a dominator walk is sufficient to
> order invariant statements moved.  However, consider a diamond CFG
> 
> a
>/ \
>   b   c
>\ /
> d
> 
> a dominates b, c & d.  
> 
> Valid dominator walk orders would be
> 
> a, b, c, d
> a, b, d, c
> a, c, b, d
> a, c, d, b
> a, d, b, c
> a, d, c, b
> 
> Note carefully that we could visit d before b or c.  So a pass which assumes
> that we always visit b & c before d for correctness is fundamentally flawed.
> 
> The move_computations::before_dom_children call back is visited by the dom
> walker and just inserts instructions on the appropriate edge.  Each
> instruction is inserted on the edge *when it's appropriate block is
> visited*.  So if we have an invariant in d which depends on invariants in b
> & c, a domwalk can not be relied upon to order those statements.
> 
> The obviously question is how can that happen in SSA?  There can't be a
> statement in d that depends on something in b & c because b & c don't
> dominate d.  But wait...  PHI nodes.  A PHI can be defined in d which has
> arguments defined in b & c.
> 
> That's precisely what's happening with this BZ.  We have a PHI in block d
> which is fed by values in blocks c & b.  However, the order of visitation in
> the domwalk is b, d, c resulting in something like this:
> 
> _71 = (char) pretmp_85;
> c_lsm.17_116 = r_75 != 0 ? _93 : _71;
> _93 = (char) pretmp_85;
> 
> Which is obviously invalid SSA (ignore that _71 and _93 have the same value).
> 
> What's key to remember here is that a domwalk will not guarantee that blocks
> defining arguments in a PHI will be visited before the PHI itself -- even in
> loop-free code.
> 
> If we're going to keep the current design of the invariant-motion code, then
> we probably need to do something like a topological sort of the statements
> on the edges before we commit the edge insertions.
> 
> We could also consider sorting the blocks for the dominator walk.  There's
> been a few cases through the years where that would be helpful, but not in a
> really significant way, just minor stuff we'd catch earlier in the optimizer
> pipeline if we had a better visitation order.

domwalk already does that though, but it seems to be not enough if you consider

   C
  / \
 B   D-E
 |   |
 |   F
  \ /  
   A

where children of C are B, A and D (but not F!).  The simple diamond is dealt
with with

  default:
qsort ([saved_sp], sp - saved_sp,
   sizeof (basic_block), cmp_bb_postorder);

which sorts children in rpo order.

The issue is latent - I'll think of sth not too invasive to fix it.

[Bug ada/67205] violation of No_Implicit_Dynamic_Code restriction not reported

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #7 from simon at pushface dot org ---
As far as I can see 5.1.0 (and 5.2.0) are happy that the trampolines should be
*generated* in the presence of pragma Restrictions (No_Implicit_Dynamic_Code);
trampoline.adb compiles and builds without problem.

The problem arises when the trampolines are invoked; 

with Ada.Containers.Vectors;
procedure Trampoline is
   package Vectors is new Ada.Containers.Vectors (Positive, Integer);
   type Capacity_P is
 access function (Container : Vectors.Vector)
 return Ada.Containers.Count_Type;
   P : Capacity_P;
begin
   P := Vectors.Capacity'Access;
end Trampoline;

results in the expected 'violation of restriction “No_Implicit_Dynamic_Code”’
error at compile time.

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kuganv at linaro dot org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Started with:
Author: kugan 
Date:   Fri Jul 24 01:43:22 2015 +

gcc/testsuite/ChangeLog:

2015-07-23  Kugan Vivekanandarajah  

* gcc.target/arm/reg_equal_test.c: New test.

gcc/ChangeLog:

2015-07-23  Kugan Vivekanandarajah  

* config/arm/arm.c (arm_emit_movpair): Add REG_EQUAL notes to
instruction.

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 37461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37461=edit
patch for testing

I am testing the attached - using a RPO walk rather than a domwalk

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Mine.

[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3

[ienkovich at gcc dot gnu.org]

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

--- Comment #12 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Jan 25 12:48:54 2016
New Revision: 232792

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

PR target/69421
* tree-vect-stmts.c (vectorizable_condition): Check vectype
of operands is compatible with a statement vectype.

gcc/testsuite/

PR target/69421
* gcc.dg/pr69421.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69421.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/69466] ICE: Invalid PHI argument after vectorization (on -O2)

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
Created attachment 37459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37459=edit
Reproducer

[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|ICE: Invalid PHI argument   |[6 Regression] ICE: Invalid
   |after vectorization (on |PHI argument after
   |-O2)|vectorization (on -O2)

[Bug tree-optimization/69466] ICE: Invalid PHI argument after vectorization (on -O2)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-25
 CC||alalaw01 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r225311.

[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

Alexander Fomin  changed:

   What|Removed |Added

  Attachment #37037|0   |1
is obsolete||
 CC||afomin.mailbox at gmail dot com

--- Comment #13 from Alexander Fomin  ---
Created attachment 37460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37460=edit
Detailed RTL expand dumps

Ready.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It's in  now, so better to include both to be portable.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[matz at gcc dot gnu.org]

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

--- Comment #6 from Michael Matz  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Jakub Jelinek from comment #3)
> > That means we need #define USE_ALGORITHM before #include "system.h" in
> > genmodes.c with a comment.
> 
> But std::swap is used in many places. IMO, a configure check what to include
> would be the best solution here.

Indeed.  Starting with g++ 4.3 it's available from  (via stl_pair and
stl_move).  We really don't want to include  if at all possible.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[ysrumyan at gmail dot com]

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

Bug ID: 69467
   Summary: [6 Regression] Pattern X * C1 CMP 0 to X CMP 0 causes
performance drop on 32-bit x86.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

This is caused by the same revision as 67438
 http://gcc.gnu.org/viewcvs/gcc?view=revision=225248

The issue can be reproduced with attached test-case.
After such transformation applied to loop upper bound:
for ( count = ((*(ptr)) & 0xf) * 2; count > 0; count--, addr++ )
two redundant instructions are generated:
  after   before
movl48(%esp), %ebx movl48(%esp), %ecx
movzbl  (%ebx), %eax   movzbl  (%ecx), %edx   
andl$15, %eax  andl$15, %edx  
movzbl  %al, %ecx  addl%edx, %edx
addl%ecx, %ecx
testb   %al, %al
je  .L12   je  .L12

This can be essential if loop has low trip count.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #7 from Ulrich Weigand  ---
I see the same problem in my SPU daily build (running on a RHEL 5 system using
the gcc 4.1.2 host compiler).

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #7)
> Started with:
> Author: kugan 
> Date:   Fri Jul 24 01:43:22 2015 +
> 
> gcc/testsuite/ChangeLog:
> 
> 2015-07-23  Kugan Vivekanandarajah  
> 
> * gcc.target/arm/reg_equal_test.c: New test.
> 
> gcc/ChangeLog:
> 
> 2015-07-23  Kugan Vivekanandarajah  
> 
> * config/arm/arm.c (arm_emit_movpair): Add REG_EQUAL notes to
> instruction.

Which was revision r226135.

[Bug tree-optimization/65356] [meta-bug] Port tail-merge fixes to 4.9

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-cvs/2016-01/msg00780.html :

Author: vries
Date: Mon Jan 25 14:21:03 2016
New Revision: 232794

URL: https://gcc.gnu.org/viewcvs?rev=232794=gcc=rev
Log:
Backport "Fix PR64091"

2016-01-25  Tom de Vries  

backport from trunk:
2014-11-27  Richard Biener  

PR tree-optimization/PR64091
* tree-ssa-tail-merge.c (update_debug_stmt): After resetting
the stmt break from the loop over use operands.

* gcc.dg/torture/pr64091.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr64091.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-tail-merge.c

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

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 37462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37462=edit
test-case to reproduce

Need to compile with -m32 at -O2 or -O3 -funroll-loops options.
In description the assembly with -O3 -funroll-loops options was cited.

[Bug target/69475] New: [x32][6]: FTBFS: configure: error: cannot compute sizeof (long long)

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 69475
   Summary: [x32][6]: FTBFS: configure: error: cannot compute
sizeof (long long)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
  Target Milestone: ---
Target: x86_64-linux-gnux32

Hello!

gcc-6 fails to build from source on x86_64-linux-gnux32 (Debian) as apparently
the size of (long long) is not properly defined:

checking for long long... yes
checking size of long long... configure: error: in `/«PKGBUILDDIR»/build/gcc':
configure: error: cannot compute sizeof (long long)
See `config.log' for more details.
Makefile:4205: recipe for target 'configure-stage1-gcc' failed
make[4]: *** [configure-stage1-gcc] Error 77
make[4]: Leaving directory '/«PKGBUILDDIR»/build'
Makefile:24128: recipe for target 'stage1-bubble' failed
make[3]: *** [stage1-bubble] Error 2
make[3]: Leaving directory '/«PKGBUILDDIR»/build'
Makefile:24448: recipe for target 'bootstrap' failed
make[2]: *** [bootstrap] Error 2
make[2]: Leaving directory '/«PKGBUILDDIR»/build'
T Wed, 23 Dec 2015 01:56:18 +
s=`cat status`; rm -f status; \
if [ $s -ne 0 ] && [ -z "$NO_CONFIG_LOG_DUMP$NO_CONFIG_LOG_DUMPS" ]; then \
  for log in $(find /«PKGBUILDDIR»/build -name config.log); do \
case "$log" in */build/build-*|*/stage1-*|*/prev-*) continue; esac; \
echo LOGFILE START $log; \
cat $log; \
echo LOGFILE END $log; \

Full log available on buildd.debian.org [1]. So far, gcc-6 hasn't been built on
x32 because of this.

Cheers,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-6=x32=6-20151220-1=1450835798

[Bug other/69006] [6 Regression] Extraneous newline emitted between error messages in GCC 6

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
v2 patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01915.html

[Bug target/69475] [x32][6]: FTBFS: configure: error: cannot compute sizeof (long long)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Your bootstrap compiler is broken.

configure:5934: x86_64-linux-gnux32-g++-5 -std=gnu++98 -o conftest -g
conftest.cpp  >&5
/usr/bin/ld: cannot find /lib/x86_64-linux-gnux32/libmvec_nonshared.a
collect2: error: ld returned 1 exit status

[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 #7 from H.J. Lu  ---
Created attachment 37468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37468=edit
A patch

Here is a patch.  Ilya, can you take care of this?  Thanks.

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

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

--- Comment #3 from Steve Ellcey  ---
Here is a cutdown test case that I used to reproduce the problem.  I used the
'-mips32r2 -mips216 -Os -fstack-protector' options.

typedef struct s {
 unsigned long long d;
 long long t;
} p;

int sh(int x, unsigned char *buf)
{
 p *uhdr = (p *)buf;
 unsigned int i = 0;
 uhdr->d = ((uhdr->d & 0xff00LL) >> 56)
| ((uhdr->d & 0xff00LL) >> 24)
| ((uhdr->d & 0xff00LL) << 8)
| ((uhdr->d & 0x00ffLL) << 56);
 uhdr->t = ((uhdr->t & 0xff00LL) >> 56)
| ((uhdr->t & 0xff00LL) >> 24)
| ((uhdr->t & 0x00ffLL) >> 8)
| ((uhdr->t & 0xff00LL) << 8)
| ((uhdr->t & 0xff00LL) << 40)
| ((uhdr->t & 0x00ffLL) << 56);
 i += 4;
 if (x < i) return 0; else return 1;
}

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[janus at gcc dot gnu.org]

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

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #14)
> Would you be so good as to OK this patch to the list?

Sure, will do ...

[Bug tree-optimization/68398] [6 Regression] coremark regression due to r229685

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 25 19:19:09 2016
New Revision: 232802

URL: https://gcc.gnu.org/viewcvs?rev=232802=gcc=rev
Log:
PR tree-optimization/69196
PR tree-optimization/68398
* tree-ssa-threadupdate.h (enum bb_dom_status): Moved here from
tree-ssa-threadupdate.c.
(determine_bb_domination_status): Prototype
* tree-ssa-threadupdate.c (enum bb_dom_status): Remove
(determine_bb_domination_status): No longer static.
(valid_jump_thread_path): Remove code to detect characteristics
of the jump thread path not associated with correctness.
* tree-ssa-threadbackward.c (fsm_find_control_statment_thread_paths):
Correct test for thread path length.  Count PHIs for real operands as
statements that need to be copied.  Do not count ASSERT_EXPRs.
Look at all the blocks in the thread path.  Compute and selectively
filter thread paths based on threading through the latch, threading
a multiway branch or crossing a multiway branch.

PR tree-optimization/69196
PR tree-optimization/68398
* gcc.dg/tree-ssa/pr66752-3.c: Update expected output
* gcc.dg/tree-ssa/pr68198.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66752-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68198.c
trunk/gcc/tree-ssa-threadbackward.c
trunk/gcc/tree-ssa-threadupdate.c
trunk/gcc/tree-ssa-threadupdate.h

[Bug middle-end/68621] [6 Regression] FAIL: gcc.dg/tree-ssa/ifc-8.c scan-tree-dump-times ifcvt "Applying if-conversion" 1

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

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

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
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.

[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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Ilya Enkovich from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > I need additional -march=x86-64 to trigger this.
> > I'd say either we have to pessimistically assume what the STV pass might be
> > doing already during expansion, or the STV pass would need to perform parts
> > of what expand_stack_alignment is doing (basically check if what the STV
> > pass created causes any differences in decision during
> > expand_stack_alignment, and if yes, tweak things so that the end result
> > looks as if those decisions were done already during the expansion (STV is
> > pre-RA pass, so maybe it still could work), or maybe easiest fix is for now
> > disable TARGET_STV if preferred_stack_boundary is smaller than 4.
> 
> Looking into expand_stack_alignment I see we may need to allocate DRAP
> register and make  fixup_tail_calls call.  Isn't it too late for that? 
> Couldn't we make some optimizations basing on notes fixup_tail_calls
> invalidates?
> 
> I propose this change in STV gate:
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 34b57a4..fb11680 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3661,7 +3661,11 @@ public:
>/* opt_pass methods: */
>virtual bool gate (function *)
>  {
> -  return !TARGET_64BIT && TARGET_STV && TARGET_SSE2 && optimize > 1;
> +  return !TARGET_64BIT && TARGET_STV && TARGET_SSE2 && optimize > 1
> +   /* Check we don't need to allocate DRAP register for STV.  */
> +   && (crtl->drap_reg
> +   || !crtl->need_drap
> +   || INCOMING_STACK_BOUNDARY >= 128);
>  }
> 
>virtual unsigned int execute (function *)

Already during the expansion TARGET_STV makes quite a big difference, won't
just disabling the stv pass cause performance regression to -mno-stv?
Also, I'm surprised you are checking INCOMING_STACK_BOUNDARY, I'd have expected
|| ix86_preferred_stack_boundary >= 128
instead.

I had in mind either:

--- gcc/config/i386/i386.c.jj   2016-01-25 12:10:57.0 +0100
+++ gcc/config/i386/i386.c  2016-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).
Another alternative is if the STV pass changes anything and creates possible
need for aligned vector spills, create drap rtx during that pass.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
r232798 doesn't fix the bootstrap failure, but it makes including the C++11
version of  much less expensive, which is the problem that r232736
was addressing.

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

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

--- Comment #4 from Steve Ellcey  ---
Created attachment 37469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37469=edit
New patch

Here is an alternative patch.  The problem is that memory_operand matches any
legal MIPS memory reference and does not take the MIPS16 limitations (such as
illegal base registers) into account.

I will submit this new patch after running it through the GCC testsuite.

[Bug ipa/69216] ICE in ipa_merge_profiles

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to Benigno from comment #2)
> benigno@benigno-System-Product-Name:~$ gcc --version
> gcc (Ubuntu 5.2.1-23ubuntu1~15.10) 5.2.1 20151028
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> benigno@benigno-System-Product-Name:~$ g++ --version
> g++ (Ubuntu 5.2.1-23ubuntu1~15.10) 5.2.1 20151028
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> make profile-build ARCH=x86-64-modern
> 
> see Makefile from SugarR: SugarR: https://github.com/Zerbinati/SugarR

Hi.

The link should be probably:
(In reply to Benigno from comment #2)
> benigno@benigno-System-Product-Name:~$ gcc --version
> gcc (Ubuntu 5.2.1-23ubuntu1~15.10) 5.2.1 20151028
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> benigno@benigno-System-Product-Name:~$ g++ --version
> g++ (Ubuntu 5.2.1-23ubuntu1~15.10) 5.2.1 20151028
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> make profile-build ARCH=x86-64-modern
> 
> see Makefile from SugarR: SugarR: https://github.com/Zerbinati/SugarR

Hi.

The link should be probably:
https://github.com/Zerbinati/SugaR

Well, I've just tried to run:
$ make profile-build ARCH=x86-64-modern

for gcc --version:
gcc --version
gcc (SUSE Linux) 5.2.1 20151008 [gcc-5-branch revision 228597]

and:
gcc (GCC) 6.0.0 20160125 (experimental)

and both can build profiled LTO binary.

I had to apply following patch to be able to build the project:
diff --git a/srcS/opt.cpp b/srcS/opt.cpp
index d581b7d..6f7a223 100644
--- a/srcS/opt.cpp
+++ b/srcS/opt.cpp
@@ -17,6 +17,7 @@
 */

 #include 
+#include 

 #include "thread.h"
 #include "tt.h"
@@ -26,8 +27,8 @@ using namespace std;
 #define TRUE 1
 #define FALSE 0

-#define MEMALIGN(a, b, c) a = _aligned_malloc (c, b) 
-#define ALIGNED_FREE(x) _aligned_free (x)
+#define MEMALIGN(a, b, c) a = aligned_alloc (c, b)
+#define ALIGNED_FREE(x) free (x)

 int large_use;

@@ -84,10 +85,10 @@ void FREE_MEM(void* A)
large_use=FALSE;
 }

-void SETUP_PRIVILEGES(){}
-
 #else

+void SETUP_PRIVILEGES(){}
+
 void CREATE_MEM(void** A,int align,uint64_t size)
 {
large_use=FALSE;

Martin

[Bug c++/65189] [4.9/5/6 Regression] --fdump-translation-unit is broken for virtual dtors

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #2)
> I suspect the handling of dtors happens now after the dump happens.

It happens before that actually, finish_vtbls which in turn eventually calls
build_vtbl_initializer is called before dump_class_hierarchy, but the latter
that dumps this seems to be looking at the vtables, so reports what it finds
there.  If the current behavior is undesirable, then not sure if it is possible
to figure out for which vtable entries build_vtbl_initializer has performed
this and pretend the original values are stored in there instead.

[Bug fortran/69455] [5/6 Regression] Assembler error(s) when using intrinsic modules in two BLOCK

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> (In reply to Dominique d'Humieres from comment #5)
> > The problem is gone if I revert revision r229540.
> 
> A casual perusal on sym in gdb shows that the construction
> of the intrinsic modules is incorrect.  For the code in
> comment #1, 
> 
> (gdb) p *sym
> $2 = {name = 0x2039bf000 "ik", module = 0x2039a3a30 "iso_fortran_env", 
>   declared_at = {nextc = 0x203629e2c, lb = 0x203629dc0}, ts = {
> type = BT_INTEGER, kind = 4, u = {derived = 0x0, cl = 0x0, pad = 0}, 
> interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, 
> deferred = false}, attr = {allocatable = 0, dimension = 0, 
> codimension = 0, external = 0, intrinsic = 0, optional = 0, pointer = 0, 
> target = 0, value = 0, volatile_ = 0, temporary = 0, dummy = 0, 
> result = 0, assign = 0, threadprivate = 0, not_always_present = 0, 
> implied_index = 0, subref_array_pointer = 0, proc_pointer = 0, 
> asynchronous = 0, contiguous = 0, fe_temp = 0, class_pointer = 0, 
> save = SAVE_NONE, data = 0, is_protected = 0, use_assoc = 1, 
> used_in_submodule = 0, use_only = 0, use_rename = 0, imported = 0, 
> 
> Notice name is 'ik', but neither use_only nor use_rename is set.
> 
> Revision 229540 isn't the problem.

A two line patch (or one rather long line) is sufficient to work
around the brokeness of the intrinsics modules.

[Bug target/68753] PowerPC: double precision reciprocal estimate missed optimisations

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Bill Schmidt  ---
Discussed offline and agreed that there is no compelling performance argument
for this change.  Closing as WONTFIX.

[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 #10 from Jakub Jelinek  ---
Created attachment 37467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37467=edit
gcc6-pr69442.patch

Untested fix.  Seems the above mentioned commit newly defined REG_EQUAL for
ZERO_EXTRACT lhs, but has adjusted just CSE and not other places for it.
As can be seen in the fix, we also need to adjust the combiner, and I wonder if
e.g. the RA or other places don't need adjustments too.

[Bug target/69469] New: test case gcc.target/powerpc/vsx-vector-2.c fails on power starting with r232632

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 69469
   Summary: test case gcc.target/powerpc/vsx-vector-2.c fails on
power starting with r232632
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on both BE and LE.

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/vsx-vector-2.c  
-fno-diagnostics-show-caret -fdiagnostics-color=never  -O2 -ftree-vectorize
-mcpu=power7 -ffast-math -ffat-lto-objects -S   -o vsx-vector-2.s(timeout =
300)
spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/vsx-vector-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize
-mcpu=power7 -ffast-math -ffat-lto-objects -S -o vsx-vector-2.s
PASS: gcc.target/powerpc/vsx-vector-2.c (test for excess errors)
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvaddsp
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvsubsp
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvmulsp
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvdivsp
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler vmadd
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvmsub
FAIL: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvsqrtsp
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvcpsgnsp
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvrspim
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvrspip
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvrspiz
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvrspic
PASS: gcc.target/powerpc/vsx-vector-2.c scan-assembler xvrspi 

The differences in the output are significant:

seurer@genoa:~/gcc/build/gcc-test3$ diff vsx-vector-2.s.r232631 
vsx-vector-2.s.r232632
. . .
242a243
>   xxlxor 11,11,11
245,246c246
<   ld 10,.LC22@toc@l(9)
<   li 9,0
---
>   addi 9,9,.LC22@toc@l
248c248,252
<   .p2align 5,,31
---
>   lxvd2x 10,0,9
>   addis 9,2,.LC23@toc@ha
>   ld 10,.LC23@toc@l(9)
>   li 9,0
>   .p2align 4,,15
251c255,261
<   xvsqrtsp 0,0
---
>   xvrsqrtesp 12,0
>   xvcmpgtsp 9,0,11
>   xxsel 12,11,12,9
>   xvmulsp 0,12,0
>   xvmulsp 12,12,10
>   xvnmsubmsp 12,0,10
>   xvmaddasp 0,0,12

Those are in the vector_sqrt function.


r232632 | dje | 2016-01-20 13:39:08 -0600 (Wed, 20 Jan 2016) | 6 lines

PR target/68609
* config/rs6000/rs6000.c (rs6000_emit_swsqrt): Add vector sqrt
domain check.
* config/rs6000/vector.md (sqrt2): Call rs6000_emit_swsqrt
for V4SFmode.

[Bug lto/69408] LD crashes with LTO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to night_ghost from comment #2)
> there are reqirements for reporting *language* bugs but no LTO bugs in
> https://gcc.gnu.org/bugs.html
> 
> I can ZIP build tree but I saw a list of all that i can send in the "we do
> not want". Crash occurs on final linking so I can't give the refined test
> case. But crash always comes.

Hi.

I know that it's harder to provide a reproducer, however I can try to reproduce
the problem on machine. That would require providing steps that one needs to
clone and build the project. As I've seen the project, you probably use a
cross-compiler for AVR?

Martin

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

[ysrumyan at gmail dot com]

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

--- Comment #3 from Yuri Rumyantsev  ---
Richard,

I checked that performance is back with your patch.

Thanks.

2016-01-25 17:50 GMT+03:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69467
>
> Richard Biener  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |ASSIGNED
>Last reconfirmed||2016-01-25
>Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
> gnu.org
>Target Milestone|--- |6.0
>  Ever confirmed|0   |1
>
> --- Comment #2 from Richard Biener  ---
> To restore the state before the move from fold to match.pd we'd need to mark
> any such pattern involving compares as the outermost expr (and thus match
> on GIMPLE_CONDs) with an explicit && single_use () check.  Fix for this one:
>
> Index: gcc/match.pd
> ===
> --- gcc/match.pd(revision 232792)
> +++ gcc/match.pd(working copy)
> @@ -1821,12 +1821,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (for cmp (simple_comparison)
>   scmp (swapped_simple_comparison)
>   (simplify
> -  (cmp (mult @0 INTEGER_CST@1) integer_zerop@2)
> +  (cmp (mult@3 @0 INTEGER_CST@1) integer_zerop@2)
>/* Handle unfolded multiplication by zero.  */
>(if (integer_zerop (@1))
> (cmp @1 @2)
> (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
> -   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
> +   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
> +   && single_use (@3))
>  /* If @1 is negative we swap the sense of the comparison.  */
>  (if (tree_int_cst_sgn (@1) < 0)
>   (scmp @0 @2)
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Michael Matz from comment #8)
> Please try https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01875.html
> if possible.

Thanks, will do tomorrow morning (CET).

[Bug fortran/61831] [4.9 Regression] runtime error: pointer being freed was not allocated

[bergner at gcc dot gnu.org]

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

--- Comment #63 from Peter Bergner  ---
Author: bergner
Date: Mon Jan 25 16:51:20 2016
New Revision: 232799

URL: https://gcc.gnu.org/viewcvs?rev=232799=gcc=rev
Log:
PR fortran/61831
* gfortran.dg/derived_constructor_comps_6.f90: Add missing } to fix
up dg-additional-options.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
   
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||astralien3000 at yahoo dot fr

--- Comment #1 from Georg-Johann Lay  ---
*** Bug 68199 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=69347 |

--- Comment #10 from Jeffrey A. Law  ---
Scratch that, I meant 68398.

[Bug c++/69327] [6 Regression] constexpr leaves reference member var uninitialized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[abel at gcc dot gnu.org]

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

--- Comment #6 from Andrey Belevantsev  ---
I've debugged it on gcc-5.1.0 since the picture on trunk is different.  Thanks
Jakub for great explanations, it was not easy to get to the root problem.

We speculate an insn (the load in your listing) but we do not make a check for
it though we should.  The thing that broke this was the fix for PR 45472.  In
that pr, we have moved a volatile insn too far up because we failed to merge
the bits describing its volatility when we have processed a control flow split.
 The code to propagate the insn pattern with the insn merging was added when
the volatility of the two insns from the both split branches differ.  However,
the volatility of the speculated insn and its original differ: the original
insn may trap while the speculated version may not.  Thus, we replace a
speculative pattern with the original one per the PR 45472 fix for no reason.

The attached patch for this problem just limits the original fix for pr 45472
to apply for non-speculative insns only.  Jakub, can you check it on your code?
 The patch should apply to both gcc 5 and gcc 6, so you can use whichever is
more convenient for you.

[Bug target/68199] avr-gcc rise a warning when defining a custom interruption

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Georg-Johann Lay  ---
Cf. PR67353

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

[Bug target/28314] cpp: x86/powerpc inconsistency for the __linux macro

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Bill Schmidt  ---
I discussed with the OP and he no longer is concerned about it, so we might as
well get this one off of our books, even though it's kind of a stupid bug.

[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[abel at gcc dot gnu.org]

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

--- Comment #5 from Andrey Belevantsev  ---
Created attachment 37464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37464=edit
patch for gcc trunk (applies to gcc-5 too)

[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM

[tyrel at kulshanconcepts dot com]

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

--- Comment #14 from Tyrel Haveman  ---
Is there a flag I can add to `configure` or anything else I might be able to do
to work around this issue so that I can get my builds going? Not being able to
build GCC is blocking a lot of other work here.

Thanks!

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

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to H.J. Lu from comment #5)
> wide-int.h has

>   if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
> ^^^
> 
> This is miscompiled due to PR 65656.
> 

We hit this via:

Breakpoint 1, wi::lrshift >,
generic_wide_int > > (x=..., y=...)
at /export/gnu/import/git/sources/gcc-release/gcc/wide-int.h:2898
2898  val[0] = xi.to_uhwi () >> shift;
(gdb) bt
#0  wi::lrshift >,
generic_wide_int > > (x=..., y=...)
at /export/gnu/import/git/sources/gcc-release/gcc/wide-int.h:2898
#1  0x009e7bbe in
wi::rshift >,
generic_wide_int > > (sgn=, 
y=..., x=...)
at /export/gnu/import/git/sources/gcc-release/gcc/wide-int.h:2947
#2  bit_value_binop_1 (code=code@entry=RSHIFT_EXPR, 
type=type@entry=0x7fffefe82dc8, val=val@entry=0x7fffd7c0, 
mask=mask@entry=0x7fffd790, r1type=0x7fffefe82dc8, r1val=..., 
r1mask=..., r2type=0x7fffefd6b690, r2val=..., r2mask=...)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:1348
#3  0x009e9e7b in bit_value_binop (code=code@entry=RSHIFT_EXPR, 
type=0x7fffefe82dc8, rhs1=rhs1@entry=0x7fffefd71708, rhs2=)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:1549
#4  0x009eb520 in evaluate_stmt (stmt=stmt@entry=0x7fffefe9a160)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:1785
#5  0x009ec8d2 in visit_assignment (stmt=stmt@entry=0x7fffefe9a160, 
output_p=output_p@entry=0x7fffdba0)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2258
#6  0x009ec9c2 in ccp_visit_stmt (stmt=0x7fffefe9a160, 
taken_edge_p=0x7fffdba8, output_p=0x7fffdba0)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2336
---Type  to continue, or q  to quit---
#7  0x00a4efcf in simulate_stmt (stmt=stmt@entry=0x7fffefe9a160)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-propagate.c:348
#8  0x00a50f79 in simulate_block (block=)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-propagate.c:471
#9  ssa_propagate (
visit_stmt=visit_stmt@entry=0x9ec937 , visit_phi=visit_phi@entry=0x9e6aa5 )
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-propagate.c:888
#10 0x009e6295 in do_ssa_ccp ()
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2382
#11 (anonymous namespace)::pass_ccp::execute (this=)
at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2415
#12 0x0089ca0c in execute_one_pass (pass=pass@entry=0x19b4bf0)
at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2330
#13 0x0089cd62 in execute_pass_list_1 (pass=0x19b4bf0)
at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2382
#14 0x0089cd7f in execute_pass_list_1 (pass=0x19b4a70, 
pass@entry=0x19b48f0)
at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2383
#15 0x0089cd9c in execute_pass_list (fn=0x7fffefe98000, pass=0x19b48f0)
at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2393
#16 0x0089ba57 in do_per_function_toporder (
callback=callback@entry=0x89cd83 ,
---Type  to continue, or q  to quit---
data=0x19b48f0) at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:1728
#17 0x0089d3e3 in execute_ipa_pass_list (pass=0x19b4890)
at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2736
#18 0x0066f3ac in ipa_passes ()
at /export/gnu/import/git/sources/gcc-release/gcc/cgraphunit.c:2172
#19 symbol_table::compile (this=this@entry=0x7fffefd6b000)
at /export/gnu/import/git/sources/gcc-release/gcc/cgraphunit.c:2313
#20 0x00670be5 in symbol_table::finalize_compilation_unit (
this=0x7fffefd6b000)
at /export/gnu/import/git/sources/gcc-release/gcc/cgraphunit.c:2462
#21 0x0058ea41 in c_write_global_declarations ()
at /export/gnu/import/git/sources/gcc-release/gcc/c/c-decl.c:10822
#22 0x00939509 in compile_file ()
at /export/gnu/import/git/sources/gcc-release/gcc/toplev.c:613
#23 0x0093b3c4 in do_compile ()
at /export/gnu/import/git/sources/gcc-release/gcc/toplev.c:2067
#24 toplev::main (this=this@entry=0x7fffdf60, argc=argc@entry=15, 
argv=argv@entry=0x7fffe068)
at /export/gnu/import/git/sources/gcc-release/gcc/toplev.c:2165
#25 0x00f50ab7 in main (argc=15, argv=0x7fffe068)
at /export/gnu/import/git/sources/gcc-release/gcc/main.c:39
(gdb) p x
$2 = (const 

[Bug fortran/66707] Endless compilation on wrong usage of common

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> > Confirmed with 4.9.3 and 5.2. This seems to have been fixed on trunk between
> > revision r226476 (2015-08-02, endless compilation) and r227016 (2015-08-19,
> > tests compiled in a fraction of second).
>
> Can someone confirms that the tests compile on recent trunk (post r227016)?
> A finer range would be nice too!

Back porting r226732 to the gcc5 branch "fixes" the issue.

[Bug bootstrap/60743] build/genautomata uses 700 MB memory for ARM

[dave.anglin at bell dot net]

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

--- Comment #15 from dave.anglin at bell dot net ---
On 2016-01-25 11:18 AM, tyrel at kulshanconcepts dot com wrote:
> Is there a flag I can add to `configure` or anything else I might be able to 
> do
> to work around this issue so that I can get my builds going? Not being able to
> build GCC is blocking a lot of other work here.
You should be able to build on a system with limited memory if you can 
add swap storage.

[Bug bootstrap/69464] [6 Regression]: bootstrap failure on CentOS 5.11: error: ‘swap’ is not a member of ‘std’

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 25 16:44:30 2016
New Revision: 232798

URL: https://gcc.gnu.org/viewcvs?rev=232798=gcc=rev
Log:
Avoid including all of  in 

PR libstdc++/69464
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/random.h (uniform_int_distribution): Move to
bits/uniform_int_dist.h.
* include/bits/random.tcc (uniform_int_distribution::operator(),
uniform_int_distribution::__generate_impl): Likewise.
* include/bits/uniform_int_dist.h: New header.
* include/bits/stl_algo.h [__cplusplus >= 201103L]: Include
 instead of .
* testsuite/20_util/specialized_algorithms/uninitialized_copy/
move_iterators/1.cc: Include correct header for uninitialized_copy.
* testsuite/20_util/specialized_algorithms/uninitialized_copy_n/
move_iterators/1.cc: Likewise.
* testsuite/25_algorithms/nth_element/58800.cc: Include correct
header for vector.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lines.

Added:
trunk/libstdc++-v3/include/bits/uniform_int_dist.h
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc
trunk/libstdc++-v3/include/bits/stl_algo.h
   
trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/move_iterators/1.cc
   
trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy_n/move_iterators/1.cc
trunk/libstdc++-v3/testsuite/25_algorithms/nth_element/58800.cc
trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc

[Bug fortran/69455] [5/6 Regression] Assembler error(s) when using intrinsic modules in two BLOCK

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> The problem is gone if I revert revision r229540.

A casual perusal on sym in gdb shows that the construction
of the intrinsic modules is incorrect.  For the code in
comment #1, 

(gdb) p *sym
$2 = {name = 0x2039bf000 "ik", module = 0x2039a3a30 "iso_fortran_env", 
  declared_at = {nextc = 0x203629e2c, lb = 0x203629dc0}, ts = {
type = BT_INTEGER, kind = 4, u = {derived = 0x0, cl = 0x0, pad = 0}, 
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, 
deferred = false}, attr = {allocatable = 0, dimension = 0, 
codimension = 0, external = 0, intrinsic = 0, optional = 0, pointer = 0, 
target = 0, value = 0, volatile_ = 0, temporary = 0, dummy = 0, 
result = 0, assign = 0, threadprivate = 0, not_always_present = 0, 
implied_index = 0, subref_array_pointer = 0, proc_pointer = 0, 
asynchronous = 0, contiguous = 0, fe_temp = 0, class_pointer = 0, 
save = SAVE_NONE, data = 0, is_protected = 0, use_assoc = 1, 
used_in_submodule = 0, use_only = 0, use_rename = 0, imported = 0, 

Notice name is 'ik', but neither use_only nor use_rename is set.

Revision 229540 isn't the problem.

[Bug target/28314] cpp: x86/powerpc inconsistency for the __linux macro

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #4 from Vincent Lefèvre  ---
I don't know what the discussion was. Anyway, neither __linux nor __linux__ is
mentioned in the GCC manual (at least for the recent versions), so that I
assume that the developers should not rely on it.

[Bug target/69469] test case gcc.target/powerpc/vsx-vector-2.c fails on power starting with r232632

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #2 from David Edelsohn  ---
Fixed testcase.

[Bug target/69469] test case gcc.target/powerpc/vsx-vector-2.c fails on power starting with r232632

[dje at gcc dot gnu.org]

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

--- Comment #1 from David Edelsohn  ---
Author: dje
Date: Mon Jan 25 16:16:21 2016
New Revision: 232796

URL: https://gcc.gnu.org/viewcvs?rev=232796=gcc=rev
Log:
PR target/69469
* gcc.target/powerpc/vsx-vector-2.c: Adjust for Goldschmidt's
Algorithm.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/vsx-vector-2.c

[Bug other/67373] Can't compile gcc snapshot for avr target with mingw

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Keywords||build
   Last reconfirmed||2016-01-25
  Component|bootstrap   |other
 CC||gjl at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/69455] [5/6 Regression] Assembler error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Revision 229540 isn't the problem.

At least it exposes the problem.

[Bug c++/69470] New: [concepts] bogus constrained member class template redeclared with different access

[lucdanton at free dot fr]

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

Bug ID: 69470
   Summary: [concepts] bogus constrained member class template
redeclared with different access
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

Using 6.0.0 20160122, testcase compiled with:
g++-trunk -std=c++1z main.cpp

results in:

main.cpp:13:5: error: 'struct foo<0, T>' redeclared with different access

Full testcase:

struct enclosing {
private:
template
struct foo {};

template
requires false
struct foo<0, T> {};

template
requires true
// error: 'struct foo<0, T>' redeclared with different access
struct foo<0, T> {};
};

int main()
{
}

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||easyhack
   Target Milestone|6.0 |---

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

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01780.html

[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

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Just a random thought, if the expander can figure out that
u64_1 / 0xffe7ULL
is in the range of [0, 1] and expand the division as
(u64_1 >= 0xffe7ULL),
why the expansion of
u64_1 % 0xffe7ULL
still performs the multiplication, i.e.
u64_1 - (u64_1 >= 0xffe7ULL) * 0xffe7ULL
?  Wouldn't it be usually better to do:
res = u64_1;
if (u64_1 >= 0xffe7ULL) res -= 0xffe7ULL;
?  Stage1 material of course.

[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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #6 from H.J. Lu  ---
The STV pass should check decisions made by expand_stack_alignment
and make sure that they are still valid after the STV pass.

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #8 from Abe  ---
Slightly more reduced [2 bytes less? ;-)]...

__attribute__((noreturn))void V(int);
struct R{R(const R&){}};
R f(){V(0);}
R c(){V(0);}



This might be the most-reduced-possible form of this test case. 
Experimentation shows that:

  * removing the second function definition removes the ICE
  * removing the user-defined copy ctor removes the ICE
  * removing the int param. from 'V'removes the ICE

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

[wavexx at thregr dot org]

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

Bug ID: 69471
   Summary: "-march=native" unintentionally breaks further
-march/-mtune flags
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wavexx at thregr dot org
  Target Milestone: ---

On a haswell host, the following:

gcc -march=native -march=opteron

or

gcc -march=opteron -march=native

both emit code which is illegal for the opteron ISA.
Specifying -march=opteron alone works as intended.

By running gcc -v I see:

% g++ -MD -D_FILE_OFFSET_BITS=64 -O3 -march=native -pipe
-fvisibility-inlines-hidden -O3 -pipe -march=opteron -mtune=generic -ggdb3
-std=gnu++11 -Wall -Wextra -Wpedantic -Wno-unused-parameter -c -o metasplit.o
metasplit.cc -v 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6-20160117-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.0.0 20160117 (experimental) [trunk revision 232481] (Debian
6-20160117-1) 
COLLECT_GCC_OPTIONS='-MD' '-D' '_FILE_OFFSET_BITS=64' '-O3' '-march=native'
'-pipe' '-fvisibility-inlines-hidden' '-O3' '-pipe' '-march=opteron'
'-mtune=generic' '-ggdb3' '-std=gnu++11' '-Wall' '-Wextra' '-Wpedantic'
'-Wno-unused-parameter' '-c' '-o' 'metasplit.o' '-v' '-shared-libgcc'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-MD metasplit.d -MQ metasplit.o -dD -D_GNU_SOURCE -D _FILE_OFFSET_BITS=64
metasplit.cc -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3
-mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2
-msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx -mno-clzero -mno-pku -quiet
-dumpbase metasplit.cc -march=opteron -mtune=generic -auxbase-strip metasplit.o
-ggdb3 -O3 -O3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -std=gnu++11
-version -fvisibility-inlines-hidden -o - |
 as -v --64 -o metasplit.o

It becomes obvious why is that: -march=native gets expanded to all
host-specific instructions, while the next -march=opteron doesn't reset them.

Since I generally override the default flags in makefiles by appending
exceptions where needed, I expect the regular behavior where the last flags
overrides previous ones and thus found the current behavior unexpected.

I originally discovered this problem in gcc 5.2, but it's still present in all
further versions.

[Bug target/28366] Divide with vectors cause extra stores (and more stack space) (with VMX)

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
What I meant by suboptimal is the eight vector stores when it seems that just
two instructions are needed to save the two vector registers that hold the
arguments like Clang does:

addi 3, 1, -48
addi 4, 1, -64
stvx 3, 0, 3
stvx 2, 0, 4
addi 3, 1, -32
nop
lfs 0, -36(1)
lfs 1, -52(1)
lfs 2, -40(1)
lfs 3, -56(1)
lfs 4, -44(1)
lfs 5, -60(1)
lfs 12, -48(1)
lfs 6, -64(1)
fdivs 0, 1, 0
fdivs 2, 3, 2
fdivs 13, 5, 4
fdivs 1, 6, 12
stfs 0, -20(1)
stfs 2, -24(1)
stfs 13, -28(1)
stfs 1, -32(1)
nop
lvx 2, 0, 3
blr
.long   0
.quad   0

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem

[paul.richard.thomas at gmail dot com]

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

--- Comment #14 from paul.richard.thomas at gmail dot com  ---
Hi Janus,

Would you be so good as to OK this patch to the list?

Thanks

Paul

On 22 January 2016 at 12:50, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385
>
> --- Comment #13 from janus at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #11)
>> Changing the entire block to:
>>  [...]
>> fixes Martin's problem and makes the following work correctly:
>
> It also cures my problem, i.e. comment 5. Thanks a lot for the fix!
>
>
>> For some reason that I cannot for the life of me understand, my svn+ssh
>> connection from my laptop is failing because of some problem with my public
>> keys.
>
> I recently got an email from the sourceware admins which said they are
> currently scanning the ssh keys for continued compatibility. Possibly you need
> to generate a new key (in case yours is too weak). Mine is apparently still
> working, luckily.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

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

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Some discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg0.html

However ...

(In reply to wavexx from comment #0)
> Since I generally override the default flags in makefiles by appending
> exceptions where needed, I expect the regular behavior where the last flags
> overrides previous ones and thus found the current behavior unexpected.

Why would either you or the makefile add something like -march=opteron on a
haswell host?

Surely the makefile should only add option that make sense, and you should only
override them with options that make sense.

[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 #2 from wavexx at thregr dot org ---
On 25/01/16 18:38, redi at gcc dot gnu.org wrote:
> Why would either you or the makefile add something like -march=opteron on a
> haswell host?
> 
> Surely the makefile should only add option that make sense, and you should 
> only
> override them with options that make sense.

I generally use -march=native for most of my in-house projects.

However, on very few binaries part of a larger project I actually target
some older ISAs so I simply append -march=[x] as an exception with the
usual CFLAGS += 

I could also (as I'm currently doing) splice -march out of CFLAGS and/or
override CFLAGS in the required rules, so it's not a huge deal (as
outlined in the original discussion), but even if documented, I would
find the current behavior unexpected.

I would have expected -march=native to simply expand to -march=haswell
so that I could override it normally as I do for almost everything else.