[Bug tree-optimization/70144] [4.9/5 Regression] g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] g++|[4.9/5 Regression] g++ ICE
   |ICE at -O1 and above on |at -O1 and above on valid
   |valid code on   |code on x86_64-linux-gnu in
   |x86_64-linux-gnu in |"copy_reference_ops_from_re
   |"copy_reference_ops_from_re |f"
   |f"  |

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug fortran/70260] ICE: gimplification failed

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Another situation :


$ cat z3.f90
subroutine s (f)
   integer, external :: f, g
   integer :: h
   g = f(2)
   h = g(2)
end


$ gfortran-6 -c z3.f90
gimplification failed:
g 
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2abc6cc7e738
attributes 
value >>
pointer_to_this >
unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2abc6ce1d1f8>
constant
arg 0 
addressable used public external QI file z3.f90 line 2 col 0 align 8
context 
chain 
public static QI file z3.f90 line 1 col 0 align 8 context
 initial 
result 
(mem:QI (symbol_ref:DI ("s_") [flags 0x3] ) [0  S1 A8]) arguments 
struct-function 0x2abc6ce1d498 chain >>
z3.f90:4:0 start: z3.f90:4:0 finish: z3.f90:4:0>
z3.f90:4:0:

g = f(2)

internal compiler error: gimplification failed



Before :

$ gfortran-5 -c z3.f90
z3.f90:4:0:

g = f(2)
 ^
internal compiler error: in gimplify_expr, at gimplify.c:9063



Working variant :

$ cat z4.f90
subroutine s (f)
   integer, external :: f, g
   integer :: h
   h = f(2)
   h = g(2)
end

[Bug c++/70145] g++-5 and g++-6: invalid code generated for -fno-elide-constructors and constexpr array

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
dup

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

[Bug c++/70139] [5/6 Regression] -fno-elide-constructor makes static std::regex to throw

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill  ---
Author: jason
Date: Fri Mar 18 20:17:04 2016
New Revision: 234346

URL: https://gcc.gnu.org/viewcvs?rev=234346&root=gcc&view=rev
Log:
PR c++/70139
* constexpr.c (cxx_eval_call_expression): Don't shortcut trivial copy.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c

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

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed on trunk so far - does this need a backport to the 5 branch ?

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-17
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Fails on x86_64-linux and i686-linux too.

[Bug c/70264] [6 Regression] ICE at -O0 to -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (compatible_locations_p, at diagnostic-show-locus.c:490)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r234303; marking as resolved.

[Bug c++/70218] [5/6 Regression] Illegal access to private fields succeeds with 5/6

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Changing to ASSIGNED so that it's visible in the BZ summary list that this is
being taken care of.

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I think the problem is that after the r234261 change the new flag is set only
during gimplification, which is too late for the C++ ctors and dtors, which
need to check copy_forbidden already before gimplification.
So, shall we use the new flag + restore the old walk_tree_without_duplicates,
or do the latter only if not gimplified yet?

[Bug c++/70295] [6 Regression] bogus -Wnonnull-compare for "dynamic_cast(this) != nullptr"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Let's make it
struct A { A (); virtual ~A (); bool foo (bool); };
struct B : virtual public A { B (); virtual ~B (); };

bool
A::foo (bool x)
{
  if (x && dynamic_cast(this) != nullptr)
return true;
  return false;
}
then.

[Bug debug/70271] [6 Regression] internal compiler error: in dwarf2out_finish, at dwarf2out.c:27346

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/70262] Segmentation fault with large stack array, no fault when alloca the same size

[nickdu at msn dot com]

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

--- Comment #4 from nickdu at msn dot com ---
That doesn't explain why it works with alloca().

> From: gcc-bugzi...@gcc.gnu.org
> To: nic...@msn.com
> Subject: [Bug c/70262] Segmentation fault with large stack array, no fault 
> when alloca the same size
> Date: Wed, 16 Mar 2016 23:04:14 +
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70262
> 
> --- Comment #3 from Andrew Pinski  ---
> (In reply to nickdu from comment #2)
> > Why is this resolved as invalid?  I realize I can increase my stack size. 
> > However, I believe I'm currently under the limit.  In addition, alloca of
> > the same size works.
> 
> 
> Well without a testcase that is self contained, there is no way to test it and
> make sure.  Also is this on a secondary thread?  Is so the thread stack space
> is usually much smaller unless you programatically increase it.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.
  =

[Bug c/70281] New: valgrind error in can_be_stored_compactly_p (line-map.c:148)

[dcb314 at hotmail dot com]

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

Bug ID: 70281
   Summary: valgrind error in can_be_stored_compactly_p
(line-map.c:148)
   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 38001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38001&action=edit
gzipped C source code

The attached code, when compiled by gcc trunk dated 20160313 does this:

==18886== Conditional jump or move depends on uninitialised value(s)
==18886==at 0x104961E: can_be_stored_compactly_p (line-map.c:148)
==18886==by 0x104961E: get_combined_adhoc_loc(line_maps*, unsigned int,
source_range, 
void*) (line-map.c:190)
==18886==by 0xBBCF88: COMBINE_LOCATION_DATA (line-map.h:993)
==18886==by 0xBBCF88: set_source_range(tree_node*, source_range)
(tree.c:14028)
==18886==by 0xBBCFB1: set_source_range(tree_node*, unsigned int, unsigned
int) (tree.c
:14015)
==18886==by 0x5F69FF: set_c_expr_source_range (c-parser.c:78)

Only gcc flag required is -c.

[Bug driver/70192] -fno-pic doesn't work with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to psturm from comment #7)
> Built hjl/pr70192 both with and without --enable-default-pie. The test
> results were almost identical, the only difference being the number of test
> cases run. gcc didn't have any issues, but g++ had a couple of new
> unresolved test cases. I am not sure if these are related or not, so here is
> the summary:
> 
> === g++ tests ===
> 
> 
> Running target unix
> UNRESOLVED: g++.dg/cpp1y/constexpr-instantiate.C  -std=c++11  scan-tree-dump
> optimized "bool [fg]("
> UNRESOLVED: g++.dg/cpp1y/constexpr-instantiate.C  -std=c++14  scan-tree-dump
> optimized "bool [fg]("

I didn't see it.  Please run the command by hand and show me the
output.

[Bug other/70185] fdump-tree-all-graph produces invalid dot files

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-17
 Ever confirmed|0   |1

--- Comment #3 from vries at gcc dot gnu.org ---
stage1 approved (conditional on bootstrap/regtest):
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00980.html

[Bug tree-optimization/70288] ICE with -O1 -fno-tree-dominator-opts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||ice-on-valid-code
  Known to fail||5.3.1, 6.0

--- Comment #3 from Richard Biener  ---
Also fails on trunk in the same way, both ICE and compile-time hog (which I
also confirm).

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[rth at gcc dot gnu.org]

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

--- Comment #22 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 21:23:05 2016
New Revision: 234269

URL: https://gcc.gnu.org/viewcvs?rev=234269&root=gcc&view=rev
Log:
PR target/70048

  * config/aarch64/aarch64.c (virt_or_elim_regno_p): New.
  (aarch64_classify_address): Use it.
  (aarch64_legitimize_address): Force all subexpressions of PLUS
  into registers.  Simplify as (sfp+const)+reg or (reg+reg)+const.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug c/70306] New: wrong code at -O2 and -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu [related to __attribute__((destructor)) and __attribute__((constructor))]

[chengniansun at gmail dot com]

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

Bug ID: 70306
   Summary: wrong code at -O2 and -O3 in 32-bit and 64-bit mode on
x86_64-linux-gnu [related to
__attribute__((destructor)) and
__attribute__((constructor))]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code is miscompiled by the trunk at -O2 and -O3 in 32-bit and
64-bit modes on x86_64-linux-gnu. 

This bug also affects gcc-5.1. 


$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160318 (experimental) [trunk revision 234347] (GCC) 
$: 
$: gcc-trunk -O1 small.c ; ./a.out
A
A
B
B
$: gcc-trunk -O2 small.c ; ./a.out
A
B
$: gcc-4.9 -O3 small.c ; ./a.out
A
A
B
B
$: 
$: cat small.c
int printf(const char *, ...);

__attribute__((constructor))
void A() { printf("A\n"); }

__attribute__((destructor))
void B() { printf("B\n"); }

__attribute__((constructor))
static void C() { printf("A\n"); }

__attribute__((destructor))
static void D() { printf("B\n"); }

int main() { return 0; }
$:

