New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 829795 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Mac , Fuchsia
Pri: 3
Type: Bug



Sign in to add a comment

Decide if we want to keep -fmerge-all-constants

Project Member Reported by thakis@chromium.org, Apr 6 2018

Issue description

Started here: https://ci.chromium.org/buildbot/chromium.clang/ToTLinux%20%28dbg%29/2517

FAILED: gpu_unittests 
python "../../build/toolchain/gcc_link_wrapper.py" --output="./gpu_unittests" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread -Wl,--as-needed -fuse-ld=lld -Wl,--icf=all -m64 -Werror -Wl,--gdb-index -Wl,--fatal-warnings -nostdlib++ --sysroot=../../build/linux/debian_sid_amd64-sysroot -L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-rpath=\$ORIGIN/. -Wl,-rpath-link=. -Wl,--export-dynamic -o "./gpu_unittests" -Wl,--start-group @"./gpu_unittests.rsp" ./libgles2.so ./libgpu.so ./libbase.so ./libcc_paint.so ./libviz_resource_format.so ./libgles2_c_lib.so ./libgles2_implementation.so ./libgles2_utils.so ./libgl_in_process_context.so ./libgpu_ipc_service.so ./libmojo_edk.so ./libbindings.so ./libskia.so ./libgfx.so ./libgeometry.so ./libgl_wrapper.so ./liburl.so ./libmojo_public_system_cpp.so ./libmojo_public_system.so ./libcolor_space.so ./libgeometry_skia.so ./libgfx_switches.so ./libicui18n.so ./libicuuc.so ./libanimation.so ./libcodec.so ./librange.so ./libcrash_key.so ./libipc.so ./libmessage_support.so ./libipc_mojom.so ./libipc_mojom_shared.so ./libbindings_base.so ./libmojo_mojom_bindings.so ./libmojo_mojom_bindings_shared.so ./libprotobuf_lite.so ./libgfx_ipc.so ./libgfx_ipc_geometry.so ./liburl_ipc.so ./libui_base.so ./libui_data_pack.so ./libevents_base.so ./libplatform.so ./libkeycodes_x11.so ./libui_base_x.so ./libdisplay.so ./libdisplay_types.so ./libgl_init.so ./libbase_i18n.so ./libfontconfig.so ./libx11_window.so ./libcc_base.so ./libcc_debug.so ./libraster.so ./libgpu_util.so ./libmojo_base_mojom_shared.so ./libmojo_base_mojom.so ./libmojo_base_lib.so ./libmojo_base_shared_typemap_traits.so ./libgfx_ipc_color.so ./libnet.so ./libcrcrypto.so ./libboringssl.so ./libmojo_edk_ports.so ./libnet_with_v8.so ./libfreetype_harfbuzz.so ./libc++.so -Wl,--end-group   -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lnss3 -lnssutil3 -lsmime3 -lplds4 -lplc4 -lnspr4 -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst 
/b/c/b/ToTLinux__dbg_/src/out/Debug/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: undefined symbol: gpu::gles2::ClientServiceMap<unsigned long, unsigned long>::kMaxFlatArraySize
>>> referenced by client_service_map_unittest.cc:159 (../../gpu/command_buffer/service/client_service_map_unittest.cc:159)
>>>               obj/gpu/gpu_unittests/client_service_map_unittest.o:(gpu::gles2::ClientServiceMap_ForEach_Test::TestBody())
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)


The pinned bots are happy and there's no client_service code change, so probably an lld regression.

First bad: 329319
Last good: 329291

`svn log -r329292:329319 https://nico@llvm.org/svn/llvm-project`

Hm, that does include "r329300; Disable -fmerge-all-constants as default." which might be related. The rest looks pretty harmless. Since we want to add that flag explicitly anyhow, we should probably just try adding it on the tot bots and see if it helps.



