[Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]

public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed

* [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]
@ 2013-05-08 12:30 marxin.liska at gmail dot com
  2013-05-08 12:32 ` [Bug c++/57208] " marxin.liska at gmail dot com
                   ` (28 more replies)
  0 siblings, 29 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-05-08 12:30 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

             Bug #: 57208
           Summary: Latest chromium compilation fails with enabled LTO
                    [4.8.1/4.9.0]
    Classification: Unclassified
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marxin.liska@gmail.com


Chromium git repository: May 4, 2013

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/marxin/gcc48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,java --enable-bootstrap
--disable-libsanitizer --prefix=/home/marxin/gcc48
Thread model: posix
gcc version 4.8.1 20130505 (prerelease) (GCC) 

failure:
g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC
-Wl,-uIsHeapProfilerRunning,-uProfilerStart
-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22InitialMallocHook_MMapPKvS0_jiiix,-u_Z22InitialMallocHook_SbrkPKvi
-Wl,-u_Z21InitialMallocHook_NewPKvm,-u_Z22InitialMallocHook_MMapPKvS0_miiil,-u_Z22InitialMallocHook_SbrkPKvl
-Wl,-u_ZN15HeapLeakChecker12IgnoreObjectEPKv,-u_ZN15HeapLeakChecker14UnIgnoreObjectEPKv
-Wl,-O1 -Wl,--as-needed -flto=9 -fno-fat-lto-objects -Wl,--gc-sections  -o
out/Release/base_unittests -Wl,--start-group
out/Release/obj.target/base_unittests/base/at_exit_unittest.o
out/Release/obj.target/base_unittests/base/atomicops_unittest.o
out/Release/obj.target/base_unittests/base/base64_unittest.o
out/Release/obj.target/base_unittests/base/bind_helpers_unittest.o
out/Release/obj.target/base_unittests/base/bind_unittest.o
out/Release/obj.target/base_unittests/base/bits_unittest.o
out/Release/obj.target/base_unittests/base/build_time_unittest.o
out/Release/obj.target/base_unittests/base/callback_unittest.o
out/Release/obj.target/base_unittests/base/cancelable_callback_unittest.o
out/Release/obj.target/base_unittests/base/command_line_unittest.o
out/Release/obj.target/base_unittests/base/containers/linked_list_unittest.o
out/Release/obj.target/base_unittests/base/containers/mru_cache_unittest.o
out/Release/obj.target/base_unittests/base/containers/small_map_unittest.o
out/Release/obj.target/base_unittests/base/containers/stack_container_unittest.o
out/Release/obj.target/base_unittests/base/cpu_unittest.o
out/Release/obj.target/base_unittests/base/debug/crash_logging_unittest.o
out/Release/obj.target/base_unittests/base/debug/leak_tracker_unittest.o
out/Release/obj.target/base_unittests/base/debug/stack_trace_unittest.o
out/Release/obj.target/base_unittests/base/debug/trace_event_unittest.o
out/Release/obj.target/base_unittests/base/deferred_sequenced_task_runner_unittest.o
out/Release/obj.target/base_unittests/base/environment_unittest.o
out/Release/obj.target/base_unittests/base/file_util_unittest.o
out/Release/obj.target/base_unittests/base/files/dir_reader_posix_unittest.o
out/Release/obj.target/base_unittests/base/files/file_path_unittest.o
out/Release/obj.target/base_unittests/base/files/file_util_proxy_unittest.o
out/Release/obj.target/base_unittests/base/files/important_file_writer_unittest.o
out/Release/obj.target/base_unittests/base/files/scoped_temp_dir_unittest.o
out/Release/obj.target/base_unittests/base/gmock_unittest.o
out/Release/obj.target/base_unittests/base/guid_unittest.o
out/Release/obj.target/base_unittests/base/hi_res_timer_manager_unittest.o
out/Release/obj.target/base_unittests/base/id_map_unittest.o
out/Release/obj.target/base_unittests/base/i18n/break_iterator_unittest.o
out/Release/obj.target/base_unittests/base/i18n/char_iterator_unittest.o
out/Release/obj.target/base_unittests/base/i18n/case_conversion_unittest.o
out/Release/obj.target/base_unittests/base/i18n/file_util_icu_unittest.o
out/Release/obj.target/base_unittests/base/i18n/icu_string_conversions_unittest.o
out/Release/obj.target/base_unittests/base/i18n/number_formatting_unittest.o
out/Release/obj.target/base_unittests/base/i18n/rtl_unittest.o
out/Release/obj.target/base_unittests/base/i18n/string_search_unittest.o
out/Release/obj.target/base_unittests/base/i18n/time_formatting_unittest.o
out/Release/obj.target/base_unittests/base/json/json_parser_unittest.o
out/Release/obj.target/base_unittests/base/json/json_reader_unittest.o
out/Release/obj.target/base_unittests/base/json/json_value_converter_unittest.o
out/Release/obj.target/base_unittests/base/json/json_value_serializer_unittest.o
out/Release/obj.target/base_unittests/base/json/json_writer_unittest.o
out/Release/obj.target/base_unittests/base/json/string_escape_unittest.o
out/Release/obj.target/base_unittests/base/lazy_instance_unittest.o
out/Release/obj.target/base_unittests/base/logging_unittest.o
out/Release/obj.target/base_unittests/base/md5_unittest.o
out/Release/obj.target/base_unittests/base/memory/aligned_memory_unittest.o
out/Release/obj.target/base_unittests/base/memory/discardable_memory_unittest.o
out/Release/obj.target/base_unittests/base/memory/linked_ptr_unittest.o
out/Release/obj.target/base_unittests/base/memory/ref_counted_memory_unittest.o
out/Release/obj.target/base_unittests/base/memory/ref_counted_unittest.o
out/Release/obj.target/base_unittests/base/memory/scoped_ptr_unittest.o
out/Release/obj.target/base_unittests/base/memory/scoped_vector_unittest.o
out/Release/obj.target/base_unittests/base/memory/shared_memory_unittest.o
out/Release/obj.target/base_unittests/base/memory/singleton_unittest.o
out/Release/obj.target/base_unittests/base/memory/weak_ptr_unittest.o
out/Release/obj.target/base_unittests/base/message_loop/message_loop_proxy_impl_unittest.o
out/Release/obj.target/base_unittests/base/message_loop/message_loop_proxy_unittest.o
out/Release/obj.target/base_unittests/base/message_loop_unittest.o
out/Release/obj.target/base_unittests/base/message_pump_glib_unittest.o
out/Release/obj.target/base_unittests/base/message_pump_libevent_unittest.o
out/Release/obj.target/base_unittests/base/metrics/sample_map_unittest.o
out/Release/obj.target/base_unittests/base/metrics/sample_vector_unittest.o
out/Release/obj.target/base_unittests/base/metrics/bucket_ranges_unittest.o
out/Release/obj.target/base_unittests/base/metrics/field_trial_unittest.o
out/Release/obj.target/base_unittests/base/metrics/histogram_base_unittest.o
out/Release/obj.target/base_unittests/base/metrics/histogram_unittest.o
out/Release/obj.target/base_unittests/base/metrics/sparse_histogram_unittest.o
out/Release/obj.target/base_unittests/base/metrics/stats_table_unittest.o
out/Release/obj.target/base_unittests/base/metrics/statistics_recorder_unittest.o
out/Release/obj.target/base_unittests/base/observer_list_unittest.o
out/Release/obj.target/base_unittests/base/path_service_unittest.o
out/Release/obj.target/base_unittests/base/pickle_unittest.o
out/Release/obj.target/base_unittests/base/platform_file_unittest.o
out/Release/obj.target/base_unittests/base/posix/file_descriptor_shuffle_unittest.o
out/Release/obj.target/base_unittests/base/posix/unix_domain_socket_linux_unittest.o
out/Release/obj.target/base_unittests/base/power_monitor/power_monitor_unittest.o
out/Release/obj.target/base_unittests/base/pr_time_unittest.o
out/Release/obj.target/base_unittests/base/prefs/default_pref_store_unittest.o
out/Release/obj.target/base_unittests/base/prefs/json_pref_store_unittest.o
out/Release/obj.target/base_unittests/base/prefs/overlay_user_pref_store_unittest.o
out/Release/obj.target/base_unittests/base/prefs/pref_change_registrar_unittest.o
out/Release/obj.target/base_unittests/base/prefs/pref_member_unittest.o
out/Release/obj.target/base_unittests/base/prefs/pref_notifier_impl_unittest.o
out/Release/obj.target/base_unittests/base/prefs/pref_service_unittest.o
out/Release/obj.target/base_unittests/base/prefs/pref_value_map_unittest.o
out/Release/obj.target/base_unittests/base/prefs/pref_value_store_unittest.o
out/Release/obj.target/base_unittests/base/process_util_unittest.o
out/Release/obj.target/base_unittests/base/profiler/tracked_time_unittest.o
out/Release/obj.target/base_unittests/base/rand_util_unittest.o
out/Release/obj.target/base_unittests/base/safe_numerics_unittest.o
out/Release/obj.target/base_unittests/base/scoped_clear_errno_unittest.o
out/Release/obj.target/base_unittests/base/scoped_native_library_unittest.o
out/Release/obj.target/base_unittests/base/security_unittest.o
out/Release/obj.target/base_unittests/base/sequence_checker_unittest.o
out/Release/obj.target/base_unittests/base/sequence_checker_impl_unittest.o
out/Release/obj.target/base_unittests/base/sha1_unittest.o
out/Release/obj.target/base_unittests/base/stl_util_unittest.o
out/Release/obj.target/base_unittests/base/string16_unittest.o
out/Release/obj.target/base_unittests/base/string_util_unittest.o
out/Release/obj.target/base_unittests/base/stringprintf_unittest.o
out/Release/obj.target/base_unittests/base/strings/string_number_conversions_unittest.o
out/Release/obj.target/base_unittests/base/strings/string_piece_unittest.o
out/Release/obj.target/base_unittests/base/strings/string_split_unittest.o
out/Release/obj.target/base_unittests/base/strings/string_tokenizer_unittest.o
out/Release/obj.target/base_unittests/base/strings/stringize_macros_unittest.o
out/Release/obj.target/base_unittests/base/strings/sys_string_conversions_unittest.o
out/Release/obj.target/base_unittests/base/strings/utf_offset_string_conversions_unittest.o
out/Release/obj.target/base_unittests/base/synchronization/cancellation_flag_unittest.o
out/Release/obj.target/base_unittests/base/synchronization/condition_variable_unittest.o
out/Release/obj.target/base_unittests/base/synchronization/lock_unittest.o
out/Release/obj.target/base_unittests/base/synchronization/waitable_event_unittest.o
out/Release/obj.target/base_unittests/base/synchronization/waitable_event_watcher_unittest.o
out/Release/obj.target/base_unittests/base/sys_info_unittest.o
out/Release/obj.target/base_unittests/base/system_monitor/system_monitor_unittest.o
out/Release/obj.target/base_unittests/base/task_runner_util_unittest.o
out/Release/obj.target/base_unittests/base/template_util_unittest.o
out/Release/obj.target/base_unittests/base/test/expectations/expectation_unittest.o
out/Release/obj.target/base_unittests/base/test/expectations/parser_unittest.o
out/Release/obj.target/base_unittests/base/test/trace_event_analyzer_unittest.o
out/Release/obj.target/base_unittests/base/threading/non_thread_safe_unittest.o
out/Release/obj.target/base_unittests/base/threading/platform_thread_unittest.o
out/Release/obj.target/base_unittests/base/threading/sequenced_worker_pool_unittest.o
out/Release/obj.target/base_unittests/base/threading/simple_thread_unittest.o
out/Release/obj.target/base_unittests/base/threading/thread_checker_unittest.o
out/Release/obj.target/base_unittests/base/threading/thread_collision_warner_unittest.o
out/Release/obj.target/base_unittests/base/threading/thread_id_name_manager_unittest.o
out/Release/obj.target/base_unittests/base/threading/thread_local_storage_unittest.o
out/Release/obj.target/base_unittests/base/threading/thread_local_unittest.o
out/Release/obj.target/base_unittests/base/threading/thread_unittest.o
out/Release/obj.target/base_unittests/base/threading/watchdog_unittest.o
out/Release/obj.target/base_unittests/base/threading/worker_pool_posix_unittest.o
out/Release/obj.target/base_unittests/base/threading/worker_pool_unittest.o
out/Release/obj.target/base_unittests/base/time_unittest.o
out/Release/obj.target/base_unittests/base/timer_unittest.o
out/Release/obj.target/base_unittests/base/tools_sanity_unittest.o
out/Release/obj.target/base_unittests/base/tracked_objects_unittest.o
out/Release/obj.target/base_unittests/base/tuple_unittest.o
out/Release/obj.target/base_unittests/base/utf_string_conversions_unittest.o
out/Release/obj.target/base_unittests/base/values_unittest.o
out/Release/obj.target/base_unittests/base/version_unittest.o
out/Release/obj.target/base_unittests/base/vlog_unittest.o
out/Release/obj.target/base_unittests/base/nix/xdg_util_unittest.o
out/Release/obj.target/base/libbase.a
out/Release/obj.target/base/libbase_i18n.a
out/Release/obj.target/base/libbase_prefs.a
out/Release/obj.target/base/libbase_prefs_test_support.a
out/Release/obj.target/base/libbase_static.a
out/Release/obj.target/base/librun_all_unittests.a
out/Release/obj.target/base/libtest_support_base.a
out/Release/obj.target/base/third_party/dynamic_annotations/libdynamic_annotations.a
out/Release/obj.target/testing/libgmock.a
out/Release/obj.target/testing/libgtest.a
out/Release/obj.target/third_party/icu/libicui18n.a
out/Release/obj.target/third_party/icu/libicuuc.a
out/Release/obj.target/base/allocator/liballocator.a
out/Release/obj.target/third_party/libevent/libevent.a
out/Release/obj.target/base/allocator/liballocator_extension_thunks.a
out/Release/obj.target/third_party/modp_b64/libmodp_b64.a
out/Release/obj.target/base/libsymbolize.a
out/Release/obj.target/base/libxdg_mime.a
out/Release/obj.target/third_party/icu/libicudata.a
out/Release/obj.target/net/third_party/nss/libcrssl.a
out/Release/obj.target/third_party/zlib/libchrome_zlib.a -Wl,--end-group -lrt
-ldl -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0
-lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lX11 -lXi
-lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 --save-temps
lto1: internal compiler error: bytecode stream: expected tag decltype_type
instead of error_mark
0x89a4e1 lto_tag_check
    ../../gcc/lto-streamer.h:934