[Bug rtl-optimization/70263] [4.9/5/6 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (segmentation fault)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Had to exposed some kind of latent bug in IRA.  I'll try to take a look
shortly.

[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[hongxu.jia at windriver dot com]

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

--- Comment #3 from hongxu jia  ---
(In reply to Richard Biener from comment #2)
> IMHO it doesn't make sense to prune system header paths here and having them 
> is desired.

Hi Richard,

It is just a simple example to explain the requirements.

In our OpenEmbedded project, we do many cross complication,
and have very complex build path.

Here is the actual use of option '-fdebug-prefix-map' in our project:

DEBUG_FLAGS="-g -feliminate-unused-debug-types
-fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/work/core2-64-poky-linux/service/0.1-r0/service-0.1=/usr/src/service
-fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/work/core2-64-poky-linux/service/0.1-r0/service-0.1=/usr/src/service
-fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/sysroots/x86_64-linux=
-fdebug-prefix-map=/buildarea/raid0/hjia/build-20160316-yocto-buildpath-2/tmp/sysroots/qemux86-64=
"

//Hongxu

[Bug rtl-optimization/70284] ICE: in replace_rtx at rtlanal.c for mips n32

[faraz.shahbazker at imgtec dot com]

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

Faraz Shahbazker  changed:

   What|Removed |Added

 CC||faraz.shahbazker at imgtec dot 
com

--- Comment #2 from Faraz Shahbazker  ---
Created attachment 38008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38008&action=edit
Proposed patch

[Bug lto/70283] New: [6 regression] bogus vtable mismatch warnings

[hubicka at gcc dot gnu.org]

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

Bug ID: 70283
   Summary: [6 regression] bogus vtable mismatch warnings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

While building libreoffice we get:
/aux/hubicka/libreoffice2/core/sw/source/core/attr/calbck.cxx:27:1: note:
virtual method �_ZN2sw16LegacyModifyHintD2Ev.localalias.7�
 sw::LegacyModifyHint::~LegacyModifyHint() {}
 ^
/aux/hubicka/libreoffice2/core/sw/source/core/attr/calbck.cxx:27:1: note: ought
to match virtual method �__comp_dtor � but does not
Makefile:246: recipe for target 'build' failed

This is a conflict between vtable matching and the local alias optimization. We
need to walk aliases before outputting the mismatch.

[Bug c++/70259] [6 Regression] -flifetime-dse=2 bug with empty bases

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/70307] New: [6 Regression] ICE: in gimplify_expr, at gimplify.c:10915 on valid code

[zsojka at seznam dot cz]

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

Bug ID: 70307
   Summary: [6 Regression] ICE: in gimplify_expr, at
gimplify.c:10915 on valid code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-*, aarch64-*, powerpc*-*, sparc*-*, i686-*,
arm*-*

Compiler output:
$ gcc testcase.c
testcase.c: In function 'foo':
testcase.c:6:12: internal compiler error: in gimplify_expr, at gimplify.c:10934
   return i <= (v4si){(0, 0)};
  ~~^
0x8f4d83 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.c:10934
0x8f283d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.c:10907
0x8f3ff7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.c:10807
0x90578c gimplify_modify_expr
/repo/gcc-trunk/gcc/gimplify.c:4721
0x8f3f84 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.c:10190
0x8f7186 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.c:5656
0x8f545e gimplify_and_add
/repo/gcc-trunk/gcc/gimplify.c:425
0x8f545e gimplify_return_expr
/repo/gcc-trunk/gcc/gimplify.c:1359
0x8f545e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.c:10439
0x8f7186 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.c:5656
0x8f83a7 gimplify_bind_expr
/repo/gcc-trunk/gcc/gimplify.c:1142
0x8f4152 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.c:10389
0x8f7186 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.c:5656
0x8f8e96 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.c:11336
0x8f94f6 gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.c:11492
0x755c77 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.c:625
0x7587e0 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.c:1086
0x759a48 symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r234350 - FAIL
r234247 - FAIL
5-branch r234210 - OK

[Bug ipa/70306] [5/6 Regression] wrong code at -O2 and -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu [related to __attribute__((destructor)) and __attribute__((constructor))]

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
  Component|c   |ipa
  Known to work||4.9.0
   Target Milestone|--- |5.4
Summary|wrong code at -O2 and -O3   |[5/6 Regression] wrong code
   |in 32-bit and 64-bit mode   |at -O2 and -O3 in 32-bit
   |on x86_64-linux-gnu |and 64-bit mode on
   |[related to |x86_64-linux-gnu [related
   |__attribute__((destructor)) |to
   |and |__attribute__((destructor))
   |__attribute__((constructor) |and
   |)]  |__attribute__((constructor)
   ||)]
  Known to fail||5.1.0, 6.0

--- Comment #1 from Andrew Pinski  ---
Most likely IPA commoning pass is causing C to become an alias of A and D an
alias of B but not emmitting an extra constructor/deconstructor.

[Bug c++/70286] New: ICE on template specialization

[rippey.e at gmail dot com]

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

Bug ID: 70286
   Summary: ICE on template specialization
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rippey.e at gmail dot com
  Target Milestone: ---

When the following code:

templatestruct A B;
template<>struct B<>:

is run with g++ 5.3.0, with the argument "--std=c++14", the following is
produced:

a.cpp:2:18: internal compiler error: Segmentation fault
 template<>struct B<>:
  ^
0xacecef crash_signal
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/toplev.c:383
0x66180e maybe_process_partial_specialization(tree_node*)
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/pt.c:834
0x696177 cp_parser_class_head
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:20428
0x696177 cp_parser_class_specifier_1
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:19816
0x696177 cp_parser_class_specifier
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:20108
0x696177 cp_parser_type_specifier
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:14727
0x6a9a87 cp_parser_decl_specifier_seq
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:11958
0x6ae998 cp_parser_single_declaration
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:23776
0x6af33d cp_parser_explicit_specialization
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:14623
0x691bbf cp_parser_declaration
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:11332
0x6b87ea cp_parser_declaration_seq_opt
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:11265
0x6b8aff cp_parser_translation_unit
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:4100
0x6b8aff c_parse_file()
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:33229
0x76bb92 c_common_parse_file()
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

A similar report is produced if the compiler is given the flag "--std=c++11":

a.cpp:1:23: warning: variable templates only available with -std=c++14 or
-std=gnu++14
 templatestruct A B;
   ^
a.cpp:2:18: internal compiler error: Segmentation fault
 template<>struct B<>:
  ^
0xacecef crash_signal
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/toplev.c:383
0x66180e maybe_process_partial_specialization(tree_node*)
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/pt.c:834
0x696177 cp_parser_class_head
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:20428
0x696177 cp_parser_class_specifier_1
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:19816
0x696177 cp_parser_class_specifier
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:20108
0x696177 cp_parser_type_specifier
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:14727
0x6a9a87 cp_parser_decl_specifier_seq
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:11958
0x6ae998 cp_parser_single_declaration
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:23776
0x6af33d cp_parser_explicit_specialization
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:14623
0x691bbf cp_parser_declaration
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:11332
0x6b87ea cp_parser_declaration_seq_opt
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:11265
0x6b8aff cp_parser_translation_unit
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:4100
0x6b8aff c_parse_file()
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/cp/parser.c:33229
0x76bb92 c_common_parse_file()
/disk/0/erippey/gcc/objdir/../gcc-5.3.0/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Running gcc 4.8.5 with "--std=c++11" does not produce an ICE.

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 16 17:52:20 2016
New Revision: 234265

URL: https://gcc.gnu.org/viewcvs?rev=234265&root=gcc&view=rev
Log:
PR target/70245
* rtlanal.c (replace_rtx): For REG, if from is a REG,
return to even if only REGNO is equal, and assert
mode is the same.

* g++.dg/opt/pr70245.C: New test.
* g++.dg/opt/pr70245.h: New file.
* g++.dg/opt/pr70245-aux.cc: New file.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr70245-aux.cc
trunk/gcc/testsuite/g++.dg/opt/pr70245.C
trunk/gcc/testsuite/g++.dg/opt/pr70245.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
Consider:
// PR c++/70147
// { dg-do run }
// { dg-options "-fsanitize=vptr" }

static int ac, ad, bc, bd, cc, cd, dc, dd;
struct A { A () { ac++; } virtual void f () {} ~A () { ad++; }; };
struct D { D (int x) { if (x) throw 1; dc++; } ~D () { dd++; } };
struct B : virtual A, D { B () : D (1) { bc++; } virtual void f () {} ~B () {
bd++; } };
struct C : B, virtual A { C () { cc++; } ~C () { cd++; } };

int
main ()
{
  {
try { C c; }
catch (...) {}
  }
  if (ac != 1 || ad != 1 || bc || bd || cc || cd || dc || dd)
__builtin_abort ();
}

This shows that for -fsanitize=vptr this PR is still not resolved, maybe all
the sanitization vptr initializations to NULL need to be guarded with  if there are any virtual bases,
rather than just the initializers of the virtual base vtbl pointers.

But, this also shows the CLOBBER issue.  Above, we have 8 byte long CLOBBER
in A::A, B::B and C::C and 0 byte long CLOBBER in D::D, the whole C is just 8
bytes long.
C::C first clobbers all the 8 bytes (ok), then constructs A::A at the same
address (this clobbers all of the 8 bytes (ok again), and sets the (only)
pointer in there to &_ZTV1A + 16 (ok), then calls B::B subobject ctor on the
same address, and this clobbers 8 bytes at that address again (wrong!, we rely
on the earlier value of the vtable from the A::A ctor), then calls D::D which
throws.  Now, if say we'd e.g. inline the A::A and B::B ctors into C::C, but
not D::D, I think DSE could happily remove the store of &_ZTV1A + 16 into
_vptr.A.

If I modify the testcase to:
static int ac, ad, bc, bd, cc, cd, dc, dd;
struct A { A () { ac++; } virtual void f () {} __attribute__((noinline)) ~A ();
};
struct D { __attribute__((noinline)) D (int); ~D () { dd++; } };
struct B : virtual A, D { B () : D (1) { bc++; } virtual void f () {} ~B () {
bd++; } };
struct C : B, virtual A { C () { cc++; } ~C () { cd++; } };

D::D (int x)
{
  if (x) throw 1;
  dc++;
}

__attribute__((noinline, noclone)) void
foo (A *p)
{
  p->f ();
}

A::~A ()
{
  foo (this);
  ad++;
}

int
main ()
{
  {
try { C c; }
catch (...) {}
  }
  if (ac != 1 || ad != 1 || bc || bd || cc || cd || dc || dd)
__builtin_abort ();
}

then indeed I see e.g. in phicprop1:
  MEM[(struct  &)&c] ={v} {CLOBBER};
  MEM[(struct A *)&c]._vptr.A = &MEM[(void *)&_ZTV1A + 16B];
  ac.11_20 = ac;
  _21 = ac.11_20 + 1;
  ac = _21;
  MEM[(struct  &)&c] ={v} {CLOBBER};
  D::D (&c.D.2413, 1);
and in the following dse2:
  ac.11_20 = ac;
  _21 = ac.11_20 + 1;
  ac = _21;
  MEM[(struct  &)&c] ={v} {CLOBBER};
  D::D (&c.D.2413, 1);
so the _vptr.A initialization is gone.  The reason why this testcase doesn't
abort is that the destructor A::~A as the first thing it does is it changes the
_vptr.A again to &_ZTV1A + 16B.

Are so problematic only empty classes with virtual bases, or when exactly can
this happen?  When I've added fields to all 4, A would not overlap with B and
this wouldn't be an issue.

[Bug tree-optimization/70252] ICE in vect_get_vec_def_for_stmt_copy with -O3 -march=skylake-avx512.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #3 from Ilya Enkovich  ---
Well, for now we have only two scalar masks sharing the same mode.  It means we
may handle them by changing appropriate optabs from direct to conversion type
and having separate entries for QI<->QI and QI<->HI cases.  But if we have two
elements scalar mask added for some target then it can't work.  Also we have a
common code used for multiple conversion cases and changing one of optabs would
break it.

For now we should just reject conversion cases involving different masks
sharing the same mode (we don't have conversion patterns for them anyway).

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
I should point out that there is a proposed standard way of controlling 
various floating-point optimizations, in the form of pragmas in draft TS 
18661-5 (current public draft N2004) (in this case, the 
FENV_ALLOW_ASSOCIATIVE_LAW pragma).

That said, part 5 should be considered by far the most experimental and 
difficult to implement part of TS 18661, and given the limited interest 
seen so far in implementing C99/C11 Annex F or most of the parts of TS 
18661, I wouldn't expect anything from part 5 to be implemented any time 
soon by GCC (or by any other implementation - limited interest in this 
area goes beyond just GCC).

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
Yes, I think we need to do that, because even if glibc were to change that
wouldn't help on non-gnu targets.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to psturm from comment #7)
> Created attachment 38007 [details]
> test suite summary
> 
> I built hjl/pr70150 branch and while the prior test suite failures are gone,
> 6 new ones appeared. Full test suite summary is attached.
> 
> Running target unix
> FAIL: g++.dg/ext/label13a.C  -std=gnu++98 execution test
> FAIL: g++.dg/ext/label13a.C  -std=gnu++98  scan-assembler _ZN1CC4Ev
> FAIL: g++.dg/ext/label13a.C  -std=gnu++11 execution test
> FAIL: g++.dg/ext/label13a.C  -std=gnu++11  scan-assembler _ZN1CC4Ev
> FAIL: g++.dg/ext/label13a.C  -std=gnu++14 execution test
> FAIL: g++.dg/ext/label13a.C  -std=gnu++14  scan-assembler _ZN1CC4Ev

Do you get them without --enable-default-pie?

[Bug target/70113] [AArch64] -mpc-relative-literal-loads conflicts with fix-cortex-a53-843419

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed on trunk.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #9 from psturm at computervoice dot com ---
I didn't finish the full system build with --enable default-pie yet. I'll build
it without next and let you know.

[Bug c++/70299] New: pow(long double, int) gives more imprecise result than pow(long double,long double) in c++03 mode

[b7.10110111 at gmail dot com]

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

Bug ID: 70299
   Summary: pow(long double, int) gives more imprecise result than
pow(long double,long double) in c++03 mode
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

The following example program appears to get different results for different
overloads of std::pow(), even though all the parameters don't lose precision on
call:

#include 
#include 
#include 

int main()
{
std::cout.precision(std::numeric_limits::digits10+3); //
=max_digits10
std::cout << "pow(long double, int) :" << std::pow(10.L,-4823) <<
"\n";
std::cout << "pow(long double, long double): " << std::pow(10.L,-4823.L) <<
"\n";
}

Its output in -std=c++03 mode:
pow(long double, int) :1.0288e-4823
pow(long double, long double): 1.0005e-4823

And in -std=c++11 and -std=c++14 mode it's correct:
pow(long double, int) :1.0005e-4823
pow(long double, long double): 1.0005e-4823

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
The problem in case for is in the l.h.s. of the assignment, not the r.h.s:

program p
   complex :: z[*]
   real:: x[*], y
!  z = x / cmplx(0.0, x)
   z = 1 / cmplx(y)
end

pr69604-z4.f90:5:0:

z = 1 / cmplx(y)

internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
0x82f7280 gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*,
tree_node*)
../../trunk/gcc/fortran/trans.c:158
0x82f72e9 gfc_add_modify(stmtblock_t*, tree_node*, tree_node*)
../../trunk/gcc/fortran/trans.c:170
0x833c0dd gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool)
../../trunk/gcc/fortran/trans-expr.c:8292
0x8344590 gfc_trans_assignment_1
../../trunk/gcc/fortran/trans-expr.c:9378
0x834f008 gfc_trans_assign(gfc_code*)
../../trunk/gcc/fortran/trans-expr.c:9551
0x82fc257 trans_code
../../trunk/gcc/fortran/trans.c:1680
0x82fc8d3 gfc_trans_code(gfc_code*)
../../trunk/gcc/fortran/trans.c:1991
0x8331e06 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6140
0x82fc90e gfc_generate_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:2008
0x82a67d3 translate_all_program_units
[...]

[Bug target/70290] -mavx512vl breaks parsing of C++ vector condition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
 CC||ienkovich at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Probably because of vector bool representation.

[Bug libstdc++/70299] pow(long double, int) gives more imprecise result than pow(long double,long double) in c++03 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
The GCC docs for __builtin_powil says "Unlike the pow function no guarantees
about precision and rounding are made."

So I suppose we should switch the C++03 pow(floating-point-type, int) functions
to use a better built-in.

[Bug c++/70272] New: [5/6 Regression] -flifetime-dse miscompilation starting with r217967

[jakub at gcc dot gnu.org]

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

Bug ID: 70272
   Summary: [5/6 Regression] -flifetime-dse miscompilation
starting with r217967
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct Empty { };
struct A { A() : a(true) { } bool a; ~A() { if (!a) __builtin_abort(); } };
struct B : Empty { B() : Empty() { } ~B() { } };
struct C : A, B { C() : A(), B() { } ~C() { } };
int main() {
  C c;
}

is miscompiled at -O2 starting with r217967.
This is the dtor counterpart of PR70259.

[Bug c++/70205] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This patch makes us compile the testcase and also passes dg.exp testsuite.  But
my understanding of BASELINK stuff is too weak to gauge whether this is
reasonable approach.

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8125,6 +8125,10 @@ build_new_method_call_1 (tree instance, tree fns,
vec **args,
   /* Dismantle the baselink to collect all the information we need.  */
   if (!conversion_path)
 conversion_path = BASELINK_BINFO (fns);
+
+  if (conversion_path == error_mark_node)
+return error_mark_node;
+
   access_binfo = BASELINK_ACCESS_BINFO (fns);
   binfo = BASELINK_BINFO (fns);
   optype = BASELINK_OPTYPE (fns);

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[shatz at dsit dot co.il]

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

--- Comment #8 from shatz at dsit dot co.il ---
Now a bit of philosophy.

Bugs aside, I should say that use of function attribute optimize() does not
look to me as an ideal solution for forcing ISO rules.
>From theoretical point of view, when we are specifying -Ofast or -ffast-math we
are no longer coding in C, but in programming language that looks like C, but
semantically is more close to Fortran. In this new language a specific grouping
of FP arithmetic ops is by default undefined. So, in this new language, we need
a construct that makes it defined again. Something like built-in function
__iso_order().

So, my test case will look like:
double foo1(double h, double l)
{
  double s = __iso_order(h + 1.0);
  return __iso_order(__iso_order(1.0 - s) + h) + l;
}

It has two advantages
1) Makes an intention of programmer more pronounced, which is always a good
thing
2) provides finer level of control than the whole function.
Because typically when I care about grouping of ops I only care about few
specific statements and don't care about the rest which tends to be a majority
even in a specific function.

[Bug c++/70301] missing diagnostic on taking the address of a temporary

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-19
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Marc Glisse  ---
It would make the testcase a bit more convincing if you actually used those
pointers. Just taking the address is dead code. For instance, if you try to
read *p, you will get:

  D.2276 = f ();
  D.2276 ={v} {CLOBBER};
  _6 = MEM[(int *)&D.2276];

which we should diagnose in the middle-end (there are a couple PRs about it).
If you just call an unknown function on the pointer:

  D.2264 = f ();
  D.2264 ={v} {CLOBBER};
  fun (&D.2264.a);

(or if you try to write to *p instead of reading) then it looks like the
middle-end cannot do anything, as it lost the information that the memory
location is gone, not just its content, and we could have valid code (running a
destructor, then placement new) that looks the same in gimple. So it does look
like the C++ FE is the only place where we could warn.

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Looking at 20011029-1.c -Os on ppc64le, replace_rtx is called from
rs6000_frame_related from rs6000_emit_prologue, on a large parallel containing
(use (reg:DI 12 12))
and from is:
(reg:DI 12 12)
(but not pointer equal) and to is:
(plus:DI (reg/f:DI 1 1)
(const_int -144 [0xff70]))
I'm going to revert the rtlanal.c change and we need a new function with the
new behavior and sort this out later.

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #1 from Ilya Enkovich  ---
Confirm.  The problem is that

vect_patt_50.39_93 = VEC_COND_EXPR ;
vect__17.44_98 = vect_patt_50.39_93 + vect__16.43_97;

is replaced with:

_1 = VIEW_CONVERT_EXPR(mask_patt_51.38_90);
vect__17.44_98 = vect__16.43_97 - _1;

which works for vector masks but doesn't work for scalar masks.

[Bug rtl-optimization/69047] memcpy of 64-bit integer to 32-bit integer causes pointless stack operations on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target|arm |arm, aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
True on both arm and aarch64.

[Bug middle-end/70280] New: -fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw

[zsojka at seznam dot cz]

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

Bug ID: 70280
   Summary: -fcompare-debug failure (length) with
--param=integer-share-limit=4016 -mavx512bw
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ gcc --param=integer-share-limit=4016 -mavx512bw -fcompare-debug
testcase-min4.c
...
gcc: error: testcase-min4.c: -fcompare-debug failure (length)

$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-234258-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-234258-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20160316 (experimental) (GCC) 


$ diff -u /tmp/ccjXoibm.gkd /tmp/ccv30gMz.gk.gkd
--- /tmp/ccjXoibm.gkd   2016-03-17 17:05:30.128234688 +0100
+++ /tmp/ccv30gMz.gk.gkd2016-03-17 17:05:36.668234748 +0100
@@ -10658,7 +10658,7 @@
 0:   extern int va_start ();
 4:   extern int va_end ();
 1:   struct  args[1];
-2:   static int BIO_vsnprintf (char *, size_t, const char *, struct  *, void,
...);
+2:   static int BIO_vsnprintf (char *, size_t, const char *, struct  *);
 7:   void ;

 ;; Function BIO_snprintf (BIO_snprintf, funcdef_no=12, cgraph_uid=12,
symbol_order=12)


The file is auto-reduced from openssl-1.0.1h  b_print.c, licensed under SSLeay
( https://www.openssl.org/source/license.txt ) (likely not GPL compatible).

Each iteration of delta removes a few lines, but reducing the testcase is very
slow and the testcase is still quite long (now after 4 delta iterations).


Fails both gcc-5-branch and gcc-trunk; gcc-4_9-branch doesn't support
-mavx512bw.

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #5)

The patch in comment #5 regtests without new failures.

It appears that a testcase based on comment #4 is sufficient:

Index: gcc/testsuite/gfortran.dg/pr68566.f90
===
--- gcc/testsuite/gfortran.dg/pr68566.f90   (revision 0)
+++ gcc/testsuite/gfortran.dg/pr68566.f90   (revision 0)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/68566 - ICE on using unusable array in reshape
+! Testcase by Gerhard Steinmetz 
+
+program p
+  integer, parameter :: a(:)   = 1  ! { dg-error "or of deferred shape" }
+  integer, parameter :: b(2,2) = reshape([a], [2,2])
+end

[Bug tree-optimization/70274] optimization goes astray and adds completely redundant code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-17
 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yes.  It's SCCP that runs and does this transform independently of whether
it makes the loop "dead" or whether it enables other transforms such as
vectorization.

IMHO it should be re-written as a tool used by transforms it enables.

[Bug c++/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 18 07:59:36 2016
New Revision: 234319

URL: https://gcc.gnu.org/viewcvs?rev=234319&root=gcc&view=rev
Log:
PR c++/70267
* init.c (build_new_1): Complain and return error_mark_node
if alloc_fn is not _Jv_AllocObject function returning pointer.

* g++.dg/ext/java-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/java-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/70289] [openacc] ICE in input_varpool_node

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-18
   Assignee|unassigned at gcc dot gnu.org  |cesar at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
On gomp-4_0-branch:

lto1: error: Missing 'temp2'
lto1: fatal error: errors during merging of translation units
compilation terminated.
mkoffload: fatal error:
build-gcc/gcc/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status
compilation terminated.
lto-wrapper: fatal error: build-gcc/gcc//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
[...]/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

As far as I can tell, the difference of ICE vs. error is due to Cesar's

(which isn't in trunk) -- but I don't understand why we're seeing this error to
begin with: from a quick glance at least, the test case looks like valid
OpenACC code?

[Bug c++/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |c++

--- Comment #3 from Richard Biener  ---
(gdb) p debug_gimple_stmt (stmt)
# VUSE <.MEM_3>
f.0_4 = (struct Foo *) D.2296;

is not valid gimple (but we fail to diagnose this).  It converts

 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x769dfb28
fields 
public static external nonlocal decl_3 decl_5 decl_6 VOID file t.C
line 24 col 34
align 8 context 
chain > context 
full-name "class java::lang::Foo"
X() n_parents=1 use_template=0 interface-unknown
pointer_to_this  chain >
ignored QI file t.C line 33 col 29 size  unit
size 
align 8 context  chain >

to (struct Foo *).

  (void) (f = (struct Foo *) TARGET_EXPR )

maybe a ADDR_EXPR is missing around the TARGET_EXPR?

Frontend issue.  At -O0 we end up with

  :
  _Jv_AllocObject (&_ZN4java4lang3Foo6class$E);
  f.0_4 = (struct Foo *) D.2296;
  f = f.0_4;
  f.1_6 = f;
  _Jv_Throw (f.1_6);

which obviously is bullshit.

[Bug target/70296] Incorrect handling of vector X; if X is function-like macro

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target||powerpc*-linux*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug c++/70139] [5/6 Regression] -fno-ellide-constructor makes static std::regex to throw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Slightly more reduced:
template
struct A
{
  T a;
  U b;
  constexpr A () : a (), b () { }
  constexpr A (const T &x, const U &y) : a (x), b (y) { }
};
struct B
{
  constexpr B (const bool x) : c (x) {}
  constexpr bool operator!= (const B x) const { return c != x.c; }
  bool c;
};
constexpr static A d[] = { { B (true), nullptr }, { B (false), nullptr }
};
static_assert (d[0].a != d[1].a, "");

[Bug c++/70299] pow(long double, int) gives more imprecise result than pow(long double,long double) in c++03 mode

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The difference is due to a change between C++03 and C++11, see
http://cplusplus.github.io/LWG/lwg-defects.html#550, but I don't know why the
calls to __builtin_powl and __builtin_powil should give different results.

[Bug rtl-optimization/70261] New: r234265 causes fails on rs6000

[segher at gcc dot gnu.org]

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

Bug ID: 70261
   Summary: r234265 causes fails on rs6000
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

After r234265 we are seeing ICEs on building various packages, and on
bootstrap too.  A simple testcase:

===
void fn1(unsigned);
void fn2(int p1) { fn1(p1); }
===

which gives

===
$ time ~/build/tot-master/gcc/cc1plus -quiet -Wall -W -O2 break.c   
break.c: In function 'void fn2(int)':
break.c:2:29: internal compiler error: in replace_rtx, at rtlanal.c:2969
 void fn2(int p1) { fn1(p1); }
 ^
0x10f18a53 replace_rtx(rtx_def*, rtx_def*, rtx_def*)
/home/segher/src/gcc/gcc/rtlanal.c:2969
0x10f18b57 replace_rtx(rtx_def*, rtx_def*, rtx_def*)
/home/segher/src/gcc/gcc/rtlanal.c:2991
0x119db3c3 record_value_for_reg
/home/segher/src/gcc/gcc/combine.c:12707
0x119db887 record_dead_and_set_regs_1
/home/segher/src/gcc/gcc/combine.c:12807
0x10f153af note_stores(rtx_def const*, void (*)(rtx_def*, rtx_def const*,
void*)
, void*)
/home/segher/src/gcc/gcc/rtlanal.c:1860
0x119dbd73 record_dead_and_set_regs
/home/segher/src/gcc/gcc/combine.c:12888
0x119b06a7 combine_instructions
/home/segher/src/gcc/gcc/combine.c:1488
0x119e0bcb rest_of_handle_combine
/home/segher/src/gcc/gcc/combine.c:14379
0x119e0d1b execute
/home/segher/src/gcc/gcc/combine.c:14422
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
===

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #7 from Richard Biener  ---
The bswap pass could learn to split this up into two loads and bswaps and
combine the results with a single shift and or.

[Bug driver/70192] -fno-pic doesn't work with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #7 from psturm at computervoice dot com ---
Built hjl/pr70192 both with and without --enable-default-pie. The test results
were almost identical, the only difference being the number of test cases run.
gcc didn't have any issues, but g++ had a couple of new unresolved test cases.
I am not sure if these are related or not, so here is the summary:

=== g++ tests ===


Running target unix
UNRESOLVED: g++.dg/cpp1y/constexpr-instantiate.C  -std=c++11  scan-tree-dump
optimized "bool [fg]("
UNRESOLVED: g++.dg/cpp1y/constexpr-instantiate.C  -std=c++14  scan-tree-dump
optimized "bool [fg]("
XPASS: g++.dg/tls/thread_local-order2.C  -std=c++11 execution test
XPASS: g++.dg/tls/thread_local-order2.C  -std=c++14 execution test

=== g++ Summary ===

# of expected passes103233
# of unexpected successes   2
# of expected failures  285
# of unresolved testcases   2
# of unsupported tests  3673
/sources/gcc-build/gcc/testsuite/g++/../../xg++  version 6.0.0 20160316
(experimental) (GCC) 

=== gcc tests ===


Running target unix

=== gcc Summary ===

# of expected passes112137
# of expected failures  311
# of unsupported tests  1705
/sources/gcc-build/gcc/xgcc  version 6.0.0 20160316 (experimental) (GCC)

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-17
 CC||rth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Henderson  ---
This also fails on aarch64 stage1 libstdc++, also during combine.

#1  0x0100dc90 in replace_rtx (x=0x3ffad2b58f8, from=0x3ffad2b1cb0, 
to=0x3ffad2b5910) at ../../git-rh/gcc/rtlanal.c:2969
2969  gcc_assert (GET_MODE (x) == GET_MODE (from));
(gdb) call debug_rtx(x)
(reg:CC_NZ 66 cc)
(gdb) call debug_rtx(from)
(reg:CC 66 cc)

I'll attach the preprocessed for reference.

[Bug libquadmath/68686] tgammaq(x) is always negative for noninteger x < 0

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-17
 Depends on||65757
 Ever confirmed|0   |1

--- Comment #3 from kargl at gcc dot gnu.org ---
This may be fixed by updating libquadmath as suggested by Joseph in PR65757.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
[Bug 65757] gfortran gives incorrect result for anint with real*16 argument

[Bug tree-optimization/70144] [4.9/5/6 Regression] g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref"

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 17 15:58:22 2016
New Revision: 234297

URL: https://gcc.gnu.org/viewcvs?rev=234297&root=gcc&view=rev
Log:
PR c++/70144
* cp-tree.h (magic_varargs_p): Return int instead of bool.
* call.c (magic_varargs_p): Return int instead of bool, return 2 for
Cilk+ reductions, otherwise 1 for magic varargs and 0 for normal
varargs.
(build_over_call): If magic_varargs_p == 2, call reject_gcc_builtin,
if magic_varargs_p == 1, call decay_conversion
instead of mark_type_use.  Don't store error_mark_node arguments to
argarray, instead return error_mark_node.

* c-c++-common/pr70144-1.c: New test.
* c-c++-common/pr70144-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr70144-1.c
trunk/gcc/testsuite/c-c++-common/pr70144-2.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/testsuite/ChangeLog

[Bug target/70232] [6 regression] excessive stack usage with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
So, except for at most 16 bytes regressions, there were just 2 commits that
made the #c0 testcase use significantly more stack,
r227307 from 140 to 604 and r229685 from 612 to 1152, both FSM related.

[Bug middle-end/68215] [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:10 2016
New Revision: 234272

URL: https://gcc.gnu.org/viewcvs?rev=234272&root=gcc&view=rev
Log:
Revert r231575

  PR middle-end/70240
  PR middle-end/68215
  2015-12-11  Eric Botcazou  
  * tree-vect-generic.c (tree_vec_extract): Remove GSI parameter.
  Do not gimplify the result.
  (do_unop): Adjust call to tree_vec_extract.
  (do_binop): Likewise.
  (do_compare): Likewise.
  (do_plus_minus): Likewise.
  (do_negate): Likewise.
  (expand_vector_condition): Likewise.
  (do_cond): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug c/70093] Instancing function with VM return type cases internal compiler error in 'assign_stack_temp_for_type'.

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Wed Mar 16 15:51:47 2016
New Revision: 234259

URL: https://gcc.gnu.org/viewcvs?rev=234259&root=gcc&view=rev
Log:
PR c/70093
* c-typeck.c (build_function_call_vec): Create a TARGET_EXPR for
nested functions returning VM types.

* cgraphunit.c (cgraph_node::expand_thunk): Also build call to the
function being thunked if the result type doesn't have fixed size.
* gimplify.c (gimplify_modify_expr): Also set LHS if the result type
doesn't have fixed size.

* gcc.dg/nested-func-10.c: New test.
* gcc.dg/nested-func-9.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/nested-func-10.c
trunk/gcc/testsuite/gcc.dg/nested-func-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cgraphunit.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/69766] go.test/test/env.go fails on biarch

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #4 from Ian Lance Taylor  ---
This is fixed by your patch, I think.  Let me know if not.

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[shatz at dsit dot co.il]

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

--- Comment #7 from shatz at dsit dot co.il ---
(In reply to Richard Biener from comment #1)
> Confirmed.  The issue seems to be that you add the optimize attribute after
> the function definition.
> 
> This causes .original to be already
> 
> ;; Function foo1 (null)
> ;; enabled by -tree-original
> 
> 
> {
>   double s = h + 1.0e+0;
> 
> double s = h + 1.0e+0;
>   return ((h - s) + l) + 1.0e+0;
> }
> 
> which is probably an artifact of fully delayed folding.
> 
> The optimize attribute is still applied in the end but too late.
> 
> Workaround is to put
> 
> double foo1(double h, double l)
> __attribute__((optimize("no-associative-math")));
> 
> before the definition.

Thank you for the tip.

[Bug c/70308] New: memset generates rep stosl instead of rep stosq

[socketpair at gmail dot com]

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

Bug ID: 70308
   Summary: memset generates rep stosl instead of rep stosq
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: socketpair at gmail dot com
  Target Milestone: ---

Consider this program:

=
#include 
#include 
#include 

int main() {
char buf[128];
if (scanf("%s", buf) != 1)   return 42;
memset(buf,0, 128);
asm volatile("": : :"memory");
return 0;
}
==
compile with -O3

and you will see, that memset is translated to "rep stosl". good.

Next, comment line with scanf() and compile again

and you will see, that memset is translated to "rep stosq", which is much
faster.

So, I consider that gcc should emit "rep stosq" in both cases.

[Bug rtl-optimization/69047] memcpy of 64-bit integer to 32-bit integer causes pointless stack operations on ARM

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
Might be related to PR36409 and PR49157

[Bug c++/70285] [6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I would like to have a look but first I need to wrap up something else -- so
I'll take it unless someone else beats me.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Component|c   |testsuite

--- Comment #6 from H.J. Lu  ---
They should be fixed on hjl/pr70150 branch in GCC git repo.

[Bug rtl-optimization/70278] [6 regression] LRA ICE on trunk for ARM Thumb1 with Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-17
 CC||ramana at gcc dot gnu.org
Summary|LRA ICE on trunk for ARM|[6 regression] LRA ICE on
   |Thumb1 with Os  |trunk for ARM Thumb1 with
   ||Os
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
confirmed.

[Bug libstdc++/70276] New: Writing to standard output concurrently through `std::cout` triggers a datarace

[stefan at vectorfabrics dot com]

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

Bug ID: 70276
   Summary: Writing to standard output concurrently through
`std::cout` triggers a datarace
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at vectorfabrics dot com
  Target Milestone: ---

Consider the following C++11 program:

  #include  
  #include  
  #include  

  int main() 
  { 
std::future future = 
  std::async(std::launch::async, []() { std::cout << "foo" << std::endl;
}); 
std::cout << "bar" << std::endl; 
future.wait(); 

return EXIT_SUCCESS; 
  }

This program exhibits a datarace for the member variable
`std::ios_base::_M_width` of `std::cout`.

For example, Pareon Verify reports (some details elided for clarity):

  [M0108] Data race(s) detected:
an object of size 272
is concurrently accessed by
the write in
  function ios_base::width at .../include/bits/ios_base.h:656
  called from function std::__ostream_insert at
.../include/bits/ostream_insert.h:102
  called from function std::operator<< at .../include/ostream:535
  called from function main at test.cpp:9
  ^^^ application start ^^^
performing 1 access of size 8 at an offset of 24 bytes from the start of
the object
and the read in
  function ios_base::width at .../include/bits/ios_base.h:645
  called from function std::__ostream_insert at
.../include/bits/ostream_insert.h:87
  called from function std::operator<< at .../include/ostream:535
  ...
  called from function execute_native_thread_routine at .../thread.cc:84
  ^^^ thread start ^^^
  called from function pthread_create
  ...
  called from function std::async at include/c++/4.9.2/future:1580
  called from function main at test.cpp:8
  ^^^ application start ^^^
performing 1 access of size 8 at an offset of 24 bytes from the start of
the object

Helgrind produces a similar (albeit somewhat more cryptic) message.

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 16 Mar 2016, ienkovich at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
> 
> --- Comment #2 from Ilya Enkovich  ---
> Here is a responsible match.pd pattern:
> 
> /* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C), since vector comparisons
>return all-1 or all-0 results.  */
> /* ??? We could instead convert all instances of the vec_cond to negate,
>but that isn't necessarily a win on its own.  */
> (simplify
>  (plus:c @3 (view_convert? (vec_cond @0 integer_each_onep@1 integer_zerop@2)))
>  (if (VECTOR_TYPE_P (type)
>   && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
>   && (TYPE_MODE (TREE_TYPE (type))
>   == TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)
>   (minus @3 (view_convert @0
> 
> I propose this patch:
> 
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 112deb3..7245ff4 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -1759,6 +1759,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (simplify
>   (plus:c @3 (view_convert? (vec_cond @0 integer_each_onep@1 
> integer_zerop@2)))
>   (if (VECTOR_TYPE_P (type)
> +  && VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0)))
>&& TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
>&& (TYPE_MODE (TREE_TYPE (type))
>== TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)
> @@ -1768,6 +1769,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (simplify
>   (minus @3 (view_convert? (vec_cond @0 integer_each_onep@1 integer_zerop@2)))
>   (if (VECTOR_TYPE_P (type)
> +  && VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0)))
>&& TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
>&& (TYPE_MODE (TREE_TYPE (type))
>== TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)

Looks good to me.

[Bug c/70264] New: ICE at -O0 to -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (compatible_locations_p, at diagnostic-show-locus.c:490)

[chengniansun at gmail dot com]

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

Bug ID: 70264
   Summary: ICE at -O0 to -O3 in both 32-bit and 64-bit modes on
x86_64-linux-gnu (compatible_locations_p, at
diagnostic-show-locus.c:490)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160316 (experimental) [trunk revision 234270] (GCC) 
$: 
$: gcc-trunk small.c
small.c:1:11: error: expected identifier or ‘(’ before numeric constant

small.c:1:11: internal compiler error: in compatible_locations_p, at
diagnostic-show-locus.c:490
small.c:2:1: note: in expansion of macro ‘X’
 X
 ^
0x1317e8d compatible_locations_p
../../gcc-source-trunk/gcc/diagnostic-show-locus.c:490
0x131884a layout
../../gcc-source-trunk/gcc/diagnostic-show-locus.c:609
0x1318cdf diagnostic_show_locus(diagnostic_context*, diagnostic_info const*)
../../gcc-source-trunk/gcc/diagnostic-show-locus.c:1102
0x6b6960 c_diagnostic_finalizer
../../gcc-source-trunk/gcc/c-family/c-opts.c:167
0x1316019 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc-source-trunk/gcc/diagnostic.c:828
0x1316e95 error(char const*, ...)
../../gcc-source-trunk/gcc/diagnostic.c:1154
0x699f7c c_parse_error(char const*, cpp_ttype, tree_node*, unsigned char)
../../gcc-source-trunk/gcc/c-family/c-common.c:10138
0x6421ec c_parser_direct_declarator
../../gcc-source-trunk/gcc/c/c-parser.c:3485
0x6421ec c_parser_declarator
../../gcc-source-trunk/gcc/c/c-parser.c:3369
0x64a6fb c_parser_declaration_or_fndef
../../gcc-source-trunk/gcc/c/c-parser.c:1815
0x654cae c_parser_external_declaration
../../gcc-source-trunk/gcc/c/c-parser.c:1548
0x6557b9 c_parser_translation_unit
../../gcc-source-trunk/gcc/c/c-parser.c:1429
0x6557b9 c_parse_file()
../../gcc-source-trunk/gcc/c/c-parser.c:17840
0x6b9512 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$: 
$: cat small.c
#define X __LINE__
X
$:

[Bug ipa/70269] [5/6 Regression] ICE with -fdump-ipa-pta-graph -fipa-pta

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-17
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from vries at gcc dot gnu.org ---
trunk stage 4/ branch 5 approved:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00975.html

[Bug target/70296] New: Incorrect handling of vector X; if X is function-like macro

[jakub at gcc dot gnu.org]

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

Bug ID: 70296
   Summary: Incorrect handling of vector X; if X is function-like
macro
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

#define c(x) x
#define f(x)
#define i int
#define k
typedef int vector;
vector int a;
vector b;
vector c(int) d;
vector c(e);
vector c;
vector f(int) int g;
vector f(int) h;
vector i j;
vector k int l;
vector k m;

void
foo ()
{
  vector int *p;
  p = &a;
  p = &d;
  p = &g;
  p = &j;
  p = &l;
  int *q;
  q = &b;
  q = &e;
  q = &c;
  q = &h;
  q = &m;
}

fails to compile on powerpc* with -maltivec -std=gnu11 (or any other options
where altivec and the vector built-in macro handling are not disabled).
The bug is in calling cpp_get_node, even when we aren't sure the function-like
macro has any arguments, so the token gets dropped on the floor.

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[bernd.edlinger at hotmail dot de]

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

--- Comment #26 from Bernd Edlinger  ---
I just fail to understand why we cannot just clobber the whole
object once in the in-charge constructor,
then if sanitizing vptrs initialize every vptr once to zero.
and skip all the clobber and vptr initializing on the
not in-charge constructors.

That would make just more sense.


Bernd.

[Bug testsuite/70227] pr69589 does not check for -rdynamic availability

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #1 from Ramana Radhakrishnan  ---
confirmed.

[Bug c/70309] New: wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[chengniansun at gmail dot com]

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

Bug ID: 70309
   Summary: wrong code at -O2 and -O3 in both 32-bit and 64-bit
modes on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code is miscompiled by the trunk at -O2 and -O3 in both 32-bit
and 64-bit modes on x86_64-linux-gnu.

This bug also affects gcc-4.8 and later versions. gcc-4.7 is okay.


$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160319 (experimental) [trunk revision 234350] (GCC) 
$: 
$: gcc-trunk -O2 small.c ; ./a.out ; echo $?
1
$: gcc-trunk -O1 small.c ; ./a.out ; echo $?
0
$: gcc-4.8 -O3 small.c ; ./a.out ; echo $?
1
$: cat small.c
typedef struct {
unsigned b0:1;
unsigned b1:1;
unsigned b2:1;
unsigned b3:1;
unsigned b4:1;
unsigned b5:1;
unsigned b6:1;
unsigned b7:1;
unsigned b8:1;
unsigned b9:1;
unsigned b10:1;
unsigned b11:1;
unsigned b12:1;
unsigned b13:1;
unsigned b14:1;
unsigned b15:1;
} BitField;

BitField BA;
unsigned short *pA = (unsigned short *) &BA;
BitField BB;
unsigned short *pB = (unsigned short *) &BB;

char * fn(void)
{
if (BA.b11) {
if (BB.b11)
return "F";
else
return "S";
} else
return "F";
}

int
main (void)
{
*pA = 0xedcb;
*pB = 0x1234;
return fn ()[0] == 'F';
}

$:

[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304

[law at redhat dot com]

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

--- Comment #20 from Jeffrey A. Law  ---
And FWIW, the test in this BZ is totally compromised on the trunk.  Two primary
reasons.  First DOM does a much better job at finding & eliminating redundant
loads.   Second, erroneous path isolation finds a store to *0, it wipes out the
RHS of that store allowing massive cleanups by DCE.

I'll see if I can reasonably derive a testcase from 68654.

[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #8 from Ilya Enkovich  ---
Fixed by r234283.

[Bug rtl-optimization/70284] New: ICE: in replace_rtx at rtlanal.c for mips n32

[faraz.shahbazker at imgtec dot com]

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

Bug ID: 70284
   Summary: ICE: in replace_rtx at rtlanal.c for mips n32
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: faraz.shahbazker at imgtec dot com
  Target Milestone: ---

Created attachment 38005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38005&action=edit
Minimal test case

New assert in commit 867c9e995539beefa594475f2bd831438e36a077 causes ICE for
mips64 n32. Minimal test-case attached, failure found while building glibc.

$ ./install-mips-mti-linux-gnu/bin/mips-mti-linux-gnu-gcc -v -save-temps
-mips64 -mabi=n32 -O2 -c test.c
Using built-in specs.
COLLECT_GCC=./install-mips-mti-linux-gnu/bin/mips-mti-linux-gnu-gcc
Target: mips-mti-linux-gnu
Configured with: /scratch/frs/src/gcc/configure
--prefix=/scratch/frs/install-mips-mti-linux-gnu --disable-libssp
--disable-libmudflap --disable-decimal-float --with-mips-plt
--target=mips-mti-linux-gnu --enable-languages=c --without-headers
--disable-shared --disable-threads --disable-libquadmath --disable-libatomic
--with-sysroot=/scratch/frs/install-mips-mti-linux-gnu/sysroot --enable-debug
Thread model: single
gcc version 6.0.0 20160317 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mips64' '-mabi=n32' '-O2' '-c'
'-mllsc' '-mplt' '-mno-synci' '-mno-shared' '-EB'

/scratch/frs/install-mips-mti-linux-gnu/libexec/gcc/mips-mti-linux-gnu/6.0.0/cc1
-E -quiet -v -isysroot
/scratch/frs/install-mips-mti-linux-gnu/sysroot/mips-r1-hard test.c -meb
-mips64 -mabi=n32 -mllsc -mplt -mno-synci -mno-shared -O2 -fpch-preprocess -o
test.i
ignoring nonexistent directory
"/scratch/frs/install-mips-mti-linux-gnu/sysroot/mips-r1-hard/usr/local/include"
ignoring nonexistent directory
"/scratch/frs/install-mips-mti-linux-gnu/lib/gcc/mips-mti-linux-gnu/6.0.0/../../../../mips-mti-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/scratch/frs/install-mips-mti-linux-gnu/lib/gcc/mips-mti-linux-gnu/6.0.0/include

/scratch/frs/install-mips-mti-linux-gnu/lib/gcc/mips-mti-linux-gnu/6.0.0/include-fixed
 /scratch/frs/install-mips-mti-linux-gnu/sysroot/mips-r1-hard/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mips64' '-mabi=n32' '-O2' '-c'
'-mllsc' '-mplt' '-mno-synci' '-mno-shared' '-EB'

/scratch/frs/install-mips-mti-linux-gnu/libexec/gcc/mips-mti-linux-gnu/6.0.0/cc1
-fpreprocessed test.i -meb -quiet -dumpbase test.c -mips64 -mabi=n32 -mllsc
-mplt -mno-synci -mno-shared -auxbase test -O2 -version -o test.s
GNU C11 (GCC) version 6.0.0 20160317 (experimental) (mips-mti-linux-gnu)
compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-16), GMP
version 4.3.2, MPFR version 3.0.1, MPC version 0.9, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 6.0.0 20160317 (experimental) (mips-mti-linux-gnu)
compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-16), GMP
version 4.3.2, MPFR version 3.0.1, MPC version 0.9, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 93ffb79b8f803fb23bc523b8a8a85910
test.c: In function ‘test’:
test.c:6:1: internal compiler error: in replace_rtx, at rtlanal.c:2969
 }
 ^
0xa69cde replace_rtx(rtx_def*, rtx_def*, rtx_def*)
/scratch/frs/src/gcc/gcc/rtlanal.c:2969
0xa69dba replace_rtx(rtx_def*, rtx_def*, rtx_def*)
/scratch/frs/src/gcc/gcc/rtlanal.c:3009
0xf9fa57 record_value_for_reg
/scratch/frs/src/gcc/gcc/combine.c:12673
0xfadca2 combine_instructions
/scratch/frs/src/gcc/gcc/combine.c:1488
0xfadca2 rest_of_handle_combine
/scratch/frs/src/gcc/gcc/combine.c:14345
0xfadca2 execute
/scratch/frs/src/gcc/gcc/combine.c:14388
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/70259] [6 Regression] -flifetime-dse=2 bug with empty bases

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Another reproducer:

struct Empty { };
struct A { A() : a(true) { } bool a; };
struct B : Empty { B() : Empty() { } };
struct C : A, B { C() : A(), B() { } };
int main() {
  C c;
  if ( c.a == false )
__builtin_abort();
};

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Vladimir Makarov from comment #3)
> (In reply to Ramana Radhakrishnan from comment #2)
> > Waiting.
> 
> Actually, I have a candidate patch to deal with scratches created during
> LRA.  But I can not test it as I have no "local change to gcc", a test case
> and used option set.
> 
> In any case, if this problem is solved by other means (e.g. using another
> patterns), we should probably close the bug.

Sorry I wasn't clear - the WAITING was for Renlin to put up his local changes
if he still had them.

[Bug c++/70295] [6 Regression] bogus -Wnonnull-compare for "dynamic_cast(this) != nullptr"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Wait, surely we don't want to warn here?

[Bug rtl-optimization/70224] [6 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
So I realized that given the nature of this bug a simple bootstrap on sparc
wasn't going to be particularly interesting -- bootstraps don't tickle this
code (if they did, it'd fault in a manner similar to Rainer's test).  So my
time trying to put together a usable sparc/sparc64 qemu testing environment was
largely wasted.

I'm going to go forward with the obvious patch.

Rainer, if you could do a bootstrap with -freorder-blocks-and-partition after I
commit the obvious fix, it'd be appreciated as an additional sanity check.

[Bug c/70309] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Does adding -fno-strict-aliasing "fix" the issue?

[Bug tree-optimization/70287] RTL LSM very slow with very many loads/stores in a BB

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
Summary|Slow compilation time   |RTL LSM very slow with very
   ||many loads/stores in a BB
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Works fine with GCC 6 btw.  Note that compile-time hog testcases where you
need to disable dead code removal are ... a bit fishy ;)

Note that tree optimizers optimize this to a single basic-block (everything
unrolled) but w/o all the scalar cleanups 9 stmts remain in that
basic-block.  With -ffloat-store another 18 stores/loads are emitted
at RTL expansion time and GCSE SM barfs on this (well, it could specially
detect that in a single-basic-block function there is nothing to do ... ;))

But as said, I think the testcase is quite artificial though it has a point
in that it looks like LSM is awfully slow for basic-blocks with very many
loads/stores (well, not that surprising).

For GCC 6 I can't find enough options to disable, I always end up with just

  :
  var0_110 = -212204486;
  ivtmp_111 = 9;
  var0_116 = var0_110 + 1;
  var0_121 = var0_116 + 1;
  var0_126 = var0_121 + 1;
  var0_133 = var0_126 + 1;
  var0_137 = var0_133 + 1;
  var0_142 = var0_137 + 1;
  var0_149 = var0_142 + 1;
  var0_154 = var0_149 + 1;
  ivtmp_155 = ivtmp_111 + 4294967288;
  var0_37 = var0_154 + 1;
  ivtmp_18 = ivtmp_155 + 4294967295;
  return 0;

before RTL expansion (tried to disable forwprop, DOM and VRP).

So, kind of "confirmed", but the artificial testcase should be rewritten
to not require all those disabled opts but directly have a very large
single BB with many loads/stores (or better at least some LSM opportunities)
that are _not_ dead.

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
Simplified a bit :


$ cat z7.f90
program p
   integer, parameter :: a(:) = 1
   integer, parameter :: b(2,2) = reshape([a], [2,2])
end


$ gfortran-6 z7.f90
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': double free or
corruption (fasttop): 0x03a00630 ***
...
f951: internal compiler error: Aborted

[Bug c++/70272] [5/6 Regression] -flifetime-dse miscompilation starting with r217967

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 17 15:56:19 2016
New Revision: 234296

URL: https://gcc.gnu.org/viewcvs?rev=234296&root=gcc&view=rev
Log:
PR c++/70272
* decl.c (begin_destructor_body): Don't insert clobber if
is_empty_class (current_class_type).

* g++.dg/opt/flifetime-dse5.C (main): Remove extra semicolon.
* g++.dg/opt/flifetime-dse6.C: New test.
* g++.dg/tree-ssa/ehcleanup-1.C: Adjust unreachable count.

Added:
trunk/gcc/testsuite/g++.dg/opt/flifetime-dse6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/opt/flifetime-dse5.C
trunk/gcc/testsuite/g++.dg/tree-ssa/ehcleanup-1.C

[Bug c/70262] Segmentation fault with large stack array, no fault when alloca the same size

[nickdu at msn dot com]

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

--- Comment #2 from nickdu at msn dot com ---
Why is this resolved as invalid?  I realize I can increase my stack size. 
However, I believe I'm currently under the limit.  In addition, alloca of the
same size works.

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[jiwang at gcc dot gnu.org]

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

--- Comment #21 from Jiong Wang  ---
(In reply to Richard Henderson from comment #19)
> (In reply to Jiong Wang from comment #16)
> > But there is a performance issue as described at
> >
> >   https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00281.html
> >
> >   "this patch forces register scaling expression out of memory ref, so that
> >RTL CSE pass can handle common register scaling expressions"
> >
> > This is particularly performance critial if a group of instructions are
> > using the same "scaled register" inside hot loop. CSE can reduce redundant
> > calculations.
>
> I wish that message had been a bit more complete with the description
> of the performance issue.  I must guess from this...

Please check the documentation at
http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf,
page 14, the line describe "Load register, register offset, scale by 2".

> I'll note for the record that you cannot hope to solve this with
> the legitimize_address hook alone for the simple reason that it's not
> called for legitimate addresses, of which (base + index * 2) is
> a member.  The hook is only being called for illegitimate addresses.

Agreed, while double check the code, for the performance related "scale by 2"
situation, aarch64 backend has already made it a illegitimate address.

There is the following check in aarch64_classify_address, the "GET_MODE_SIZE
(mode) != 16" is catching that.

  bool allow_reg_index_p =
!load_store_pair_p
&& (GET_MODE_SIZE (mode) != 16 || aarch64_vector_mode_supported_p (mode))
&& !aarch64_vect_struct_mode_p (mode);

So if the address is something like (base for short + index * 2), then it will
go through the aarch64_legitimize_address. Thus I think your second patch at
#c10 with my minor modification still is the proper fix for current stage.

[Bug c++/70254] Compiler crash

[dannix84 at gmail dot com]

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

--- Comment #3 from Daniel  ---
Created attachment 37992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37992&action=edit
test case


g++ -m64 -g -Wall -Wextra -pipe -fvisibility=default -x c++ -std=c++14 -fPIC
example.cpp

results in a crash

[Bug c/69602] [6/7 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|6.0 |7.0
Summary|[6 Regression]  |[6/7 Regression]
   |over-ambitious logical-op   |over-ambitious logical-op
   |warning on EAGAIN vs|warning on EAGAIN vs
   |EWOULDBLOCK |EWOULDBLOCK

--- Comment #13 from Marek Polacek  ---
Changing target milestone; it's not viable to fix this in stage4.

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Or better yet decide whether to walk the initializers or not based on
!gimple_body (fndecl) && !fun->cfg ?

[Bug driver/70192] -fno-pic doesn't work with --enable-default-pie

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Mar 17 15:11:35 2016
New Revision: 234295

URL: https://gcc.gnu.org/viewcvs?rev=234295&root=gcc&view=rev
Log:
Properly set flag_pie and flag_pic

We can't set flag_pie to the default when flag_pic == 0, which may be
set by -fno-pic or -fno-PIC, since the default value of flag_pie is
non-zero when GCC is configured with --enable-default-pie.  We need
to initialize flag_pic to -1 so that we can tell if -fpic, -fPIC,
-fno-pic or -fno-PIC is used.

Since Darwin defaults to PIC (__PIC__ == 2) and the PIC setting can't
be changed, skip tests of default __PIC__ and __PIE__ setting for
*-*-darwin* targets.

gcc/

PR driver/70192
* opts.c (finish_options): Don't set flag_pie to the default if
-fpic, -fPIC, -fno-pic or -fno-PIC is used.  Set flag_pic to 0
if it is -1.

gcc/testsuite/

PR driver/70192
* gcc.dg/pic-1.c: New test.
* gcc.dg/pic-2.c: Likewise.
* gcc.dg/pic-3.c: Likewise.
* gcc.dg/pic-4.c: Likewise.
* gcc.dg/pie-1.c: Likewise.
* gcc.dg/pie-2.c: Likewise.
* gcc.dg/pie-3.c: Likewise.
* gcc.dg/pie-4.c: Likewise.
* gcc.dg/pie-5.c: Likewise.
* gcc.dg/pie-6.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pic-1.c
trunk/gcc/testsuite/gcc.dg/pic-2.c
trunk/gcc/testsuite/gcc.dg/pic-3.c
trunk/gcc/testsuite/gcc.dg/pic-4.c
trunk/gcc/testsuite/gcc.dg/pie-1.c
trunk/gcc/testsuite/gcc.dg/pie-2.c
trunk/gcc/testsuite/gcc.dg/pie-3.c
trunk/gcc/testsuite/gcc.dg/pie-4.c
trunk/gcc/testsuite/gcc.dg/pie-5.c
trunk/gcc/testsuite/gcc.dg/pie-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anthony.ajw at gmail dot com

--- Comment #13 from nsz at gcc dot gnu.org ---
*** Bug 70298 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/70263] [4.9/5/6 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (segmentation fault)

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra  ---
Created attachment 38017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38017&action=edit
possible fix

Maybe something as simple as this?

[Bug c/69407] -Wunused-value on __atomic_fetch_OP and __atomic_OP_fetch

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 17 18:43:08 2016
New Revision: 234304

URL: https://gcc.gnu.org/viewcvs?rev=234304&root=gcc&view=rev
Log:
PR c/69407
* c-common.c (resolve_overloaded_builtin): Set TREE_USED for the fetch
operations.

* gcc.dg/atomic-op-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/atomic-op-6.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/70310] New: [6 Regression] wrong code with vector compare at -O0

[zsojka at seznam dot cz]

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

Bug ID: 70310
   Summary: [6 Regression] wrong code with vector compare at -O0
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

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

Output:
$ gcc -O0 testcase.c
$ ./a.out 
00ff
Aborted

$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-234340-checking-yes-rtl-df-nobootstrap-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --disable-bootstrap --without-cloog --without-ppl
--without-isl --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-234340-checking-yes-rtl-df-nobootstrap-nographite
Thread model: posix
gcc version 6.0.0 20160318 (experimental) (GCC)