[Bug rtl-optimization/19705] -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2006-03-05 03:12:14 |2016-1-27
 CC||msebor at gcc dot gnu.org
Summary|Cannot turn off doloop  |-fno-branch-count-reg
   |optimization via|doesn't prevent decrement
   |-fno-branch-count-reg if|and branch instructions on
   |-fno-ivopts is also |a count register
   |supplied|
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
I spent a bit of time looking at this today (more than I should have).

Based on the comments and based on my own testing and debugging, the Summary of
this bug isn't correct: the -fno-branch-count-reg option does disable the
doloop optimization (even when -fno-ivopts).  What's not correct is the
description of the effects of the option in the manual:

Do not use "decrement and branch" instructions on a count register, but instead
generate a sequence of instructions that decrement a register, compare it
against zero, then branch based upon the result.

I've adjusted the Summary to reflect that.

That said, I'm not sure what would be a meaningful update to the documentation.
 Saying that the -fno-branch-count-reg option may not actually do what its name
implies it's meant to do because there's some other pass that might do the
opposite doesn't seem very helpful.

FWIW, I was curious to know what pass is responsible for inserting the bdnz
instruction.  It seems that it's the combine pass and only in 32-bits.  That's
the first pass where I see the ctrsi_internal1 pattern introduced for the test
case.  (powerpc64 doesn't emit bdnz when -fno-branch-count-reg is used, at
least not for the test case.)

Anyway, with this background my opinion, for whatever it's worth, is that if
the purpose of the -fno-branch-count-reg option is to let users (as opposed to
GCC developers) control the kind of code that GCC emits then this seems like a
bug in the compiler that should be fixed by changing it to avoid emitting the
ctr_internal* patterns.  Otherwise, if its purpose is to let GCC
developers control whether or not the doloop pass runs, then that's how the
option should be documented.  (I do realize that despite what the manual
suggests these options are primarily used for debugging GCC so perhaps the
second alternative is the way to go.)

[Bug fortran/69520] Implement reversal of -fcheck options

[anlauf at gmx dot de]

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

--- Comment #1 from Harald Anlauf  ---
The patch in comment #0 regtests ok on i686-pc-linux-gnu.

Possible ChangeLog entry:

2016-01-27  ...

PR fortran/69520
* options.c: Enhance -fcheck by reversal of specifications.
* invoke.texi: Document enhancement of -fcheck.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #12)
> At revision 232901, this testcase still ICEs on i686 (or x86_64 with -m32)
> on Fedora 23:
> 
> Running target unix/-m32
> FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
> FAIL: gcc.dg/graphite/id-pr45230-1.c (test for excess errors)

Also seen in [1].

[1] https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02668.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

--- Comment #15 from Richard Henderson  ---
Author: rth
Date: Wed Jan 27 22:08:02 2016
New Revision: 232905

URL: https://gcc.gnu.org/viewcvs?rev=232905=gcc=rev
Log:
PR rtl-opt/69447

  * lra-remat.c (subreg_regs): New.
  (dump_candidates_and_remat_bb_data): Dump it.
  (operand_to_remat): Reject if operand in subreg_regs.
  (set_bb_regs): Collect subreg_regs.
  (lra_remat): Init and free subreg_regs.  Compute
  calculate_local_reg_remat_bb_data before create_cands.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr69447.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-remat.c
trunk/gcc/testsuite/ChangeLog