0x89a4e1 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
    ../../gcc/tree-streamer-in.c:505
0x6c5aa5 lto_read_tree
    ../../gcc/lto-streamer-in.c:1012
0x6c5aa5 lto_input_tree(lto_input_block*, data_in*)
    ../../gcc/lto-streamer-in.c:1082
0x4f9799 lto_read_decls
    ../../gcc/lto/lto.c:2086
0x4f9799 lto_file_finalize
    ../../gcc/lto/lto.c:2339
0x4f9799 lto_create_files_from_ids
    ../../gcc/lto/lto.c:2349
0x4f9799 lto_file_read
    ../../gcc/lto/lto.c:2389
0x4f9799 read_cgraph_and_symbols
    ../../gcc/lto/lto.c:2964
0x4f9799 lto_main()
    ../../gcc/lto/lto.c:3375

Martin


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
@ 2013-05-08 12:32 ` marxin.liska at gmail dot com
  2013-06-03 14:50 ` [Bug c++/57208] Latest chromium compilation fails with enabled LTO marxin.liska at gmail dot com
                   ` (27 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-05-08 12:32 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #2 from Martin Liška <marxin.liska at gmail dot com> 2013-05-08 12:32:51 UTC ---
Created attachment 30055
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30055
common.gypi - build configuration
>From gcc-bugs-return-421843-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 08 12:32:56 2013
Return-Path: <gcc-bugs-return-421843-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2082 invoked by alias); 8 May 2013 12:32:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1860 invoked by uid 48); 8 May 2013 12:32:24 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57208] Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0]
Date: Wed, 08 May 2013 12:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57208-4-tBksEs4IAz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00516.txt.bz2
Content-length: 254


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #1 from Martin Liška <marxin.liska at gmail dot com> 2013-05-08 12:32:24 UTC ---
Created attachment 30054
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30054
Savetemps dump
>From gcc-bugs-return-421846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 08 12:42:51 2013
Return-Path: <gcc-bugs-return-421846-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8684 invoked by alias); 8 May 2013 12:42:51 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8642 invoked by uid 48); 8 May 2013 12:42:48 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug web/52239] Upgrade GCC Bugzilla to 4.4
Date: Wed, 08 May 2013 12:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: web
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: LpSolit at netscape dot net
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-52239-4-9GSG98i1vY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52239-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52239-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00519.txt.bz2
Content-length: 307


http://gcc.gnu.org/bugzilla/show_bug.cgi?idR239

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-05-08 12:42:47 UTC ---
Any chance we can take the occasion to restore the svn -> Bugzilla link, where
the former automatically sends the commit ChangeLogs to the audit trails?


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
  2013-05-08 12:32 ` [Bug c++/57208] " marxin.liska at gmail dot com
@ 2013-06-03 14:50 ` marxin.liska at gmail dot com
  2013-06-03 15:17 ` marxin.liska at gmail dot com
                   ` (26 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-03 14:50 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4792 bytes --]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #3 from Martin LiÅ¡ka <marxin.liska at gmail dot com> ---
I had a problem with linker, looks like chrome build system uses both linkers.
I hacked build system to use just ld.bfd.

gcc revision: 197652. I know it's about 2 months old, same error is given by
gcc from about 15th May 2013. Latest gcc suffers from a different failure that
will be added in following comment.

ld --version:
GNU ld (GNU Binutils) 2.23.52.20130526

Failure:
g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-O1
-Wl,--as-needed -flto -fno-fat-lto-objects -o mksnapshot.x64 -Wl,--start-group
obj/v8/src/mksnapshot.x64.mksnapshot.o obj/v8/tools/gyp/libv8_nosnapshot.x64.a
obj/v8/tools/gyp/libv8_base.x64.a  -Wl,--end-group -fdump-ipa-all --save-temps
lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:267
0x709296 inline_call(cgraph_edge*, bool, vec<cgraph_edge*, va_heap, vl_ptr>*,
int*, bool)
    ../../gcc/ipa-inline-transform.c:263
0x6fb118 inline_small_functions
    ../../gcc/ipa-inline.c:1613
0x6fb118 ipa_inline
    ../../gcc/ipa-inline.c:1794
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: g++ returned 1 exit status
[Leaving LTRANS mksnapshot.x64.ltrans.out]
[Leaving LTRANS /tmp/ccIviE1Z.args]
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

Dump:
https://docs.google.com/file/d/0B0pisUJ80pO1ck5sUmF5Q0k1Mmc/edit?usp=sharing

Thanks,
Martin
>From gcc-bugs-return-423734-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 03 15:00:46 2013
Return-Path: <gcc-bugs-return-423734-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21582 invoked by alias); 3 Jun 2013 15:00:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21543 invoked by uid 48); 3 Jun 2013 15:00:43 -0000
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
Date: Mon, 03 Jun 2013 15:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gjl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-57503-4-QXavV1scRG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57503-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57503-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00113.txt.bz2
Content-length: 1248

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW503

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Created attachment 30252
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0252&actioníit
.165r.expand: dump file with -Os -mmcu=atmega168 -fno-expensive-optimizations

The tree-ssa part for widening_mul can be disabled by
-fno-expensive-optimizations, but the code is still wrong.  Cf. the attached
.expand dump of

long
func1 (unsigned char a, unsigned char b, int c)
{
    unsigned ab = a * b;
    return (long) ab * c;
}

ab is computed in insn 10 with zero-extended inputs:

(insn 8 5 9 2 (set (reg:HI 53 [ D.1447 ])
        (zero_extend:HI (reg/v:QI 49 [ a ]))) cecky.c:4 -1
     (nil))
(insn 9 8 10 2 (set (reg:HI 54 [ D.1447 ])
        (zero_extend:HI (reg/v:QI 50 [ b ]))) cecky.c:4 -1
     (nil))
(insn 10 9 11 2 (set (reg:HI 55 [ D.1447 ])
        (mult:HI (reg:HI 53 [ D.1447 ])
            (reg:HI 54 [ D.1447 ]))) cecky.c:4 -1

This is correct, but then in insn 11 ab gets sign-extended even though it is
unsigned:

(insn 11 10 12 2 (set (reg:SI 56 [ D.1448 ])
        (sign_extend:SI (reg:HI 55 [ D.1447 ]))) cecky.c:5 -1
     (nil))

Insn combine combines this wrong extension into a widening multiplication.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
  2013-05-08 12:32 ` [Bug c++/57208] " marxin.liska at gmail dot com
  2013-06-03 14:50 ` [Bug c++/57208] Latest chromium compilation fails with enabled LTO marxin.liska at gmail dot com
@ 2013-06-03 15:17 ` marxin.liska at gmail dot com
  2013-06-05 12:12 ` izamyatin at gmail dot com
                   ` (25 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-03 15:17 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
gcc --version: HEAD (June 3rd, 2013)

Failure:
g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-O1
-Wl,--as-needed -flto -fno-fat-lto-objects -o protoc -Wl,--start-group
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.code_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.command_line_interface.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.plugin.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.plugin.pb.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.subprocess.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.zip_writer.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_enum.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_enum_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_extension.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_file.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_helpers.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_message.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_message_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_primitive_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_service.o
obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_string_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_enum.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_enum_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_extension.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_file.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_helpers.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_message.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_message_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_primitive_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_service.o
obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_string_field.o
obj/third_party/protobuf/src/google/protobuf/compiler/python/protoc.python_generator.o
obj/third_party/protobuf/src/google/protobuf/compiler/protoc.main.o
obj/third_party/protobuf/libprotobuf_full_do_not_use.a  -Wl,--end-group 
lto1: internal compiler error: in get_alias_symbol, at lto-cgraph.c:921
0x77d283 get_alias_symbol
    ../../gcc/lto-cgraph.c:921
0x77ff45 input_node
    ../../gcc/lto-cgraph.c:1012
0x77ff45 input_cgraph_1
    ../../gcc/lto-cgraph.c:1176
0x77ff45 input_symtab()
    ../../gcc/lto-cgraph.c:1449
0x507cda read_cgraph_and_symbols
    ../../gcc/lto/lto.c:2967
0x507cda lto_main()
    ../../gcc/lto/lto.c:3327
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: g++ returned 1 exit status
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

Dump:
https://docs.google.com/file/d/0B0pisUJ80pO1MWZRMU5MZ3BYWE0/edit?usp=sharing

Thank you,
Martin
>From gcc-bugs-return-423736-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 03 15:26:11 2013
Return-Path: <gcc-bugs-return-423736-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11012 invoked by alias); 3 Jun 2013 15:26:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10675 invoked by uid 48); 3 Jun 2013 15:26:06 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
Date: Mon, 03 Jun 2013 15:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc component
Message-ID: <bug-57484-4-H2cFZTLME5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57484-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57484-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00115.txt.bz2
Content-length: 545

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW484

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
          Component|c++                         |middle-end

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> ---
middle-end seems more appropriate. Richard, can you help me triaging this?
Thanks in advance.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (2 preceding siblings ...)
  2013-06-03 15:17 ` marxin.liska at gmail dot com
@ 2013-06-05 12:12 ` izamyatin at gmail dot com
  2013-06-05 16:26 ` marxin.liska at gmail dot com
                   ` (24 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: izamyatin at gmail dot com @ 2013-06-05 12:12 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

Igor Zamyatin <izamyatin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |izamyatin at gmail dot com

--- Comment #5 from Igor Zamyatin <izamyatin at gmail dot com> ---
Probably it is ok now due to
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00198.html


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (3 preceding siblings ...)
  2013-06-05 12:12 ` izamyatin at gmail dot com
@ 2013-06-05 16:26 ` marxin.liska at gmail dot com
  2013-06-17 21:46 ` marxin.liska at gmail dot com
                   ` (23 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-05 16:26 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #6 from Martin Liška <marxin.liska at gmail dot com> ---
I've just tested latest gcc and the same message is still received by compiler.
>From gcc-bugs-return-423855-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 05 16:45:12 2013
Return-Path: <gcc-bugs-return-423855-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25723 invoked by alias); 5 Jun 2013 16:45:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25629 invoked by uid 48); 5 Jun 2013 16:45:04 -0000
From: "alan.j.flavell at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/52119] [C++11] overflow in signed left shift isn't diagnosed
Date: Wed, 05 Jun 2013 16:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: accepts-invalid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: alan.j.flavell at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-52119-4-v4BrHRfcfh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52119-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52119-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00234.txt.bz2
Content-length: 1151

