[Bug inline-asm/68843] ICE with "u" input constraint

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
hmm, yes.

the registers are named "st" "st(1)" "st(2)" .. "st(7)"

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

[burnus at gcc dot gnu.org]

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

Bug ID: 68850
   Summary: Coarray events: EVENT_QUERY not documented as
intrinsic subroutine
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: fanfarillo.gcc at gmail dot com
  Target Milestone: ---

The gfortran manual, https://gcc.gnu.org/onlinedocs/gfortran/ is supposed to
document all supported intrinsic functions and subroutines.

The recently added EVENT_QUERY atomic subroutine is not documented (only the
API to the libarary is).

Cf. 8.4.15 in N2974:
http://isotc.iso.org/livelink/livelink/nfetch/-8919044/8919782/8919787/17001078/ISO-IECJTC1-SC22-WG5_N2074_Draft_TS_18508_Additional_Paralle.pdf?nodeid=17288706&vernum=0

[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/68832] FAIL: gcc.c-torture/execute/alias-2.c -O1 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Richard Biener  ---
Honza, please have a look here.

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

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
the statement:
  else if (i == 3)
k = 12;
is not evaluated; in iteration 3, k == 8.

[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 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 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 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 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 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 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 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&action=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 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 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 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 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&root=gcc&view=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 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 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 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 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&root=gcc&view=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 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 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 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 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 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 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&action=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 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?

gcc-bugs@gcc.gnu.org

[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&root=gcc&view=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

gcc-bugs@gcc.gnu.org

[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 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 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 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 blink::PaintLayerCompositor::updateIfNeeded() ()
#7  0x58b680a6 in
blink::PaintLayerCompositor::updateIfNeededRecursive() ()

However this is a different issue, because -O1 "fixes" it.

[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 cp_parser_translation_u

[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

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

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Can you bisect it to the alias changes from Honza or is this older?  Is this
part of chromium single-threaded?

[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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|spec2006 test case  |[6 Regression] spec2006
   |465.tonto fails with the|test case 465.tonto fails
   |gcc 6.0 fortran compiler|with the gcc 6.0 fortran
   ||compiler

[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&action=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 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 #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 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 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&action=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 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 = &REALPART_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 = &REALPART_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/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/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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Richard Biener  ---
So before the patch:

  _9157 = (void *) ivtmp.7110_9173;
  vect__1371.6453_5409 = MEM[base: _9157, offset: 0B];
  _9156 = (void *) ivtmp.7111_9168;
  [shell2.fppized.f90:975:0] _964 = MEM[base: _9156, offset: 0B];
...
  _3980 = REALPART_EXPR <_968>;
  _390 = IMAGPART_EXPR <_968>;
  [shell2.fppized.f90:975:0] vect_cst__10558 = {_964, _964};
  [shell2.fppized.f90:975:0] vect_cst__10556 = {_3980, _390};
  [shell2.fppized.f90:975:0] vect__455.6454_10315 = vect_cst__10556 *
vect_cst__10558 + vect__1371.6453_5409;
  [shell2.fppized.f90:975:0] MEM[base: _9157, offset: 0B] =
vect__455.6454_10315;

after it:

  _9159 = (void *) ivtmp.7109_9175;
  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];
...
  _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;

somehow the IMAGPART <_968> * _964 got "lost" and replaced by a load from _395.

So a bug in the vectorizer after all.  More next week ...

[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/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 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 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&action=edit
unreduced testcase

Started with r226861.

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[alalaw01 at gcc dot gnu.org]

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

--- Comment #10 from alalaw01 at gcc dot gnu.org ---
This causes to FAIL the scan-tree-dump-times 'vectorizing stmts using SLP' in
slp-perm-{1,2,3,5,6,7,8,11}.c. Looking at the assembler before and after...

slp-perm-1.c: this looks a big win; several st3's are generated instead of many
stp's, we lose all the tbl's, and many constant-pool entries consisting of
'byte's are removed, with the corresponding ADRP's. The loop is fully unrolled
in both cases, and the new code is much shorter (48 instructions rather than
95).

slp-perm-2.c: less clear, but looks like an overall win. Loop gets unrolled by
factor of 2; each "half" loses a TRN1 and a TRN2 but gains an ORR (move).

slp-perm-3.c: Again we lose a load of constants and ADRPs (outside the
4-iteration loop), gaining some MOVIs. With the patchlet, the loop gets fully
unrolled, and loses 4*tbl per iteration (!). Still executing 8*mul, 8*mla,
4*add, but dropping the TBLs again makes for a win.

slp-perm-5: less clear, but again looks like an overall win. Both loops have
been fully unrolled, and the combining of stores doesn't help much (we seem to
gain as many moves as we lose stores!). but with the patch, we lose several
TBLs and TRNs. Also an MLA becomes a MUL.

A side comment would be that if we could 'fix' the register allocation here, to
put things into the right place ready for the stN rather than moving it there
later, we'd have quite a big win...but that's another issue.

Also a recurring theme is that the vec_(load/store)_lanes approach seems to
make much better use of movi, rather than pushing things into the constant
pool. I haven't really looked into this, it may be fundamental, or just a
limitation of our current code for loading immediates.

slp-perm-6: some wins from constants, and dropping 8 tbls.

slp-perm-7.c: Similarly.

slp-perm-8.c: Loop here iterates 4 times, and the ld3/st3 manages to lose us
4*move and 9*tbl per iteration (!); huge improvement.

slp-perm-11.c: a 16-iteration loop gets unrolled *2, and now uses an st2, but
no load_lanes, just a bunch of ldr's: 10 rather than the original 3(*2). 3 strs
become 4 stp's (+st2). Doesn't look like an improvement!

However, 7 out of 8 cases look better, in some cases much better. So I'd say
that was a definite codegen improvement :).

[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&id=4390920
[2] http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479519

[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&id=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 #13 from Jan-Benedict Glaw  ---
Created attachment 36996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36996&action=edit
Patch to fix indention/trailing whitespace

[Bug ipa/68857] New: [6 regression] FAIL: gcc.target/i386/mpx/vararg-8-nov.c -O3 -g (internal compiler error)

[ienkovich at gcc dot gnu.org]

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

Bug ID: 68857
   Summary: [6 regression] FAIL:
gcc.target/i386/mpx/vararg-8-nov.c   -O3 -g  (internal
compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Starts from r231540

>gcc -mmpx -fcheck-pointer-bounds -O3 vararg-8-nov.c -c
vararg-8-nov.c:35:1: error: Instrumentation thunk has wrong edge callee
 }
 ^

foo/3 (foo) @0x7fe77ca4a170
  Type: function definition analyzed
  Visibility: externally_visible public
  References: foo.chkp/8 (chkp)
  Referring:
  Availability: available
  First run: 0
  Function flags:
  Thunk fixed offset 0 virtual value 0 has virtual offset 0)
  Called by:
  Calls: foo.chkp.constprop.0/19 (1.00 per call)
  Has instrumented version.
vararg-8-nov.c:35:1: internal compiler error: verify_cgraph_node failed
0x8a7b59 cgraph_node::verify_node()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraph.c:3163
0x897d25 symtab_node::verify()
/export/users/ienkovic/issues/mpx/gcc/gcc/symtab.c:1170
0x897da6 symtab_node::verify_symtab_nodes()
/export/users/ienkovic/issues/mpx/gcc/gcc/symtab.c:1190
0x8b5ab0 symtab_node::checking_verify_symtab_nodes()
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraph.h:602
0xb210d6 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/export/users/ienkovic/issues/mpx/gcc/gcc/ipa.c:673
0xc5fff6 execute_todo
/export/users/ienkovic/issues/mpx/gcc/gcc/passes.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

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

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

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

--- Comment #23 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&id=4390920
[2] http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479519

[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

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

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

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

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

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

[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&action=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 tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[seurer at linux dot vnet.ibm.com]

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

--- Comment #10 from William Seurer  ---
It fails with -fdbg-cnt=vect_slp:31 and succeeds with -fdbg-cnt=vect_slp:30

[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 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 rtl-optimization/64818] User specified register don't work correctly in inline-asm operands.

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[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&action=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 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 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 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 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 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&root=gcc&view=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/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&root=gcc&view=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&root=gcc&view=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 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 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 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&action=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 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 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 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 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 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 #5 from Markus Trippelsdorf  ---
Created attachment 37002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37002&action=edit
unreduced testcase

Reducing is very slow. Here is the unreduced testcase.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #21 from The Written Word  
---
I built gcc-4.7.4 with the change to gcc/config/ia64/hpux.h of "#undef
MAKE_DECL_ONE_ONLY" and just tried building gcc-4.8.5. Is anyone else seeing
this when trying to build libgomp:
/opt/build/gcc-4.8.5/libgomp/parallel.c: In function
'omp_get_ancestor_thread_num':
/opt/build/gcc-4.8.5/libgomp/parallel.c:169:1: internal compiler error: in
plus_constant, at explow.c:86
 omp_get_ancestor_thread_num (int level)
 ^

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[alm at sibmail dot ru]

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

--- Comment #22 from Alexander  ---
I tried using libgomp but is the same as your error has occurred.
After that , I only used libgmp, libmpc and libmpfr ( in the GCC source tree )
.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #23 from The Written Word  
---
(In reply to Alexander from comment #22)
> I tried using libgomp but is the same as your error has occurred.
> After that , I only used libgmp, libmpc and libmpfr ( in the GCC source tree
> ) .

How do you avoid libgomp? When building 4.8.5, we're using out-of-tree
gmp-5.1.2, mpfr-3.1.2, and mpc-1.0.3.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[jvb at cyberscience dot com]

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

--- Comment #24 from John Buddery  ---
You can use --disable-libgomp in the configure command, I had to do this on my
HP builds.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[alm at sibmail dot ru]

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

--- Comment #25 from Alexander  ---
../gcc-4.8.5/configure \
--enable-languages=c,c++
--prefix=/import/home/nskdvlp/CC_Libs/CC/ia64-hp-hpux_11.31_-64 \
--with-local-prefix=/usr/CC/ia64-hp-hpux_11.31_-64 --with-gnu-as \
--with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld \
--disable-nls --disable-libgcj --enable-shared --enable-threads=posix
--with-dwarf2   \
--disable-libgomp SED=/usr/local/bin/sed SHELL=/usr/bin/bash --enable-lto

is my configure cmd line (but libs inlace in tree)

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

[vasyl.vavrychuk at globallogic dot com]

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

--- Comment #2 from vasyl.vavrychuk at globallogic dot com ---
--ansi is passed by build system of a big 3rd party project that I compile. It
is possible to change it to remove --ansi but in my opinion there is gcc bug
too. Gcc should either:
* ignore ansi in the case of assembly source
* report that ansi is invalid option

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Andrew Pinski  ---
Calling a NULL object is undefined.  


  Address address() { return reinterpret_cast(this); }

  bool is_valid() { return address() !=
# 475 "../../v8/src/heap/spaces.h" 3 4
   __null
# 475 "../../v8/src/heap/spaces.h"
   ; }


That will always be true.  That is this can never be NULL.

[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 #37001|0   |1
is obsolete||

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

the v3 patch fixes coding conventions (thanks, Bernd Schmidt!)

[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 #37004|0   |1
is obsolete||

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

[Bug tree-optimization/68861] New: [6 regression] FAIL: libgomp.fortran/vla8.f90 -O3 -g execution test

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

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

Bug ID: 68861
   Summary: [6 regression] FAIL: libgomp.fortran/vla8.f90   -O3 -g
 execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: law at redhat dot com
Blocks: 68619
  Target Milestone: ---
Target: aarch64-*-*

$ gcc/xgcc -Bgcc/ ../libgomp/testsuite/libgomp.fortran/vla8.f90
-Baarch64-suse-linux/./libgomp/ -Baarch64-suse-linux/./libgomp/.libs
-Iaarch64-suse-linux/./libgomp -I../include -I../libgomp -fopenmp -O3 -g
-Baarch64-suse-linux/libgfortran/.libs
-fintrinsic-modules-path=aarch64-suse-linux/libgomp
-Laarch64-suse-linux/libgomp/.libs -Laarch64-suse-linux/libgfortran/.libs
-lgfortran -lm -o ./vla8.exe
$
LD_LIBRARY_PATH=.:aarch64-suse-linux/libgomp/.libs:gcc:aarch64-suse-linux/libgfortran/.libs:aarch64-suse-linux/libstdc++-v3/src/.libs
./vla8.exe

Program aborted. Backtrace:
Aborted (core dumped)

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68619
[Bug 68619] [6 Regression] error: loop with header 6 not in loop tree

[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 #37003|0   |1
is obsolete||

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

[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Updated patch kit posted here:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01291.html