(cc ruiu for this tangent: I find lld error output hard to read somehow. One, why does it print the name of itself in front of errors? Two, if it must do that (clang doesn't; and the build system usually prints what step failed), maybe just the basename is enough. With that:

error: undefined symbol: gpu::gles2::ClientServiceMap<unsigned long, unsigned long>::kMaxFlatArraySize
>>> referenced by client_service_map_unittest.cc:159 (../../gpu/command_buffer/service/client_service_map_unittest.cc:159)
>>>               obj/gpu/gpu_unittests/client_service_map_unittest.o:(gpu::gles2::ClientServiceMap_ForEach_Test::TestBody())

Then, why print ">>>" instead of just whitespace?

error: undefined symbol: gpu::gles2::ClientServiceMap<unsigned long, unsigned long>::kMaxFlatArraySize
    referenced by client_service_map_unittest.cc:159 (../../gpu/command_buffer/service/client_service_map_unittest.cc:159)
                  obj/gpu/gpu_unittests/client_service_map_unittest.o:(gpu::gles2::ClientServiceMap_ForEach_Test::TestBody())

Also, it might be nice to not print "error: hi.obj: undefined symbol:" for each undefined symbol, but instead do:

error: undefined symbols:
  gpu::gles2::ClientServiceMap<unsigned long, unsigned long>::kMaxFlatArraySize, referenced by
      client_service_map_unittest.cc:159 (../../gpu/command_buffer/service/client_service_map_unittest.cc:159)
      obj/gpu/gpu_unittests/client_service_map_unittest.o:(gpu::gles2::ClientServiceMap_ForEach_Test::TestBody())
  next undefined symbol if there's more than one


I'd find each of these steps a big improvement in lld output readability. Also, it looks like lld-link doesn't print the "referenced by" bit (?). Probably should file different bugs for this...)
 
https://cs.chromium.org/search/?q=kMaxFlatArraySize&sq=package:chromium&type=cs

kMaxFlatArraySize is declared like so:

https://cs.chromium.org/chromium/src/gpu/command_buffer/service/client_service_map.h?type=cs&q=kMaxFlatArraySize&sq=package:chromium&l=148

  static constexpr size_t kMaxFlatArraySize = 0x4000;

But its storage is never defined. So the linker is technically correct to complain about this, but since nothing takes the address of kMaxFlatArraySize one would hope that all references to kMaxFlatArraySize would get optimized away even in debug builds :-/

The best real fix would be to use an unnamed enum to declare this constant instead.
Project Member

Comment 2 by bugdroid1@chromium.org, Apr 6 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/850cd2070b28008d08112054d3a08c470749c6eb

commit 850cd2070b28008d08112054d3a08c470749c6eb
Author: Nico Weber <thakis@chromium.org>
Date: Fri Apr 06 17:35:33 2018

Explicitly pass -fmerge-all-constants to clang.

Speculative change to try and get the debug bots to link again.

Bug: 829795
Change-Id: I987675ee5c0163f2dc1e725910f9be14ca92aa1e
Reviewed-on: https://chromium-review.googlesource.com/999323
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548842}
[modify] https://crrev.com/850cd2070b28008d08112054d3a08c470749c6eb/build/config/compiler/BUILD.gn

Blocking: 828582
Cc: mark@chromium.org
Labels: OS-Android OS-Fuchsia OS-Linux
Bot is green again: https://ci.chromium.org/buildbot/chromium.clang/ToTLinux%20%28dbg%29/2529

Let's retitle this bug and keep it open for what to do with -fmerge-all-constants.

The flag makes clang do an optimization that's strictly speaking not standards-compliant, but it hasn't caused issues in practice in the last 7 years. clang now no longer turns this flag on by default. It's kind of the opposite of -fno-strict-aliasing that we use which is a standards-conforming optimization but one that we violate so often that I don't dare enable that optimization. We now turn it on explicitly (in part to work around a build error; see above). My guess is we want to keep it on.

Should probably first measure how much binary size it saves.


+mento who wrote https://bugs.llvm.org/show_bug.cgi?id=18538#c13
Summary: Decide if we want to keep -fmerge-all-constants (was: ToTLinux (dbg) fails to link)
Let's actually retitle.
Blocking: -828582
…and since the bot is now happy, let's remove the blocker.
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 30 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3e568aae1d572c4b373f40e0826de7ea0a39d3c0

commit 3e568aae1d572c4b373f40e0826de7ea0a39d3c0
Author: Hans Wennborg <hans@chromium.org>
Date: Mon Apr 30 21:24:46 2018

Build with -fmerge-all-constants also on Windows

After Clang r329300 we need to request this explicitly. Make sure to do
so also on Windows.

Bug:  835506 , 829795
Change-Id: I4b47e897ac202eb796d8c5b31808dfae2aeb5b22
Reviewed-on: https://chromium-review.googlesource.com/1035265
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554881}
[modify] https://crrev.com/3e568aae1d572c4b373f40e0826de7ea0a39d3c0/build/config/compiler/BUILD.gn

(filed bug 861743 for the parenthetical in comment 0)
On Linux, with Chromium #578992

$ gn gen out/release --args='is_chrome_branded=true is_debug=false is_official_build=true use_goma=true symbol_level=0'
$ ninja -C out/release -j1000 chrome

Vanilla build:

$ ls -l out/release/chrome
-rwxr-x--- 1 hwennborg primarygroup 208247232 Jul 30 10:41 out/release/chrome

Without -fmerge-all-constants:

$ ls -l out/release/chrome
-rwxr-x--- 1 hwennborg primarygroup 208129904 Jul 30 10:37 out/release/chrome


It seems that -fmerge-all-constants is actually making the binary 115 KB larger!

Sign in to add a comment