http://gcc.gnu.org/bugzilla/show_bug.cgi?idR119

ajf <alan.j.flavell at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.j.flavell at gmail dot com

--- Comment #10 from ajf <alan.j.flavell at gmail dot com> ---
(In reply to Jeffrey Yasskin from comment #0)
> numeric_limits<T>::min() is defined as (__glibcxx_signed (T) ? (T)1 <<
> __glibcxx_digits (T) : (T)0). Unfortunately, shifting into the sign bit is
> undefined behavior (C++11[expr.shift]p2), and undefined behavior makes an
> expression non-constant.

MY apologies if I am missing something obvious, but what exactly makes shifting
a 1 into the sign bit undefined behavior? Seems rather defined to me, assuming
it's actually being using as a integral numerical data-type (in this case,
32-bit int, long), which would result in a signed numerical value.In other
words, the sign bit, like any other bit, can only be 0 or 1, so I honestly do
not understand how undefined behavior enters the equation, or what impact it
may have.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (4 preceding siblings ...)
  2013-06-05 16:26 ` marxin.liska at gmail dot com
@ 2013-06-17 21:46 ` marxin.liska at gmail dot com
  2013-06-19 17:03 ` hubicka at gcc dot gnu.org
                   ` (22 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-17 21:46 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #7 from Martin Liška <marxin.liska at gmail dot com> ---
I've updated to latest gcc, all previous bugs are irrelevant: I mixed different
-Ox cflags and chromium build system is full of hacks (they use gold as a
primary linker, but bfd is used for some stuff, I used just bfd in my
compilation).

gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)

I finally reached WPA stage of LTO, memory usage was about 8GB for ld and 11 GB
for lto1.

lto1 was running for about 20 minutes and following error occured:

lto1: error: ELF section name out of range
lto1: internal compiler error: Segmentation fault
0x85e0bf crash_signal
    ../../gcc/toplev.c:333
0xd7f0dd htab_delete
    ../../libiberty/hashtab.c:419
0x50a41c lto_file_read
    ../../gcc/lto/lto.c:2824
0x50a41c read_cgraph_and_symbols
    ../../gcc/lto/lto.c:3401
0x50a41c lto_main()
    ../../gcc/lto/lto.c:3834
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: g++ returned 1 exit status
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Do you have any ideas?
>From gcc-bugs-return-424556-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 17 22:07:40 2013
Return-Path: <gcc-bugs-return-424556-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8534 invoked by alias); 17 Jun 2013 22:07:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8460 invoked by uid 48); 17 Jun 2013 22:07:33 -0000
From: "furue at hawaii dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57628] spurious error: division by zero in if statement
Date: Mon, 17 Jun 2013 22:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: furue at hawaii dot edu
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57628-4-fkwy2ujkbe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57628-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57628-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00935.txt.bz2
Content-length: 672

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW628

--- Comment #16 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Steve Kargl from comment #12)
> On Sun, Jun 16, 2013 at 11:33:49PM +0000, furue at hawaii dot edu wrote:
> >
> > Is this an inconsistency in the implementation of -no-range-check ?
>
> No.

Then, what's the counterpart of -fno-range-check that takes care of such cases
as sqrt?  To repeat the code:

  real, parameter:: a = -1.0
  if (a > 0) write(*,*) sqrt(a)

With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN and
let the code pass.

Or is it better to extend -fno-range-check to cover these cases, too?