[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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Richard Henderson  ---
Fixed.

[Bug rtl-optimization/69447] [5 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|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[5/6 Regression] wrong code |[5 Regression] wrong code
   |with -O2|with -O2
   |-fno-schedule-insns and |-fno-schedule-insns and
   |mixed 8/16/32/64bit |mixed 8/16/32/64bit
   |arithmetics @ armv7a|arithmetics @ armv7a

--- Comment #18 from Richard Henderson  ---
Of course it should.  Overeager close.

[Bug target/5372] [powerpc-*-eabi] -mno-eabi not working

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
The PowerPC EABI document itself does not say anything about __eabi
or process startup (it even says there are no requirements).

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|powerpc-*-*, arm*-*-*   |powerpc-*-*, arm*-*-*,
   ||i?86-*-*
 CC||ubizjak at gmail dot com

--- Comment #12 from Uroš Bizjak  ---
At revision 232901, this testcase still ICEs on i686 (or x86_64 with -m32) on
Fedora 23:

Running target unix/-m32
FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
FAIL: gcc.dg/graphite/id-pr45230-1.c (test for excess errors)

Executing on host: /ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c  -m32   
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/ 
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt 
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs 
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/ 
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap 
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -fgraphite-identity
-ffast-math -S -o id-pr45230-1.s(timeout = 300)
spawn -ignore SIGHUP /ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -m32
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fgraphite-identity
-ffast-math -S -o id-pr45230-1.s
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In
function 'main':
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1:
internal compiler error: Segmentation fault
0xb2a58f crash_signal
/home/uros/gcc-svn/trunk/gcc/toplev.c:335
0x11cd064 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1652
0x11cd0cf translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1662
0x11cd0cf translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1662
0x11cd0cf translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1662
0x11ce727 translate_isl_ast_to_gimple::rename_all_uses(tree_node*,
basic_block_def*, basic_block_def*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1814
0x11ce900 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, basic_block_def*, basic_block_def*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1871
0x11d0f5f translate_isl_ast_to_gimple::rename_uses(gimple*,
gimple_stmt_iterator*, basic_block_def*, loop*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1981
0x11d27f7
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:2861
0x11d2c66
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:3077
0x11d3367
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1172
0x11d36d9 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:922
0x11d391c translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1090
0x11d3ae5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,

[Bug fortran/69520] Implement reversal of -fcheck options

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
Harald, if you have commits rights or are interested in getting such, let me
know and we can let you take this one. (Otherwise I will do so)

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

[zsojka at seznam dot cz]

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

--- Comment #17 from Zdenek Sojka  ---
(In reply to Richard Henderson from comment #16)
> Fixed.

This patch is not going to the 5-branch?

[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

--- Comment #3 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Jan 27 22:32:52 2016
New Revision: 232906

URL: https://gcc.gnu.org/viewcvs?rev=232906=gcc=rev
Log:
2016-01-27  Janus Weil  

PR fortran/69484
* invoke.texi: Fix documentation of -Wall with respect to -Wtabs.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/invoke.texi

[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Segher Boessenkool  ---
I think a long time ago (early 4.x era?) something went in to always
prefer integer registers for copying.  With the following testcase,
the only floating point use is for the structs with doubles.  (-m32
-mcpu=603 or similar).  Closing as fixed.

===
long long a, b;
struct { int x[2]; } sa, sb;
struct { char x[8]; } ta, tb;
struct { int x; int y; } ua, ub;
struct { float x; float y; } va, vb;
struct { double x; } wa, wb;
struct { double x[1]; } xa, xb;

void f(void)
{
a = b;
sa = sb;
ta = tb;
ua = ub;
va = vb;
wa = wb;
xa = xb;
}
===

[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

[amodra at gmail dot com]

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

--- Comment #10 from Alan Modra  ---
I guess rs6000 needs to implement targetm.override_options_after_change() if
we're to keep flag_pic and TARGET_RELOCATABLE consistent.

[Bug target/18154] Inefficient max/min code for PowerPC

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target|powerpc-*-* |powerpc*-*-*
 Status|NEW |WAITING
   Last reconfirmed|2006-10-22 23:16:26 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #7 from Martin Sebor  ---
Current trunk as well as all supported GCC versions before it still emits the
same code (see below).  XLC 12 on gcc111.fsffrance.org also emits a branch (see
below).  Ditto for Clang.

David, in light of this and in light of comments #4 and #5, do you still
believe that GCC should change as you suggested in the Description?

.min:   # 0x (H.10.NO_SYMBOL)
cmp0,r3,r4
bc BO_IF,CR0_LT,__L10
oril   r3,r4,0x
bcrBO_ALWAYS,CR0_LT
__L10:  # 0x0010 (H.10.NO_SYMBOL+0x10)
bcrBO_ALWAYS,CR0_LT


$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S
-Wall -Wextra -Wpedantic -o/dev/stdout ~/tmp/t.c
int min(int a, int b) {
  if (a < b)
return a;
  else
return b;
}
.file   "t.c"
.machine power8
.abiversion 2
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl min
.type   min, @function
min:
cmpw 7,3,4
ble 7,.L2
mr 3,4
.L2:
extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   min,.-min
.ident  "GCC: (GNU) 6.0.0 20160125 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug c++/24208] C++ front-end can still be sped up

[ppalka at gcc dot gnu.org]

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

--- Comment #9 from Patrick Palka  ---
Author: ppalka
Date: Thu Jan 28 01:06:29 2016
New Revision: 232912

URL: https://gcc.gnu.org/viewcvs?rev=232912=gcc=rev
Log:
Low-hanging C++-lexer speedup (PR c++/24208)

gcc/cp/ChangeLog:

PR c++/24208
* parser.c (LEXER_DEBUGGING_ENABLED_P): New macro.
(cp_lexer_debugging_p): Use it.
(cp_lexer_start_debugging): Likewise.
(cp_lexer_stop_debugging): Likewise.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/22238] Awful error messages with virtual functions

[dmalcolm at gcc dot gnu.org]

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

--- Comment #22 from David Malcolm  ---
(In reply to Manuel López-Ibáñez from comment #20)
[...]
> I maintain my opinion that any user-facing diagnostic using %qE is
> potentially broken.

Thanks; I'm inclined to agree.

Notes to self: implementation of %qE is in cp/error.c:cp_printer, which calls
expr_to_string.

$ grep "%qE" gcc/cp/*.c | wc -l
195

[Bug c++/53341] overloaded operator delete(void *) appear in object file even when not directly used

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
With -std=c++0x  included  (until a few days ago on trunk),
which is what caused the difference.

I don't see _ZdlPv since 4.8.0 though.

[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

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra  ---
For the testcase in comment #7, global_options are inconsistent (*) and wrong
when compiling foo.  I see flag_pic == 2 there??

(*) In particular, TARGET_RELOCATABLE and flag_pic don't agree.  See
config/rs6000/sysv4.h SUBTARGET_OVERRIDE_OPTIONS.  flag_pic == 2 ought to mean
TARGET_RELOCATABLE is true, but TARGET_RELOCATABLE is false.  This combination
is not recognized in rs6000_emit_move.

[Bug middle-end/17958] expand_divmod fails to optimize division of 64-bit quantity by small constant when BITS_PER_WORD is 32

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2007-07-02 21:30:35 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
It doesn't look like the patch referenced in comment #2 was ever committed and
the 32-bit code still emits a call to __divdi3, not just on powerpc but also on
x86_64.  This affects all still supported GCC versions.

$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S
-Wall -Wextra -Wpedantic -m32 -o/dev/stdout ~/tmp/t.c
long long div10(long long n) { return n / 10; }
.file   "t.c"
.machine power4
.globl __divdi3
.section".text"
.align 2
.p2align 4,,15
.globl div10
.type   div10, @function
div10:
stwu 1,-16(1)
li 5,0
mflr 0
li 6,10
stw 0,20(1)
bl __divdi3
lwz 0,20(1)
addi 1,1,16
mtlr 0
blr
.size   div10,.-div10
.ident  "GCC: (GNU) 6.0.0 20160125 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #4 from Jerry DeLisle  ---
Dominique, I will take this one unless you want to.

[Bug c++/69521] -Wdeprecated-declarations errors in unused inline methods

[loic.yhuel at gmail dot com]

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

Loïc Yhuel  changed:

   What|Removed |Added

 CC||loic.yhuel at gmail dot com

--- Comment #1 from Loïc Yhuel  ---
> If it's easier to do, perhaps using a deprecated function in a deprecated
> function shouldn't produce a warning (deprecated code would be able to use
> other deprecated code).
Clang seems to do this.
Testing with clang 3.7, the 3 cases (first code, second code in C++ mode,
second code in C mode) don't produce any warning, unless I remove the
deprecated attribute from qLowerBound.

[Bug c++/69523] New: -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

Bug ID: 69523
   Summary: -Wliteral-suffix should not warn within namespace std
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37497=edit
reproducer.cpp

While developing for libc++ I enable warnings in the headers. Unfortunately
 always emits the warning:

> libcxx/include/string:4267:36: error: literal operator suffixes not preceded 
> by ‘_’ are reserved for future standardization [-Werror]

Obviously this is a false positive. Since the warning is on by default and
-Wno-literal-suffix doesn't disable it, then it needs to ignore user defined
literals within namespace std.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
How about declaring those headers as system headers by using -isystem instead
of using -I :)?

[Bug tree-optimization/22226] vectorization library

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
There's been no activity on this bug in almost eight years.  Is this still a
desirable enhancement today (or are there better alternatives), and is there
any likelihood that it will be implemented?  (I don't have an opinion, just
trying to clear out some old inactive bugs.)

[Bug target/65010] ppc backend generates unnecessary signed extension

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #6 from David Edelsohn  ---
This is not the same.  There is a difference between sign extension of
arguments and sign extensions within a function.

[Bug target/19746] printf() optimisation ignores longcall attribute

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2005-05-09 01:18:53 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
The behavior is still present on trunk and currently supported versions.  The
test case below shows the difference between the expected call sequence (in
bar_long) and the actual call sequence (in foo, which matches that in
bar_short).

That said, I don't think this is a target-specific problem.  The same issue
exists in other back ends, and is likely caused by some early folding not
taking into account differences in attributes or the presence of user-defined
declarations (as suggested by the patch in comment #2).

It seems that this bug should be reclassified as middle-end?

$ cat t.c && /build/sysroot/powerpc-eabispe/bin/powerpc-eabispe-gcc -O2 -S -o
/dev/stdout t.c
int printf (const char*, ...) __attribute__ ((__longcall__)); 
int puts (const char*) __attribute__ ((__longcall__));

void foo (void) { printf (" \n"); }

int puts_long (const char*) __attribute__ ((__longcall__));
int puts_short (const char*) __attribute__ ((__shortcall__));

void bar_long (void) { puts_long (" "); }
void bar_short (void) { puts_short (" "); }


.file   "t.c"
.section".text"
.align 2
.globl foo
.type   foo, @function
foo:
lis 3,.LC0@ha
la 3,.LC0@l(3)
b puts
.size   foo, .-foo
.align 2
.globl bar_long
.type   bar_long, @function
bar_long:
stwu 1,-8(1)
lis 9,puts_long@ha
mflr 0
la 9,puts_long@l(9)
lis 3,.LC0@ha
stw 0,12(1)
la 3,.LC0@l(3)
mtctr 9
bctrl
lwz 0,12(1)
addi 1,1,8
mtlr 0
blr
.size   bar_long, .-bar_long
.align 2
.globl bar_short
.type   bar_short, @function
bar_short:
lis 3,.LC0@ha
la 3,.LC0@l(3)
b puts_short
.size   bar_short, .-bar_short
.section.rodata.str1.4,"aMS",@progbits,1
.align 2
.LC0:
.string " "
.ident  "GCC: (GNU) 6.0.0 20160121 (experimental)"

[Bug tree-optimization/69522] New: gcc hangs on valid code on x86_64-linux-gnu

[helloqirun at gmail dot com]

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

Bug ID: 69522
   Summary: gcc hangs on valid code on x86_64-linux-gnu
   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 current gcc trunk hangs on the following valid code snippets on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

I assume the code snippets are valid since both gcc-4.4 and clang-trunk compile
them. gcc-4.4 and clang-trunk generate no warning for the first code snippet.
The second one is essentially the same as the first one having the line control
removed.

I tested them for gcc-4.6, gcc-4.8, gcc-4.9, gcc-5.1, gcc-5.2 and gcc-5.3. Only
gcc-4.8 got an ICE for "abc2.c", the others were just hanging.


$ gcc-4.4 -Wall -Wextra abc1.c -c
$ clang-trunk -Wall -Wextra -Wpedantic abc1.c -c
$ 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 20160127 (experimental) [trunk revision 232874] (GCC) 


$ time gcc-trunk abc1.c
^C

real21m50.378s
user0m0.000s
sys 0m0.002s



$ cat abc1.c
# 1 "" 3
struct str {};
struct {
  struct str b;
  float c[4];
  int d;
  float e[2];
  int f;
} a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};





$ time gcc-trunk abc2.c
abc.c:8:1: warning: braces around scalar initializer
 } a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};
 ^
abc.c:8:1: note: (near initialization for ‘a.d’)
abc.c:8:1: warning: braces around scalar initializer
abc.c:8:1: note: (near initialization for ‘a.f’)
^C

real14m22.631s
user0m0.000s
sys 0m0.002s


$ gcc-4.8 abc2.c
abc.c:8:1: warning: braces around scalar initializer [enabled by default]
 } a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};
 ^
abc.c:8:1: warning: (near initialization for ‘a.d’) [enabled by default]
abc.c:8:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccVkQrfE.out file, please attach this to
your bugreport.


$cat abc2.c
struct str {};
struct {
  struct str b;
  float c[4];
  int d;
  float e[2];
  int f;
} a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};

[Bug target/23450] local functions should not sign extend results (and arguments) for speed reasons

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||carrot at google dot com

--- Comment #4 from Martin Sebor  ---
*** Bug 65010 has been marked as a duplicate of this bug. ***

[Bug target/65010] ppc backend generates unnecessary signed extension

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Last reconfirmed|2015-03-21 00:00:00 |2016-1-27
 Resolution|--- |DUPLICATE
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
This is a duplicate of 23450.

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

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
@Andrew I'm a libc++ developer and I really like using compiler warnings when
developing and testing libc++. Using -isystem prevents this entirely. Normally
they are system headers but this is explicitly turned off during development.

[Bug target/23450] local functions should not sign extend results (and arguments) for speed reasons

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2007-07-01 00:47:09 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
Even though the generated code has changed, this is still a problem with 6.0
and in all supported versions prior to it as noted in bug 65010, for both
powerpc64 and powerpc64le, where GCC emits:

f:
addi 3,3,1
extsw 3,3
blr

g:
addi 3,3,1
extsw 3,3
b f

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

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 37498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37498=edit
Patch I'm testing to fix the bug

LRA wants harder than reload to avoid creating a stack slot to satisfy insn
constraints.  As a result, it creates an additional REG:TI pseudo to reload a
SUBREG:V2DF of a REG:TI, and then it tries to assign that pseudo to VSX_REGS,
which in turn causes another reload because there's no way to load a TImode
value into a VSX_REG in *mov_ppc64, and that requires another, and so on,
until the limit on reload insns is exceeded.

The first problem is that we shouldn't be creating a TImode reload for
VSX_REGS, since we can't possibly satisfy that: TImode values are not ok for
VSX_REGS.  I've adjusted in_class_p to check HARD_REGNO_MODE_OK, and that put
an end to infinite stream of reloads.

It was still a very long stream, though.  simplify_operand_subreg attempts to
turn SUBREGs of MEMs into MEMs, but it will only proceed with the
simplification if the resulting address is at least as valid as the original.  

Alas, instead of the simplification, we end up repeatedly generating reloads
copying the initial value to stack slots with growing offsets, until the offset
grows enough that the address becomes invalid, at which point the subreg
simplification is performed.  That's 2047 excess stores and loads, plus insns
that compute the stack address for each of them.

In order to fix that, I amended the test on whether to proceed with the subreg
simplification to take into account the availability of regs that can hold a
value of the intended mode in the goal class for that operand.

With that, we go from 2047 excess stores and loads to only 1.  I couldn't
figure out yet how to get rid of this one extra store and load, and the excess
stack slot, but I figured I'd share what I have, that I believe to be a solid
fix, and save the investigation on an additional LRA improvement for later.

[Bug target/22271] No builtin preprocessing defines to tell SDATA mode.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
This enhancement request has a patch but it's over 10 years old.  Is it still
applicable/worthwhile applying?  If so, Sergei, can you post it to gcc-patches?
 If not, should it be closed as WONTFIX?

[Bug tree-optimization/22226] vectorization library

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from David Edelsohn  ---
This is still of interest.

[Bug target/18154] Inefficient max/min code for PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||wschmidt at gcc dot gnu.org

--- Comment #8 from David Edelsohn  ---
Branchless code generally is better.

[Bug debug/21913] REG_EXPR wrong for parameters passed by invisible reference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
It looks to me like this isn't a problem anymore but my DAWRF-fu is weak to
tell for sure.  Jakub, can you please confirm whether or not this has been
fixed?

[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
I haven't been able to reproduce the use of floating point registers in struct
copying with any of my compilers or cross-compilers.  Is there test case that
shows that the problem still exists?

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

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On Tue, 26 Jan 2016, afomin.mailbox at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
> 
> --- Comment #21 from Alexander Fomin  ---
> (In reply to Richard Biener from comment #18)
> > Heh.  What about testcases?
> We don't have a reproducer yet, but I can provide any RTL dumps immediately 
> (of
> course).

Can you simply attach preprocessed source of the relevant file?

[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 #3 from Rainer Emrich  ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 26.01.2016 um 16:08 schrieb Rainer Emrich:
> 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!

I confirm, revision 232832 doesn't have the issue.
I mark this as duplicate of pr68446.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWqHx/AAoJEB3HOsWs+KJbmqYH/3fNkJQuBeALQtmMNXKkM8EM
5FAOgykAFDQQhmodoXt2kE+MdzlOdWefoKTySEsxy+qfHK3kXpxgmw8RN3Ir19++
KMXGZAla6836UU7UEZYxwd0Xt7pxukQ7HqGxOBzxrivh6ntT6BwLV2qZRR3emkmm
PM+l17UlgJfB9x2LfTxq8C7nzAnoBm8vV3KHdpNeiWS7kwm6xB63M2MOlfK/PW/q
4SlzzPjrUNKwNGbp4bkVkVhz13XD13lSQvYNnvb20vadWCu89Q5Zko5cwmhdwhFB
ZYYs/uyL58cW7omrRCo6eEH5/leX9xvwcUJ6ar2f19UgTcd5AgLH0gvq5U9ZWOw=
=qbY3
-END PGP SIGNATURE-

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

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Should be fixed with

2016-01-25  Richard Biener  

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

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

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 37486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37486=edit
Patch I'm testing to fix the problem

The problem occurs because we call set_current_def for phi nodes after
duplicating some blocks, but it isn't always the case that the blocks passed to
slpeel_duplicate_current_defs_from_edges were copied from one another.  In the
given testcase, the exit blocks passed to this function don't seem to be
related at all, so taking information from corresponding phi nodes to call
set_current_def is most certainly incorrect.  Indeed, it's calling
set_current_def for a virtual operand from a "corresponding" non-virtual
operand that causes slpeel_duplicate_current_defs_from_edges's use of
get_current_def to set up an incorrect, non-virtual value for the
virtual-operand phi node.  With this patch, we refrain from setting current
defs when blocks don't have analogous phi nodes, and this is enough to address
the problem.

It would be nice, however, if someone more familiar with the loop vectorizer
would check whether our calling this function with mismatched blocks indicates
another latent problem, or whether we could check for the mismatch and bypass
the call more efficiently at the caller.  For this testcase, the mismatching
call is the single_exit (scalar_loop) one in
slpeel_tree_duplicate_loop_to_edge_cfg.

[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

Rainer Emrich  changed:

   What|Removed |Added

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

--- Comment #4 from Rainer Emrich  ---
Marked as duplicate of PR68446, which is solved in r232567.

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

[Bug jit/68446] [6 Regression] jit testsuite failures seen inside dwarf2out.c:gen_producer_string

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

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

Rainer Emrich  changed:

   What|Removed |Added

 CC||rai...@emrich-ebersheim.de

--- Comment #9 from Rainer Emrich  ---
*** Bug 69490 has been marked as a duplicate of this bug. ***

[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r232881.

[Bug middle-end/65686] [5/6 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So, does the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962#c9 patch help
here?

[Bug middle-end/68542] [6 Regression] 10% 481.wrf performance regression

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On January 27, 2016 5:03:18 PM GMT+01:00, "mpolacek at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68542
>
>Marek Polacek  changed:
>
>   What|Removed |Added
>
>CC||mpolacek at gcc dot gnu.org
>
>--- Comment #6 from Marek Polacek  ---
>Fixed?

Not yet

[Bug c++/69509] infinite loop compiling a VLA in a recursive constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/69516] [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/69516] New: [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 69516
   Summary: [5/6 regression] infinite recursion on a VLA with
excess initializer elements in constexpr function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC gets itself into infinite recursion compiling the following test case
derived derived from the one shown in the discussion of a patch for bug 69496
(https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02098.html).  See also bug 69509
(which might be the same problem.)

The same problem exists in 5.x.  4.9.3 doesn't suffer from it because it
doesn't implement the more relaxed C++ 14 constexpr rules and rejects constexpr
functions that consist of more than just a return statement.

$ (cat t.c && ulimit -t 10 && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc  -Wall -Wextra -Wpedantic -std=c++14
-xc++ t.c)
constexpr int foo (int n)
{
 int a[n] = { 1, 2, 3, 4, 5, 6 };
 int z = 0;
 for (unsigned i = 0; i < 3; ++i)
   z += a[i];
 return z;
}

int main ()
{
   constexpr int n = foo (3);
   __builtin_printf ("%d\n", n);
}
t.c: In function ‘constexpr int foo(int)’:
t.c:3:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
  int a[n] = { 1, 2, 3, 4, 5, 6 };
 ^
xgcc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
.

[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 27 15:44:07 2016
New Revision: 232881

URL: https://gcc.gnu.org/viewcvs?rev=232881=gcc=rev
Log:
PR c++/69317 - [6 regression] wrong ABI version in -Wabi warnings

gcc/cp/ChangeLog:
2016-01-27  Martin Sebor  

PR c++/69317
* mangle.c (mangle_decl): Reference the correct (saved) version
of the ABI in -Wabi diagnostics.

gcc/testsuite/ChangeLog:
2016-01-27  Martin Sebor  

PR c++/69317
* g++.dg/abi/Wabi-2-2.C: New test.
* g++.dg/abi/Wabi-2-3.C: New test.
* g++.dg/abi/Wabi-3-2.C: New test.
* g++.dg/abi/Wabi-3-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/abi/Wabi-2-2.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-2-3.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-3-2.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-3-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[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 #12 from Richard Henderson  ---
(In reply to ktkachov from comment #10)
> This patch also seems to fix the wrong code in PR 69124

Good to know -- I wasn't able to reproduce that failure myself.

[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures

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

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

--- Comment #6 from Rainer Emrich  ---
I tested the new version of the proposed patch. Now the tests all pass on
x86_64-unknown-linux-gnu and x86_64-w64-mingw32.

Eric, please submit to mainline.

[Bug target/68380] NetBSD has SSP in libc

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Patch committed to the trunk.

[Bug target/68380] NetBSD has SSP in libc

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan 27 16:54:48 2016
New Revision: 232884

URL: https://gcc.gnu.org/viewcvs?rev=232884=gcc=rev
Log:
2016-01-27  Thomas Klausner  

PR target/68380
* configure.ac: NetBSD provides SSP in its C library.
* configure: Updated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug ada/69488] tests in gnat/sso give a lot of spurious failures

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
.

[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

--- Comment #9 from Richard Biener  ---
I am testing that patch now.

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to janus from comment #4)
> > Is there a reason for this behavior?
> 
> https://gcc.gnu.org/wiki/FAQ#wnowarning

I see. So this is intended and not a bug. Thanks for the pointer.


> But the third call should have given some other warning; otherwise there is
> a bug.

Right, there was a warning. I just omitted it because I did not expect that it
makes a difference.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
Hopefully fixed.

[Bug c++/66487] [6 Regression] Firefox segfault with LTO enabled

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #13)
> Author: hubicka
> Date: Wed Jan 13 23:47:45 2016
> New Revision: 232356
> 
> URL: https://gcc.gnu.org/viewcvs?rev=232356=gcc=rev
> Log:
> 
>   PR ipa/66487
>   * ipa-polymorphic-call.c (inlined_polymorphic_ctor_dtor_block_p):
>   use block_ultimate_origin
>   (noncall-stmt_may_be_vtbl_ptr_store): Likewise.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/ipa-polymorphic-call.c

Has this commit fixed the remaining issues?

[Bug fortran/49627] NINT(x,16) doesn't work (at all, ever, I don't think)

[dr.robert.kosik at gmail dot com]

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

dr.robert.kosik at gmail dot com changed:

   What|Removed |Added

 CC||dr.robert.kosik at gmail dot 
com

--- Comment #4 from dr.robert.kosik at gmail dot com ---
This Bug is still open in 2016-01-27 with gfortran 4.8.4

double precision :: X
integer(16) :: norm
norm = NINT(X,KIND=16)

internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:394
   norm = NINT(X,KIND=16)
 ^
Please submit a full bug report.

It works fine with other types of rounding, i.e., INT(X,16), FLOOR(X,16),
CEILING(X,16) compile ok.

[Bug tree-optimization/66797] [6 Regression] FAIL: gcc.dg/tree-ssa/pr65447.c scan-tree-dump-not ivopts "\\nuse 5\\n"

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from amker at gcc dot gnu.org ---
Should be fixed.

[Bug c++/66487] [6 Regression] Firefox segfault with LTO enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #4)
> Actually, I guess checking for this is more of a fit for an uninitialized
> read detector such as MemorySanitizer or Valgrind memcheck.

Well, AddressSanitizer should be able to do that too with some extra work, what
we need is know not just when the lifetime of a variable ends, but also when it
starts, and instrument those two, plus disable reusing variable stack slots
when instrumenting.  In the function prologue we'd then mark the variables as
unavailable, not just their padding, and then when they get into scope (that is
the first clobber these days), we'd mark them enabled and when they get out of
scope (second clobber) mark them unavailable again.  GCC7 material.

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 27 16:46:40 2016
New Revision: 232882

URL: https://gcc.gnu.org/viewcvs?rev=232882=gcc=rev
Log:
PR c++/69379
* constexpr.c (cxx_eval_constant_expression): Handle PTRMEM_CSTs
wrapped in NOP_EXPRs.

* g++.dg/pr69379.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr69379.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/69488] tests in gnat/sso give a lot of spurious failures

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Jan 27 16:53:27 2016
New Revision: 232883

URL: https://gcc.gnu.org/viewcvs?rev=232883=gcc=rev
Log:
PR ada/69488
* gnat.dg/sso/*.adb: Robustify dg-output directives.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gnat.dg/sso/conv1.adb
trunk/gcc/testsuite/gnat.dg/sso/p1.adb
trunk/gcc/testsuite/gnat.dg/sso/p10.adb
trunk/gcc/testsuite/gnat.dg/sso/p11.adb
trunk/gcc/testsuite/gnat.dg/sso/p12.adb
trunk/gcc/testsuite/gnat.dg/sso/p13.adb
trunk/gcc/testsuite/gnat.dg/sso/p2.adb
trunk/gcc/testsuite/gnat.dg/sso/p3.adb
trunk/gcc/testsuite/gnat.dg/sso/p4.adb
trunk/gcc/testsuite/gnat.dg/sso/p5.adb
trunk/gcc/testsuite/gnat.dg/sso/p6.adb
trunk/gcc/testsuite/gnat.dg/sso/p7.adb
trunk/gcc/testsuite/gnat.dg/sso/p8.adb
trunk/gcc/testsuite/gnat.dg/sso/p9.adb
trunk/gcc/testsuite/gnat.dg/sso/q1.adb
trunk/gcc/testsuite/gnat.dg/sso/q10.adb
trunk/gcc/testsuite/gnat.dg/sso/q11.adb
trunk/gcc/testsuite/gnat.dg/sso/q12.adb
trunk/gcc/testsuite/gnat.dg/sso/q13.adb
trunk/gcc/testsuite/gnat.dg/sso/q2.adb
trunk/gcc/testsuite/gnat.dg/sso/q3.adb
trunk/gcc/testsuite/gnat.dg/sso/q4.adb
trunk/gcc/testsuite/gnat.dg/sso/q5.adb
trunk/gcc/testsuite/gnat.dg/sso/q6.adb
trunk/gcc/testsuite/gnat.dg/sso/q7.adb
trunk/gcc/testsuite/gnat.dg/sso/q8.adb
trunk/gcc/testsuite/gnat.dg/sso/q9.adb
trunk/gcc/testsuite/gnat.dg/sso/r11.adb
trunk/gcc/testsuite/gnat.dg/sso/r12.adb
trunk/gcc/testsuite/gnat.dg/sso/r3.adb
trunk/gcc/testsuite/gnat.dg/sso/r5.adb
trunk/gcc/testsuite/gnat.dg/sso/r6.adb
trunk/gcc/testsuite/gnat.dg/sso/r7.adb
trunk/gcc/testsuite/gnat.dg/sso/r8.adb
trunk/gcc/testsuite/gnat.dg/sso/s11.adb
trunk/gcc/testsuite/gnat.dg/sso/s12.adb
trunk/gcc/testsuite/gnat.dg/sso/s3.adb
trunk/gcc/testsuite/gnat.dg/sso/s5.adb
trunk/gcc/testsuite/gnat.dg/sso/s6.adb
trunk/gcc/testsuite/gnat.dg/sso/s7.adb
trunk/gcc/testsuite/gnat.dg/sso/s8.adb
trunk/gcc/testsuite/gnat.dg/sso/t1.adb
trunk/gcc/testsuite/gnat.dg/sso/t10.adb
trunk/gcc/testsuite/gnat.dg/sso/t11.adb
trunk/gcc/testsuite/gnat.dg/sso/t12.adb
trunk/gcc/testsuite/gnat.dg/sso/t13.adb
trunk/gcc/testsuite/gnat.dg/sso/t2.adb
trunk/gcc/testsuite/gnat.dg/sso/t3.adb
trunk/gcc/testsuite/gnat.dg/sso/t4.adb
trunk/gcc/testsuite/gnat.dg/sso/t5.adb
trunk/gcc/testsuite/gnat.dg/sso/t6.adb
trunk/gcc/testsuite/gnat.dg/sso/t7.adb
trunk/gcc/testsuite/gnat.dg/sso/t8.adb
trunk/gcc/testsuite/gnat.dg/sso/t9.adb
trunk/gcc/testsuite/gnat.dg/sso/u11.adb
trunk/gcc/testsuite/gnat.dg/sso/u5.adb
trunk/gcc/testsuite/gnat.dg/sso/u6.adb

[Bug c++/68514] [6 Regression] ICE in tr1/5_numerical_facilities libstdc++ test cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

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

[Bug middle-end/68542] [6 Regression] 10% 481.wrf performance regression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
Fixed?

[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
Thanks, will apply it.

[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 #13 from Richard Henderson  ---
(In reply to Jakub Jelinek from comment #11)
> Without knowing the lra-remat code at all, I just wonder if subreg_regs
> needs to be one per the whole function, rather than say per extended basic
> block or basic block, with the patch any uses in multi-reg subregs anywhere
> in the function will affect remat of all other spots where it is used.

I started with subreg_regs being per-block.  But since IRA has
some global component, I was concerned that there would be some
edge case that would be missed, and switched to a global bitmap.

Perhaps someone who knows the allocator better can comment.

[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures

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

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

--- Comment #5 from Rainer Emrich  ---
Created attachment 37491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37491=edit
proposed patch, new version

* gnat.dg/sso/*.adb: Robustify dg-output directives.

Changed conv1.adb again. The double "\\" for escaping are necessary.

[Bug c++/69517] New: [5/6 regression] SEGV on a VLA with excess initializer elements

[msebor at gcc dot gnu.org]

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

Bug ID: 69517
   Summary: [5/6 regression] SEGV on a VLA with excess initializer
elements
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Continuing with my testing of VLAs in G++ (see bug 69516, bug 69496, and bug 
69509), I discovered another problem.

When compiled with GCC 4.9.3, the program below aborts with the following
output:

terminate called after throwing an instance of 'std::bad_array_length'
  what():  std::bad_array_length
Aborted (core dumped)

However, when compiled with 5.x or 6.0, it crashes with a SEGV:

$ (cat t.c && ulimit -t 10 && ~/bin/gcc-5.1.0/bin/g++  -Wall -Wextra -Wpedantic
-std=c++14 -xc++ t.c) && ./a.out
int foo (int n)
{
 int a[n] = { 1, 2, 3, 4, 5, 6 };
 int z = 0;
 for (unsigned i = 0; i < 3; ++i)
   z += a[i];
 return z;
}

int main ()
{
   int n = foo (3);
   __builtin_printf ("%d\n", n);
}
t.c: In function ‘int foo(int)’:
t.c:3:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
  int a[n] = { 1, 2, 3, 4, 5, 6 };
 ^
Segmentation fault (core dumped)

[Bug c++/69436] Method returning "auto&" fails to resolve "*this" (-std=c++17)

[vmorgulys at gmail dot com]

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

--- Comment #6 from vmorgulys at gmail dot com ---
Hello Jonathan,

I have another similar issue with auto and deleted contructrors
("=delete"). They are not detected at compile time.

Do you think it is related to what you mention in your comment (Concept TS)?

If I understand correctly, I need to build gcc with the trunk version to be
sure. Is it correct?

Thank you a lot for your work on gcc.

Cheers,

Marc

2016-01-22 22:03 GMT+01:00 redi at gcc dot gnu.org :

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69436
>
> --- Comment #2 from Jonathan Wakely  ---
> (In reply to vmorgulys from comment #0)
> >  auto& f2(auto v)
>
> This is not standard C++, it's part of the Concepts TS, and so doesn't work
> properly until GCC 6.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug fortran/69524] New: [ICE] [F2008] Compiler segfaults on simple testcase @ -O0

[kyukhin at gcc dot gnu.org]

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

Bug ID: 69524
   Summary: [ICE] [F2008] Compiler segfaults on simple testcase @
-O0
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37501=edit
Reproducer

Attached testcase produces ICE while compiling w/ recent trunk:

$ ./build-x86_64-linux/gcc/gfortran -B./build-x86_64-linux/gcc -S 2.f08
f951: internal compiler error: in build_function_decl, at
fortran/trans-decl.c:2065
0x88c1df build_function_decl
/export/users/kyukhin/gcc/git/gcc2/gcc/fortran/trans-decl.c:2065
0x88ec53 gfc_create_function_decl(gfc_namespace*, bool)
/export/users/kyukhin/gcc/git/gcc2/gcc/fortran/trans-decl.c:2758
0x86361d gfc_generate_module_code(gfc_namespace*)
/export/users/kyukhin/gcc/git/gcc2/gcc/fortran/trans.c:2043
0x7f9d19 translate_all_program_units
/export/users/kyukhin/gcc/git/gcc2/gcc/fortran/parse.c:5599
0x7fa3f7 gfc_parse_file()
/export/users/kyukhin/gcc/git/gcc2/gcc/fortran/parse.c:5818
0x84c839 gfc_be_parse_file
/export/users/kyukhin/gcc/git/gcc2/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/60526] [4.9/5/6 Regression] Accepts-invalid: Variable name same as type name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #37499|0   |1
is obsolete||

--- Comment #12 from Thomas Koenig  ---
Created attachment 37500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37500=edit
Actual patch

... the other file was a test case.

[Bug fortran/60526] [4.9/5/6 Regression] Accepts-invalid: Variable name same as type name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #11 from Thomas Koenig  ---
Created attachment 37499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37499=edit
Better patch

OK, so types only have their first letter converted to upper case
in the symtree.

Fortran *can* have variable names longer than one character :-)

Nonetheless, the strange error message formatting remains.

[Bug c++/69267] [cilkplus] ICE when calling a function with an empty class as an argument

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Ryan's patch fixed this on the trunk.

[Bug target/3920] [PPC] wrong register number for CTR in stabs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
There hasn't been any progress or activity on this bug in 10 years.  Is it
still a problem with a recent GCC or can the bug be closed?

[Bug fortran/66094] Handle transpose(A) in inline matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Created attachment 37492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37492=edit
Patch to handle matmul(transpose(a),b)

This patch implements matmul(transpose(a),b).  However, it does not enable
vectorization even with -Ofast.

I do not intend to submit this patch in this form.

It still needs some work to create the rank-one temporary and use it,
to enable vectorization.  This is only suitable for stage 1 in gcc 7.

[Bug c++/67824] constexpr char* compare operations not constexpr, but char[] operations ARE

[erich.keane at intel dot com]

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

--- Comment #3 from Erich Keane  ---
Don't know if it is a result of the red-hat packaging, or the .1 release, but
the 3.7.1 release from here: http://llvm.org/releases/download.html

seems to no longer crash.(In reply to Erich Keane from comment #2)
> Don't know if it is a result of the red-hat packaging, or the .1 release,
> but the 3.7.1 release from here: http://llvm.org/releases/download.html
> 
> seems to no longer crash.

Er, sorry, this is for a different bug meant for clang.  Please disregard, I
don't see how to delete it.

[Bug target/5372] [powerpc-*-eabi] -mno-eabi not working

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2004-01-02 06:15:10 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||3.0.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.0

--- Comment #7 from Martin Sebor  ---
Reconfirmed with 6.0.  The manual says:

Selecting -mno-eabi means that the stack is aligned to a 16-byte boundary, no
EABI initialization function is called from main, and the -msdata option only
uses r13 to point to a single small data area. 

The following test case shows that a call to __eabi is emitted despite the
-mno-eabi option:

$ echo "int main (void) { return 0; }" |
/build/sysroot/powerpc-eabispe/bin/powerpc-eabispe-gcc -c -mno-eabi -nostdlib
-o a.o -xc - && objdump -t a.o | grep '*UND\*'
 *UND*   __eabi

I don't know enough about the EABI to tell for sure whether the problem is in
the manual or if GCC is wrong for calling __eabi even with the option.

[Bug target/10778] Exception handling seems to fail on a powerpc using GCC 3.2.3 powerpc-eabi cross compiler

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #10 from Martin Sebor  ---
I'm having trouble building the test program (it seems that the defintions of
some symbols are missing).  There hasn't been any activity on this bug report
in over 10 years.  Does the problem still exist with recent GCC?

[Bug c++/67824] constexpr char* compare operations not constexpr, but char[] operations ARE

[erich.keane at intel dot com]

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

--- Comment #2 from Erich Keane  ---
Don't know if it is a result of the red-hat packaging, or the .1 release, but
the 3.7.1 release from here: http://llvm.org/releases/download.html

seems to no longer crash.

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
The ICEs in this PR and PR69498 disappear withe following patch

--- ../_clean/gcc/fortran/symbol.c  2016-01-04 19:51:09.0 +0100
+++ gcc/fortran/symbol.c2016-01-27 12:55:59.0 +0100
@@ -2754,10 +2754,11 @@ gfc_release_symbol (gfc_symbol *sym)
 }

   sym->refs--;
-  if (sym->refs > 0)
+  /* if (sym->refs > 0) */
+  if (sym->refs != 0)
 return;

-  gcc_assert (sym->refs == 0);
+  /* gcc_assert (sym->refs == 0); */
   gfc_free_symbol (sym);
 }

@@ -3696,9 +3698,10 @@ gfc_free_namespace (gfc_namespace *ns)
 return;

   ns->refs--;
-  if (ns->refs > 0)
+  /* if (ns->refs > 0) */
+  if (ns->refs != 0)
 return;
-  gcc_assert (ns->refs == 0);
+  /* gcc_assert (ns->refs == 0); */

   gfc_free_statements (ns->code);

[Bug fortran/69514] ICE with nested array constructor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug c/69518] New: Flag -g causes "error: type variant has different TYPE_VFIELD"

[dcb314 at hotmail dot com]

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

Bug ID: 69518
   Summary: Flag -g causes "error: type variant has different
TYPE_VFIELD"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 37493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37493=edit
C source code

gcc trunk, dated 20160127, when given the attached C code
and asked to compile it with -g, does this:

common.c: In function ‘stats_errcount’:
common.c:611:1: error: type variant has different TYPE_VFIELD
  constant 640>
unit size  constant 80>
align 64 symtab -1998967440 alias set -1 canonical type 0x7f8488d94690
fields 

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov  ---
(In reply to Richard Henderson from comment #13)
> (In reply to Jakub Jelinek from comment #11)
> > Without knowing the lra-remat code at all, I just wonder if subreg_regs
> > needs to be one per the whole function, rather than say per extended basic
> > block or basic block, with the patch any uses in multi-reg subregs anywhere
> > in the function will affect remat of all other spots where it is used.
> 
> I started with subreg_regs being per-block.  But since IRA has
> some global component, I was concerned that there would be some
> edge case that would be missed, and switched to a global bitmap.
> 
> Perhaps someone who knows the allocator better can comment.

Richard, thanks for working on it.  You used the right approach.  I believe
some edge cases are possible, e.g. sched1 could move one subreg insn into
another block.  So just non-global approach would be vulnerable.

The patch looks ok to me.  So you can commit it if the test results are ok.

Thanks again.  I had no time to work on it as I am too busy with other RA bugs.

[Bug c++/69509] [5/6 regression] infinite loop compiling a VLA in a recursive constexpr function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|infinite loop compiling a   |[5/6 regression] infinite
   |VLA in a recursive  |loop compiling a VLA in a
   |constexpr function  |recursive constexpr
   ||function
  Known to fail||5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
Marking this a 5/6 regression since ICE 4.9.3 rejects the code with the error
below because it doesn't allow contexpr functions to have more than one
(return) statement.

t.c: In function ‘constexpr int foo(int)’:
t.c:8:1: error: body of constexpr function ‘constexpr int foo(int)’ not a
return-statement
 }
 ^
t.c: At global scope:
t.c:10:25: error: ‘constexpr int foo(int)’ called in a constant expression
 constexpr int i = foo (3);
 ^

[Bug target/69512] [6 Regression] ICE when using avx with i586

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jan 27 17:08:00 2016
New Revision: 232885

URL: https://gcc.gnu.org/viewcvs?rev=232885=gcc=rev
Log:
2016-01-27  Uros Bizjak  

PR target/69512
* config/i386/i386.md (*zext_doubleword_and): New pattern.
(*zext_doubleword): Disable for TARGET_ZERO_EXTEND_WITH_AND.

testsuite/ChangeLog:

2016-01-27  Uros Bizjak  

PR target/69512
* gcc.target/i386/pr69512.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr69512.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/69267] [cilkplus] ICE when calling a function with an empty class as an argument

[law at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan 27 17:17:23 2016
New Revision: 232887

URL: https://gcc.gnu.org/viewcvs?rev=232887=gcc=rev
Log:
2016-01-15  Ryan Burn  

PR cilkplus/69267
* cilk.c (cilk_gimplify_call_params_in_spawned_fn): Change to use
gimplify_arg. Removed superfluous post_p argument.
* c-family.h (cilk_gimplify_call_params_in_spawned_fn): Removed
superfluous post_p argument.
* c-gimplify.c (c_gimplify_expr): Likewise.

gcc/cp/ChangeLog:

2016-01-15  Ryan Burn  

PR cilkplus/69267
* cp-gimplify.c (cilk_cp_gimplify_call_params_in_spawned_fn): Removed
superfluous post_p argument in call to
cilk_gimplify_call_params_in_spawned_fn.

gcc/testsuite/ChangeLog:

2016-01-15  Ryan Burn  

PR cilkplus/69267
* g++.dg/cilk-plus/CK/pr69267.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr69267.cc
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-gimplify.c
trunk/gcc/c-family/cilk.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/69479] [4.9 only] test case gcc.dg/and-1.c fails on power for gcc 4.9

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
Fixed in r232886.

[Bug java/50045] [4.9/5/6 regression] ICE in gcc/java/lang.c:427 with -fdump-tree-all

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #14 from Jeffrey A. Law  ---
Kai fixed this back in early 2013, so it should be working in 4.9, 5 & on the
trunk (I verified the latter, of course).

[Bug debug/69518] [6 Regression] Flag -g causes "error: type variant has different TYPE_VFIELD"

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-27
 CC||trippels at gcc dot gnu.org
  Component|c   |debug
Summary|Flag -g causes "error: type |[6 Regression] Flag -g
   |variant has different   |causes "error: type variant
   |TYPE_VFIELD"|has different TYPE_VFIELD"
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat bug269.c
struct s_stats a;
typedef struct s_stats cstats;
struct s_stats {
} fn1(cstats p1) {
}

markus@x4 tmp % gcc -c -g bug269.c
bug269.c: In function ‘fn1’:
bug269.c:5:1: error: type variant has different TYPE_VFIELD
 }
 ^
  constant 0>
unit size  constant 0>
align 8 symtab 2001394976 alias set -1 canonical type 0x7fc47749a348
context 
chain >
  constant 0>
unit size  constant 0>
align 8 symtab 2001395216 alias set -1 canonical type 0x7fc47749a348
context 
chain >
bug269.c:5:1: internal compiler error: verify_type failed
0xdc44ad verify_type(tree_node const*)
../../gcc/gcc/tree.c:13888
0x7c522c gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:22701
0x7c65f6 gen_type_die
../../gcc/gcc/dwarf2out.c:22899
0x7be320 gen_decl_die
../../gcc/gcc/dwarf2out.c:23555
0x7bb364 gen_subprogram_die
../../gcc/gcc/dwarf2out.c:20704
0x7bde6c gen_decl_die
../../gcc/gcc/dwarf2out.c:23468
0x7bedae dwarf2out_decl
../../gcc/gcc/dwarf2out.c:23951
0x7d6538 dwarf2out_early_global_decl
../../gcc/gcc/dwarf2out.c:23624
0x74efeb symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2549

[Bug target/15767] ppc-linux type attribute aligned, packed on vector types behaves wrongly

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2004-06-01 22:33:42 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.0

--- Comment #4 from Martin Sebor  ---
I believe GCC behavior for first struct is correct and matches documentation.

The problem with the second struct is that attribute aligned doesn't behave as
specified.

According to the manual, "The 'aligned' attribute can only increase the
alignment" so the aligned attribute in the defintion of myChar in the second
test case is ignored.

At the same time, as pointed out in bug 65672, the attribute can have the
effect of reducing the alignment of a type in a typedef.  That's not what we
see in the output of the second test case, but it does happen when the order of
the two attributes is reversed.  In other words, when attribute aligned comes
after attribute vector it overrides the alignment of the vector.

Below is a test case that unifies the two from the Description and adds a third
showing the ordering difference.

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra
-Wpedantic -maltivec t.c && ./a.out
#define Align(N) __attribute__ ((aligned (N)))
#define Vector(N)  __attribute__ ((vector_size (N)))

typedef Align (2) Vector (16) unsigned char myChar;
typedef Vector (16) Align (2) unsigned char otherChar;

struct __attribute__((packed)) A {
   char   a;
   vector int b;
} sa;

struct B {
char  c;
myChara;
char  b;
} sb;


struct C {
char  c;
otherChar a;
char  b;
} sc;

int main (void)
{
__builtin_printf ("sizeof   sa:%2zu\n", sizeof (sa));
__builtin_printf ("alignof  sa:%2zu\n", __alignof__ (sa));
__builtin_printf ("offsetof sa.b:  %2zu\n\n",
  __builtin_offsetof (struct A, b));

__builtin_printf ("sizeof   sb:%2zu\n", sizeof (sb));
__builtin_printf ("alignof  sb:%2zu\n", __alignof__ (sb));
__builtin_printf ("offsetof sb.a:  %2zu\n",
   __builtin_offsetof (struct B, a));
__builtin_printf ("offsetof sb.b:  %2zu\n\n",
   __builtin_offsetof (struct B, b));

__builtin_printf ("sizeof   sc:%2zu\n", sizeof (sc));
__builtin_printf ("alignof  sc:%2zu\n", __alignof__ (sc));
__builtin_printf ("offsetof sc.a:  %2zu\n",
   __builtin_offsetof (struct C, a));
__builtin_printf ("offsetof sc.b:  %2zu\n",
   __builtin_offsetof (struct C, b));
}
t.c: In function ‘main’:
t.c:28:49: warning: ISO C does not allow ‘__alignof__ (expression)’
[-Wpedantic]
 __builtin_printf ("alignof  sa:%2zu\n", __alignof__ (sa));
 ^~~

t.c:33:49: warning: ISO C does not allow ‘__alignof__ (expression)’
[-Wpedantic]
 __builtin_printf ("alignof  sb:%2zu\n", __alignof__ (sb));
 ^~~

t.c:40:49: warning: ISO C does not allow ‘__alignof__ (expression)’
[-Wpedantic]
 __builtin_printf ("alignof  sc:%2zu\n", __alignof__ (sc));
 ^~~

sizeof   sa:17
alignof  sa: 1
offsetof sa.b:   1

sizeof   sb:48
alignof  sb:16
offsetof sb.a:  16
offsetof sb.b:  32

sizeof   sc:20
alignof  sc: 2
offsetof sc.a:   2
offsetof sc.b:  18
$

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 27 19:13:42 2016
New Revision: 232894

URL: https://gcc.gnu.org/viewcvs?rev=232894=gcc=rev
Log:
PR c/68062
* c-typeck.c (build_binary_op) [EQ_EXPR, GE_EXPR]: Promote operand
to unsigned, if needed.  Add -Wsign-compare warning.

* typeck.c (cp_build_binary_op): Promote operand to unsigned, if
needed.  Add -Wsign-compare warning.

* c-c++-common/vector-compare-4.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/vector-compare-4.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/22238] Awful error messages with virtual functions

[manu at gcc dot gnu.org]

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

--- Comment #21 from Manuel López-Ibáñez  ---
(In reply to David Malcolm from comment #19)
> /tmp/test2.cc:9:24: error: return-statement with a value, in function
> returning 'void' [-fpermissive]
>  return P->bar() + *P;
> ^

And that location is terrible, but that is a different issue.

[Bug rtl-optimization/16456] PowerPC - redundant subtract involving pointer types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||4.8.5, 6.0
 Resolution|--- |FIXED

--- Comment #6 from Martin Sebor  ---
This appears to have improved.  Current trunk (as well as 4.8.5) emit what
looks like optimal code at both -O2 and -O3.  Resolving as fixed.

.L.foo:
addis 10,2,.LC0@toc@ha  # gpr load fusion, type long
ld 10,.LC0@toc@l(10)
addis 9,2,.LC1@toc@ha   # gpr load fusion, type long
ld 9,.LC1@toc@l(9)
addis 8,2,.LC2@toc@ha   # gpr load fusion, type long
ld 8,.LC2@toc@l(8)
ld 7,0(10)
ld 9,0(9)
addis 10,2,.LC3@toc@ha  # gpr load fusion, type long
ld 10,.LC3@toc@l(10)
subf 9,9,7
stw 9,0(8)
std 9,0(10)
blr

[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 #7 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan 27 19:19:47 2016
New Revision: 232897

URL: https://gcc.gnu.org/viewcvs?rev=232897=gcc=rev
Log:
PR tree-optimization/68398
* params.def (PARAM_FSM_SCALE_PATH_STMTS): New parameter.
(PARAM_FSM_SCALE_PATH_BLOCKS): Likewise.
* tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
Only count PHIs in the last block in the path.  The others will
const/copy propagate away.  Add heuristic to allow more irreducible
subloops to be created when it is likely profitable to do so.

* tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
Fix typo in comment.  Use gsi_after_labels and remove the GIMPLE_LABEL
check from within the loop.  Use gsi_next_nondebug rather than
gsi_next.

PR tree-optimization/68398
* gcc.dg/tree-ssa/pr66752-3.c: Update expected output.
* gcc.dg/tree-ssa/ssa-dom-thread-2c.c: Add extra statements on thread
path to avoid new heuristic allowing more irreducible regions
* gcc.dg/tree-ssa/ssa-dom-thread-2d.c: Likewise.
* gcc.dg/tree-ssa/vrp46.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Update expected output.
* gcc.dg/tree-ssa/ssa-dom-thread-2g.c: New test.
* gcc.dg/tree-ssa/ssa-dom-thread-2h.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2g.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2h.c
  - copied, changed from r232894,
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2d.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66752-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2c.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2d.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
trunk/gcc/tree-ssa-threadbackward.c

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug c++/22238] Awful error messages with virtual functions

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #19 from David Malcolm  ---
gcc trunk (r232888 fwiw) currently emits this for comment #0:

/tmp/test.cc: In member function ‘void A::bar()’:
/tmp/test.cc:4:23: error: could not convert ‘A::foo()’ from ‘void’ to ‘bool’
   void bar() { if (foo()) ; }
~~~^~

and this for the dup reported in PR 50817:

/tmp/test2.cc: In function ‘void test(foo*)’:
/tmp/test2.cc:9:21: error: no match for ‘operator+’ (operand types are ‘int’
and ‘foo’)
 return P->bar() + *P;
~^~~~
/tmp/test2.cc:9:24: error: return-statement with a value, in function returning
'void' [-fpermissive]
 return P->bar() + *P;
^

Is it time to close this one out as fixed?