[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
The issue seems to be fixed. Not sure what revision fixed it.

[Bug c++/68842] Better error output when template needed before dependent name

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
N.B. GCC 4.8 is no longer supported and the branch is closed, but the
diagnostic is the same in current releases, and I agree a "fix-it" hint would
be better than the current error.

Clang gives a different error, which IMHO is even less helpful despite trying
to give a fix-it hint:

tt.cc:15:5: error: reference to non-static member function must be called
  t.do_nothing(0);
  ~~^~
tt.cc:20:3: note: in instantiation of function template specialization
'do_test<2>' requested here
  do_test<2>();
  ^
tt.cc:5:8: note: possible target for call
  void do_nothing(int value)
   ^
1 error generated.

[Bug rtl-optimization/68636] [5 Regression] unnecessary unaligned load on mips o32

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #10 from Martin Jambor  ---
*** Bug 68064 has been marked as a duplicate of this bug. ***

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Caused by r231540:

commit 15a1fce36358508909f2013fd6d07e0b9fcad97a
Author: hubicka 
Date:   Thu Dec 10 19:20:14 2015 +

* ipa-cp.c (ipcp_cloning_candidate_p): Use node->optimize_for_size_p.
(good_cloning_opportunity_p): Likewise.
(gather_context_independent_values): Do not return true when
polymorphic call context is known or when we have known aggregate
value of unused parameter.
(estimate_local_effects): Try to create clone for all context
when either some params are substituted or devirtualization is possible
or some params can be removed; use local flag instead of
node->will_be_removed_from_program_if_no_direct_calls_p.
(identify_dead_nodes): Likewise.

* gcc.c-torture/execute/20010122-1.c: Disable cloning.

[Bug ipa/68851] New: [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[trippels at gcc dot gnu.org]

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

Bug ID: 68851
   Summary: [6 Regression] ICE:  in set_comdat_group, at
ipa-comdats.c:213
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz
  Target Milestone: ---

Trying to build Chromium shows:

../../third_party/WebKit/Source/platform/Timer.h:55:13: internal compiler
error: in set_comdat_group, at ipa-comdats.c:213
 {
 ^

0x13ad12a set_comdat_group(symtab_node*, void*)
../../gcc/gcc/ipa-comdats.c:213
0x916795 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
../../gcc/gcc/cgraph.c:2217
0x916820 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool, bool)
../../gcc/gcc/cgraph.c:2235
0x13ae5cb ipa_comdats
../../gcc/gcc/ipa-comdats.c:368
0x13ae5cb execute
../../gcc/gcc/ipa-comdats.c:412

Reducing.

[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #11 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #10)
> This PR is tagged as a regression.  Has anyone determined when it last
> worked or is it longstanding bug uncovered by recent non-fortran fe changes?

For users it is a regression in the sense that packages that compiled with
-flto -Werror with 5.3 will now stop building.

The underlying FE issue is much older, I guess.

[Bug libstdc++/64132] [5/6 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[lixin.fnst at cn dot fujitsu.com]

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

li xin  changed:

   What|Removed |Added

 CC||lixin.fnst at cn dot 
fujitsu.com

--- Comment #6 from li xin  ---
The LSB test cases also Failed.
/22_locale/messages/members/char/2.cc 1
/22_locale/messages/members/char/wrapped_env.cc 1
/22_locale/messages/members/char/wrapped_locale.cc 1 are Failed.

They are pass on gcc-4.9.3.
and fail on gcc-5.1 and gcc-5.2

[Bug rtl-optimization/64818] User specified register don't work correctly in inline-asm operands.

[belagod at gcc dot gnu.org]

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

Tejas Belagod  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||belagod at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Tejas Belagod  ---
Fixed in r222306.

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Fri Dec 11 11:27:11 2015
New Revision: 231559

URL: https://gcc.gnu.org/viewcvs?rev=231559=gcc=rev
Log:
Add an asssert and testcase for PR 68064

2015-12-11  Martin Jambor  

PR ipa/68064
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Add checking
assert that align is nonzero.

testsuite/
* g++.dg/torture/pr68064.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr68064.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/68139] rethrow_if_nested should tolerate overloaded unary operator

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Fri Dec 11 12:04:23 2015
New Revision: 231562

URL: https://gcc.gnu.org/viewcvs?rev=231562=gcc=rev
Log:
PR libstdc++/68139

Added:
trunk/libstdc++-v3/testsuite/18_support/nested_exception/68139.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/nested_exception.h

[Bug libstdc++/64132] [5/6 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[lixin.fnst at cn dot fujitsu.com]

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

--- Comment #7 from li xin  ---
(In reply to li xin from comment #6)
> The LSB test cases also Failed.
> /22_locale/messages/members/char/2.cc 1
> /22_locale/messages/members/char/wrapped_env.cc 1
> /22_locale/messages/members/char/wrapped_locale.cc 1 are Failed.
> 
> They are pass on gcc-4.9.3.
> and fail on gcc-5.1 and gcc-5.2

The output is as following:
2.cc:54: void test02(): Assertion `s01 == "s'il vous pla�t"' failed.
DejaGNUTest.command_output_1:

[Bug tree-optimization/68835] [5/6 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Assignee|jakub at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #8 from Jakub Jelinek  ---
The > HOST_BITS_PER_WIDE_INT stuff is just weird.
p debug_tree (build_nonstandard_integer_type (66, 1))
  constant 128>
unit size  constant 16>
align 128 symtab 0 alias set -1 canonical type 0x718170a8 precision 66
min  max >
(gdb) p debug_tree (build_int_cst (0x718170a8, 1))
  constant 1>
(gdb) p debug_tree (int_const_binop (MINUS_EXPR, 0x717302b8,
0x718271b0))
  constant
0xfffe>
(gdb) p debug_tree (build_int_cst (0x718170a8, 2))
  constant 2>
(gdb) p debug_tree (int_const_binop (TRUNC_DIV_EXPR, 0x717302b8,
0x718271e0))
  constant
0x1>

The max value of the unsigned type (for signed types both the min and max
values look ok) looks wrong, and so does the max - 1 value, but the max / 2
value is printed correctly.  This can be surely a pretty printer bug, or could
be a bug in wide_int_to_tree.  Depends on what should be the canonical
representation of precision > HOST_BITS_PER_WIDE_INT (and < 2 *
HOST_BITS_PER_WIDE_INT) unsigned values in between maximum and maximum -
LLONG_MAX.

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Yes, it has been fixed by Richi's r231246 which is a fix of PR68636
(of which this is basically a duplicate, only manifesting elsewhere).
I am have just committed a testcase and an assert for detecting this
earlier should it happen again, see
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01246.html

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

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
  Component|c++ |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
-fno-tree-fre "fixes" the issue.

[Bug middle-end/68852] New: [6 Regression] ICE in vect_is_simple_use (tree-vect-stmts.c:8750) using -O3

[marxin at gcc dot gnu.org]

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

Bug ID: 68852
   Summary: [6 Regression] ICE in vect_is_simple_use
(tree-vect-stmts.c:8750) using -O3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36991=edit
test-case

Starting from r230993:

Author: rguenth 
Date:   Fri Nov 27 08:31:44 2015 +

2015-11-27  Richard Biener  

PR tree-optimization/68553
* tree-vect-slp.c (vect_get_mask_element): Remove.
(vect_transform_slp_perm_load): Implement in a simpler way.

* gcc.dg/vect/pr45752.c: Adjust.
* gcc.dg/vect/slp-perm-4.c: Likewise.

I see ICE in tree-vect-stmts.c:8750:

$ ./xgcc -B. -O3 ~/Programming/testcases/tree-vect-stmts-ice/vect-ice.ii -c
/home/marxin/Programming/testcases/tree-vect-stmts-ice/vect-ice.ii: In function
‘void fn1()’:
/home/marxin/Programming/testcases/tree-vect-stmts-ice/vect-ice.ii:46:6:
internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8750
 void fn1() {
  ^~~

0xf28870 vect_is_simple_use(tree_node*, vec_info*, gimple**, vect_def_type*,
tree_node**)
../../gcc/tree-vect-stmts.c:8750
0xf2f143 vectorizable_operation
../../gcc/tree-vect-stmts.c:4874
0xf3e2f7 vect_analyze_stmt(gimple*, bool*, _slp_tree*)
../../gcc/tree-vect-stmts.c:8090
0xf57192 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:2205
0xf57113 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:2196
0xf583cc vect_slp_analyze_operations(vec<_slp_instance*, va_heap, vl_ptr>,
void*)
../../gcc/tree-vect-slp.c:2228
0xf5d35c vect_slp_analyze_bb_1
../../gcc/tree-vect-slp.c:2511
0xf5d35c vect_slp_bb(basic_block_def*)
../../gcc/tree-vect-slp.c:2598
0xf5f4b5 execute
../../gcc/tree-vectorizer.c:759

Thanks,
Martin

[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Is this PR fixed by revision r231485?

[Bug ada/68849] Bug box when using a type with static predicate as formal parameter of generic procedure

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> I was able to reproduce it with the adacore libre version
> (gnat-gpl-2015-x86_64-linux-bin.tar.gz)
> from http://libre.adacore.com/download/configurations on a x86_64 Linux
> machine.
> 
> I used the latter configuration first and it told me to write to
> rep...@adacore.com, which I did.
> That was a week ago and there wasn't any reaction.
> I'm sorry if this bug report is redundant.

GNAT GPL and GCC are 2 different products so you can report problems for them
independently but please pick one of them and don't create duplicate reports.

[Bug target/66551] [SPARC64] Fails to bootstrap in stage 3 with linker error

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
> Sorry for not reporting back.

No problem.

> This issue seems to have been resolved, we currently don't see any build
> issues with gcc-5 on sparc64. You can view the latest build log for
> gcc-5_5.3.1 in [1].

That's great, thanks.

[Bug c++/68842] Better error output when template needed before dependent name

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
And interestingly EDG compiles it without error!

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Still reducing. But Martin emailed me a patch, that fixes the issue:

diff --git a/gcc/ipa-comdats.c b/gcc/ipa-comdats.c
index 3aabd71..f7a6ff4 100644
--- a/gcc/ipa-comdats.c
+++ b/gcc/ipa-comdats.c
@@ -210,7 +210,12 @@ set_comdat_group (symtab_node *symbol,
 {
   symtab_node *head = (symtab_node *)head_p;

-  gcc_assert (!symbol->get_comdat_group ());
+  if (symbol->get_comdat_group ())
+{
+  gcc_assert (symbol->get_comdat_group () == head->get_comdat_group ());
+  return false;
+}
+
   symbol->set_comdat_group (head->get_comdat_group ());
   symbol->add_to_same_comdat_group (head);
   return false;

[Bug middle-end/68852] [6 Regression] ICE in vect_is_simple_use (tree-vect-stmts.c:8750) using -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-11
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug fortran/68850] Coarray events: EVENT_QUERY not documented as intrinsic subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
g++ -MMD -MF
obj/third_party/WebKit/Source/core/layout/webcore_rendering.LayoutObject.o.d
-DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -D_FILE_OFFSET_BITS=64 -DDISABLE_NACL
-DCHROMIUM_BUILD -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_ASH=1
-DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1
-DUSE_X11=1 -DUSE_CLIPBOARD_AURAX11=1 -DENABLE_ONE_CLICK_SIGNIN
-DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 -DUSE_PROPRIETARY_CODECS
-DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS
-DENABLE_HIDPI=1 -DENABLE_TOPCHROME_MD=1 -DUSE_UDEV -DDONT_EMBED_BUILD_METADATA
-DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1
-DENABLE_PDF=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1
-DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_PRINTING=1
-DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1
-DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1
-DENABLE_SUPERVISED_USERS=1 -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1
-DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD
-DSAFE_BROWSING_DB_LOCAL -DGL_GLEXT_PROTOTYPES -DBLINK_IMPLEMENTATION=1
-DINSIDE_BLINK -DENABLE_LAYOUT_UNIT_IN_INLINE_BOXES=0
-DWTF_USE_CONCATENATED_IMPULSE_RESPONSES=1 -DENABLE_INPUT_MULTIPLE_FIELDS_UI=1
-DENABLE_WEB_AUDIO=1 -DWTF_USE_WEBAUDIO_FFMPEG=1
-DWTF_USE_DEFAULT_RENDER_THEME=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0
-DU_STATIC_IMPLEMENTATION -DSK_SUPPORT_GPU=1
-DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DCHROME_PNG_WRITE_SUPPORT
-DPNG_USER_CONFIG -DLIBXML_STATIC -DLIBXSLT_STATIC -DUSE_LIBPCI=1
-DUSE_OPENSSL=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-D_FORTIFY_SOURCE=2 -Igen -I../.. -I../../skia/config
-I../../third_party/WebKit/Source -I../../third_party/khronos -I../../gpu
-Igen/angle -Igen/blink -I../../third_party/angle/include
-I../../third_party/ffmpeg -I../../third_party/icu/source/i18n
-I../../third_party/icu/source/common -I../../third_party/WebKit
-I../../third_party/skia/include/core -I../../third_party/skia/include/effects
-I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu
-I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops
-I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports
-I../../third_party/skia/include/utils -I../../skia/ext
-I../../third_party/iccjpeg -I../../third_party/libpng
-I../../third_party/libwebp -I../../third_party/libxml/linux/include
-I../../third_party/libxml/src/include -I../../third_party/libxslt
-I../../third_party/npapi -I../../third_party/npapi/bindings
-I../../third_party/ots/include -I../../third_party/qcms/src
-I../../third_party/zlib -I../../v8/include -fstack-protector
--param=ssp-buffer-size=4 -pthread -fno-strict-aliasing -Wall
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe
-fPIC -Wno-unused-local-typedefs -fno-strict-aliasing -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -m64 -march=x86-64 -O3 -fno-ident -fdata-sections
-ffunction-sections -funwind-tables -fno-exceptions -fno-rtti
-fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare
-Wno-c++0x-compat -std=gnu++11 -Wno-narrowing -Wno-literal-suffix -c
../../third_party/WebKit/Source/core/layout/LayoutObject.cpp -o
obj/third_party/WebKit/Source/core/layout/webcore_rendering.LayoutObject.o 

Also gets miscompiled:

Program received signal SIGSEGV, Segmentation fault.
0x58ad00a5 in blink::LayoutObject::isDescendantOf(blink::LayoutObject
const*) const ()
(gdb) bt
#0  0x58ad00a5 in
blink::LayoutObject::isDescendantOf(blink::LayoutObject const*) const ()
#1  0x58b60790 in
blink::CompositedLayerMapping::containingSquashedLayer(blink::LayoutObject
const*, unsigned int) ()
#2  0x58be0bf6 in
blink::CompositingLayerAssigner::assignLayersToBackingsInternal(blink::PaintLayer*,
blink::CompositingLayerAssigner::SquashingState&,
WTF::Vector&) ()
#3  0x58be0769 in
blink::CompositingLayerAssigner::assignLayersToBackingsInternal(blink::PaintLayer*,
blink::CompositingLayerAssigner::SquashingState&,
WTF::Vector&) ()
#4  0x58be0769 in
blink::CompositingLayerAssigner::assignLayersToBackingsInternal(blink::PaintLayer*,
blink::CompositingLayerAssigner::SquashingState&,
WTF::Vector&) ()
#5  0x58be0e11 in
blink::CompositingLayerAssigner::assign(blink::PaintLayer*,
WTF::Vector&) ()
#6  0x58b66758 in 

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on trunk (6.0) for revisions newer than r228222 (pr63921).

[Bug c++/68853] New: [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

Bug ID: 68853
   Summary: [6 Regression] gcc-6 miscompiles Chromium v8 garbage
collector
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Chromium build with gcc-6 crashes almost immediately in the
v8 (javascript) garbage collector.

Program received signal SIGSEGV, Segmentation fault.
0x57830de0 in
v8::internal::IncrementalMarking::ActivateIncrementalWriteBarrier() ()
(gdb) bt
#0  0x57830de0 in
v8::internal::IncrementalMarking::ActivateIncrementalWriteBarrier() ()
#1  0x57831007 in v8::internal::IncrementalMarking::StartMarking() ()
#2  0x57831163 in v8::internal::IncrementalMarking::Start(char const*)
()
#3  0x57820e86 in
v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*,
char const*, v8::GCCallbackFlags) ()
#4  0x577f0b7d in v8::internal::Factory::NewRawOneByteString(int,
v8::internal::PretenureFlag) ()
#5  0x57b86b62 in v8::internal::Runtime_StringToLowerCase(int,
v8::internal::Object**, v8::internal::Isolate*) ()

markus@x4 Release % c++ -MMD -MF
obj/v8/src/heap/v8_base.incremental-marking.o.d -DV8_DEPRECATION_WARNINGS
-DCLD_VERSION=2 -D_FILE_OFFSET_BITS=64 -DDISABLE_NACL -DCHROMIUM_BUILD
-DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_ASH=1 -DUSE_PANGO=1
-DUSE_CAIRO=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1
-DUSE_CLIPBOARD_AURAX11=1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_WEBRTC=1
-DENABLE_MEDIA_ROUTER=1 -DUSE_PROPRIETARY_CODECS -DENABLE_PEPPER_CDMS
-DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS -DENABLE_HIDPI=1
-DENABLE_TOPCHROME_MD=1 -DUSE_UDEV -DDONT_EMBED_BUILD_METADATA
-DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1
-DENABLE_PDF=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1
-DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_PRINTING=1
-DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1
-DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1
-DENABLE_SUPERVISED_USERS=1 -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1
-DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD
-DSAFE_BROWSING_DB_LOCAL -DV8_TARGET_ARCH_X64 -DV8_I18N_SUPPORT
-DV8_IMMINENT_DEPRECATION_WARNINGS -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE
-DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION
-DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DNDEBUG
-DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DENABLE_HANDLE_ZAPPING -I../../v8
-Igen -I../../third_party/icu/source/i18n -I../../third_party/icu/source/common
-fstack-protector --param=ssp-buffer-size=4  -pthread -fno-strict-aliasing
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe
-fPIC -Wno-unused-local-typedefs -Wno-format -Wno-unused-result -m64
-march=x86-64 -m64 -O3 -fno-ident -fdata-sections -ffunction-sections
-funwind-tables -fdata-sections -ffunction-sections -O3 -fno-exceptions
-fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -Wno-deprecated
-std=gnu++11 -Wno-narrowing -Wno-literal-suffix  -c
../../v8/src/heap/incremental-marking.cc -o
obj/v8/src/heap/v8_base.incremental-marking.o

Compiling this file with gcc-5 fixes the issue.
I will try to narrow this further down to a single function.

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Fri Dec 11 10:59:29 2015
New Revision: 231556

URL: https://gcc.gnu.org/viewcvs?rev=231556=gcc=rev
Log:
Fix PR target/67484

Uros Bizjak  

PR target/67484
* config/i386/i386.c (ix86_valid_target_attribute_tree):
Use ggc_strdup to copy option_strings to opts->x_ix86_arch_string and
opts->x_ix86_tune_string.

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

[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file

[jan.stancek at gmail dot com]

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

Jan Stancek  changed:

   What|Removed |Added

 CC||jan.stancek at gmail dot com

--- Comment #3 from Jan Stancek  ---
Created attachment 36992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36992=edit
reproducer based off linux kernel fs/xfs/libxfs/xfs_sb.c

I came across this problem while running lcov on gcov enabled kernel. gcov is
really struggling with xfs_sb.c - it takes up to _36 hours_ to complete on
Intel Xeon CPUs.

I narrowed it down to following condition:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/libxfs/xfs_sb.c?h=v4.4-rc4#n229

And based on that I made the attached reproducer. To reproduce run:

gcc -O2 -fprofile-arcs -ftest-coverage test1.c
./a.out
gcov -b -c -d -a test1.gcda

[Bug libstdc++/68139] rethrow_if_nested should tolerate overloaded unary operator

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #4 from Ville Voutilainen  ---
Done.

[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
SPARC/Solaris with system linker has it as well

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
So the mentioned revision is responsible for creation of a new consprop clone:

IPA decision stage:
...
 - Creating a specialized node of virtual bool
blink::HTMLFormControlElement::isFormControlElement() const/14820 for all known
contexts.
...
IPA constant propagation end


and the symbol is identified to be set to a comdat group in ipa-comdats.c:365:

  if (is_a  (symbol))
   dyn_cast (symbol)->call_for_symbol_thunks_and_aliases
  (set_comdat_group_1,
   *comdat_head_map.get (group),
   true);

as the function calls 'set_comdat_group_1' for the constprop cloned function,
the original function of the clone is thunk and calls the clone. So that
set_comdat_group_1
is called for the original function:

_ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv/14822 (virtual
bool
blink::HTMLFormControlElement::_ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv()
const) @0x7fffeb51b8a0
  Type: function definition analyzed
  Visibility: externally_visible asm_written public weak comdat
comdat_group:_ZNK5blink22HTMLFormControlElement20isFormControlElementEv
one_only
section:.text._ZNK5blink22HTMLFormControlElement20isFormControlElementEv
(implicit_section) virtual artificial
  Same comdat group as:
_ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390
  Aux: @0x1  References: 
  Referring: 
  Availability: available
  First run: 0
  Function flags: nonfreeing_fn
  Thunk fixed offset -96 virtual value 0 has virtual offset 0)
  Called by: 
  Calls:
_ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390
(1.00 per call) (can throw external) 

constprop clone:

_ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390
() @0x7fffe8bc6000
  Type: function definition analyzed
  Visibility:
comdat_group:_ZNK5blink22HTMLFormControlElement20isFormControlElementEv
  Same comdat group as:
_ZNK5blink22HTMLFormControlElement20isFormControlElementEv/14820
  previous sharing asm name: 31394
  References: 
  Referring: 
  Clone of _ZNK5blink22HTMLFormControlElement20isFormControlElementEv/14820
  Availability: local
  First run: 0
  Function flags: local nonfreeing_fn
  Called by:
_ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv/14822 (1.00
per call) (can throw external) 
  Calls: 

Problem is that the original function has already set comdat_group here:

#0  symtab_node::set_comdat_group (this=0x7fffeb51b8a0, group=0x7fffeb4dc620)
at ../../gcc/cgraph.h:220
#1  0x00a53972 in symtab_node::add_to_same_comdat_group
(this=0x7fffeb51b8a0, old_node=0x7fffeb51b5c0) at ../../gcc/symtab.c:461
#2  0x008d05e2 in use_thunk (thunk_fndecl=0x7fffeb4ec7e0, emit_p=true)
at ../../gcc/cp/method.c:396
#3  0x008e2979 in emit_associated_thunks (fn=0x7fffeb4dc620) at
../../gcc/cp/semantics.c:4080
#4  0x008e2cb8 in expand_or_defer_fn (fn=0x7fffeb4dc620) at
../../gcc/cp/semantics.c:4178
#5  0x0087a103 in cp_parser_function_definition_after_declarator
(parser=0x77feeb40, inline_p=true) at ../../gcc/cp/parser.c:25212
#6  0x0087b772 in cp_parser_late_parsing_for_member
(parser=0x77feeb40, member_function=0x7fffeb4dc620) at
../../gcc/cp/parser.c:26033
#7  0x008745f7 in cp_parser_class_specifier_1 (parser=0x77feeb40)
at ../../gcc/cp/parser.c:21412
#8  0x008746bb in cp_parser_class_specifier (parser=0x77feeb40) at
../../gcc/cp/parser.c:21438
#9  0x0086b65b in cp_parser_type_specifier (parser=0x77feeb40,
flags=1, decl_specs=0x7fffd6b0, is_declaration=true,
declares_class_or_enum=0x7fffd634, is_cv_qualifier=0x7fffd633) at
../../gcc/cp/parser.c:15736
#10 0x00867008 in cp_parser_decl_specifier_seq (parser=0x77feeb40,
flags=1, decl_specs=0x7fffd6b0, declares_class_or_enum=0x7fffd6ac) at
../../gcc/cp/parser.c:12657
#11 0x00866645 in cp_parser_simple_declaration (parser=0x77feeb40,
function_definition_allowed_p=true, maybe_range_for_decl=0x0) at
../../gcc/cp/parser.c:12200
#12 0x008665cd in cp_parser_block_declaration (parser=0x77feeb40,
statement_p=false) at ../../gcc/cp/parser.c:12147
#13 0x0086634f in cp_parser_declaration (parser=0x77feeb40) at
../../gcc/cp/parser.c:12044
#14 0x00865e7b in cp_parser_declaration_seq_opt (parser=0x77feeb40)
at ../../gcc/cp/parser.c:11923
#15 0x0086e172 in cp_parser_namespace_body (parser=0x77feeb40) at
../../gcc/cp/parser.c:17505
#16 0x0086e113 in cp_parser_namespace_definition
(parser=0x77feeb40) at ../../gcc/cp/parser.c:17482
#17 0x0086624d in cp_parser_declaration (parser=0x77feeb40) at
../../gcc/cp/parser.c:12024
#18 0x00865e7b in cp_parser_declaration_seq_opt (parser=0x77feeb40)
at ../../gcc/cp/parser.c:11923
#19 0x00857aaa in 

[Bug fortran/68856] New: wrong compilation wtih character interoperability

[valeryweber at hotmail dot com]

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

Bug ID: 68856
   Summary: wrong compilation wtih character interoperability
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

Dear All

The following code compiles with 5.3.0. Would it be possible to have an error
check on character with len>1 that are binded to C?
thanks
valery


cat t.f90
module test
  use iso_c_binding
  TYPE, BIND(C), PUBLIC :: cudaDeviceProp_t
 character(kind=c_char,len=256) :: name
  end type cudaDeviceProp_t
end module test

gfortran-5.3.0 -c t.f90 -std=f2008ts -Wall

[Bug preprocessor/68854] New: isystem and ansi cause arm assembly preprocessing problem

[vasyl.vavrychuk at globallogic dot com]

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

Bug ID: 68854
   Summary: isystem and ansi cause arm assembly preprocessing
problem
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vasyl.vavrychuk at globallogic dot com
  Target Milestone: ---

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

I have next test.s file

#include "test.h"
D(b)

and in the folder h I have test.h file

#define D(x) .globl x

Running command

/usr/lib/gcc/x86_64-linux-gnu/5/cc1 -E -lang-asm -isystem h test.s --ansi

I get

# 1 "test.s"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4  
# 1 "" 2  
# 1 "test.s"
# 1 "h/test.h" 1 3 4
# 2 "test.s" 2  

# 2 "test.s" 3 4
.globl  
# 2 "test.s"
b   

which is not correct since ".globl b" is splited and wont be compiled by
assebler.

If I remove '--ansi' or replace '-isystem' with '-I' result because correct

# 1 "test.s"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.s"
# 1 "h/test.h" 1
# 2 "test.s" 2
.globl b

Here I put gcc command line which shows assembler error

gcc -ansi -xassembler-with-cpp -isystemh -c test.s -v
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
COLLECT_GCC_OPTIONS='-ansi' '-isystem' 'h' '-c' '-v' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -E -lang-asm -quiet -v -imultiarch
x86_64-linux-gnu -isystem h test.s -mtune=generic -march=x86-64 -ansi
-fstack-protector-strong -Wformat -Wformat-security -fno-directives-only -o
/tmp/ccqIhd5s.s
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 h
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-ansi' '-isystem' 'h' '-c' '-v' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o test.o /tmp/ccqIhd5s.s
GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.25.1
test.s: Assembler messages:
test.s:2: Error: expected symbol name
test.s:3: Error: no such instruction: `b'

On gcc 4.9 it is not reproduced.

[Bug c++/68842] Better error output when template needed before dependent name

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4907,8 +4907,13 @@ cp_build_binary_op (location_t location,
   if (!result_type)
 {
   if (complain & tf_error)
-   error ("invalid operands of types %qT and %qT to binary %qO",
-  TREE_TYPE (orig_op0), TREE_TYPE (orig_op1), code);
+{
+  error ("invalid operands of types %qT and %qT to binary %qO",
+ TREE_TYPE (orig_op0), TREE_TYPE (orig_op1), code);
+  if (code == LT_EXPR)
+inform (input_location, "use the keyword % before the "
+"name of a member template belonging to a dependent
type");
+}
   return error_mark_node;
 }

This patch adds the following line after the error:

tt.cc:15:15: note: use the keyword ‘template’ before the name of a member
template belonging to a dependent type

I don't know how to make it only issue that note when the LHS is one of
foo.bar, foo->bar, or foo::bar.

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #3)
> Can you bisect it to the alias changes from Honza or is this older?

The first issue is older. At least a few weeks.
I don't have a powerful enough machine to bisect this and the 
compile farm machines cannot build Chromium, because of missing
libraries. 
(I've seen the second issue for the first time today.)

> Is this  part of chromium single-threaded?

If you start chromium with:
 google-chrome --no-sandbox --renderer-cmd-prefix='xterm -title renderer -e gdb
-ex run --args'
it will attach a debugger to every started thread.
The segfault happens in one of them.

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
wrong-code fixed on trunk.
Code quality work tracked by PR 68543

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #4)
> (In reply to Richard Biener from comment #3)
> > Can you bisect it to the alias changes from Honza or is this older?
> 
> The first issue is older. At least a few weeks.
> I don't have a powerful enough machine to bisect this and the 
> compile farm machines cannot build Chromium, because of missing
> libraries. 

OK. I will run a bisection just on that one object file...

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
Fixed in trunk.

[Bug target/68543] [AArch64] Implement overflow arithmetic standard names {u,}{add,sub,mul}v4 and/or negv3

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
After some discussion on IRC, WORD_REGISTER_OPERATIONS seems wrong for aarch64
since 32-bit operations i.e. in SImode operate like normal 32-bit operations
because they use the 32-bit W-form of the registers. Thus they don't behave
like word_mode operations, because word_mode is DImode on aarch64.
So we may want to look at implementing the standard names after all

[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Ok, it looks like a ppc64le cross happily (eh) accepts sources preprocessed on
x86_64-linux and even required built modules.

So I have the dump files myself and the -fopt-info-vec difference (for BB
vectorization only) is empty.  It looks like the only code difference is
for the vectorization of the BB in loop

shell2.fppized.f90:971

that is

  do k = 1, k_max
k1 = k_x(k);k2 = k_y(k);k3 = k_z(k)
dot1 = k1*P1+k2*P2+k3*P3
dot2 = g4 * (k1*k1+k2*k2+k3*k3)
res_ij(k) = res_ij(k) + therm(k) * (fac1 *
exp(cmplx(dot2,dot1,kind=kind((1.0d0,1.0d0)
  end do

which has now one less vector operand.

If you can confirm this by "bisecting" the file with -fdbg-cnt=vect_slp:N
that would be nice.

The vectorized code looks ok to me so I suspect a target issue here.

Note that we do both a vector load from the realpart of a complex and
a scalar load of the imaginary part and then use that to construct
another vector:

  _1371 = REALPART_EXPR <[shell2.fppized.f90:975:0] [shell2.fppized.f90:975:0]
MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;
  vectp.6451_10558 = _EXPR <[shell2.fppized.f90:975:0]
[shell2.fppized.f90:975:0] MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;
  vect__1371.6452_10556 = MEM[(real(kind=8) *)vectp.6451_10558];
  _395 = IMAGPART_EXPR <[shell2.fppized.f90:975:0] [shell2.fppized.f90:975:0]
MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;

  [shell2.fppized.f90:975:0] _177 = _964 * _3980;
  [shell2.fppized.f90:975:0] vect_cst__10554 = {_177, _395};
  [shell2.fppized.f90:975:0] vect__455.6453_5427 = vect_cst__10554 +
vect__1371.6452_10556;
  [shell2.fppized.f90:975:0] _389 = _395 + _3549;
  vectp.6455_5409 = _EXPR <[shell2.fppized.f90:975:0]
[shell2.fppized.f90:975:0] MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;
  [shell2.fppized.f90:975:0] MEM[(real(kind=8) *)vectp.6455_5409] =
vect__455.6453_5427;

in .optimized the above looks like

  vect__1371.6452_10556 = MEM[base: _9159, offset: 0B];
  _395 = MEM[base: _9159, offset: 8B];
  _9158 = (void *) ivtmp.7110_9170;
  [shell2.fppized.f90:975:0] _964 = MEM[base: _9158, offset: 0B];
  [shell2.fppized.f90:975:0] _486 = __builtin_exp (dot2_958);
  [shell2.fppized.f90:975:0] _508 = REALPART_EXPR ;
  _1815 = _486 * fac1$real_1370;
  [shell2.fppized.f90:975:0] _518 = IMAGPART_EXPR ;
  [shell2.fppized.f90:975:0] _178 = _508 * _1815;
  [shell2.fppized.f90:975:0] _201 = _518 * _1815;
  [shell2.fppized.f90:975:0] _967 = COMPLEX_EXPR <_178, _201>;
  [shell2.fppized.f90:975:0] _968 = ((_967));
  _3980 = REALPART_EXPR <_968>;
  [shell2.fppized.f90:975:0] _177 = _964 * _3980;
  [shell2.fppized.f90:975:0] vect_cst__10554 = {_177, _395};
  [shell2.fppized.f90:975:0] vect__455.6453_5427 = vect_cst__10554 +
vect__1371.6452_10556;
  [shell2.fppized.f90:975:0] MEM[base: _9159, offset: 0B] =
vect__455.6453_5427;

which might be enough to trigger later RTL opt confusion.  I can just guess
at something CSEing the scalar load with the vector load and getting
lane ordering (endianess) wrong.

Maybe you can extract a small testcase from the above info that reproduces
the difference.

[Bug middle-end/68855] New: PAREN_EXPR not "ignored" where possible

[rguenth at gcc dot gnu.org]

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

Bug ID: 68855
   Summary: PAREN_EXPR not "ignored" where possible
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

In 465.tonto we end up with

  [shell2.fppized.f90:975:0] _967 = COMPLEX_EXPR <_178, _201>;
  [shell2.fppized.f90:975:0] _968 = ((_967));
  _3980 = REALPART_EXPR <_968>;

and _201/_967 otherwise unused.  REALPART_EXPR should look through
PAREN_EXPR here and wrap its simplification result in PAREN_EXPR
instead (or PAREN_EXPRs should be pushed into operands of non-associatable
stmts).

Not sure if one can devise other interesting examples.

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Created attachment 36993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36993=edit
candidate patch

Can you try if the fix for PR68852 (attached) fixes this?

If not, can you attach -fdump-tree-slp-details (two dump files) before and
after the rev. for that file?

[Bug tree-optimization/68835] [5/6 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Testcase that is miscompiled starting with r210113 at -O2:
__attribute__((noinline, noclone)) unsigned __int128
foo (void)
{
  unsigned __int128 x = (unsigned __int128) 0xULL;
  struct { unsigned __int128 a:65; } w;
  w.a = x;
  w.a += x;
  return w.a;
}

int
main ()
{
  unsigned __int128 x = foo ();
  if ((unsigned long long) x != 0xfffeULL
  || (unsigned long long) (x >> 64) != 1)
__builtin_abort ();
  return 0;
}

The function foo returns 0xfffe instead of
0x1fffe.  So, how do we want to represent such large unsigned
values?  Force in that case get_len () > 1 representation, or tweak all
consumers including tree-pretty-print.c and other spots that if the
representation is negative number and the type is unsigned non-power of two
precision > HOST_BITS_PER_WIDE_INT, treat negative values differently?

[Bug tree-optimization/68835] [5/6 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Seems get_int_cst_ext_nunits already has some code to handle the case of
"negative" extra large integers, but only if they have precision multiple of
HOST_BITS_PER_WIDE_INT.  So I believe we want something for the precisions that
aren't multiple of HOST_BITS_PER_WIDE_INT, but are > HOST_BITS_PER_WIDE_INT,
too.
But not sure what exactly, simply returning larger ext_len in that case does
not help.

[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)

[dkg at fifthhorseman dot net]

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

Daniel Kahn Gillmor  changed:

   What|Removed |Added

  Attachment #36989|0   |1
is obsolete||

--- Comment #1 from Daniel Kahn Gillmor  ---
Created attachment 37001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37001=edit
allow reading OLD argument to -fdebug-prefix-map from environment (using ENV:
prefix)

I'm attaching an updated patch that uses an "ENV:" prefix instead of a literal
"$", because the "$" is messy to pass through a complex build chain without a
lot of escaping.

So the reproducible use case would be something like:

  export SOURCE_BUILD_DIR="$(pwd)"
  gcc -fdebug-prefix-map=ENV:SOURCE_BUILD_DIR=/usr/src

[Bug debug/68860] New: [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1

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

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

Bug ID: 68860
   Summary: [6 regression] FAIL: gcc.dg/guality/pr36728-1.c   -O3
-g  line 16 arg1 == 1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*, ia64-*-*

Breakpoint 1, foo (arg7=, arg6=, 
arg5=, arg4=, arg3=, 
arg2=, arg1=)
at /usr/local/gcc/gcc-20151211/gcc/testsuite/gcc.dg/guality/pr36728-1.c:12
12char *x = __builtin_alloca (arg7);
$1 = 
$2 = 1
 != 1
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 16 arg1 == 1

15a1fce36358508909f2013fd6d07e0b9fcad97a is the first bad commit
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231540
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/33120] Data not put in BSS section on Mac OS

[jbg...@lug-owl.de]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 CC||jbg...@lug-owl.de

--- Comment #25 from Jan-Benedict Glaw  ---
When building with recent GCCs, this patch produces a warning, see the build
log [1] of build #479519 [2]:

g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/.
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecn
umber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o darwin.o
-MT darwin.o -MMD -MP -MF ./.deps/darwin.TPo ../../../gcc/gcc/config/darwin.c
../../../gcc/gcc/config/darwin.c: In function ‘bool
darwin_use_anchors_for_symbol_p(const_rtx)’:
../../../gcc/gcc/config/darwin.c:3016:9: error: statement is indented as if it
were guarded by... [-Werror=misleading-indentation]
 return default_use_anchors_for_symbol_p (symbol);
 ^~

../../../gcc/gcc/config/darwin.c:3012:7: note: ...this ‘if’ clause, but it is
not
   if (sect->common.flags & SECTION_NO_ANCHOR)
   ^~

cc1plus: all warnings being treated as errors
../../../gcc/gcc/config/t-darwin:22: recipe for target 'darwin.o' failed

I suggest the attached patch for reindention and fixing up trailing whitespace.

[1]
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view=4390920
[2] http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479519

[Bug c/68833] [6 Regression] -Werror=format issues an error now

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 CC||jakub at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r227368.

[Bug c++/68859] New: Add a less strict/smarter version of -Wreorder

[scovich at gmail dot com]

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

Bug ID: 68859
   Summary: Add a less strict/smarter version of -Wreorder
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com
  Target Milestone: ---

I am working with a large legacy code base that triggers a huge number of
warnings when compiled with -Wreorder (or -Wall, which enables it). 

I am not making any excuses for that code, but still it would be nice to have a
weaker-but-smarter variant of -Wreorder that only triggers when the
initialization order actually matters. For example, in the .cpp below, the
warning triggered by struct `definitely_bad` is helpful and identifies a real
bug. The warning for struct `not_a_problem`, on the other hand, is
significantly less interesting because each member is initialized completely
independently of the others (***). The middle example is evil because it calls
a member function of a partially constructed object, so I don't think it much
matters whether this smarter warning would trip or not in that case.

= example.cpp ==
struct definitely_bad {
int val;
int *ptr;
definitely_bad(int *p) : ptr(p), val(*ptr) { }
};
struct bad_for_a_different_reason {
int val;
int *ptr;
bad_for_a_different_reason(int *p)
: ptr(p), val(do_something()) { }
int do_something();
};
struct not_a_problem {
int val;
int *ptr;
not_a_problem(int* p, int v) : ptr(p), val(v) { }
};


Basically, I could imagine building a dependency graph that tracks which member
initializers depend on other members, and then trigger the warning only if the
true initialization order is not a valid partial order in that graph.

(***) I realize that members could have constructors with global side effects
(e.g. calls to printf or changes to global variables). I that case changing the
initialization order would still be observable, but this seems like a rare
enough case that the proposed warning could ignore it (leaving the existing
-Wreorder to flag it if the user desires).

[Bug c++/68859] Add a less strict/smarter version of -Wreorder

[scovich at gmail dot com]

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

--- Comment #1 from Ryan Johnson  ---
(I would be happy to do some legwork on this if somebody is willing to send a
few pointers by PM. I know the code in gcc/cp/init.c, particularly functions
`perform_member_init` and `sort_mem_initializers` are relevant, but would need
some help figuring out how to traverse trees and pick out uses of member
variables from other members' initializers)

[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres  ---
> Feel free to commit your patch, Dominique. You've been faster with providing
> a fix. :) (But maybe incorporate the whitespace fixes as well.)

Done.

[Bug preprocessor/68854] isystem and ansi cause arm assembly preprocessing problem

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  ---
ANSI is a dialect of C.  Why are you passing that flag to an assembler file?

[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2015-12-11 6:45 AM, dominiq at lps dot ens.fr wrote:
> Is this PR fixed by revision r231485?
No.  It just fixed the undefined __sync function warnings from HP ld.  
The above
revision was applied when this PR was reported.

The problem here is we no longer get any backtrace.  Haven't had a 
chance to determine
why.

[Bug target/26427] with -fsection-anchors with zero sized structs

[dominiq at gcc dot gnu.org]

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

--- Comment #25 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Dec 11 16:39:49 2015
New Revision: 231571

URL: https://gcc.gnu.org/viewcvs?rev=231571=gcc=rev
Log:
2015-12-11  Jan-Benedict Glaw  
Dominique d'Humieres  

PR target/26427
PR target/33120
PR testsuite/35710

* config/darwin.c (darwin_use_anchors_for_symbol_p): Fix indention and
trailing whitespace.


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

[Bug target/33120] Data not put in BSS section on Mac OS

[dominiq at gcc dot gnu.org]

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

--- Comment #27 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Dec 11 16:39:49 2015
New Revision: 231571

URL: https://gcc.gnu.org/viewcvs?rev=231571=gcc=rev
Log:
2015-12-11  Jan-Benedict Glaw  
Dominique d'Humieres  

PR target/26427
PR target/33120
PR testsuite/35710

* config/darwin.c (darwin_use_anchors_for_symbol_p): Fix indention and
trailing whitespace.


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

[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)

[dominiq at gcc dot gnu.org]

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

--- Comment #16 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Dec 11 16:39:49 2015
New Revision: 231571

URL: https://gcc.gnu.org/viewcvs?rev=231571=gcc=rev
Log:
2015-12-11  Jan-Benedict Glaw  
Dominique d'Humieres  

PR target/26427
PR target/33120
PR testsuite/35710

* config/darwin.c (darwin_use_anchors_for_symbol_p): Fix indention and
trailing whitespace.


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

[Bug tree-optimization/66740] [6 Regression] omp simd reduction miscompiles at -O3 with AVX (recent regression)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Can you still reproduce it?  I don't see anything wrong on the dumps I've
looked at, without -Ofast of course the order of the floating point arithmetics
is significantly different between -fopenmp and -fno-openmp - but that is to be
expected, you've asked for that.  So, for the iterations that are vectorized,
each SIMD lane has its own sum variable (with the given options the loop seems
to be vectorized with vectorization factor 8, so there are 8 SIMD lanes and
thus 8 separate sum vars), the vector version sums up into those (initialized
with 0), any scalar iterations sum into the first SIMD lane's sum var and
finally at the end the 8 partial sums are summed together (one by one, rather
than what vectorizer normally does for -Ofast reduce them by summing up 4 x 2
numbers, then 2 x 2 numbers, then 2 numbers.
If this is still a problem, can you cook up a small self-contained testcase out
of it (small function with just the #pragma omp simd loop in it, taking the
args as parameters, with noinline/noclone attribute on it ideally, and then
main that
fills up an array with the problematic input values and then checks what the
function returned (sum))?

[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
I'll have a look.

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68851
> 
> --- Comment #3 from Martin Liška  ---
> So the mentioned revision is responsible for creation of a new consprop clone:
> 
> IPA decision stage:
> ...
>  - Creating a specialized node of virtual bool
> blink::HTMLFormControlElement::isFormControlElement() const/14820 for all 
> known
> contexts.
> ...
> IPA constant propagation end

This is fine.  At this point we should have the clone and thunks associated
with it
that are local and have no compdat group.
> 
> 
> and the symbol is identified to be set to a comdat group in ipa-comdats.c:365:
> 
>   if (is_a  (symbol))
>dyn_cast  *>(symbol)->call_for_symbol_thunks_and_aliases
>   (set_comdat_group_1,
>*comdat_head_map.get (group),
>true);
> 
> as the function calls 'set_comdat_group_1' for the constprop cloned function,
> the original function of the clone is thunk and calls the clone. So that
> set_comdat_group_1
> is called for the original function:
> 
> _ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv/14822 
> (virtual
> bool
> blink::HTMLFormControlElement::_ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv()
> const) @0x7fffeb51b8a0
>   Type: function definition analyzed
>   Visibility: externally_visible asm_written public weak comdat
> comdat_group:_ZNK5blink22HTMLFormControlElement20isFormControlElementEv
> one_only
> section:.text._ZNK5blink22HTMLFormControlElement20isFormControlElementEv
> (implicit_section) virtual artificial
>   Same comdat group as:
> _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390
>   Aux: @0x1  References: 
>   Referring: 
>   Availability: available
>   First run: 0
>   Function flags: nonfreeing_fn
>   Thunk fixed offset -96 virtual value 0 has virtual offset 0)
>   Called by: 
>   Calls:
> _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390
> (1.00 per call) (can throw external) 

When do we put
_ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39
to the same comdat group?

Perhaps we forget to clear comdat groups after cloning?

Honza
> 
> constprop clone:
> 
> _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390
> () @0x7fffe8bc6000
>   Type: function definition analyzed
>   Visibility:
> comdat_group:_ZNK5blink22HTMLFormControlElement20isFormControlElementEv
>   Same comdat group as:
> _ZNK5blink22HTMLFormControlElement20isFormControlElementEv/14820
>   previous sharing asm name: 31394
>   References: 
>   Referring: 
>   Clone of _ZNK5blink22HTMLFormControlElement20isFormControlElementEv/14820
>   Availability: local
>   First run: 0
>   Function flags: local nonfreeing_fn
>   Called by:
> _ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv/14822 (1.00
> per call) (can throw external) 
>   Calls: 
> 
> Problem is that the original function has already set comdat_group here:
> 
> #0  symtab_node::set_comdat_group (this=0x7fffeb51b8a0, group=0x7fffeb4dc620)
> at ../../gcc/cgraph.h:220
> #1  0x00a53972 in symtab_node::add_to_same_comdat_group
> (this=0x7fffeb51b8a0, old_node=0x7fffeb51b5c0) at ../../gcc/symtab.c:461
> #2  0x008d05e2 in use_thunk (thunk_fndecl=0x7fffeb4ec7e0, emit_p=true)
> at ../../gcc/cp/method.c:396
> #3  0x008e2979 in emit_associated_thunks (fn=0x7fffeb4dc620) at
> ../../gcc/cp/semantics.c:4080
> #4  0x008e2cb8 in expand_or_defer_fn (fn=0x7fffeb4dc620) at
> ../../gcc/cp/semantics.c:4178
> #5  0x0087a103 in cp_parser_function_definition_after_declarator
> (parser=0x77feeb40, inline_p=true) at ../../gcc/cp/parser.c:25212
> #6  0x0087b772 in cp_parser_late_parsing_for_member
> (parser=0x77feeb40, member_function=0x7fffeb4dc620) at
> ../../gcc/cp/parser.c:26033
> #7  0x008745f7 in cp_parser_class_specifier_1 (parser=0x77feeb40)
> at ../../gcc/cp/parser.c:21412
> #8  0x008746bb in cp_parser_class_specifier (parser=0x77feeb40) at
> ../../gcc/cp/parser.c:21438
> #9  0x0086b65b in cp_parser_type_specifier (parser=0x77feeb40,
> flags=1, decl_specs=0x7fffd6b0, is_declaration=true,
> declares_class_or_enum=0x7fffd634, is_cv_qualifier=0x7fffd633) at
> ../../gcc/cp/parser.c:15736
> #10 0x00867008 in cp_parser_decl_specifier_seq (parser=0x77feeb40,
> flags=1, decl_specs=0x7fffd6b0, declares_class_or_enum=0x7fffd6ac) at
> ../../gcc/cp/parser.c:12657
> #11 0x00866645 in cp_parser_simple_declaration (parser=0x77feeb40,
> function_definition_allowed_p=true, maybe_range_for_decl=0x0) at
> ../../gcc/cp/parser.c:12200
> #12 0x008665cd in cp_parser_block_declaration (parser=0x77feeb40,
> statement_p=false) at ../../gcc/cp/parser.c:12147
> #13 0x0086634f in cp_parser_declaration (parser=0x77feeb40) at
> 

[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)

[jbg...@lug-owl.de]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 CC||jbg...@lug-owl.de

--- Comment #12 from Jan-Benedict Glaw  ---
When building with recent GCCs, this patch produces a warning, see the build
log [1] of build #479519 [2]:

g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/.
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecn
umber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o darwin.o
-MT darwin.o -MMD -MP -MF ./.deps/darwin.TPo ../../../gcc/gcc/config/darwin.c
../../../gcc/gcc/config/darwin.c: In function ‘bool
darwin_use_anchors_for_symbol_p(const_rtx)’:
../../../gcc/gcc/config/darwin.c:3016:9: error: statement is indented as if it
were guarded by... [-Werror=misleading-indentation]
 return default_use_anchors_for_symbol_p (symbol);
 ^~

../../../gcc/gcc/config/darwin.c:3012:7: note: ...this ‘if’ clause, but it is
not
   if (sect->common.flags & SECTION_NO_ANCHOR)
   ^~

cc1plus: all warnings being treated as errors
../../../gcc/gcc/config/t-darwin:22: recipe for target 'darwin.o' failed

I suggest the attached patch for reindention and fixing up trailing whitespace.

[1]
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view=4390920
[2] http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479519

[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)

[jbg...@lug-owl.de]

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

--- Comment #15 from Jan-Benedict Glaw  ---
Feel free to commit your patch, Dominique. You've been faster with providing a
fix. :) (But maybe incorporate the whitespace fixes as well.) Actually, there
are some more in the initial commit, but cleaning them up without really fixing
something just only makes rebasing more difficult.

[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)

[jbg...@lug-owl.de]

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

--- Comment #13 from Jan-Benedict Glaw  ---
Created attachment 36996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36996=edit
Patch to fix indention/trailing whitespace

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Created attachment 36995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36995=edit
unreduced testcase

Started with r226861.

[Bug c++/68810] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #9 from David Edelsohn  ---
PowerPC -m32 (including AIX) also.

[Bug c++/68858] New: Cannot use fold expression in requirements with two parameters packs

[public at alisdairm dot net]

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

Bug ID: 68858
   Summary: Cannot use fold expression in requirements with two
parameters packs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at alisdairm dot net
  Target Milestone: ---

Created attachment 36999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36999=edit
demonstrates requires clause does not recognize parameter packs are constrained
to same length

I am trying to re-implement pair using variadic templates, constrained to a
pack size of exactly two, in order to use fold expressions to simplify
exception specifications and other constraints.  However, I get a hard
(non-SFINAEable) error every time I instantiate my class template, complaining
that parameter packs are not the same length.  Source attached, but in brief,
this is my attempt to contain the packs:

template 
   requires(2 == sizeof...(TYPES))
struct MyPair {
   template 
  requires sizeof...(TYPES) == sizeof...(OTHER_TYPES)
  and (true and ... and is_constructible())
   constexpr
   MyPair(OTHER_TYPES&&... args) 
   noexcept((true and ... and is_nothrow_constructible()));
};

Error message:
error: mismatched argument pack lengths while expanding
'std::is_constructible()'
   requires sizeof...(TYPES) == sizeof...(OTHER_TYPES) and (true and ...
and std::is_constructible())

(note that the example triggering this error does not try to invoke that
constructor, and it parses fine until the implicitly instantiated class
template performs name-lookup for a constructor).


Testing against latest gcc 6 available from MacPorts:  g++ -v

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin15/6.0.0/lto-wrapper
Target: x86_64-apple-darwin15
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20151129/configure
--prefix=/opt/local --build=x86_64-apple-darwin15
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20151129_0'
Thread model: posix
gcc version 6.0.0 20151129 (experimental) (MacPorts gcc6 6-20151129_0)

[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
The while loop in:

 421 void IncrementalMarking::ActivateIncrementalWriteBarrier() {
 422   ActivateIncrementalWriteBarrier(heap_->old_space());
 423   ActivateIncrementalWriteBarrier(heap_->map_space());
 424   ActivateIncrementalWriteBarrier(heap_->code_space());
 425   ActivateIncrementalWriteBarrier(heap_->new_space());
 426
 427   LargePage* lop = heap_->lo_space()->first_page();
 428   while (lop->is_valid()) {
 429 SetOldSpacePageFlags(lop, true, is_compacting_);
 430 lop = lop->next_page();
 431   }
 432 }


Good:  Bad: 
.p2align 4,,10 .p2align 4,,10
.p2align 3 .p2align 3
.L2183:.L2176:
orq $12, 8(%rax)   orq $12, 8(%rax)
movq176(%rax), %raxmovq176(%rax), %rax
testq   %rax, %rax jmp .L2176
jne .L2183 
rep ret
.L2192:
rep ret

[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Created attachment 36996 [details]
> Patch to fix indention/trailing whitespace

Similar patch posted at
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01249.html
and approved at https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01251.html
(without the trailing whitespace fix). Are you planning to commit the patch or
do you want me to do it?

[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
After looking at all the wrong places I finally found the correct
one.  I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01271.html

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres  ---
> I just submitted a new bug. It is a pity that my code cannot be compiled
> with gfortran 4.9 and above for more than a year now..

(Part of) your code should compile with the 5.3.0 release.

[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Expected output fixed on trunk.

[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Dec 11 21:45:51 2015
New Revision: 231574

URL: https://gcc.gnu.org/viewcvs?rev=231574=gcc=rev
Log:
Fix std::invoke support for reference_wrappers

PR libstdc++/59768
* include/std/functional (_Unwrap, __invfwd): Define.
(__invoke_impl): Remove reference_wrapper overloads and use __invfwd.
* include/std/type_traits (__result_of_memobj, __result_of_memfun):
Add partial specializations for const reference_wrappers and simplify.
* testsuite/20_util/bind/ref_neg.cc: Use dg-excess-errors.
* testsuite/20_util/function_objects/invoke/59768.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/function_objects/invoke/
trunk/libstdc++-v3/testsuite/20_util/function_objects/invoke/59768.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc

[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk.

[Bug fortran/68864] [6 Regression] ICE: in gfc_get_descriptor_dimension, at fortran/trans-array.c:268

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|bug 61819 is not completely |[6 Regression] ICE: in
   |fixed   |gfc_get_descriptor_dimensio
   ||n, at
   ||fortran/trans-array.c:268

--- Comment #2 from Dominique d'Humieres  ---
> The code compiles with 5.3.0 and 5.3.1 (r231560). With trunk it compiles
> with r229303 (2015-10-25), r229438 gives the ICE

Hence a regression.

[Bug libstdc++/56861] std::vector::reserve optimization bug

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Jonathan Wakely  ---
This is the testcase, without the Boost dependency. Compile with -std=c++11.
Define RESERVE or RESERVE_PLUS_ONE to change the behaviour.

I can't reproduce any significant difference in performance using 4.7.4 or
trunk. The time is surely bound by the std::find_if calls and I/O on the file
(which fails unless the file already exists btw, because you use std::fstream
not std::ofstream).

I don't see any bug here, or anything that needs fixing.


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

namespace {
constexpr size_t array_size = 1;

unsigned number() {
static std::random_device rd;
static std::mt19937 random_engine(rd());
static std::uniform_int_distribution distribution(0,
std::numeric_limits::max());
return distribution(random_engine);
}

class Class {
public:
Class() {
x[0] = number();
}
std::string to_string() const {
return std::to_string(x[0]);
}
inline friend bool operator<=(Class const & lhs, Class const &
rhs) {
return lhs.x[0] <= rhs.x[0];
}
private:
std::array x;
};

template
void add(Container & container, Class const & value) {
auto const it = std::find_if(std::begin(container),
std::end(container), [&](Class const & c) {
return value <= c;
});
container.emplace(it, value);
}

// Do something with the result
template
void insert_to_file(Container const & container) {
std::fstream file("file.txt");
for (auto const & value : container) {
file << value.to_string() << '\n';
}
}

template
void f(std::vector const & values) {
Container container;
#if defined RESERVE
container.reserve(values.size());
#elif defined RESERVE_PLUS_ONE
container.reserve(values.size() + 1);
#endif
for (auto const & value : values) {
add(container, value);
}
insert_to_file(container);
}

}

int main(int argc, char ** argv) {
std::size_t const size = (argc == 1) ? 1 : std::stoul(argv[1]);
// Default constructor of Class fills in values here
std::vector const values_to_be_copied(size);
typedef std::vector Container;
auto start = std::chrono::system_clock::now();
f(values_to_be_copied);
auto finish = std::chrono::system_clock::now();
std::cerr << "Finished in " <<
std::chrono::duration_cast(finish -
start).count() << " seconds.\n";
}

[Bug fortran/68864] bug 61819 is not completely fixed

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The code compiles with 5.3.0 and 5.3.1 (r231560). With trunk it compiles with
r229303 (2015-10-25), r229438 gives the ICE

pr68864.f90:23:0:

 End Module part_base2_class
1
internal compiler error: in gfc_get_descriptor_dimension, at
fortran/trans-array.c:272

up to r231573.

[Bug fortran/68856] wrong compilation wtih character interoperability

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr46496 item (f) in comment 0.

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

[Bug libstdc++/63617] Crash in libstdc++ on AIX.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The currently supported releases are shown on https://gcc.gnu.org/

At any time there are two supported releases series, currently 4.9.x and 5.x,
which changes annually when the new release happens (GCC 6 is due around
April).

Without the information requested by https://gcc.gnu.org/bugs/ and using a
supported release this bug report will probably be closed.

[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
That's very possible.  No doubt r231165 just caused it to come out of the
woodwork again.  However, I verified that it didn't ICE with r230600 - r231164,
so something about r231165 managed to trigger the issue.

Thanks for looking at it!

[Bug libfortran/68867] New: numeric formatting problem in the fortran library

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 68867
   Summary: numeric formatting problem in the fortran library
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

There is a problem in the formatting code in the fortran library.  The test
case fmt_g0_7.f8 has been failing for a while now and while investigating it I
realized that it only fails when using the fortran library built with gcc trunk
but works when I use the library from gcc 5.1 or earlier versions.  I don't
know fortran so it could be that the library is correct and the test case is
wrong.


seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ export
LD_LIBRARY_PATH=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
 
seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ ./fmt_g0_7.exe 

Program aborted. Backtrace:
Aborted (core dumped)
seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ unset LD_LIBRARY_PATH
seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ ./fmt_g0_7.exe 
seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$


The abort comes from line 30 of the test case

  if (n /= 0) call abort


If I run the code via gdb using the 6.0 library:

Breakpoint 1, testit () at
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/fmt_g0_7.f08:14
14write(astring, '(ru,g0)') 1.0/real(10.0, kind=j(1))
(gdb) n
22  if (astring(2:2) /= '9') then
(gdb) print astring
$1 = '0.10002', ' ' 


But I see this when using an earlier library:

Breakpoint 1, testit () at
/home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/fmt_g0_7.f08:14
14write(astring, '(ru,g0)') 1.0/real(10.0, kind=j(1))
(gdb) n
22  if (astring(2:2) /= '9') then
(gdb) print astring
$1 = '.10002', ' ' 


Note the difference in the format of the decimal number.

All 4 tests that the code does differ similarly and one of the differences
triggers the call to abort.

[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #2 from Jeffrey A. Law  ---
So there's 4 potential jump threads as we enter the first DOM pass.  Before the
change in question, all 4 would be threaded.

After the change, we record just two threads and only actually realize one jump
thread.  So what happened?

One of the two recorded jump threads is explicitly dropped.  The block in
question originally looks like:

:
# kill_elt_40 = PHI 
if (b_elt_10(D) != 0B)
  goto ;
else
  goto ;

We record a jump thread (7,18); (18,10) as exit block #7.  We later proceed to
optimize block 18 to look like:

# kill_elt_40 = PHI 
goto ;

(ie, along every path we know that b_elt_10 != 0B)

So we remove the recorded jump thread (7,18); (18,10) -- this is desired
behaviour.  So the recorded, but unrealized jump thread is easily explained.

Additionally, by optimizing block #18 like that, we find there's no need to
record the jump thread (5,18); (18,10).   Again, desired behaviour.

We have a similar situation arise in another block:

:
if (b_elt_10(D) != 0B)
  goto ;
else
  goto ;


We optimize bb8 to look like:

:
goto ;


Which eliminates the need for the jump thread (15,3); (3,8)J; (8,14).  Very
desirable behaviour as well.


So of the 4 potential jump threads, only 1 is actually still relevant after the
change in question.  And it is properly threaded ;-)  So everything is doing
exactly what it should and we just need to twiddle the testcase a bit to
reflect current reality.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Which platform are you using (gfortran -v)?
> 
> What is the output if you uncomment the line
> 
>   !print *, i, l, trim(astring)
> 
> ?

This is probably related to 

2015-11-22  Jerry DeLisle  

* io/write_float.def (output_float): Move block determining
room for leading zero to before checkng g0 formatting.

but William did not define "has been failing for a while now".

[Bug lto/68799] lto ICE on powerpc64le-linux-gnu builing python 2.7.x

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #4 from Bill Schmidt  ---
Confirmed while building in doko's environment.  However, I haven't been able
to fully sort out the problem by looking at the SLSR detail dumps.  It appears
to involve two conditional candidates that depend on the same PHI basis.  The
first one is processed correctly, introducing a new PHI basis for it, but when
we look at the second one it appears that we can no longer map from the PHI
statement to the PHI candidate.  It may have to do with using split_edge to
place the add statements that feed the new PHI basis, but off the cuff I don't
see anything wrong with that.

Matthias, can you please incorporate th3 debug patch from the previous comment
into your source so I can gather more information at the time of the failure? 
It won't change behavior of the compiler unless -fdump-tree-slsr* is specified.

[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Fri Dec 11 23:18:22 2015
New Revision: 231577

URL: https://gcc.gnu.org/viewcvs?rev=231577=gcc=rev
Log:
[PATCH][PR tree-optimization/68844] Fix testcase expected output

PR tree-optimization/68844
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Update expected output.

2015-12-11  Jan Beulich  

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c

[Bug c/68866] New: ICE in set_lattice_value, at tree-ssa-cpp.c:490

[felix.janda at posteo dot de]

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

Bug ID: 68866
   Summary: ICE in set_lattice_value, at tree-ssa-cpp.c:490
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.janda at posteo dot de
  Target Milestone: ---

Minimal test case (containing invalid code):

static char *a[] = {""};
int main(void) {
for(int i=1;i<2;i++) if(a[i]) break;
}

The same error was already observed in

http://www.openwall.com/lists/musl/2013/11/07/14

[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Roland, could you please clarify the request, or I'll close this report as
WORKSFORME. What do you mean by "unstable iterator" and what is the problem you
want to solve?

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Dec 11 21:58:48 2015
New Revision: 231575

URL: https://gcc.gnu.org/viewcvs?rev=231575=gcc=rev
Log:
PR middle-end/68215
* 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 fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||valeryweber at hotmail dot com

--- Comment #3 from Dominique d'Humieres  ---
*** Bug 68856 has been marked as a duplicate of this bug. ***

[Bug libstdc++/61617] add boost::coroutine

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Closing, this isn't something we want to add until it comes through the
standardisation process, and it doesn't look like Boost.Coroutine is the
direction the committee is going.

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
This bug isn't fixed in GCC 4.9.  -O3 increases alignment from
64 bits to 128 bits on the original testcase:

Hardware watchpoint 6: *(unsigned int *) 0x7fffee9b4468

Old value = 64
New value = 128
ensure_base_align (stmt_info=0x1c8f990, dr=0x1db5b20)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:4907
4907  DECL_USER_ALIGN (base_decl) = 1;
(gdb) bt
#0  ensure_base_align (stmt_info=0x1c8f990, dr=0x1db5b20)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:4907
#1  0x00d33471 in vectorizable_store (stmt=0x7fffed95a280, 
gsi=0x7fffd830, vec_stmt=0x7fffd790, slp_node=0x1d9e7a0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:5131
#2  0x00d38f80 in vect_transform_stmt (stmt=0x7fffed95a280, 
gsi=0x7fffd830, grouped_store=0x7fffd84a, slp_node=0x1d9e7a0, 
slp_node_instance=0x1cb3e10)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7211
#3  0x00d5a980 in vect_schedule_slp_instance (node=0x1d9e7a0, 
instance=0x1cb3e10, vectorization_factor=1)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-slp.c:3084
#4  0x00d5abd0 in vect_schedule_slp (loop_vinfo=0x0, 
bb_vinfo=0x1ddf410)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-slp.c:3154
#5  0x00d5aea7 in vect_slp_transform_bb (bb=0x7fffece8ec30)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-slp.c:3230
#6  0x00d5e41b in execute_vect_slp ()
at /export/gnu/import/git/gcc-release/gcc/tree-vectorizer.c:605
#7  0x00d5e4c9 in (anonymous namespace)::pass_slp_vectorize::execute (
this=0x1b97010)
at /export/gnu/import/git/gcc-release/gcc/tree-vectorizer.c:649
#8  0x00a7da14 in execute_one_pass (pass=0x1b97010)
---Type  to continue, or q  to quit---q
 at /export/gnu/imporQuit
(gdb) f 1
#1  0x00d33471 in vectorizable_store (stmt=0x7fffed95a280, 
gsi=0x7fffd830, vec_stmt=0x7fffd790, slp_node=0x1d9e7a0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:5131
5131  ensure_base_align (stmt_info, dr);
(gdb) f 2
#2  0x00d38f80 in vect_transform_stmt (stmt=0x7fffed95a280, 
gsi=0x7fffd830, grouped_store=0x7fffd84a, slp_node=0x1d9e7a0, 
slp_node_instance=0x1cb3e10)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7211
7211  done = vectorizable_store (stmt, gsi, _stmt, slp_node);
(gdb) 

This bug may be really fixed by r221268:

iff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index aa9d43f..41ff802 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -4956,8 +4956,13 @@ ensure_base_align (stmt_vec_info stmt_info, struct
data_reference *dr)
   tree vectype = STMT_VINFO_VECTYPE (stmt_info);
   tree base_decl = ((dataref_aux *)dr->aux)->base_decl;

-  DECL_ALIGN (base_decl) = TYPE_ALIGN (vectype);
-  DECL_USER_ALIGN (base_decl) = 1;
+  if (decl_in_symtab_p (base_decl))
+  symtab_node::get (base_decl)->increase_alignment (TYPE_ALIGN (vectype));
+  else
+  {
+  DECL_ALIGN (base_decl) = TYPE_ALIGN (vectype);
+  DECL_USER_ALIGN (base_decl) = 1;
+  }
   ((dataref_aux *)dr->aux)->base_misaligned = false;
 }
 }

in GCC 5.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #3 from Bill Schmidt  ---
(In reply to kargl from comment #2)
> 
> This is probably related to 
> 
> 2015-11-22  Jerry DeLisle  
> 
> * io/write_float.def (output_float): Move block determining
> room for leading zero to before checkng g0 formatting.
> 
> but William did not define "has been failing for a while now".

I can confirm that this began failing with r230728, which is Jerry's patch.

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from William Seurer  ---
Removing the comment gives:

   3  39 0.6919E-0001

Program aborted. Backtrace:
Aborted (core dumped)


It's been failing for at least a week; that's when I first noticed it.

I'm running on power8 little endian though it also fails on big endian.

gfortran -v:

Using built-in specs.
COLLECT_GCC=/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran7/../../gfortran
Target: powerpc64le-unknown-linux-gnu
Configured with: ...
Thread model: posix
gcc version 6.0.0 20151211 (experimental) [trunk revision 231573] (GCC)

[Bug libstdc++/50703] std::stringstream not thread-safe

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
No testcase or results for supported releases provided, closing.

[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
It used to ICE before this patch.  It has for a long time.
This isn't the patch you are looking for.

I'll take a look though, sure.  Simplified testcase:

===
static void __attribute__ ((noinline))
testit (void)
{
  static volatile _Atomic unsigned int a = (unsigned int) (-70);
  if ((a /= (-10)) != (unsigned int) ((unsigned int) (-70) / (-10)))
abort ();
}

int
main (void)
{
  testit ();

  exit (0);
}
===

(compile with -O2 -latomic).

[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Yes, this would happen if you're setting CC and CXX, causing libstdc++ to be
configured using the compiler specified by those variables, not the one that
has just been built. So I think this is user error.

[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #26 from Jonathan Wakely  ---
Feedback not forthcoming, closing.

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[kargl at gcc dot gnu.org]

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

--- Comment #22 from kargl at gcc dot gnu.org ---
(In reply to Hossein Talebi from comment #20)
> I just submitted a new bug. It is a pity that my code cannot be compiled
> with gfortran 4.9 and above for more than a year now..

It is comments like the above that inspire me to invest my
time in gfortran.   Thanks for your support.

[Bug libfortran/68867] numeric formatting problem in the fortran library

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-12-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Which platform are you using (gfortran -v)?

What is the output if you uncomment the line

!print *, i, l, trim(astring)

?