Cheers,
Ryo


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (5 preceding siblings ...)
  2013-06-17 21:46 ` marxin.liska at gmail dot com
@ 2013-06-19 17:03 ` hubicka at gcc dot gnu.org
  2013-06-19 17:51 ` ian at airs dot com
                   ` (21 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-06-19 17:03 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-19
                 CC|                            |hubicka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
This seems to be ELF or libelf limitation. The .o produced is corrupt
apparently because we produce too many function sections.  The second largest
ltrans unit is over 20000, so perhaps elf is limited to 32000 sections?


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (6 preceding siblings ...)
  2013-06-19 17:03 ` hubicka at gcc dot gnu.org
@ 2013-06-19 17:51 ` ian at airs dot com
  2013-06-19 18:04 ` ian at airs dot com
                   ` (20 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: ian at airs dot com @ 2013-06-19 17:51 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
It looks like simple_object_elf_write_ehdr in libiberty/simple-object-elf.c
does not correctly handle the case of writing an ELF object with more than
65,280 sections.  That may be the problem here.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (7 preceding siblings ...)
  2013-06-19 17:51 ` ian at airs dot com
@ 2013-06-19 18:04 ` ian at airs dot com
  2013-06-19 18:24 ` hubicka at gcc dot gnu.org
                   ` (19 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: ian at airs dot com @ 2013-06-19 18:04 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #10 from Ian Lance Taylor <ian at airs dot com> ---
Created attachment 30323
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30323&action=edit
Possible patch

Can you see if this patch fixes the problem?


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (8 preceding siblings ...)
  2013-06-19 18:04 ` ian at airs dot com
@ 2013-06-19 18:24 ` hubicka at gcc dot gnu.org
  2013-06-19 18:27 ` jakub at gcc dot gnu.org
                   ` (18 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-06-19 18:24 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, self contained way to reproduce the bug:
evans:/tmp/:[1]# cat t.c
#include <stdio.h>
main()
{
  int i;
  printf ("int main(){}\n");
  for (i=0;i<70000;i++)
    printf ("__attribute__ ((used, externally_visible)) int
ttiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii%i(){}\n",
i);
}
evans:/tmp/:[1]# gcc t.c
evans:/tmp/:[1]# ./a.out >tt.c
evans:/tmp/:[1]# /abuild/jh/trunk-install/bin/gcc -O2 -flto tt.c --param
lto-partitions=1

takes a while.  I am testing the patch.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (9 preceding siblings ...)
  2013-06-19 18:24 ` hubicka at gcc dot gnu.org
@ 2013-06-19 18:27 ` jakub at gcc dot gnu.org
  2013-06-19 23:14 ` hubicka at gcc dot gnu.org
                   ` (17 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-06-19 18:27 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just use preprocessor rather than proglet to generate the testcase ;).


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (10 preceding siblings ...)
  2013-06-19 18:27 ` jakub at gcc dot gnu.org
@ 2013-06-19 23:14 ` hubicka at gcc dot gnu.org
  2013-06-20  6:26 ` jakub at gcc dot gnu.org
                   ` (16 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-06-19 23:14 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
progret needs a fraction of brain capacity than the preprocessor generator and
I doubt it would be faster :)))
anyway I seem to be still getting error with the patch

evans:/tmp/:[0]# /abuild/jh/trunk-install/bin/gcc -O2 -flto tt.c --param
lto-partitions=1
lto1: error: ELF section name out of range
(null):0: confused by earlier errors, bailing out
lto-wrapper: /abuild/jh/trunk-install/bin/gcc returned 1 exit status
/abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (11 preceding siblings ...)
  2013-06-19 23:14 ` hubicka at gcc dot gnu.org
@ 2013-06-20  6:26 ` jakub at gcc dot gnu.org
  2013-06-20 20:31 ` marxin.liska at gmail dot com
                   ` (15 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-06-20  6:26 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
int main() {}
#define A(n) __attribute__ ((used, externally_visible)) int \
ttiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii \
## iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii \
## iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii##n() {}
#define B(n)
A(n##0)A(n##1)A(n##2)A(n##3)A(n##4)A(n##5)A(n##6)A(n##7)A(n##8)A(n##9)
#define C(n)
B(n##0)B(n##1)B(n##2)B(n##3)B(n##4)B(n##5)B(n##6)B(n##7)B(n##8)B(n##9)
#define D(n)
C(n##0)C(n##1)C(n##2)C(n##3)C(n##4)C(n##5)C(n##6)C(n##7)C(n##8)C(n##9)
#define E(n)
D(n##0)D(n##1)D(n##2)D(n##3)D(n##4)D(n##5)D(n##6)D(n##7)D(n##8)D(n##9)
E(0)E(1)E(2)E(3)E(4)E(5)E(6)

(well, if you don't mind 00001 as opposed to 1 etc.).


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (12 preceding siblings ...)
  2013-06-20  6:26 ` jakub at gcc dot gnu.org
@ 2013-06-20 20:31 ` marxin.liska at gmail dot com
  2013-06-21 12:55 ` hubicka at gcc dot gnu.org
                   ` (14 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-20 20:31 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 26070 bytes --]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #15 from Martin LiÅ¡ka <marxin.liska at gmail dot com> ---
I did a small workaround for ELF overflow: --param lto-partitions=64.

Following errors were met:
`_ZN10disk_cache15SimpleEntryImpl17WriteDataInternalEiiPN3net8IOBufferEiRKN4base8CallbackIFviEEEb'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of obj/net/disk_cache/simple/net.simple_entry_impl.o (symbol
from plugin)
`_ZN10disk_cache15SimpleEntryImpl25CreationOperationCompleteERKN4base8CallbackIFviEEERKNS1_9TimeTicksE10scoped_ptrIPNS_22SimpleSynchronousEntryENS1_14DefaultDeleterISC_EEESA_IiNSD_IiEEEPPNS_5EntryE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of obj/net/disk_cache/simple/net.simple_entry_impl.o (symbol
from plugin)
`_ZN7content20ShaderDiskCacheEntry12OnOpCompleteEi' referenced in section
`.text' of chrome.ltrans16.ltrans.o: defined in discarded section `.text' of
obj/content/browser/gpu/content_browser.shader_disk_cache.o (symbol from
plugin)
`_ZN7content19TraceControllerImpl29OnTraceBufferPercentFullReplyEf' referenced
in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded section
`.text' of obj/content/browser/tracing/content_browser.trace_controller_impl.o
(symbol from plugin)
`_ZN7content19TraceControllerImpl15OnEndTracingAckERKSt6vectorISsSaISsEE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/content/browser/tracing/content_browser.trace_controller_impl.o (symbol
from plugin)
`_ZN3net15ViewCacheHelper12OnIOCompleteEi' referenced in section `.text' of
chrome.ltrans16.ltrans.o: defined in discarded section `.text' of
obj/net/url_request/net.view_cache_helper.o (symbol from plugin)
`_ZN15quota_internals19QuotaInternalsProxy17DidGetGlobalUsageEN5quota11StorageTypeEll'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/chrome/browser/ui/webui/quota_internals/browser_ui.quota_internals_proxy.o
(symbol from plugin)
`_ZN8appcache22AppCacheResponseWriter21OnCreateEntryCompleteEPPNS_26AppCacheDiskCacheInterface5EntryEi'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/webkit/support/../appcache/webkit_storage.appcache_response.o (symbol from
plugin)
`_ZN5media18AlsaPcmInputStream9ReadAudioEv' referenced in section `.text' of
chrome.ltrans16.ltrans.o: defined in discarded section `.text' of
obj/media/audio/linux/media.alsa_input.o (symbol from plugin)
`_ZN16sync_file_system20DriveFileSyncService34DidGetDirectoryContentForBatchSyncERKN4base8CallbackIFvNS_14SyncStatusCodeEEEERK4GURLRKSslN11google_apis14GDataErrorCodeE10scoped_ptrINSD_12ResourceListENS1_14DefaultDeleterISG_EEE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/chrome/browser/sync_file_system/browser.drive_file_sync_service.o (symbol
from plugin)
`_ZN16sync_file_system5drive28LocalChangeProcessorDelegate19DidApplyLocalChangeERKN4base8CallbackIFvNS_14SyncStatusCodeEEEEN11google_apis14GDataErrorCodeES4_'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/chrome/browser/sync_file_system/drive/browser.local_change_processor_delegate.o
(symbol from plugin)
`_ZN8remoting22RectangleUpdateDecoder12OnPacketDoneEbN4base4TimeERKNS1_8CallbackIFvvEEE'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section `.text' of
obj/remoting/client/remoting_client.rectangle_update_decoder.o (symbol from
plugin)
`_ZN17AgentHostDelegate11OnBytesReadE13scoped_refptrIN3net8IOBufferEEi'
referenced in section `.text' of chrome.ltrans16.ltrans.o: defined in discarded
section
`.gnu.linkonce.t._ZN17AgentHostDelegate11OnBytesReadE13scoped_refptrIN3net8IOBufferEEi'
of obj/chrome/browser/devtools/debugger.devtools_adb_bridge.o (symbol from
plugin)
`_ZN8remoting8protocol16ConnectionToHost20OnChannelInitializedEb' referenced in
section `.text' of chrome.ltrans16.ltrans.o: defined in discarded section
`.text' of obj/remoting/protocol/remoting_protocol.connection_to_host.o (symbol
from plugin)
chrome.ltrans16.ltrans.o: In function
`base::Callback<base::internal::BindState<base::internal::FunctorTraits<void
(net::(anonymous namespace)::DnsTCPAttempt::*)(int)>::RunnableType,
base::internal::FunctorTraits<void (net::(anonymous
namespace)::DnsTCPAttempt::*)(int)>::RunType, void
(base::internal::CallbackParamTraits<base::internal::UnretainedWrapper<net::(anonymous
namespace)::DnsTCPAttempt> >::StorageType)>::UnboundRunType> base::Bind<void
(net::(anonymous namespace)::DnsTCPAttempt::*)(int),
base::internal::UnretainedWrapper<net::(anonymous namespace)::DnsTCPAttempt>
>(void (net::(anonymous namespace)::DnsTCPAttempt::*)(int),
base::internal::UnretainedWrapper<net::(anonymous namespace)::DnsTCPAttempt>
const&) [clone .constprop.12480]':
chrome.ltrans16.o:(.text+0x635f8): undefined reference to `net::(anonymous
namespace)::DnsTCPAttempt::OnIOComplete(int)'
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
chrome.ltrans16.ltrans.o: relocation R_X86_64_PC32 against undefined symbol
`_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi' can not be used when
making a shared object; recompile with -fPIC
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: final
link failed: Bad value
collect2: error: ld returned 1 exit status

I focused firstly for the last undefined symbol:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi

chrome.wpa.000i.cgraph:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete)
@0x7f80e10be980
  Type: function definition analyzed
  Visibility: force_output prevailing_def_ironly
  Address is taken.
  References: 
  Referring: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12DoSendLengthEi/8859587
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt11DoSendQueryEi/8859588
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt12DoReadLengthEi/8859589
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt14DoReadResponseEi/8859590
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE/8859580
(addr)
  Read from file: obj/net/dns/net.dns_transaction.o
  Availability: available
  Function flags:
  Called by: 
  Calls: _ZN3net12_GLOBAL__N_113DnsTCPAttempt6DoLoopEi/8859585 (1.00 per call) 
  Has 1 outgoing edges for indirect calls.

marxin@marxinbox /ssd/chromium-2/src/out/Release $ grep
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi *.s
chrome.ltrans16.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rax
chrome.ltrans29.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:    .type   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, @function
chrome.ltrans29.s:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi:
chrome.ltrans29.s:    .size   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi,
.-_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi

grep -- _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi -lm.res 
[nothing found]
>From gcc-bugs-return-424743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 20 20:37:44 2013
Return-Path: <gcc-bugs-return-424743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13879 invoked by alias); 20 Jun 2013 20:37:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13834 invoked by uid 48); 20 Jun 2013 20:37:41 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57208] Latest chromium compilation fails with enabled LTO
Date: Thu, 20 Jun 2013 20:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57208-4-Bkut6kLcNH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01122.txt.bz2
Content-length: 11024

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #16 from Martin LiÅ¡ka <marxin.liska at gmail dot com> ---
Looks like ld.gold has a problem with large amount of files:

FAILED: flock linker.lock g++ -Wl,-z,now -Wl,-z,relro -pthread
-Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param
lto-partitions=64 -o chrome -Wl,--start-group
obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_main.o
obj/chrome/app/chrome.chrome_main_delegate.o obj/chrome/libinstaller_util.a
obj/media/libmedia_sse.a obj/third_party/icu/libicuuc.a
obj/third_party/libjingle/libjingle.a obj/skia/libskia_opts.a
obj/third_party/icu/libicudata.a obj/device/libdevice_media_transfer_protocol.a
obj/native_client/src/trusted/service_runtime/arch/x86/libservice_runtime_x86_common.a
obj/chrome/libservice.a obj/chrome/librenderer.a obj/webkit/support/libglue.a
obj/content/libcontent_worker.a obj/third_party/libwebp/libwebp_utils.a
obj/third_party/zlib/libminizip.a
obj/chrome/browser/performance_monitor/libperformance_monitor.a
obj/third_party/leveldatabase/libleveldatabase.a
obj/native_client/src/trusted/service_runtime/libenv_cleanser.a
obj/sandbox/libc_urandom_override.a obj/chrome/libbrowser.a
obj/ppapi/libppapi_host.a obj/sync/libsync_core.a obj/gpu/libgles2_cmd_helper.a
obj/third_party/smhasher/libcityhash.a
obj/third_party/libphonenumber/libphonenumber.a
obj/chrome/app/policy/libpolicy.a obj/webkit/support/libplugins_common.a
obj/native_client/src/trusted/validator_x86/libnccopy_x86_64.a
obj/webkit/support/libglue_common.a
obj/webkit/renderer/compositor_bindings/libwebkit_compositor_support.a
obj/third_party/smhasher/libmurmurhash3.a obj/content/libcontent_gpu.a
obj/native_client/src/trusted/threading/libthread_interface.a
obj/media/libmedia_mmx.a obj/ipc/libipc.a obj/third_party/libxslt/libxslt.a
obj/remoting/libremoting_client.a obj/third_party/ots/libots.a
obj/base/libsymbolize.a obj/native_client/src/trusted/validator/libvalidators.a
obj/chrome/libbrowser_extensions.a obj/skia/libskia_opts_ssse3.a
obj/third_party/protobuf/libprotobuf_lite.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform.a
obj/ui/surface/libsurface.a
obj/third_party/WebKit/Source/WebKit/chromium/libwebkit.a
obj/native_client/src/trusted/validator/x86/64/libncvalidate_x86_64.a
obj/third_party/jsoncpp/libjsoncpp.a obj/google_apis/libgoogle_apis.a
obj/chrome/libnacl.a
obj/third_party/libphonenumber/libphonenumber_without_metadata.a
obj/chrome/libdebugger.a obj/v8/tools/gyp/libv8_snapshot.a
obj/ui/native_theme/libnative_theme.a obj/third_party/libusb/libusb.a
obj/content/libcontent_common_child.a
obj/native_client/src/trusted/nacl_base/libnacl_base.a
obj/base/libbase_static.a obj/native_client/src/shared/imc/libimc.a
obj/chrome/libfeedback_proto.a
obj/components/libbrowser_context_keyed_service.a obj/components/libweb_modal.a
obj/chrome/libapps.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform_geometry.a
obj/components/libuser_prefs.a obj/content/libcontent_utility.a
obj/third_party/libevent/libevent.a obj/sandbox/libseccomp_bpf.a
obj/build/linux/libpci.a obj/ui/gl/libgl_wrapper.a
obj/third_party/mt19937ar/libmt19937ar.a
obj/third_party/angle/src/libtranslator_common.a
obj/ui/message_center/libmessage_center.a obj/third_party/libpng/libpng.a
obj/components/libwebdata_common.a obj/third_party/opus/libopus.a
obj/sync/libsync_notifier.a obj/ui/snapshot/libsnapshot.a
obj/native_client/src/trusted/validator/x86/libncval_base_x86_64.a
obj/webkit/support/libwebkit_media.a obj/third_party/libwebp/libwebp_dsp.a
obj/third_party/harfbuzz-ng/libharfbuzz-ng.a
obj/chrome/app/policy/libcloud_policy_proto_generated_compile.a
obj/base/allocator/liballocator_extension_thunks.a
obj/remoting/libremoting_jingle_glue.a
obj/native_client/src/trusted/service_runtime/libnacl_error_code.a
obj/third_party/snappy/libsnappy.a obj/cc/libcc.a
obj/third_party/libjingle/libjingle_p2p_constants.a
obj/third_party/cld/libcld.a obj/third_party/libxml/libxml2.a
obj/webkit/support/libplugins.a obj/chrome/libvariations_seed_proto.a
obj/remoting/proto/libchromotocol_proto_lib.a
obj/native_client/src/trusted/simple_service/libsimple_service.a
obj/chrome/libsync_file_system_proto.a obj/gpu/libdisk_cache_proto.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_html.a
obj/native_client/src/trusted/interval_multiset/libnacl_interval.a
obj/build/linux/libspeechd.a obj/sync/libsync_internal_api.a
obj/third_party/hunspell/libhunspell.a obj/chrome/libplugin.a
obj/ui/compositor/libcompositor.a obj/base/libbase_prefs.a
obj/ui/web_dialogs/libweb_dialogs.a
obj/native_client/src/trusted/desc/libdesc_wrapper.a
obj/third_party/angle/src/libpreprocessor.a obj/gpu/libgpu_ipc.a
obj/device/libdevice_usb.a obj/sandbox/libsuid_sandbox_client.a
obj/tools/json_schema_compiler/libapi_gen_util.a
obj/third_party/cacheinvalidation/libcacheinvalidation.a
obj/webkit/support/libwebkit_base.a obj/remoting/libremoting_base.a
obj/gpu/libcommand_buffer_client.a obj/gpu/libcommand_buffer_common.a
obj/native_client/src/trusted/service_runtime/arch/x86_64/libservice_runtime_x86_64.a
obj/third_party/libwebp/libwebp_enc.a
obj/native_client/src/trusted/validator_ragel/libdfa_validate_x86_64.a
obj/native_client/src/trusted/desc/libnrd_xfer.a
obj/chrome/libcert_logger_proto.a obj/ppapi/libppapi_ipc.a obj/sdch/libsdch.a
obj/third_party/angle/src/libtranslator_glsl.a obj/ppapi/libppapi_shared.a
obj/gpu/libgles2_implementation.a obj/third_party/libXNVCtrl/libXNVCtrl.a
obj/content/browser/speech/proto/libspeech_proto.a
obj/build/temp_gyp/libgoogleurl.a obj/webkit/support/libuser_agent.a
obj/net/libnet.a obj/media/libmedia_asm.a obj/base/libxdg_mime.a
obj/chrome/libcloud_policy_proto.a obj/content/libcontent_browser.a
obj/native_client/src/trusted/validator/libvalidation_cache.a
obj/chrome/libbrowser_ui.a obj/chrome/libcommon_constants.a
obj/base/third_party/dynamic_annotations/libdynamic_annotations.a
obj/third_party/sfntly/libsfntly.a obj/ppapi/libppapi_cpp_objects.a
obj/third_party/zlib/libzip.a obj/crypto/libcrcrypto.a
obj/webkit/renderer/compositor_bindings/libwebkit_compositor_bindings.a
obj/media/libshared_memory_support.a obj/third_party/undoview/libundoview.a
obj/native_client/src/shared/gio/libgio.a obj/third_party/qcms/libqcms.a
obj/chrome/browser/search_engines/libprepopulated_engines.a
obj/components/libvisitedlink_renderer.a obj/ui/libshell_dialogs.a
obj/sandbox/libsandbox_services.a obj/third_party/libwebp/libwebp_demux.a
obj/third_party/sqlite/libsqlite3.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_svg.a
obj/native_client/src/trusted/cpu_features/libcpu_features.a
obj/chrome/libutility.a obj/chrome/libbrowser_ui_views.a
obj/device/libdevice_bluetooth.a obj/components/libauto_login_parser.a
obj/third_party/libjpeg_turbo/libjpeg_turbo.a
obj/third_party/modp_b64/libmodp_b64.a
obj/third_party/cacheinvalidation/libcacheinvalidation_proto_cpp.a
obj/webkit/support/libwebkit_storage.a
obj/chrome/libin_memory_url_index_cache_proto.a
obj/v8/tools/gyp/libv8_base.x64.a
obj/native_client/src/trusted/validator/x86/ncval_reg_sfi/libncval_reg_sfi_x86_64.a
obj/sync/libsync_api.a obj/native_client/src/shared/srpc/libnonnacl_srpc.a
obj/build/linux/libgio.a obj/third_party/flac/libflac.a
obj/third_party/speex/libspeex.a obj/media/libmedia_sse2.a
obj/third_party/re2/libre2.a obj/net/third_party/nss/libcrssl.a
obj/jingle/libjingle_glue.a obj/components/libautofill_browser.a
obj/native_client/src/shared/platform/libplatform.a libyuv.a
obj/chrome/common/extensions/api/libapi.a obj/content/libcontent_common.a
obj/base/libbase_i18n.a obj/components/libsessions.a obj/base/libbase.a
obj/ppapi/libppapi_proxy.a obj/webkit/support/libwebkit_common.a
obj/webkit/support/libglue_renderer.a obj/jingle/libnotifier.a
obj/third_party/libwebp/libwebp_dec.a obj/components/libautofill_renderer.a
obj/third_party/WebKit/Source/wtf/libwtf.a obj/sync/libsync_proto.a
obj/remoting/libremoting_protocol.a obj/gpu/libgles2_c_lib.a
obj/chrome/libcommon_net.a obj/gpu/libgpu_config.a
obj/native_client/src/trusted/fault_injection/libnacl_fault_inject.a
obj/net/libhttp_server.a obj/chrome/libcommon.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_rendering.a
obj/dbus/libdbus.a obj/remoting/libremoting_client_plugin.a
obj/content/libcontent_app.a
obj/native_client/src/trusted/perf_counter/libnacl_perf_counter.a
obj/printing/libprinting.a obj/content/libcontent_renderer.a
obj/breakpad/libbreakpad_client.a obj/device/libmtp_file_entry_proto.a
obj/native_client/src/trusted/debug_stub/libdebug_stub.a
obj/third_party/hyphen/libhyphen.a obj/third_party/iccjpeg/libiccjpeg.a
obj/third_party/icu/libicui18n.a
obj/third_party/webrtc/modules/libdesktop_capture.a
obj/native_client/src/trusted/validator/x86/decoder/libnc_opcode_modeling_x86_64.a
obj/media/libshared_memory_support_sse.a
obj/components/libvisitedlink_browser.a obj/content/libcontent_plugin.a
obj/third_party/v8-i18n/build/libv8-i18n.a obj/skia/libskia.a
obj/webkit/common/gpu/libwebkit_gpu.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_derived.a
obj/chrome/libsafe_browsing_proto.a obj/net/libnet_with_v8.a obj/sql/libsql.a
obj/components/libautofill_common.a obj/content/libcontent_ppapi_plugin.a
obj/third_party/webrtc/system_wrappers/source/libsystem_wrappers.a
obj/native_client/src/trusted/validator/x86/decoder/libnc_decoder_x86_64.a
obj/native_client/src/trusted/platform_qualify/libplatform_qual_lib.a
obj/gpu/command_buffer/libgles2_utils.a
obj/native_client/src/trusted/gio/libgio_wrapped_desc.a obj/ui/libui.a
obj/components/libencryptor.a
obj/native_client/src/trusted/manifest_name_service_proxy/libmanifest_proxy.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_dom.a
obj/device/libmtp_storage_info_proto.a
obj/chrome/libsafe_browsing_report_proto.a
obj/components/libautofill_risk_proto.a obj/third_party/ffmpeg/libffmpeg.a
obj/components/libnavigation_interception.a obj/gpu/libcommand_buffer_service.a
obj/chrome/libmetrics_proto.a
obj/third_party/WebKit/Source/weborigin/libweborigin.a
obj/third_party/WebKit/Source/modules/libmodules.a obj/media/libmedia.a
obj/third_party/zlib/libchrome_zlib.a
obj/third_party/WebKit/Source/core/core.gyp/libwebcore_remaining.a
obj/native_client/src/trusted/service_runtime/libsel.a
obj/components/libtracing.a obj/components/libvisitedlink_common.a 
-Wl,--end-group -lX11 -lXcursor -lXrandr -lXrender -lXss -lXext -lrt -ldl
-lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0
-lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lXi -lsmime3
-lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf-2 -lresolv -lXcomposite
-lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt -lgpg-error -lz -lpthread
-lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: fatal
error: out of file descriptors and couldn't close any
>From gcc-bugs-return-424744-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 20 20:44:17 2013
Return-Path: <gcc-bugs-return-424744-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20113 invoked by alias); 20 Jun 2013 20:44:17 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20060 invoked by uid 48); 20 Jun 2013 20:44:13 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57208] Latest chromium compilation fails with enabled LTO
Date: Thu, 20 Jun 2013 20:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57208-4-dDLh9XsfL5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01123.txt.bz2
Content-length: 237

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #17 from Martin LiÅ¡ka <marxin.liska at gmail dot com> ---
I created a bug for gold linker in binutils bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=15660
>From gcc-bugs-return-424745-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 20 21:03:08 2013
Return-Path: <gcc-bugs-return-424745-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6158 invoked by alias); 20 Jun 2013 21:03:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6140 invoked by uid 48); 20 Jun 2013 21:03:04 -0000
From: "zsojka at seznam dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/57664] New: [4.8/4.9 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
Date: Thu, 20 Jun 2013 21:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zsojka at seznam dot cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-57664-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01124.txt.bz2
Content-length: 1873

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW664

            Bug ID: 57664
           Summary: [4.8/4.9 Regression] ICE: in
                    should_move_die_to_comdat, at dwarf2out.c:6750 with
                    -fdebug-types-section and lambda
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz

Created attachment 30329
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0329&actioníit
reduced testcase

Compiler output:
$ gcc -std=c++11 -g -fipa-pure-const -fdebug-types-section
-fno-eliminate-unused-debug-types testcase.C
testcase.C:5:1: internal compiler error: in should_move_die_to_comdat, at
dwarf2out.c:6750
 }
 ^
0x8da6fc should_move_die_to_comdat
        /mnt/svn/gcc-trunk/gcc/dwarf2out.c:6750
0x8da6fc break_out_comdat_types
        /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7152
0x8ffc78 dwarf2out_finish
        /mnt/svn/gcc-trunk/gcc/dwarf2out.c:23764
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-200224-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-200224-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20130619 (experimental) (GCC)

Tested revisions:
r200224 - ICE
4.8 r198018 - ICE
4.7 r200234 - OK


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (13 preceding siblings ...)
  2013-06-20 20:31 ` marxin.liska at gmail dot com
@ 2013-06-21 12:55 ` hubicka at gcc dot gnu.org
  2013-06-21 13:01 ` hubicka at gcc dot gnu.org
                   ` (13 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-06-21 12:55 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
What about trying ulimit -m to increase the number of FDs?  (it requires root)


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (14 preceding siblings ...)
  2013-06-21 12:55 ` hubicka at gcc dot gnu.org
@ 2013-06-21 13:01 ` hubicka at gcc dot gnu.org
  2013-06-21 13:07 ` marxin.liska at gmail dot com
                   ` (12 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-06-21 13:01 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
chrome.wpa.000i.cgraph:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete)
@0x7f80e10be980
  Type: function definition analyzed
  Visibility: force_output prevailing_def_ironly
  Address is taken.
  References: 
  Referring: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12DoSendLengthEi/8859587
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt11DoSendQueryEi/8859588
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt12DoReadLengthEi/8859589
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt14DoReadResponseEi/8859590
(addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE/8859580
(addr)
  Read from file: obj/net/dns/net.dns_transaction.o
  Availability: available
  Function flags:
  Called by: 
  Calls: _ZN3net12_GLOBAL__N_113DnsTCPAttempt6DoLoopEi/8859585 (1.00 per call) 
  Has 1 outgoing edges for indirect calls.

marxin@marxinbox /ssd/chromium-2/src/out/Release $ grep
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi *.s
chrome.ltrans16.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rax
chrome.ltrans29.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:    .type   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, @function
chrome.ltrans29.s:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi:
chrome.ltrans29.s:    .size   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi,
.-_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi


This actually looks like partitioning problem. I misread the dump ysterday - it
is a local function and it seems that somehow we manage to get referenc eto it
from ltrans16 while it is static to ltrans29.  Can I see .cgraph dump of
ltrans16? If you have -fdump-tree-all dumps (or you can just rebuild ltrans16
with this dump) it should be possible to grep the dumps to work out if the
symbol appears as a result of some constant folding.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (15 preceding siblings ...)
  2013-06-21 13:01 ` hubicka at gcc dot gnu.org
@ 2013-06-21 13:07 ` marxin.liska at gmail dot com
  2013-06-22 21:19 ` marxin.liska at gmail dot com
                   ` (11 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-21 13:07 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #20 from Martin Liška <marxin.liska at gmail dot com> ---
Link to ltrans16.cgraph dump:
https://docs.google.com/file/d/0B0pisUJ80pO1c0JTTmR5Z1pQb28/edit?usp=sharing
>From gcc-bugs-return-424787-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 21 13:10:59 2013
Return-Path: <gcc-bugs-return-424787-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9579 invoked by alias); 21 Jun 2013 13:10:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9478 invoked by uid 48); 21 Jun 2013 13:10:49 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
Date: Fri, 21 Jun 2013 13:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57038-4-EiSXNwKLRX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57038-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57038-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01166.txt.bz2
Content-length: 20653

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038

--- Comment #28 from Martin Liška <marxin.liska at gmail dot com> ---
Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received
is marked with '>', address: 0x2aaab390c19d 

+
B+ ¦0x2aaab390c180 <_ZN10ScDocument7CalcAllEv>      push   %r15                
                                                                               
                                                                            ¦
   ¦0x2aaab390c182 <_ZN10ScDocument7CalcAllEv+2>    push   %r14                
                                                                               
                                                                            ¦
   ¦0x2aaab390c184 <_ZN10ScDocument7CalcAllEv+4>    push   %r13                
                                                                               
                                                                            ¦
   ¦0x2aaab390c186 <_ZN10ScDocument7CalcAllEv+6>    push   %r12                
                                                                               
                                                                            ¦
   ¦0x2aaab390c188 <_ZN10ScDocument7CalcAllEv+8>    push   %rbp                
                                                                               
                                                                            ¦
   ¦0x2aaab390c189 <_ZN10ScDocument7CalcAllEv+9>    mov    %rdi,%rbp           
                                                                               
                                                                            ¦
   ¦0x2aaab390c18c <_ZN10ScDocument7CalcAllEv+12>   lea    0x21bc66(%rip),%rdi 
      # 0x2aaab3b27df9                                                         
                                                                            ¦
   ¦0x2aaab390c193 <_ZN10ScDocument7CalcAllEv+19>   push   %rbx                
                                                                               
                                                                            ¦
   ¦0x2aaab390c194 <_ZN10ScDocument7CalcAllEv+20>   sub    $0x18,%rsp          
                                                                               
                                                                            ¦
   ¦0x2aaab390c198 <_ZN10ScDocument7CalcAllEv+24>   callq  0x2aaab33c8af0
<puts@plt>                                                                     
                                                                               
  ¦
  >¦0x2aaab390c19d <_ZN10ScDocument7CalcAllEv+29>   mov    0x1c8(%rbp),%rbx    
                                                                               
                                                                            ¦
   ¦0x2aaab390c1a4 <_ZN10ScDocument7CalcAllEv+36>   test   %rbx,%rbx           
                                                                               
                                                                            ¦
   ¦0x2aaab390c1a7 <_ZN10ScDocument7CalcAllEv+39>   je     0x2aaab390c29d
<_ZN10ScDocument7CalcAllEv+285>                                                
                                                                               
  ¦
   ¦0x2aaab390c1ad <_ZN10ScDocument7CalcAllEv+45>   mov    (%rbx),%r12         
                                                                               
                                                                            ¦
   ¦0x2aaab390c1b0 <_ZN10ScDocument7CalcAllEv+48>   mov    0x8(%rbx),%rax      
                                                                               
                                                                            ¦
   ¦0x2aaab390c1b4 <_ZN10ScDocument7CalcAllEv+52>   test   %r12,%r12           
                                                                               
                                                                            ¦
   ¦0x2aaab390c1b7 <_ZN10ScDocument7CalcAllEv+55>   je     0x2aaab390c1f5
<_ZN10ScDocument7CalcAllEv+117>                                                
                                                                               
  ¦
   ¦0x2aaab390c1b9 <_ZN10ScDocument7CalcAllEv+57>   mov    (%r12,%rax,8),%r13  
                                                                               
                                                                            ¦
   ¦0x2aaab390c1bd <_ZN10ScDocument7CalcAllEv+61>   test   %r13,%r13           
                                                                               
                                                                            ¦
   ¦0x2aaab390c1c0 <_ZN10ScDocument7CalcAllEv+64>   je     0x2aaab390c1f5
<_ZN10ScDocument7CalcAllEv+117>                                                
                                                                               
  ¦
   ¦0x2aaab390c1c2 <_ZN10ScDocument7CalcAllEv+66>   sub    $0x18,%r13          
                                                                               
                                                                            ¦
   ¦0x2aaab390c1c6 <_ZN10ScDocument7CalcAllEv+70>   jne    0x2aaab390c1d6
<_ZN10ScDocument7CalcAllEv+86>                                                 
                                                                               
  ¦
   ¦0x2aaab390c1c8 <_ZN10ScDocument7CalcAllEv+72>   jmp    0x2aaab390c1f5
<_ZN10ScDocument7CalcAllEv+117>                                                
                                                                               
  ¦
   ¦0x2aaab390c1ca <_ZN10ScDocument7CalcAllEv+74>   nopw   0x0(%rax,%rax,1)    
                                                                               
                                                                            ¦
   ¦0x2aaab390c1d0 <_ZN10ScDocument7CalcAllEv+80>   sub    $0x18,%r13          
                                                                               
                                                                            ¦
   ¦0x2aaab390c1d4 <_ZN10ScDocument7CalcAllEv+84>   je     0x2aaab390c1ee
<_ZN10ScDocument7CalcAllEv+110>                                                
                                                                               
  ¦
   ¦0x2aaab390c1d6 <_ZN10ScDocument7CalcAllEv+86>   mov    0x10(%r13),%rdi     
                                                                               
                                                                            ¦
   ¦0x2aaab390c1da <_ZN10ScDocument7CalcAllEv+90>   test   %rdi,%rdi           
                                                                               
                                                                            ¦
   ¦0x2aaab390c1dd <_ZN10ScDocument7CalcAllEv+93>   je     0x2aaab390c1e5
<_ZN10ScDocument7CalcAllEv+101>                                                
                                                                               
  ¦
   ¦0x2aaab390c1df <_ZN10ScDocument7CalcAllEv+95>   mov    (%rdi),%rax         
                                                                               
                                                                            ¦
   ¦0x2aaab390c1e2 <_ZN10ScDocument7CalcAllEv+98>   callq  *0x18(%rax)         
                                                                               
                                                                            ¦
   ¦0x2aaab390c1e5 <_ZN10ScDocument7CalcAllEv+101>  mov    0x18(%r13),%r13     
                                                                               
                                                                            ¦
   ¦0x2aaab390c1e9 <_ZN10ScDocument7CalcAllEv+105>  test   %r13,%r13           
                                                                               
                                                                            ¦
   ¦0x2aaab390c1ec <_ZN10ScDocument7CalcAllEv+108>  jne    0x2aaab390c1d0
<_ZN10ScDocument7CalcAllEv+80>                                                 
                                                                               
  ¦
   ¦0x2aaab390c1ee <_ZN10ScDocument7CalcAllEv+110>  mov    (%rbx),%r12         
                                                                               
                                                                            ¦
   ¦0x2aaab390c1f1 <_ZN10ScDocument7CalcAllEv+113>  mov    0x8(%rbx),%rax      
                                                                               
                                                                            ¦
   ¦0x2aaab390c1f5 <_ZN10ScDocument7CalcAllEv+117>  lea    0x238ea4(%rip),%rcx 
      # 0x2aaab3b450a0
<_ZN5boost9unordered6detail19prime_list_templateImE5valueE.lto_priv.2744>      
                                                     ¦
   ¦0x2aaab390c1fc <_ZN10ScDocument7CalcAllEv+124>  mov    $0x28,%esi          
                                                                               
                                                                            ¦
   ¦0x2aaab390c201 <_ZN10ScDocument7CalcAllEv+129>  jmp    0x2aaab390c206
<_ZN10ScDocument7CalcAllEv+134>                                                
                                                                               
  ¦
   ¦0x2aaab390c203 <_ZN10ScDocument7CalcAllEv+131>  mov    %rdx,%rsi           
                                                                               
                                                                            ¦
   ¦0x2aaab390c206 <_ZN10ScDocument7CalcAllEv+134>  mov    %rsi,%rdx           
                                                                               
                                                                            ¦
CalcAll
called------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
multi-thre Thread 0x2aaaa In: ScDocument::CalcAll                              
                                                                               
                                               Line: ??   PC: 0x2aaab390c19d
(gdb) nexti
0x00002aaab390c182 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c184 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c186 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c188 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c189 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c18c in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c193 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c194 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c198 in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
0x00002aaab390c19d in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so

Program received signal SIGSEGV, Segmentation fault.
0x00002aaab390c19d in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
(gdb)
>From gcc-bugs-return-424788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 21 13:27:13 2013
Return-Path: <gcc-bugs-return-424788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23340 invoked by alias); 21 Jun 2013 13:27:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22968 invoked by uid 48); 21 Jun 2013 13:27:08 -0000
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
Date: Fri, 21 Jun 2013 13:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: gjl at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57631-4-wukD7glEt5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57631-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57631-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01167.txt.bz2
Content-length: 1769

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW631

--- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to pebbles from comment #4)
> (In reply to Georg-Johann Lay from comment #3)
>> Would you explain what you are trying to achieve?
>
> For one thing, I'm coding in C++, so the handlers may be mangled to the
> wrong symbols unless I tell the compiler what to name them.  The warning is
> misleading at least in this case.

The ISR macro is defined by AVR-LibC. It adds extern "C" to ISR if compiled for
C++.  Thus, the handlers are not mangled and names like __vector_<num> are used
even if compiled for C++.

Moreover, you should not use __vector_<num> firectly, use the support macros
from avr/io.h and avr/interrupt.h.  They work for C++.  If not, please file a
bug report against AVR-LibC.

> In C++ it's conventional to place symbols inside namespaces or classes over
> prefixing them with underscores.  I'm writing a library and would like users
> to be able to define the handlers with names and scopes that match the style
> conventions of the project.

Don't use __vector_<num> directly; use defines from AVR-LibC like INT0_vect
etc.  Cf. the AVR-LibC documentation.

>> You can name the function __vectorFOO or __vector_my_ISR_function or
>> whatever without raising a warning.
>
> But that requires reading the source of GCC, which I have begun doing but is
> usually not a prerequisite for coding.  The warning should tell me that
> straight out.

You should read the documentation of AVR-LibC, of course.  You can add
documentation parts to the GCC documentation if you find it helpful.  However,
users typically read the AVR-LibC manual because ISR and the vector names are
supplyied by AVR-LibC's av/io.h and avr/interrupt.h.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (16 preceding siblings ...)
  2013-06-21 13:07 ` marxin.liska at gmail dot com
@ 2013-06-22 21:19 ` marxin.liska at gmail dot com
  2013-06-22 21:43 ` hubicka at gcc dot gnu.org
                   ` (10 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-22 21:19 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #21 from Martin Liška <marxin.liska at gmail dot com> ---
Ltrans grep


marxin@marxinbox /ssd/chrome-dumps $ grep
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi chrome.ltrans*
Binary file chrome.ltrans16.o matches
chrome.ltrans16.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rax
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  Called by:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (1.00 per call)
_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE.lto_priv.62289/8859580
(0.62 per call) 
chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591
(OnIOComplete) @0x7ff6f304a5f0
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:  Called by:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (1.00 per call)
_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE.lto_priv.62289/8859580
(0.62 per call) 
chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591
(OnIOComplete) @0x7ff6f304a5f0
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591
(OnIOComplete) @0x7ff6f304a5f0
chrome.ltrans29.000i.cgraph:  References:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr)
chrome.ltrans29.045i.cp:;; Function OnIOComplete
(_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, funcdef_no=1376,
decl_uid=894468, symbol_order=8859591)
chrome.ltrans29.047i.inline:;; Function OnIOComplete
(_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, funcdef_no=1376,
decl_uid=894468, symbol_order=8859591)
Binary file chrome.ltrans29.o matches
chrome.ltrans29.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:    leaq   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi
chrome.ltrans29.s:    .type   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, @function
chrome.ltrans29.s:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi:
chrome.ltrans29.s:    .size   
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi,
.-_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi
>From gcc-bugs-return-424864-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 22 21:23:13 2013
Return-Path: <gcc-bugs-return-424864-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5508 invoked by alias); 22 Jun 2013 21:23:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5430 invoked by uid 48); 22 Jun 2013 21:23:04 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57208] Latest chromium compilation fails with enabled LTO
Date: Sat, 22 Jun 2013 21:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-57208-4-x13tYyEH1K@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57208-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01243.txt.bz2
Content-length: 245

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #22 from Martin Liška <marxin.liska at gmail dot com> ---
Created attachment 30340
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30340&action=edit
chrome.ltrans16.s
>From gcc-bugs-return-424865-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 22 21:32:38 2013
Return-Path: <gcc-bugs-return-424865-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9166 invoked by alias); 22 Jun 2013 21:32:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9145 invoked by uid 48); 22 Jun 2013 21:32:35 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57679] c++11: ICE on template type alias to enum
Date: Sat, 22 Jun 2013 21:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_known_to_work resolution
Message-ID: <bug-57679-4-daS9yCgbdA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57679-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57679-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01244.txt.bz2
Content-length: 514

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW679

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to work|                            |4.8.0, 4.9.0
         Resolution|---                         |FIXED

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
This is fixed in 4.8.0.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (17 preceding siblings ...)
  2013-06-22 21:19 ` marxin.liska at gmail dot com
@ 2013-06-22 21:43 ` hubicka at gcc dot gnu.org
  2013-06-22 22:05 ` hubicka at ucw dot cz
                   ` (9 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-06-22 21:43 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #23 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
It seems late optimizers translate

cloning Bind to
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_EEEENS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunTypeEFvNS6_19CallbackParamTraitsIT0_E11StorageTypeEEE14UnboundRunTypeEEESC_RKSH_.constprop.12480
Bind (struct 
{       
  void DnsTCPAttempt::<T2bc0a> (struct DnsTCPAttempt *, int) * __pfn;
  long int __delta;
} functor, const struct UnretainedWrapper & p1)
{       
  void DnsTCPAttempt::<T2bc0a> (struct DnsTCPAttempt *, int) * method$__pfn;
  long int method$__delta;

  <bb 2>:
  method$__pfn_10 = MEM[(const struct  &)&functor];
  method$__delta_11 = MEM[(const struct  &)&functor + 8];
  _5 = operator new (40);
  _12 = &MEM[(struct RefCountedThreadSafe *)_5 + 8B].D.4332;
  __base_ctor  (_12);
  MEM[(struct BindStateBase *)_5]._vptr.BindStateBase = &MEM[(void
*)&_ZTVN4base8internal13BindStateBaseE + 16B];
  MEM[(struct BindState *)_5].D.961227._vptr.BindStateBase = &MEM[(void
*)&_ZTVN4base8internal9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS5_iEFvNS0_17UnretainedWrapperIS5_EEEEE
+ 16B];
  MEM[(struct BindState *)_5 + 16B] = method$__pfn_10;
  MEM[(struct BindState *)_5 + 24B] = method$__delta_11;
  MEM[(struct BindState *)_5].p1_ = *p1_6(D);
  _13 = &_8(D)->D.42504;
  __base_ctor  (_13, _5);
  _8(D)->D.42504.polymorphic_invoke_ = Run;
  return _8(D);

}

into 
        .globl 
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_EEEENS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunType
        .hidden
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_EEEENS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunType
        .type  
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_EEEENS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunType
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_EEEENS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunTypeEFvNS6_19Callbac
.LFB10639:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rcx, %rbp
        pushq   %rbx
        .cfi_def_cfa_offset 24
        .cfi_offset 3, -24
        movq    %rdi, %rbx
        movl    $40, %edi
        subq    $8, %rsp
        .cfi_def_cfa_offset 32
        call    _Znwm@PLT
        movl    $0, 8(%rax)
        movq    %rax, %rsi
        leaq   
16+_ZTVN4base8internal9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS5_iEFvNS0_17UnretainedWrapperIS5_EEEEE.lto_priv.73096(%rip),
%rax
        movq    $0, 24(%rsi)
        movq    %rbx, %rdi
        movq    %rax, (%rsi)
        leaq    _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip),
%rax
        movq    %rax, 16(%rsi)
        movq    0(%rbp), %rax
        movq    %rax, 32(%rsi)
        call    _ZN4base8internal12CallbackBaseC2EPNS0_13BindStateBaseE
        leaq   
_ZN4base8internal7InvokerILi1ENS0_9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS6_iEFvNS0_17UnretainedWrapperIS6_EEEEESB_E3RunEPNS0_13Bind
       movq    %rax, 8(%rbx)
        addq    $8, %rsp
        .cfi_def_cfa_offset 24 
        movq    %rbx, %rax
        popq    %rbx
        .cfi_def_cfa_offset 16
        popq    %rbp
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
.LFE10639:

So someone folds
  MEM[(struct BindStateBase *)_5]._vptr.BindStateBase = &MEM[(void
*)&_ZTVN4base8internal13BindStateBaseE + 16B];
  MEM[(struct BindState *)_5].D.961227._vptr.BindStateBase = &MEM[(void
*)&_ZTVN4base8internal9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS5_iEFvNS0_17UnretainedWrapperIS5_EEEEE
+ 16B];
  MEM[(struct BindState *)_5 + 16B] = method$__pfn_10;
  MEM[(struct BindState *)_5 + 24B] = method$__delta_11;
  MEM[(struct BindState *)_5].p1_ = *p1_6(D);

into reference to the symbol that is in other ltrans and not seen by
partitioning...


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (18 preceding siblings ...)
  2013-06-22 21:43 ` hubicka at gcc dot gnu.org
@ 2013-06-22 22:05 ` hubicka at ucw dot cz
  2013-06-23 12:20 ` hubicka at ucw dot cz
                   ` (8 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at ucw dot cz @ 2013-06-22 22:05 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #24 from Jan Hubicka <hubicka at ucw dot cz> ---
does this patch help?


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (19 preceding siblings ...)
  2013-06-22 22:05 ` hubicka at ucw dot cz
@ 2013-06-23 12:20 ` hubicka at ucw dot cz
  2013-06-24 10:24 ` jamborm at gcc dot gnu.org
                   ` (7 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: hubicka at ucw dot cz @ 2013-06-23 12:20 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #25 from Jan Hubicka <hubicka at ucw dot cz> ---
Updated patch.
Honza


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (20 preceding siblings ...)
  2013-06-23 12:20 ` hubicka at ucw dot cz
@ 2013-06-24 10:24 ` jamborm at gcc dot gnu.org
  2013-06-24 16:10 ` jamborm at gcc dot gnu.org
                   ` (6 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: jamborm at gcc dot gnu.org @ 2013-06-24 10:24 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #26 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #25)
> Created attachment 30346 [details]
> conti
> 

This patch creates references where the referring node is the old one,
not the newly created clone.  I think that create_specialized_node
should traverse aggvals and create the references.  Hopefully I can
prepare a patch doing that in the course of this afternoon (but of
course feel free to make one yourself if you are faster).


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (21 preceding siblings ...)
  2013-06-24 10:24 ` jamborm at gcc dot gnu.org
@ 2013-06-24 16:10 ` jamborm at gcc dot gnu.org
  2013-06-24 22:25 ` marxin.liska at gmail dot com
                   ` (5 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: jamborm at gcc dot gnu.org @ 2013-06-24 16:10 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #27 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Created attachment 30355
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30355&action=edit
Proposed patch

I'd suggest this (yet untested) patch.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (22 preceding siblings ...)
  2013-06-24 16:10 ` jamborm at gcc dot gnu.org
@ 2013-06-24 22:25 ` marxin.liska at gmail dot com
  2013-06-25 11:02 ` jamborm at gcc dot gnu.org
                   ` (4 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-06-24 22:25 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #28 from Martin Liška <marxin.liska at gmail dot com> ---
Patch solved the problem for chromium ;) I will test libreoffice tomorrow.

(In reply to Martin Jambor from comment #27)
> Created attachment 30355 [details]
> Proposed patch
> 
> I'd suggest this (yet untested) patch.
>From gcc-bugs-return-425038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 24 22:39:33 2013
Return-Path: <gcc-bugs-return-425038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20823 invoked by alias); 24 Jun 2013 22:39:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20794 invoked by uid 48); 24 Jun 2013 22:39:29 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/57704] std::char_traits<char>::lt is not standards-compliant
Date: Mon, 24 Jun 2013 22:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.7.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-57704-4-XpfXJViLyN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57704-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57704-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01417.txt.bz2
Content-length: 706

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW704

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-24
     Ever confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
This is LWG 467, thus it applies to C++98 too. Since, moreover, at the moment
there are no internal uses in the library of char_traits<char>::lt, I think the
straightforward tweak can be implemented unconditionally and safely.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (23 preceding siblings ...)
  2013-06-24 22:25 ` marxin.liska at gmail dot com
@ 2013-06-25 11:02 ` jamborm at gcc dot gnu.org
  2013-07-02 16:42 ` jamborm at gcc dot gnu.org
                   ` (3 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: jamborm at gcc dot gnu.org @ 2013-06-25 11:02 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2649 bytes --]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #29 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Martin LiÅ¡ka from comment #28)
> Patch solved the problem for chromium ;) I will test libreoffice tomorrow.

Great, I have submitted the patch to the mailing list then:

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01422.html
>From gcc-bugs-return-425081-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 11:06:10 2013
Return-Path: <gcc-bugs-return-425081-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8898 invoked by alias); 25 Jun 2013 11:06:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8870 invoked by uid 48); 25 Jun 2013 11:06:08 -0000
From: "allan at archlinux dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57653] filename information discarded when using -imacros
Date: Tue, 25 Jun 2013 11:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: allan at archlinux dot org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-57653-4-ppa8GHgSSy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57653-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57653-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01460.txt.bz2
Content-length: 491

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW653

--- Comment #17 from Allan McRae <allan at archlinux dot org> ---
Created attachment 30359
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0359&actioníit
gdb log when using -include

When using -include instead of -imacros, the trail is:

LC_ENTER   foo.c
LC_RENAME  <command-line>
LC_ENTER   /usr/include/stdc-predef.h
LC_LEAVE   0x0
LC_ENTER   foo.h
LC_LEAVE   0x0
LC_RENAME  foo.c
LC_LEAVE   0x0

gdb log with -include attached.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (24 preceding siblings ...)
  2013-06-25 11:02 ` jamborm at gcc dot gnu.org
@ 2013-07-02 16:42 ` jamborm at gcc dot gnu.org
  2013-07-02 16:43 ` jamborm at gcc dot gnu.org
                   ` (2 subsequent siblings)
  28 siblings, 0 replies; 30+ messages in thread
From: jamborm at gcc dot gnu.org @ 2013-07-02 16:42 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #30 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Author: jamborm
Date: Thu Jun 27 13:49:28 2013
New Revision: 200468

URL: http://gcc.gnu.org/viewcvs?rev=200468&root=gcc&view=rev
Log:
2013-06-27  Martin Jambor  <mjambor@suse.cz>

    PR lto/57208
    * ipa-ref.h (ipa_maybe_record_reference): Declare.
    * ipa-ref.c (ipa_maybe_record_reference): New function.
    * cgraphclones.c (cgraph_create_virtual_clone): Use it.
    * ipa-cp.c (create_specialized_node): Record potential references from
    aggvals.
    * Makefile.in (ipa-ref.o): Add IPA_REF_H to dependencies.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/cgraphclones.c
    trunk/gcc/ipa-cp.c
    trunk/gcc/ipa-ref.c
    trunk/gcc/ipa-ref.h


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (25 preceding siblings ...)
  2013-07-02 16:42 ` jamborm at gcc dot gnu.org
@ 2013-07-02 16:43 ` jamborm at gcc dot gnu.org
  2013-07-17 14:14 ` marxin.liska at gmail dot com
  2022-01-01 22:58 ` pinskia at gcc dot gnu.org
  28 siblings, 0 replies; 30+ messages in thread
From: jamborm at gcc dot gnu.org @ 2013-07-02 16:43 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #31 from Martin Jambor <jamborm at gcc dot gnu.org> ---
All right.  I hope the PR can be closed now.  Please re-open if the bug is
istill present.


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (26 preceding siblings ...)
  2013-07-02 16:43 ` jamborm at gcc dot gnu.org
@ 2013-07-17 14:14 ` marxin.liska at gmail dot com
  2022-01-01 22:58 ` pinskia at gcc dot gnu.org
  28 siblings, 0 replies; 30+ messages in thread
From: marxin.liska at gmail dot com @ 2013-07-17 14:14 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208

--- Comment #32 from Martin Liška <marxin.liska at gmail dot com> ---
Sorry for late answer, proposed patch works for me.

Thanks,
Martin

(In reply to Ian Lance Taylor from comment #10)
> Created attachment 30323 [details]
> Possible patch
> 
> Can you see if this patch fixes the problem?
>From gcc-bugs-return-426327-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 17 15:24:10 2013
Return-Path: <gcc-bugs-return-426327-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14297 invoked by alias); 17 Jul 2013 15:24:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11389 invoked by uid 48); 17 Jul 2013 15:22:07 -0000
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
Date: Wed, 17 Jul 2013 15:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gjl at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57909-4-lDtNyfYlsJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57909-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57909-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00834.txt.bz2
Content-length: 178

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW909

--- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
You can write r201005 and bugzilla will link it for you :-)


^ permalink raw reply	[flat|nested] 30+ messages in thread

* [Bug c++/57208] Latest chromium compilation fails with enabled LTO
  2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
                   ` (27 preceding siblings ...)
  2013-07-17 14:14 ` marxin.liska at gmail dot com
@ 2022-01-01 22:58 ` pinskia at gcc dot gnu.org
  28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-01 22:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
Bug 57208 depends on bug 57703, which changed state.

Bug 57703 Summary: Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2022-01-01 22:58 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-08 12:30 [Bug c++/57208] New: Latest chromium compilation fails with enabled LTO [4.8.1/4.9.0] marxin.liska at gmail dot com
2013-05-08 12:32 ` [Bug c++/57208] " marxin.liska at gmail dot com
2013-06-03 14:50 ` [Bug c++/57208] Latest chromium compilation fails with enabled LTO marxin.liska at gmail dot com
2013-06-03 15:17 ` marxin.liska at gmail dot com
2013-06-05 12:12 ` izamyatin at gmail dot com
2013-06-05 16:26 ` marxin.liska at gmail dot com
2013-06-17 21:46 ` marxin.liska at gmail dot com
2013-06-19 17:03 ` hubicka at gcc dot gnu.org
2013-06-19 17:51 ` ian at airs dot com
2013-06-19 18:04 ` ian at airs dot com
2013-06-19 18:24 ` hubicka at gcc dot gnu.org
2013-06-19 18:27 ` jakub at gcc dot gnu.org
2013-06-19 23:14 ` hubicka at gcc dot gnu.org
2013-06-20  6:26 ` jakub at gcc dot gnu.org
2013-06-20 20:31 ` marxin.liska at gmail dot com
2013-06-21 12:55 ` hubicka at gcc dot gnu.org
2013-06-21 13:01 ` hubicka at gcc dot gnu.org
2013-06-21 13:07 ` marxin.liska at gmail dot com
2013-06-22 21:19 ` marxin.liska at gmail dot com
2013-06-22 21:43 ` hubicka at gcc dot gnu.org
2013-06-22 22:05 ` hubicka at ucw dot cz
2013-06-23 12:20 ` hubicka at ucw dot cz
2013-06-24 10:24 ` jamborm at gcc dot gnu.org
2013-06-24 16:10 ` jamborm at gcc dot gnu.org
2013-06-24 22:25 ` marxin.liska at gmail dot com
2013-06-25 11:02 ` jamborm at gcc dot gnu.org
2013-07-02 16:42 ` jamborm at gcc dot gnu.org
2013-07-02 16:43 ` jamborm at gcc dot gnu.org
2013-07-17 14:14 ` marxin.liska at gmail dot com
2022-01-01 22:58 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).