All of lore.kernel.org
 help / color / mirror / Atom feed
* Build regressions/improvements in v4.9-rc1
@ 2016-10-17  7:21 Geert Uytterhoeven
  2016-10-17  7:34   ` Geert Uytterhoeven
  0 siblings, 1 reply; 35+ messages in thread
From: Geert Uytterhoeven @ 2016-10-17  7:21 UTC (permalink / raw)
  To: linux-kernel

Below is the list of build error/warning regressions/improvements in
v4.9-rc1[1] compared to v4.8[2].

Summarized:
  - build errors: +48/-3
  - build warnings: +1576/-1194

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.9-rc1.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/11053/ (all 262 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/10989/ (all 262 configs)


*** ERRORS ***

48 error regressions:
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r4]':  => 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r5]':  => 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r6]':  => 475, 476
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r8]':  => 476, 475, 515
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r11]':  => 476
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r13]':  => 493, 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r14]':  => 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r18]':  => 493
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r21]':  => 493
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r6]':  => 476, 475, 515
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r7]':  => 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r12]':  => 493
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r3]':  => 475
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r8]':  => 493
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r9]':  => 493
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r0,[r6]':  => 516
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r10,[r12]':  => 496
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r14,[r9]':  => 496
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r16,[r8]':  => 496
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r0]':  => 479
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r13]':  => 496, 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r18]':  => 496
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r21]':  => 496
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r4]':  => 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r5]':  => 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r6]':  => 478, 516, 479
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r8]':  => 479, 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r11]':  => 479
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r13]':  => 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r14]':  => 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r6]':  => 479, 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r7]':  => 478
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
  + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
  + /home/kisskb/slave/src/arch/powerpc/kvm/book3s_hv_rm_xics.c: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]:  => 758:2
  + /home/kisskb/slave/src/drivers/dma/omap-dma.c: error: unrecognizable insn::  => 350:1
  + /home/kisskb/slave/tmp/ccQySjGw.s: Error: pcrel too far BFD_RELOC_BFIN_10:  => 912
  + error: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A
  + error: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.list_del' defined in .text section in lib/built-in.o:  => (.text+0x1ff8458)
  + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.rcu_read_lock_sched_held' defined in .text section in kernel/built-in.o:  => (.text+0x1ff8084), (.text+0x1ff81bc)
  + error: usb.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.__raw_spin_lock_init' defined in .text section in kernel/built-in.o:  => (.text+0x1ff989c), (.text+0x1ff9264), (.text+0x1ff9808)
  + error: usb.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.flush_workqueue' defined in .text section in kernel/built-in.o:  => (.text+0x1ff8f10)
  + error: usb.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.list_del' defined in .text section in lib/built-in.o:  => (.text+0x1ff8adc)
  + error: usb.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.skb_dequeue' defined in .text section in net/built-in.o:  => (.text+0x1ff9c0c)
  + error: usb.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.udelay' defined in .text section in arch/powerpc/kernel/built-in.o:  => (.text+0x1ff91a8)

3 error improvements:
  - /home/kisskb/slave/tmp/ccWS5U7E.s: Error: pcrel too far BFD_RELOC_BFIN_10: 889 => 
  - error: phy_g.c: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o: (.text+0x1ffa180), (.text+0x1ffae00), (.text+0x1ff9858), (.text+0x1ffacb8), (.text+0x1ffad84), (.text+0x1ffb89c), (.text+0x1ffa318), (.text+0x1ffbaf4), (.text+0x1ffc8d0), (.text+0x1ffb134) => 
  - {standard input}: Error: Instruction with long immediate data in delay slot: 18729 => 


*** WARNINGS ***

[Deleted 1451 lines about "warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]" on parisc-allmodconfig]

1576 warning regressions:
  + /home/kisskb/slave/src/arch/s390/pci/pci_dma.c: warning: 'pa' may be used uninitialized in this function [-Wuninitialized]:  => 309:13
  + /home/kisskb/slave/src/arch/sh/include/asm/bitops-op32.h: warning: array subscript is above array bounds [-Warray-bounds]:  => 139:20
  + /home/kisskb/slave/src/drivers/auxdisplay/img-ascii-lcd.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]:  => 109:5, 207:5
  + /home/kisskb/slave/src/drivers/block/rbd.c: warning: '__rbd_acknowledge_notify' uses dynamic stack allocation [enabled by default]:  => 3737:1
  + /home/kisskb/slave/src/drivers/block/rbd.c: warning: '__rbd_notify_op_lock' uses dynamic stack allocation [enabled by default]:  => 3245:1
  + /home/kisskb/slave/src/drivers/block/rbd.c: warning: 'struct_v' may be used uninitialized in this function [-Wuninitialized]:  => 3793:30
  + /home/kisskb/slave/src/drivers/gpio/gpiolib.c: warning: 'gpiochip_irqchip_free_valid_mask' declared inline after being called:  => 75
  + /home/kisskb/slave/src/drivers/gpio/gpiolib.c: warning: 'gpiochip_irqchip_init_valid_mask' declared inline after being called:  => 74
  + /home/kisskb/slave/src/drivers/gpio/gpiolib.c: warning: previous declaration of 'gpiochip_irqchip_free_valid_mask' was here:  => 75
  + /home/kisskb/slave/src/drivers/gpio/gpiolib.c: warning: previous declaration of 'gpiochip_irqchip_init_valid_mask' was here:  => 74
  + /home/kisskb/slave/src/drivers/infiniband/hw/qedr/verbs.c: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]:  => 1307:2, 1340:2
  + /home/kisskb/slave/src/drivers/media/i2c/ir-kbd-i2c.c: warning: 'toggle' may be used uninitialized in this function [-Wuninitialized]:  => 120:4
  + /home/kisskb/slave/src/drivers/media/usb/dvb-usb/dib0700_core.c: warning: 'protocol' may be used uninitialized in this function [-Wuninitialized]:  => 763:12
  + /home/kisskb/slave/src/drivers/mfd/htc-pasic3.c: warning: unused variable 'asic' [-Wunused-variable]:  => 189:22
  + /home/kisskb/slave/src/drivers/mtd/ubi/eba.c: warning: 'opnum' may be used uninitialized in this function [-Wuninitialized]:  => 897:7
  + /home/kisskb/slave/src/drivers/mtd/ubi/eba.c: warning: 'opnum' may be used uninitialized in this function:  => 859
  + /home/kisskb/slave/src/drivers/mtd/ubi/eba.c: warning: 'vid_hdr' is used uninitialized in this function:  => 744
  + /home/kisskb/slave/src/drivers/mtd/ubi/eba.c: warning: 'vid_hdr' may be used uninitialized in this function [-Wuninitialized]:  => 744:2
  + /home/kisskb/slave/src/drivers/net/dsa/mv88e6xxx/global2.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]:  => 471:7
  + /home/kisskb/slave/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: warning: 'is_11d' may be used uninitialized in this function [-Wuninitialized]:  => 4586:31
  + /home/kisskb/slave/src/drivers/power/supply/da9150-fg.c: warning: 'da9150_fg_read_attr.isra.4' uses dynamic stack allocation [enabled by default]:  => 108:1
  + /home/kisskb/slave/src/drivers/power/supply/da9150-fg.c: warning: 'da9150_fg_write_attr.isra.3.constprop.5' uses dynamic stack allocation [enabled by default]:  => 126:1
  + /home/kisskb/slave/src/drivers/staging/iio/accel/sca3000_core.c: warning: 'base_freq' may be used uninitialized in this function [-Wuninitialized]:  => 529:23
  + /home/kisskb/slave/src/drivers/staging/iio/adc/ad7606_par.c: warning: unused variable 'st' [-Wunused-variable]:  => 39:23, 23:23
  + /home/kisskb/slave/src/drivers/staging/lustre/lustre/llite/xattr.c: warning: 'll_xattr_get_common' uses dynamic stack allocation [enabled by default]:  => 354:1
  + /home/kisskb/slave/src/drivers/staging/lustre/lustre/llite/xattr.c: warning: 'll_xattr_set_common' uses dynamic stack allocation [enabled by default]:  => 152:1
  + /home/kisskb/slave/src/drivers/staging/media/lirc/lirc_serial.c: warning: the frame size of 1496 bytes is larger than 1024 bytes [-Wframe-larger-than=]:  => 626:1
  + /home/kisskb/slave/src/drivers/staging/media/s5p-cec/s5p_cec.c: warning: 's5p_cec_runtime_resume' defined but not used [-Wunused-function]:  => 242:12
  + /home/kisskb/slave/src/drivers/staging/media/s5p-cec/s5p_cec.c: warning: 's5p_cec_runtime_suspend' defined but not used [-Wunused-function]:  => 234:12
  + /home/kisskb/slave/src/drivers/usb/dwc3/gadget.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]:  => 1981:7
  + /home/kisskb/slave/src/drivers/usb/dwc3/gadget.c: warning: 'trb' may be used uninitialized in this function [-Wuninitialized]:  => 1988:12
  + /home/kisskb/slave/src/fs/ceph/super.c: warning: 'root' may be used uninitialized in this function [-Wuninitialized]:  => 818:17
  + /home/kisskb/slave/src/fs/ext2/inode.c: warning: 'bno' may be used uninitialized in this function:  => 783
  + /home/kisskb/slave/src/fs/f2fs/checkpoint.c: warning: 'get_checkpoint_version' uses dynamic stack allocation [enabled by default]:  => 693:1
  + /home/kisskb/slave/src/fs/nfs/nfs4proc.c: warning: (near initialization for 'freeme.<anonymous>') [-Wmissing-braces]:  => 1548:2
  + /home/kisskb/slave/src/fs/nfs/nfs4proc.c: warning: missing braces around initializer [-Wmissing-braces]:  => 1548:2
  + /home/kisskb/slave/src/fs/posix_acl.c: warning: value computed is not used:  => 146
  + /home/kisskb/slave/src/fs/pstore/ram_core.c: warning: 'persistent_ram_decode_rs8.isra.5' uses dynamic stack allocation [enabled by default]:  => 118:1
  + /home/kisskb/slave/src/fs/pstore/ram_core.c: warning: 'persistent_ram_encode_rs8.isra.6' uses dynamic stack allocation [enabled by default]:  => 106:1
  + /home/kisskb/slave/src/include/linux/dcache.h: warning: passing argument 1 of 'd_real' discards qualifiers from pointer target type:  => 590
  + /home/kisskb/slave/src/include/net/dst.h: warning: 'dst' may be used uninitialized in this function [-Wuninitialized]:  => 221:2
  + /home/kisskb/slave/src/kernel/trace/bpf_trace.c: warning: 'bpf_perf_event_output_tp' uses dynamic stack allocation [enabled by default]:  => 474:1
  + /home/kisskb/slave/src/lib/iov_iter.c: warning: format '%zd' expects argument of type 'signed size_t', but argument 3 has type 'size_t' [-Wformat=]:  => 318:2
  + /home/kisskb/slave/src/lib/iov_iter.c: warning: format '%zd' expects argument of type 'signed size_t', but argument 3 has type 'size_t' [-Wformat]:  => 318:2
  + /home/kisskb/slave/src/lib/raid6/recov_avx512.c: warning: #warning "your version of binutils lacks AVX512 support" [-Wcpp]:  => 387:2
  + /home/kisskb/slave/src/net/can/bcm.c: warning: the frame size of 1176 bytes is larger than 1024 bytes [-Wframe-larger-than=]:  => 240:1
  + /home/kisskb/slave/src/net/core/flow_dissector.c: warning: 'vlan' may be used uninitialized in this function [-Wuninitialized]:  => 283:7
  + /home/kisskb/slave/src/net/core/flow_dissector.c: warning: 'vlan' may be used uninitialized in this function:  => 248, 248:26
  + /home/kisskb/slave/src/net/core/rtnetlink.c: warning: 'ivvl[0]' may be used uninitialized in this function:  => 1739
  + /home/kisskb/slave/src/net/ipv4/proc.c: warning: 'snmp_seq_show_tcp_udp.isra.5' uses dynamic stack allocation [enabled by default]:  => 458:1
  + /home/kisskb/slave/src/net/ipv6/ip6_output.c: warning: passing argument 1 of 'l3mdev_ip6_out' discards qualifiers from pointer target type:  => 243
  + /home/kisskb/slave/src/net/ipv6/proc.c: warning: 'snmp6_seq_show_item' uses dynamic stack allocation [enabled by default]:  => 214:1
  + /home/kisskb/slave/src/net/ipv6/proc.c: warning: 'snmp6_seq_show_item64.isra.1.constprop.2' uses dynamic stack allocation [enabled by default]:  => 227:1
  + /home/kisskb/slave/src/net/mac80211/mesh_pathtbl.c: warning: 'new_mpath' may be used uninitialized in this function [-Wuninitialized]:  => 422:28
  + /home/kisskb/slave/src/net/netfilter/nft_range.c: warning: 'mismatch' may be used uninitialized in this function [-Wuninitialized]:  => 45:5
  + /home/kisskb/slave/src/net/rxrpc/call_accept.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]:  => 573:2
  + /home/kisskb/slave/src/net/rxrpc/recvmsg.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]:  => 99:2
  + /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_decrypt_response.isra.5' uses dynamic stack allocation [enabled by default]:  => 1010:1
  + /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_encrypt_response.isra.6' uses dynamic stack allocation [enabled by default]:  => 743:1
  + /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_secure_packet_auth.isra.7' uses dynamic stack allocation [enabled by default]:  => 180:1
  + /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_secure_packet_encrypt.isra.8' uses dynamic stack allocation [enabled by default]:  => 242:1
  + /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_verify_packet_1' uses dynamic stack allocation [enabled by default]:  => 391:1
  + /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_verify_packet_2' uses dynamic stack allocation [enabled by default]:  => 481:1
  + /home/kisskb/slave/src/net/sunrpc/xprtsock.c: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]:  => 2553:3
  + /home/kisskb/slave/src/net/sunrpc/xprtsock.c: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat]:  => 2553:3
  + <stdin>: warning: #warning syscall pkey_alloc not implemented [-Wcpp]:  => 1319:2
  + <stdin>: warning: #warning syscall pkey_alloc not implemented:  => 1319:2
  + <stdin>: warning: #warning syscall pkey_free not implemented [-Wcpp]:  => 1322:2
  + <stdin>: warning: #warning syscall pkey_free not implemented:  => 1322:2
  + <stdin>: warning: #warning syscall pkey_mprotect not implemented [-Wcpp]:  => 1316:2
  + <stdin>: warning: #warning syscall pkey_mprotect not implemented:  => 1316:2
  + scripts/Makefile.gcc-plugins: warning: cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler:  => 23
  + warning: (ARM_EXYNOS_BUS_DEVFREQ && ARM_TEGRA_DEVFREQ && ARM_RK3399_DMC_DEVFREQ && DEVFREQ_EVENT_EXYNOS_NOCP && DEVFREQ_EVENT_EXYNOS_PPMU) selects PM_OPP which has unmet direct dependencies (SPARC64):  => N/A
  + warning: drivers/built-in.o(.data+0x19bc): Section mismatch in reference from the variable lba_driver to the function .init.text:lba_driver_probe():  => N/A
  + warning: drivers/built-in.o(.data+0x1a78): Section mismatch in reference from the variable ccio_driver to the function .init.text:ccio_probe():  => N/A
  + warning: drivers/built-in.o(.data+0x1c1c): Section mismatch in reference from the variable dino_driver to the function .init.text:dino_probe():  => N/A
  + warning: drivers/built-in.o(.data+0x1d5c): Section mismatch in reference from the variable lasi_driver to the function .init.text:lasi_init_chip():  => N/A
  + warning: drivers/built-in.o(.data+0x1dc0): Section mismatch in reference from the variable asp_driver to the function .init.text:asp_init_chip():  => N/A
  + warning: drivers/built-in.o(.data+0x1e24): Section mismatch in reference from the variable wax_driver to the function .init.text:wax_init_chip():  => N/A
  + warning: drivers/built-in.o(.data+0x1e8c): Section mismatch in reference from the variable eisa_driver to the function .init.text:eisa_probe():  => N/A
  + warning: drivers/built-in.o(.data+0x2090): Section mismatch in reference from the variable superio_driver to the function .init.text:superio_probe():  => N/A
  + warning: drivers/built-in.o(.text+0x11c475): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry():  => N/A
  + warning: drivers/built-in.o(.text+0x13c441): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry():  => N/A
  + warning: drivers/built-in.o(.text+0x3385d20): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label():  => N/A
  + warning: drivers/hwmon/built-in.o(.text+0x3e700): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label():  => N/A
  + warning: drivers/hwmon/ibmpowernv.o(.text+0x7cc): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label():  => N/A
  + warning: drivers/iommu/built-in.o(.text+0x6df5): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry():  => N/A
  + warning: drivers/iommu/built-in.o(.text+0xe861): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x1ac): Section mismatch in reference from the variable lba_driver to the function .init.text:lba_driver_probe():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x268): Section mismatch in reference from the variable ccio_driver to the function .init.text:ccio_probe():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x40c): Section mismatch in reference from the variable dino_driver to the function .init.text:dino_probe():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x54c): Section mismatch in reference from the variable lasi_driver to the function .init.text:lasi_init_chip():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x5b0): Section mismatch in reference from the variable asp_driver to the function .init.text:asp_init_chip():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x614): Section mismatch in reference from the variable wax_driver to the function .init.text:wax_init_chip():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x67c): Section mismatch in reference from the variable eisa_driver to the function .init.text:eisa_probe():  => N/A
  + warning: drivers/parisc/built-in.o(.data+0x880): Section mismatch in reference from the variable superio_driver to the function .init.text:superio_probe():  => N/A
  + warning: drivers/scsi/g_NCR5380.o(.text+0x34d0): Section mismatch in reference from the variable .L493 to the function .init.text:NCR5380_probe_irq.constprop.1():  => N/A
  + warning: mm/built-in.o(.text.unlikely+0x108c): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid():  => N/A
  + warning: mm/built-in.o(.text.unlikely+0x10e8): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid():  => N/A
  + warning: mm/built-in.o(.text.unlikely+0x114c): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.__init_single_page.isra.40():  => N/A
  + warning: vmlinux.o(.data+0x5a45c): Section mismatch in reference from the variable lba_driver to the function .init.text:lba_driver_probe():  => N/A
  + warning: vmlinux.o(.data+0x5a518): Section mismatch in reference from the variable ccio_driver to the function .init.text:ccio_probe():  => N/A
  + warning: vmlinux.o(.data+0x5a6bc): Section mismatch in reference from the variable dino_driver to the function .init.text:dino_probe():  => N/A
  + warning: vmlinux.o(.data+0x5a7fc): Section mismatch in reference from the variable lasi_driver to the function .init.text:lasi_init_chip():  => N/A
  + warning: vmlinux.o(.data+0x5a860): Section mismatch in reference from the variable asp_driver to the function .init.text:asp_init_chip():  => N/A
  + warning: vmlinux.o(.data+0x5a8c4): Section mismatch in reference from the variable wax_driver to the function .init.text:wax_init_chip():  => N/A
  + warning: vmlinux.o(.data+0x5a92c): Section mismatch in reference from the variable eisa_driver to the function .init.text:eisa_probe():  => N/A
  + warning: vmlinux.o(.data+0x5ab30): Section mismatch in reference from the variable superio_driver to the function .init.text:superio_probe():  => N/A
  + warning: vmlinux.o(.text+0x16c): Section mismatch in reference from the function module_alloc() to the function .init.text:early_trap_init():  => N/A
  + warning: vmlinux.o(.text+0x174): Section mismatch in reference from the function __aa_kvmalloc() to the function .init.text:start_kernel():  => N/A
  + warning: vmlinux.o(.text+0x244): Section mismatch in reference from the function key_schedule_gc() to the function .init.text:setup_profiling_timer():  => N/A
  + warning: vmlinux.o(.text+0x37ac): Section mismatch in reference from the variable __boot_from_prom to the function .init.text:prom_init():  => N/A
  + warning: vmlinux.o(.text+0x3a24): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:early_setup():  => N/A
  + warning: vmlinux.o(.text+0x3a58): Section mismatch in reference from the variable start_here_common to the function .init.text:start_kernel():  => N/A
  + warning: vmlinux.o(.text+0x4395d20): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label():  => N/A
  + warning: vmlinux.o(.text+0x4cd305): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry():  => N/A
  + warning: vmlinux.o(.text+0x564d41): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry():  => N/A
  + warning: vmlinux.o(.text+0x80): Section mismatch in reference from the function pci_find_resource() to the function .init.text:map_pages():  => N/A
  + warning: vmlinux.o(.text+0xdbc): Section mismatch in reference from the function pkcs7_sig_note_skid() to the function .init.text:pcibios_init_bridge():  => N/A
  + warning: vmlinux.o(.text.unlikely+0xf05c): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid():  => N/A
  + warning: vmlinux.o(.text.unlikely+0xf0b8): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid():  => N/A
  + warning: vmlinux.o(.text.unlikely+0xf11c): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.__init_single_page.isra.40():  => N/A
  + warning: vmlinux.o(.text.unlikely+0xfe14): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid():  => N/A
  + warning: vmlinux.o(.text.unlikely+0xfe70): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid():  => N/A
  + warning: vmlinux.o(.text.unlikely+0xfed4): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.__init_single_page.isra.40():  => N/A

1194 warning improvements:

[Deleted 937 lines about "warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]" on parisc-allmodconfig]

  - /home/kisskb/slave/src/arch/arm/mach-mvebu/cpu-reset.c: warning: 'res_idx' may be used uninitialized in this function [-Wuninitialized]: 98:6 => 
  - /home/kisskb/slave/src/arch/arm/mach-omap2/omap_hwmod.c: warning: 'j' may be used uninitialized in this function [-Wuninitialized]: 1273:22 => 
  - /home/kisskb/slave/src/arch/arm/mach-omap2/omap_hwmod.c: warning: 'os' may be used uninitialized in this function [-Wuninitialized]: 1274:14 => 
  - /home/kisskb/slave/src/arch/arm/mach-omap2/omap_hwmod.c: warning: 'r' may be used uninitialized in this function [-Wuninitialized]: 2591:6 => 
  - /home/kisskb/slave/src/arch/arm/oprofile/../../../drivers/oprofile/buffer_sync.c: warning: 'code' may be used uninitialized in this function [-Wuninitialized]: 359:17 => 
  - /home/kisskb/slave/src/arch/arm/oprofile/../../../drivers/oprofile/buffer_sync.c: warning: 'pc' may be used uninitialized in this function [-Wuninitialized]: 356:10 => 
  - /home/kisskb/slave/src/arch/cris/arch-v32/kernel/fasttimer.c: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]: 353:2 => 
  - /home/kisskb/slave/src/arch/cris/arch-v32/mm/intmem.c: warning: comparison of distinct pointer types lacks a cast [enabled by default]: 123:14, 116:14 => 
  - /home/kisskb/slave/src/arch/cris/arch-v32/mm/intmem.c: warning: initialization from incompatible pointer type [enabled by default]: 148:1 => 
  - /home/kisskb/slave/src/arch/powerpc/boot/addnote.c: warning: right shift count >= width of type [enabled by default]: 183:3, 188:3, 211:3, 206:3 => 
  - /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: Warning: overflow in branch to __restore_all; converted into longer instruction sequence: 89 => 
  - /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: Warning: overflow in branch to syscall_call; converted into longer instruction sequence: 208 => 
  - /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: Warning: overflow in branch to syscall_trace_entry; converted into longer instruction sequence: 358, 356 => 
  - /home/kisskb/slave/src/drivers/android/binder.c: warning: 'buffer' may be used uninitialized in this function [-Wuninitialized]: 715:24 => 
  - /home/kisskb/slave/src/drivers/android/binder.c: warning: 'buffer_size' may be used uninitialized in this function [-Wuninitialized]: 715:37 => 
  - /home/kisskb/slave/src/drivers/android/binder.c: warning: 'cmd_name' may be used uninitialized in this function [-Wuninitialized]: 2314:5 => 
  - /home/kisskb/slave/src/drivers/base/regmap/regcache-rbtree.c: warning: 'new_base_reg' may be used uninitialized in this function [-Wuninitialized]: 455:8 => 
  - /home/kisskb/slave/src/drivers/base/regmap/regcache-rbtree.c: warning: 'new_top_reg' may be used uninitialized in this function [-Wuninitialized]: 455:8 => 
  - /home/kisskb/slave/src/drivers/base/regmap/regmap.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]: 2393:6 => 
  - /home/kisskb/slave/src/drivers/block/hd.c: warning: statement with no effect [-Wunused-value]: 467:2 => 
  - /home/kisskb/slave/src/drivers/bus/omap-ocp2scp.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]: 41:6 => 
  - /home/kisskb/slave/src/drivers/bus/omap_l3_noc.c: warning: 'l3_targ_base' may be used uninitialized in this function [-Wuninitialized]: 90:20 => 
  - /home/kisskb/slave/src/drivers/char/tpm/tpm2-cmd.c: warning: 'buf.data' may be used uninitialized in this function [-Wuninitialized]: 607:5 => 
  - /home/kisskb/slave/src/drivers/char/tpm/tpm2-cmd.c: warning: 'hash' may be used uninitialized in this function [-Wuninitialized]: 487:20 => 
  - /home/kisskb/slave/src/drivers/clk/mmp/clk-frac.c: warning: 'prev_rate' may be used uninitialized in this function [-Wuninitialized]: 47:4 => 
  - /home/kisskb/slave/src/drivers/clk/mmp/clk-mix.c: warning: 'item' may be used uninitialized in this function [-Wuninitialized]: 365:36, 401:20 => 
  - /home/kisskb/slave/src/drivers/clk/sunxi/clk-sun8i-bus-gates.c: warning: 'clk_parent' may be used uninitialized in this function [-Wuninitialized]: 85:44 => 
  - /home/kisskb/slave/src/drivers/extcon/extcon.c: warning: 'idx' may be used uninitialized in this function [-Wuninitialized]: 455:6 => 
  - /home/kisskb/slave/src/drivers/gpio/gpio-bcm-kona.c: warning: 'res' may be used uninitialized in this function [-Wuninitialized]: 301:12 => 
  - /home/kisskb/slave/src/drivers/gpio/gpio-dln2.c: warning: 'packed' attribute ignored for field of type '__le16' [-Wattributes]: 73:2 => 
  - /home/kisskb/slave/src/drivers/gpio/gpio-grgpio.c: warning: 'lirq' may be used uninitialized in this function [-Wuninitialized]: 316:27 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: warning: 'stat' may be used uninitialized in this function [-Wuninitialized]: 128:3 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_csr.c: warning: 'si' may be used uninitialized in this function [-Wuninitialized]: 218:3 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_runtime_pm.c: warning: 'cmn_a_well' may be used uninitialized in this function [-Wuninitialized]: 871:23 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_sprite.c: warning: 'src_h' may be used uninitialized in this function [-Wuninitialized]: 917:26 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_sprite.c: warning: 'src_w' may be used uninitialized in this function [-Wuninitialized]: 917:13 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_sprite.c: warning: 'src_x' may be used uninitialized in this function [-Wuninitialized]: 920:25 => 
  - /home/kisskb/slave/src/drivers/gpu/drm/i915/intel_sprite.c: warning: 'src_y' may be used uninitialized in this function [-Wuninitialized]: 933:20 => 
  - /home/kisskb/slave/src/drivers/gpu/vga/vgaarb.c: warning: 'devfn' may be used uninitialized in this function [-Wuninitialized]: 1092:5 => 
  - /home/kisskb/slave/src/drivers/hid/hid-picolcd_debugfs.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: 312:10 => 
  - /home/kisskb/slave/src/drivers/hwmon/dme1737.c: warning: 'addr' may be used uninitialized in this function [-Wuninitialized]: 2768:6 => 
  - /home/kisskb/slave/src/drivers/hwspinlock/hwspinlock_core.c: warning: 'hwlock' may be used uninitialized in this function [-Wuninitialized]: 335:14 => 
  - /home/kisskb/slave/src/drivers/hwspinlock/hwspinlock_core.c: warning: 'id' may be used uninitialized in this function [-Wuninitialized]: 301:6 => 
  - /home/kisskb/slave/src/drivers/i2c/busses/i2c-diolan-u2c.c: warning: 'byte' may be used uninitialized in this function [-Wuninitialized]: 393:18 => 
  - /home/kisskb/slave/src/drivers/ide/ide-floppy.c: warning: 'pc' may be used uninitialized in this function [-Wuninitialized]: 296:2 => 
  - /home/kisskb/slave/src/drivers/ide/ide-io-std.c: warning: statement with no effect [-Wunused-value]: 201:3, 186:4 => 
  - /home/kisskb/slave/src/drivers/input/keyboard/cros_ec_keyb.c: warning: 'cros_ec_keyb_clear_keyboard' uses dynamic stack allocation [enabled by default]: 340:1 => 
  - /home/kisskb/slave/src/drivers/input/keyboard/cros_ec_keyb.c: warning: 'cros_ec_keyb_irq' uses dynamic stack allocation [enabled by default]: 192:1 => 
  - /home/kisskb/slave/src/drivers/input/mouse/cyapa.c: warning: 'error' may be used uninitialized in this function [-Wuninitialized]: 717:3 => 
  - /home/kisskb/slave/src/drivers/input/mouse/cyapa_gen3.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]: 973:2 => 
  - /home/kisskb/slave/src/drivers/input/mouse/elan_i2c_i2c.c: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]: 579:10 => 
  - /home/kisskb/slave/src/drivers/irqchip/irq-gic-v2m.c: warning: 'offset' may be used uninitialized in this function [-Wuninitialized]: 190:25 => 
  - /home/kisskb/slave/src/drivers/irqchip/irq-mmp.c: warning: 'data' may be used uninitialized in this function [-Wuninitialized]: 154:12 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/avm_a1p.c: warning: statement with no effect [-Wunused-value]: 84:2, 120:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/avm_pci.c: warning: statement with no effect [-Wunused-value]: 101:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/diva.c: warning: statement with no effect [-Wunused-value]: 95:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/elsa.c: warning: statement with no effect [-Wunused-value]: 155:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/gazel.c: warning: statement with no effect [-Wunused-value]: 60:2, 91:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/niccy.c: warning: statement with no effect [-Wunused-value]: 59:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/sedlbauer.c: warning: statement with no effect [-Wunused-value]: 133:2 => 
  - /home/kisskb/slave/src/drivers/isdn/hisax/teles3.c: warning: statement with no effect [-Wunused-value]: 44:2 => 
  - /home/kisskb/slave/src/drivers/leds/leds-mc13783.c: warning: 'reg' may be used uninitialized in this function [-Wuninitialized]: 107:24 => 
  - /home/kisskb/slave/src/drivers/leds/leds-mc13783.c: warning: 'shift' may be used uninitialized in this function [-Wuninitialized]: 107:24 => 
  - /home/kisskb/slave/src/drivers/media/firewire/firedtv-avc.c: warning: 'pos' may be used uninitialized in this function [-Wuninitialized]: 608:26 => 
  - /home/kisskb/slave/src/drivers/media/usb/em28xx/em28xx-video.c: warning: control reaches end of non-void function [-Wreturn-type]: 842:1 => 
  - /home/kisskb/slave/src/drivers/memstick/core/mspro_block.c: warning: control reaches end of non-void function [-Wreturn-type]: 663:1 => 
  - /home/kisskb/slave/src/drivers/mfd/arizona-core.c: warning: 'n_subdevs' may be used uninitialized in this function [-Wuninitialized]: 1477:6 => 
  - /home/kisskb/slave/src/drivers/misc/bh1770glc.c: warning: 'mode' may be used uninitialized in this function [-Wuninitialized]: 236:29 => 
  - /home/kisskb/slave/src/drivers/mtd/chips/cfi_cmdset_0020.c: warning: the frame size of 1028 bytes is larger than 1024 bytes [-Wframe-larger-than=]: 603:1 => 
  - /home/kisskb/slave/src/drivers/mtd/nand/nandsim.c: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]: 782:2 => 
  - /home/kisskb/slave/src/drivers/net/dsa/mv88e6xxx/chip.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: 3114:7 => 
  - /home/kisskb/slave/src/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]: 414:1 => 
  - /home/kisskb/slave/src/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c: warning: the frame size of 1060 bytes is larger than 1024 bytes [-Wframe-larger-than=]: 731:1 => 
  - /home/kisskb/slave/src/drivers/net/ethernet/ti/tlan.c: warning: label 'err_out' defined but not used [-Wunused-label]: 614:1 => 
  - /home/kisskb/slave/src/drivers/net/hamradio/baycom_ser_fdx.c: warning: statement with no effect [-Wunused-value]: 314:4, 398:2, 399:2, 310:4 => 
  - /home/kisskb/slave/src/drivers/net/hamradio/baycom_ser_hdx.c: warning: statement with no effect [-Wunused-value]: 393:4, 455:2, 456:2, 414:4, 397:4 => 
  - /home/kisskb/slave/src/drivers/net/hamradio/yam.c: warning: statement with no effect [-Wunused-value]: 314:2, 491:2, 526:2, 525:2, 315:2, 910:3, 490:2 => 
  - /home/kisskb/slave/src/drivers/net/wireless/ath/carl9170/fwcmd.h: warning: 'packed' attribute ignored for field of type 'struct <anonymous>[]' [-Wattributes]  CC [M]  drivers/usb/wusbcore/crypto.o: 124:2 => 
  - /home/kisskb/slave/src/drivers/net/wireless/ath/carl9170/fwcmd.h: warning: 'packed' attribute ignored for field of type 'struct <anonymous>[]' [-Wattributes]: 124:2 => 
  - /home/kisskb/slave/src/drivers/net/wireless/ath/carl9170/mac.c: warning: 'power' may be used uninitialized in this function [-Wuninitialized]: 525:10 => 
  - /home/kisskb/slave/src/drivers/net/wireless/ath/carl9170/phy.c: warning: control reaches end of non-void function [-Wreturn-type]: 1568:1 => 
  - /home/kisskb/slave/src/drivers/net/wireless/ath/carl9170/rx.c: warning: 'head' may be used uninitialized in this function [-Wuninitialized]: 805:6 => 
  - /home/kisskb/slave/src/drivers/net/wireless/broadcom/b43/b43.h: warning: 'packed' attribute ignored for field of type 'union <anonymous>' [-Wattributes]  CC [M]  drivers/staging/iio/resolver/ad2s1200.o: 653:2 => 
  - /home/kisskb/slave/src/drivers/net/wireless/broadcom/b43/b43.h: warning: 'packed' attribute ignored for field of type 'union <anonymous>' [-Wattributes]: 653:2 => 
  - /home/kisskb/slave/src/drivers/net/wireless/broadcom/b43/xmit.h: warning: 'packed' attribute ignored for field of type 'struct <anonymous>' [-Wattributes]: 77:3, 294:3, 287:3, 64:3, 88:3 => 
  - /home/kisskb/slave/src/drivers/net/wireless/broadcom/b43legacy/b43legacy.h: warning: 'packed' attribute ignored for field of type 'union <anonymous>' [-Wattributes]: 381:2 => 
  - /home/kisskb/slave/src/drivers/net/wireless/intersil/p54/lmac.h: warning: 'packed' attribute ignored for field of type 'struct <anonymous>[3]' [-Wattributes]: 377:2 => 
  - /home/kisskb/slave/src/drivers/nvdimm/namespace_devs.c: warning: 'free_start' may be used uninitialized in this function [-Wuninitialized]: 632:29 => 
  - /home/kisskb/slave/src/drivers/of/irq.c: warning: 'msi_base' may be used uninitialized in this function [-Wuninitialized]: 670:23 => 
  - /home/kisskb/slave/src/drivers/of/irq.c: warning: 'rid_base' may be used uninitialized in this function [-Wuninitialized]: 670:10 => 
  - /home/kisskb/slave/src/drivers/of/platform.c: warning: 'addr' may be used uninitialized in this function [-Wuninitialized]: 89:16 => 
  - /home/kisskb/slave/src/drivers/of/resolver.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: 316:6 => 
  - /home/kisskb/slave/src/drivers/pci/quirks.c: warning: 'host_bridge' may be used uninitialized in this function [-Wuninitialized]: 2575:2 => 
  - /home/kisskb/slave/src/drivers/pinctrl/nomadik/pinctrl-abx500.c: warning: 'p' may be used uninitialized in this function [-Wuninitialized]: 747:23 => 
  - /home/kisskb/slave/src/drivers/pinctrl/qcom/pinctrl-msm.c: warning: 'bit' may be used uninitialized in this function [-Wuninitialized]: 235:13, 356:17 => 
  - /home/kisskb/slave/src/drivers/pinctrl/qcom/pinctrl-msm.c: warning: 'mask' may be used uninitialized in this function [-Wuninitialized]: 349:3, 235:6 => 
  - /home/kisskb/slave/src/drivers/pinctrl/samsung/pinctrl-exynos.c: warning: 'irq_chip' may be used uninitialized in this function [-Wuninitialized]: 521:18 => 
  - /home/kisskb/slave/src/drivers/power/da9150-fg.c: warning: 'da9150_fg_read_attr.isra.4' uses dynamic stack allocation [enabled by default]: 108:1 => 
  - /home/kisskb/slave/src/drivers/power/da9150-fg.c: warning: 'da9150_fg_write_attr.isra.3.constprop.5' uses dynamic stack allocation [enabled by default]: 126:1 => 
  - /home/kisskb/slave/src/drivers/power/ds2782_battery.c: warning: 'raw' may be used uninitialized in this function [-Wuninitialized]: 116:16, 185:21, 173:12, 145:20, 161:21, 214:17, 201:21 => 
  - /home/kisskb/slave/src/drivers/power/ds2782_battery.c: warning: 'sense_res_raw' may be used uninitialized in this function [-Wuninitialized]: 138:19 => 
  - /home/kisskb/slave/src/drivers/pwm/pwm-img.c: warning: 'div' may be used uninitialized in this function [-Wuninitialized]: 128:14 => 
  - /home/kisskb/slave/src/drivers/pwm/pwm-img.c: warning: 'timebase' may be used uninitialized in this function [-Wuninitialized]: 132:6 => 
  - /home/kisskb/slave/src/drivers/rtc/rtc-ab-b5ze-s3.c: warning: 'timer_secs' may be used uninitialized in this function [-Wuninitialized]: 365:16 => 
  - /home/kisskb/slave/src/drivers/rtc/rtc-sh.c: warning: 'sh_rtc_set_irq_wake' defined but not used [-Wunused-function]  CC      fs/proc/kmsg.o: 708:13 => 
  - /home/kisskb/slave/src/drivers/scsi/am53c974.c: warning: 'resid' may be used uninitialized in this function [-Wuninitialized]: 199:6 => 
  - /home/kisskb/slave/src/drivers/scsi/osst.h: warning: 'packed' attribute ignored for field of type 'u32' [-Wattributes]: 96:2 => 
  - /home/kisskb/slave/src/drivers/sh/clk/cpg.c: warning: passing argument 1 of 'ioread16' discards 'const' qualifier from pointer target type [enabled by default]  CC      fs/lockd/svc4proc.o: 46:2 => 
  - /home/kisskb/slave/src/drivers/soc/qcom/wcnss_ctrl.c: warning: 'expect_cbc' may be used uninitialized in this function [-Wuninitialized]: 300:5 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/aio_aio12_8.c: warning: statement with no effect [-Wunused-value]: 141:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/aio_iiro_16.c: warning: statement with no effect [-Wunused-value]: 88:3 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/das08.c: warning: statement with no effect [-Wunused-value]: 325:3, 330:3, 193:2, 194:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/das16m1.c: warning: statement with no effect [-Wunused-value]: 422:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/das1800.c: warning: statement with no effect [-Wunused-value]: 354:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/das6402.c: warning: statement with no effect [-Wunused-value]: 554:2, 496:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/dmm32at.c: warning: statement with no effect [-Wunused-value]: 483:3 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/dt2801.c: warning: statement with no effect [-Wunused-value]: 338:2, 337:2, 340:2, 339:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/dt2811.c: warning: statement with no effect [-Wunused-value]: 552:2, 553:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/dt2814.c: warning: statement with no effect [-Wunused-value]: 227:3, 228:3 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/dt282x.c: warning: statement with no effect [-Wunused-value]: 1079:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/fl512.c: warning: statement with no effect [-Wunused-value]: 101:3 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/ni_at_a2150.c: warning: statement with no effect [-Wunused-value]: 632:3 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/ni_at_ao.c: warning: statement with no effect [-Wunused-value]: 293:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/pcmda12.c: warning: statement with no effect [-Wunused-value]: 122:2, 88:4, 107:3 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/rti800.c: warning: statement with no effect [-Wunused-value]: 171:2, 274:2 => 
  - /home/kisskb/slave/src/drivers/staging/comedi/drivers/s526.c: warning: statement with no effect [-Wunused-value]: 397:2 => 
  - /home/kisskb/slave/src/drivers/staging/gdm724x/gdm_lte.c: warning: 'packed' attribute ignored for field of type 'struct <anonymous>' [-Wattributes]: 194:3 => 
  - /home/kisskb/slave/src/drivers/staging/iio/adc/ad7606_par.c: warning: statement with no effect [-Wunused-value]: 25:2, 41:2 => 
  - /home/kisskb/slave/src/drivers/staging/speakup/serialio.c: warning: statement with no effect [-Wunused-value]: 129:2, 126:2, 127:2, 128:2 => 
  - /home/kisskb/slave/src/drivers/staging/vt6656/mac.h: warning: 'packed' attribute ignored for field of type 'struct <anonymous>' [-Wattributes]: 361:3 => 
  - /home/kisskb/slave/src/drivers/thunderbolt/ctl.c: warning: 'pkg' may be used uninitialized in this function [-Wuninitialized]: 460:18 => 
  - /home/kisskb/slave/src/drivers/tty/serial/8250/8250_core.c: warning: 'i' may be used uninitialized in this function [-Wuninitialized]: 250:2, 210:2, 255:18 => 250:2, 255:18
  - /home/kisskb/slave/src/drivers/tty/serial/8250/8250_port.c: warning: statement with no effect [-Wunused-value]: 2340:3, 1348:3, 2302:3 => 
  - /home/kisskb/slave/src/drivers/tty/serial/crisv10.c: warning: 'ser_interrupt' defined but not used [-Wunused-function]: 2462:1 => 
  - /home/kisskb/slave/src/drivers/tty/vt/consolemap.c: warning: 'h' may be used uninitialized in this function [-Wuninitialized]: 801:6 => 
  - /home/kisskb/slave/src/drivers/usb/core/hcd.c: warning: 'bufp' may be used uninitialized in this function [-Wuninitialized]: 718:10 => 
  - /home/kisskb/slave/src/drivers/usb/gadget/function/f_ncm.c: warning: 'tmp' may be used uninitialized in this function [-Wuninitialized]: 1164:12, 1201:13, 1253:7, 1213:5, 1253:20, 1159:5 => 
  - /home/kisskb/slave/src/drivers/usb/host/isp1362.h: warning: statement with no effect [-Wunused-value]: 706:3 => 
  - /home/kisskb/slave/src/drivers/usb/serial/io_edgeport.c: warning: 'fw' may be used uninitialized in this function [-Wuninitialized]: 356:18, 2736:18 => 
  - /home/kisskb/slave/src/drivers/usb/wusbcore/devconnect.c: warning: 'port' may be used uninitialized in this function [-Wuninitialized]: 331:15 => 
  - /home/kisskb/slave/src/drivers/video/backlight/adp8860_bl.c: warning: 'ret_val' may be used uninitialized in this function [-Wuninitialized]: 579:10 => 
  - /home/kisskb/slave/src/drivers/video/fbdev/goldfishfb.c: warning: 'fbpaddr' may be used uninitialized in this function [-Wuninitialized]: 256:24 => 
  - /home/kisskb/slave/src/drivers/w1/slaves/w1_therm.c: warning: 'crc' may be used uninitialized in this function [-Wuninitialized]: 517:15 => 
  - /home/kisskb/slave/src/drivers/w1/slaves/w1_therm.c: warning: 'verdict' may be used uninitialized in this function [-Wuninitialized]: 519:2 => 
  - /home/kisskb/slave/src/fs/dcache.c: warning: 'n' may be used uninitialized in this function [-Wuninitialized]: 2379:2 => 
  - /home/kisskb/slave/src/fs/debugfs/file.c: warning: 'val' may be used uninitialized in this function [-Wuninitialized]: 754:2 => 
  - /home/kisskb/slave/src/fs/ext4/ext4_jbd2.h: warning: control reaches end of non-void function [-Wreturn-type]/home/kisskb/slave/src/fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]: 428:1 => 
  - /home/kisskb/slave/src/fs/f2fs/checkpoint.c: warning: 'validate_checkpoint' uses dynamic stack allocation [enabled by default]: 692:1 => 
  - /home/kisskb/slave/src/fs/pstore/ram_core.c: warning: 'persistent_ram_decode_rs8.isra.4' uses dynamic stack allocation [enabled by default]: 153:1 => 
  - /home/kisskb/slave/src/fs/pstore/ram_core.c: warning: 'persistent_ram_encode_rs8.isra.5' uses dynamic stack allocation [enabled by default]: 141:1 => 
  - /home/kisskb/slave/src/fs/reiserfs/stree.c: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]: 811:1 => 
  - /home/kisskb/slave/src/include/linux/compiler.h: warning: 'root' may be used uninitialized in this function [-Wuninitialized]: 220:2 => 
  - /home/kisskb/slave/src/include/linux/fs.h: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]: 2676:2 => 
  - /home/kisskb/slave/src/include/linux/fscrypto.h: warning: 'mode' may be used uninitialized in this function [-Wuninitialized]: 116:2 => 
  - /home/kisskb/slave/src/include/linux/pci.h: warning: 'ctrl_pos2' may be used uninitialized in this function [-Wuninitialized]: 941:2 => 
  - /home/kisskb/slave/src/include/linux/percpu-refcount.h: warning: 'percpu_count' may be used uninitialized in this function [-Wuninitialized]: 175:1, 274:1, 246:1, 212:1 => 
  - /home/kisskb/slave/src/include/linux/pinctrl/pinconf-generic.h: warning: 'arg' may be used uninitialized in this function [-Wuninitialized]: 155:9 => 
  - /home/kisskb/slave/src/include/linux/scatterlist.h: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]: 140:2 => 
  - /home/kisskb/slave/src/include/linux/spinlock.h: warning: 'dst_ptl' may be used uninitialized in this function [-Wuninitialized]: 347:2 => 
  - /home/kisskb/slave/src/include/linux/spinlock.h: warning: 'ptl' may be used uninitialized in this function [-Wuninitialized]: 347:2 => 
  - /home/kisskb/slave/src/include/sound/control.h: warning: 'speaker_vol' may be used uninitialized in this function [-Wuninitialized]  LD      net/ipv6/netfilter/built-in.o: 219:2 => 
  - /home/kisskb/slave/src/include/uapi/linux/usb/ch9.h: warning: 'ep_desc' may be used uninitialized in this function [-Wuninitialized]: 630:9 => 
  - /home/kisskb/slave/src/ipc/sem.c: warning: 'ulp' may be used uninitialized in this function [-Wuninitialized]: 1699:5 => 
  - /home/kisskb/slave/src/ipc/sem.c: warning: 'undo_list' may be used uninitialized in this function [-Wuninitialized]: 2044:3 => 
  - /home/kisskb/slave/src/ipc/shm.c: warning: 'file' may be used uninitialized in this function [-Wuninitialized]: 1350:3, 1351:59 => 1351:59
  - /home/kisskb/slave/src/kernel/bpf/hashtab.c: warning: 'l_new' may be used uninitialized in this function [-Wuninitialized]: 462:16 => 
  - /home/kisskb/slave/src/lib/atomic64_test.c: warning: the frame size of 1200 bytes is larger than 1024 bytes [-Wframe-larger-than=]: 246:1 => 
  - /home/kisskb/slave/src/lib/iomap.c: warning: statement with no effect [-Wunused-value]: 197:2, 205:2, 201:2 => 
  - /home/kisskb/slave/src/lib/lz4/lz4hc_compress.c: warning: 'delta' may be used uninitialized in this function [-Wuninitialized]: 174:20 => 
  - /home/kisskb/slave/src/lib/mpi/mpicoder.c: warning: 'buff' may be used uninitialized in this function [-Wuninitialized]: 336:12, 352:8 => 336:12
  - /home/kisskb/slave/src/lib/swiotlb.c: warning: 'dev_addr' may be used uninitialized in this function [-Wuninitialized]: 677:14 => 
  - /home/kisskb/slave/src/mm/huge_memory.c: warning: 'huge_gfp' may be used uninitialized in this function [-Wuninitialized]: 998:2 => 
  - /home/kisskb/slave/src/mm/memory.c: warning: 'entry' may be used uninitialized in this function [-Wuninitialized]: 3534:2, 3534:5 => 3538:5
  - /home/kisskb/slave/src/mm/page_alloc.c: warning: 'zone_start_pfn' may be used uninitialized in this function [-Wuninitialized]: 5630:17 => 
  - /home/kisskb/slave/src/mm/percpu.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: 1031:3 => 
  - /home/kisskb/slave/src/mm/percpu.c: warning: format '%zx' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat]: 2036:3 => 
  - /home/kisskb/slave/src/net/ipv4/ping.c: warning: 'icmph' may be used uninitialized in this function [-Wuninitialized]  LD      lib/zlib_inflate/zlib_inflate.o: 515:48 => 
  - /home/kisskb/slave/src/net/ncsi/ncsi-aen.c: warning: value computed is not used [-Wunused-value]: 106:2 => 
  - /home/kisskb/slave/src/net/ncsi/ncsi-manage.c: warning: value computed is not used [-Wunused-value]: 681:4, 559:3, 679:4, 202:3 => 
  - /home/kisskb/slave/src/net/netfilter/core.c: warning: 'entry' may be used uninitialized in this function [-Wuninitialized]: 157:7 => 
  - /home/kisskb/slave/src/net/rxrpc/recvmsg.c: warning: control reaches end of non-void function [-Wreturn-type]: 400:1 => 
  - /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_decrypt_response.isra.3' uses dynamic stack allocation [enabled by default]: 973:1 => 
  - /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_encrypt_response.isra.4' uses dynamic stack allocation [enabled by default]: 706:1 => 
  - /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_secure_packet_auth.isra.5' uses dynamic stack allocation [enabled by default]: 182:1 => 
  - /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_secure_packet_encrypt.isra.6' uses dynamic stack allocation [enabled by default]: 244:1 => 
  - /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_verify_packet_auth.isra.7' uses dynamic stack allocation [enabled by default]: 389:1 => 
  - /home/kisskb/slave/src/net/rxrpc/rxkad.c: warning: 'rxkad_verify_packet_encrypt.isra.8' uses dynamic stack allocation [enabled by default]: 475:1 => 
  - /home/kisskb/slave/src/sound/core/oss/pcm_oss.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: 2160:6 => 
  - /home/kisskb/slave/src/sound/drivers/mpu401/mpu401_uart.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: 287:6, 309:6 => 
  - /home/kisskb/slave/src/sound/drivers/serial-u16550.c: warning: statement with no effect [-Wunused-value]: 460:2, 461:2, 499:2, 459:2, 305:2 => 
  - /home/kisskb/slave/src/sound/firewire/bebob/bebob_focusrite.c: warning: 'value' may be used uninitialized in this function [-Wuninitialized]: 216:14 => 
  - /home/kisskb/slave/src/sound/firewire/bebob/bebob_stream.c: warning: 'index' may be used uninitialized in this function [-Wuninitialized]: 441:51 => 
  - warning: arch/arm/mach-omap2/built-in.o(.text.unlikely+0x64): Section mismatch in reference from the function omap_init_rng() to the function .init.text:omap_device_build(): N/A => 
  - warning: drivers/built-in.o(.data+0x1974): Section mismatch in reference from the variable lba_driver to the function .init.text:lba_driver_probe(): N/A => 
  - warning: drivers/built-in.o(.data+0x1a30): Section mismatch in reference from the variable ccio_driver to the function .init.text:ccio_probe(): N/A => 
  - warning: drivers/built-in.o(.data+0x1bcc): Section mismatch in reference from the variable dino_driver to the function .init.text:dino_probe(): N/A => 
  - warning: drivers/built-in.o(.data+0x1d0c): Section mismatch in reference from the variable lasi_driver to the function .init.text:lasi_init_chip(): N/A => 
  - warning: drivers/built-in.o(.data+0x1d70): Section mismatch in reference from the variable asp_driver to the function .init.text:asp_init_chip(): N/A => 
  - warning: drivers/built-in.o(.data+0x1dd4): Section mismatch in reference from the variable wax_driver to the function .init.text:wax_init_chip(): N/A => 
  - warning: drivers/built-in.o(.data+0x1e3c): Section mismatch in reference from the variable eisa_driver to the function .init.text:eisa_probe(): N/A => 
  - warning: drivers/built-in.o(.data+0x2040): Section mismatch in reference from the variable superio_driver to the function .init.text:superio_probe(): N/A => 
  - warning: drivers/built-in.o(.text+0x119fc1): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry(): N/A => 
  - warning: drivers/built-in.o(.text+0x329a7d8): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label(): N/A => 
  - warning: drivers/built-in.o(.text+0x408174): Section mismatch in reference from the function etrax_init_module() to the function .init.text:etrax_ethernet_init(): N/A => 
  - warning: drivers/built-in.o(.text+0x698d4): Section mismatch in reference from the function omap_gpio_probe() to the function .init.text:omap_gpio_show_rev(): N/A => 
  - warning: drivers/built-in.o(.text+0x7c794): Section mismatch in reference from the function etrax_init_module() to the function .init.text:etrax_ethernet_init(): N/A => 
  - warning: drivers/built-in.o(.text+0xfc315): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry(): N/A => 
  - warning: drivers/built-in.o(.text.unlikely+0xb41c): Section mismatch in reference from the function integrator_clocksource_init() to the function .init.text:clocksource_mmio_init(): N/A => 
  - warning: drivers/clocksource/built-in.o(.text.unlikely+0x2b8): Section mismatch in reference from the function integrator_clocksource_init() to the function .init.text:clocksource_mmio_init(): N/A => 
  - warning: drivers/gpio/built-in.o(.text+0x1abe0): Section mismatch in reference from the function omap_gpio_probe() to the function .init.text:omap_gpio_show_rev(): N/A => 
  - warning: drivers/hwmon/built-in.o(.text+0x3d558): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label(): N/A => 
  - warning: drivers/hwmon/ibmpowernv.o(.text+0x80c): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label(): N/A => 
  - warning: drivers/iommu/built-in.o(.text+0x6b75): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry(): N/A => 
  - warning: drivers/iommu/built-in.o(.text+0xdab1): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry(): N/A => 
  - warning: drivers/net/built-in.o(.text+0x1e2c): Section mismatch in reference from the function etrax_init_module() to the function .init.text:etrax_ethernet_init(): N/A => 
  - warning: drivers/net/built-in.o(.text+0x5ff94): Section mismatch in reference from the function etrax_init_module() to the function .init.text:etrax_ethernet_init(): N/A => 
  - warning: drivers/net/cris/built-in.o(.text+0x13e0): Section mismatch in reference from the function etrax_init_module() to the function .init.text:etrax_ethernet_init(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x1a4): Section mismatch in reference from the variable lba_driver to the function .init.text:lba_driver_probe(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x260): Section mismatch in reference from the variable ccio_driver to the function .init.text:ccio_probe(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x3fc): Section mismatch in reference from the variable dino_driver to the function .init.text:dino_probe(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x53c): Section mismatch in reference from the variable lasi_driver to the function .init.text:lasi_init_chip(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x5a0): Section mismatch in reference from the variable asp_driver to the function .init.text:asp_init_chip(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x604): Section mismatch in reference from the variable wax_driver to the function .init.text:wax_init_chip(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x66c): Section mismatch in reference from the variable eisa_driver to the function .init.text:eisa_probe(): N/A => 
  - warning: drivers/parisc/built-in.o(.data+0x870): Section mismatch in reference from the variable superio_driver to the function .init.text:superio_probe(): N/A => 
  - warning: mm/built-in.o(.text.unlikely+0x1080): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid(): N/A => 
  - warning: mm/built-in.o(.text.unlikely+0x10dc): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid(): N/A => 
  - warning: mm/built-in.o(.text.unlikely+0x1140): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.__init_single_page.isra.39(): N/A => 
  - warning: vmlinux.o(.data+0x66fe4): Section mismatch in reference from the variable lba_driver to the function .init.text:lba_driver_probe(): N/A => 
  - warning: vmlinux.o(.data+0x670a0): Section mismatch in reference from the variable ccio_driver to the function .init.text:ccio_probe(): N/A => 
  - warning: vmlinux.o(.data+0x6723c): Section mismatch in reference from the variable dino_driver to the function .init.text:dino_probe(): N/A => 
  - warning: vmlinux.o(.data+0x6737c): Section mismatch in reference from the variable lasi_driver to the function .init.text:lasi_init_chip(): N/A => 
  - warning: vmlinux.o(.data+0x673e0): Section mismatch in reference from the variable asp_driver to the function .init.text:asp_init_chip(): N/A => 
  - warning: vmlinux.o(.data+0x67444): Section mismatch in reference from the variable wax_driver to the function .init.text:wax_init_chip(): N/A => 
  - warning: vmlinux.o(.data+0x674ac): Section mismatch in reference from the variable eisa_driver to the function .init.text:eisa_probe(): N/A => 
  - warning: vmlinux.o(.data+0x676b0): Section mismatch in reference from the variable superio_driver to the function .init.text:superio_probe(): N/A => 
  - warning: vmlinux.o(.text+0x16c): Section mismatch in reference from the function swap_cgroup_record() to the function .init.text:early_trap_init(): N/A => 
  - warning: vmlinux.o(.text+0x174): Section mismatch in reference from the function ip_tunnel_unneed_metadata() to the function .init.text:start_kernel(): N/A => 
  - warning: vmlinux.o(.text+0x244): Section mismatch in reference from the function kernel_text_address() to the function .init.text:setup_profiling_timer(): N/A => 
  - warning: vmlinux.o(.text+0x3fc9f0): Section mismatch in reference from the function omap_gpio_probe() to the function .init.text:omap_gpio_show_rev(): N/A => 
  - warning: vmlinux.o(.text+0x426eb58): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label(): N/A => 
  - warning: vmlinux.o(.text+0x4a5aa5): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry(): N/A => 
  - warning: vmlinux.o(.text+0x53a521): Section mismatch in reference from the function dmar_walk_remapping_entries() to the function .init.text:dmar_table_print_dmar_entry(): N/A => 
  - warning: vmlinux.o(.text+0x80): Section mismatch in reference from the function __rwlock_init() to the function .init.text:map_pages(): N/A => 
  - warning: vmlinux.o(.text+0x8cf0): Section mismatch in reference from the variable __boot_from_prom to the function .init.text:prom_init(): N/A => 
  - warning: vmlinux.o(.text+0x8f24): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:early_setup(): N/A => 
  - warning: vmlinux.o(.text+0x8f58): Section mismatch in reference from the variable start_here_common to the function .init.text:start_kernel(): N/A => 
  - warning: vmlinux.o(.text+0xdbc): Section mismatch in reference from the function get_user_pages_locked() to the function .init.text:pcibios_init_bridge(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0x1738): Section mismatch in reference from the function omap_init_rng() to the function .init.text:omap_device_build(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0x2af60): Section mismatch in reference from the function integrator_clocksource_init() to the function .init.text:clocksource_mmio_init(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0x2afa8): Section mismatch in reference from the function integrator_clocksource_init() to the function .init.text:sched_clock_register(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0xedfc): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0xee58): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0xeebc): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.__init_single_page.isra.39(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0xfbb4): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0xfc10): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.early_pfn_to_nid(): N/A => 
  - warning: vmlinux.o(.text.unlikely+0xfc74): Section mismatch in reference from the function .init_reserved_page() to the function .meminit.text:.__init_single_page.isra.39(): N/A => 

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-17  7:21 Build regressions/improvements in v4.9-rc1 Geert Uytterhoeven
@ 2016-10-17  7:34   ` Geert Uytterhoeven
  0 siblings, 0 replies; 35+ messages in thread
From: Geert Uytterhoeven @ 2016-10-17  7:34 UTC (permalink / raw)
  To: linux-kernel
  Cc: Vineet Gupta, arcml, Michael Ellerman, linuxppc-dev,
	Jesper Nilsson, Cris

On Mon, Oct 17, 2016 at 9:21 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.9-rc1[1] compared to v4.8[2].

> [1] http://kisskb.ellerman.id.au/kisskb/head/11053/ (all 262 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/head/10989/ (all 262 configs)

> 48 error regressions:
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r4]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r5]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r6]':  => 475, 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r8]':  => 476, 475, 515
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r11]':  => 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r13]':  => 493, 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r14]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r18]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r21]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r6]':  => 476, 475, 515
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r7]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r12]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r3]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r8]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r9]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r0,[r6]':  => 516
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r10,[r12]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r14,[r9]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r16,[r8]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r0]':  => 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r13]':  => 496, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r18]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r21]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r4]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r5]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r6]':  => 478, 516, 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r8]':  => 479, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r11]':  => 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r13]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r14]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r6]':  => 479, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r7]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478

arcv2/axs103_smp_defconfig

>   + /home/kisskb/slave/src/arch/powerpc/kvm/book3s_hv_rm_xics.c: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]:  => 758:2

powerpc/ppc64_defconfig+UP

>   + /home/kisskb/slave/src/drivers/dma/omap-dma.c: error: unrecognizable insn::  => 350:1

cris-allyesconfig
cris-allmodconfig

>   + error: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A
>   + error: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A

ppc64le/allmodconfig+ppc64le
powerpc/powerpc-allmodconfig

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-17  7:34   ` Geert Uytterhoeven
  0 siblings, 0 replies; 35+ messages in thread
From: Geert Uytterhoeven @ 2016-10-17  7:34 UTC (permalink / raw)
  To: linux-snps-arc

On Mon, Oct 17, 2016 at 9:21 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.9-rc1[1] compared to v4.8[2].

> [1] http://kisskb.ellerman.id.au/kisskb/head/11053/ (all 262 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/head/10989/ (all 262 configs)

> 48 error regressions:
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r4]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r5]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r6]':  => 475, 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r8]':  => 476, 475, 515
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r11]':  => 476
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r13]':  => 493, 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r14]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r18]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r21]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r6]':  => 476, 475, 515
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r4,[r7]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r12]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r3]':  => 475
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r8]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r6,[r9]':  => 493
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r0,[r6]':  => 516
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r10,[r12]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r14,[r9]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r16,[r8]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r0]':  => 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r13]':  => 496, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r18]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r21]':  => 496
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r4]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r5]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r6]':  => 478, 516, 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r2,[r8]':  => 479, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r11]':  => 479
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r13]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r14]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r6]':  => 479, 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r7]':  => 478
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478

arcv2/axs103_smp_defconfig

>   + /home/kisskb/slave/src/arch/powerpc/kvm/book3s_hv_rm_xics.c: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]:  => 758:2

powerpc/ppc64_defconfig+UP

>   + /home/kisskb/slave/src/drivers/dma/omap-dma.c: error: unrecognizable insn::  => 350:1

cris-allyesconfig
cris-allmodconfig

>   + error: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A
>   + error: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!:  => N/A

ppc64le/allmodconfig+ppc64le
powerpc/powerpc-allmodconfig

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-17  7:34   ` Geert Uytterhoeven
@ 2016-10-17 16:59     ` Vineet Gupta
  -1 siblings, 0 replies; 35+ messages in thread
From: Vineet Gupta @ 2016-10-17 16:59 UTC (permalink / raw)
  To: Geert Uytterhoeven, linux-kernel
  Cc: arcml, Michael Ellerman, Peter Zijlstra, Arnd Bergmann, Michal Marek

+CC Arnd, Michal

Hi Geert, Arnd

Need some guidance here.

On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> 48 error regressions:
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475

[snip...]

>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> arcv2/axs103_smp_defconfig


I'm thinking how to address this correctly.

This is due to the older version of compiler.  The fix itself is trivial - add an
"call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD

However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
gets included in build comes from Kconfig (ISA supports them or not). How do we
tie the Makefile info into the Kconfig.

We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.

Or the simpler solution is that kisskb upgrades the ARC GNU compiler ;-)

-Vineet

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-17 16:59     ` Vineet Gupta
  0 siblings, 0 replies; 35+ messages in thread
From: Vineet Gupta @ 2016-10-17 16:59 UTC (permalink / raw)
  To: linux-snps-arc

+CC Arnd, Michal

Hi Geert, Arnd

Need some guidance here.

On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> 48 error regressions:
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475

[snip...]

>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> arcv2/axs103_smp_defconfig


I'm thinking how to address this correctly.

This is due to the older version of compiler.  The fix itself is trivial - add an
"call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD

However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
gets included in build comes from Kconfig (ISA supports them or not). How do we
tie the Makefile info into the Kconfig.

We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.

Or the simpler solution is that kisskb upgrades the ARC GNU compiler ;-)

-Vineet

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-17 16:59     ` Vineet Gupta
@ 2016-10-17 21:02       ` Arnd Bergmann
  -1 siblings, 0 replies; 35+ messages in thread
From: Arnd Bergmann @ 2016-10-17 21:02 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Geert Uytterhoeven, linux-kernel, arcml, Michael Ellerman,
	Peter Zijlstra, Michal Marek

On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> +CC Arnd, Michal
> 
> Hi Geert, Arnd
> 
> Need some guidance here.
> 
> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> >> 48 error regressions:
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
> 
> [snip...]
> 
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> > arcv2/axs103_smp_defconfig
> 
> 
> I'm thinking how to address this correctly.
> 
> This is due to the older version of compiler.  The fix itself is trivial - add an
> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD
> 
> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
> gets included in build comes from Kconfig (ISA supports them or not). How do we
> tie the Makefile info into the Kconfig.
> 
> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.
> 
> Or the simpler solution is that kisskb upgrades the ARC GNU compiler 

Some ideas, none of which are perfect:

- add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses
  .long with hardcoded opcodes in place of the mnemonics.

- instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file
  in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD
  is not set.

- add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if
  old binutils are found.

I think someone was suggesting in the past that Kconfig could be extended
to make decisions based on the gcc version, and the same thing could
be done for binutils. Don't remember who that was though. I think a number
of awkward hacks in the kernel could be simplified if we had this.

	And

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-17 21:02       ` Arnd Bergmann
  0 siblings, 0 replies; 35+ messages in thread
From: Arnd Bergmann @ 2016-10-17 21:02 UTC (permalink / raw)
  To: linux-snps-arc

On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> +CC Arnd, Michal
> 
> Hi Geert, Arnd
> 
> Need some guidance here.
> 
> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> >> 48 error regressions:
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
> 
> [snip...]
> 
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
> >> >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> > arcv2/axs103_smp_defconfig
> 
> 
> I'm thinking how to address this correctly.
> 
> This is due to the older version of compiler.  The fix itself is trivial - add an
> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD
> 
> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
> gets included in build comes from Kconfig (ISA supports them or not). How do we
> tie the Makefile info into the Kconfig.
> 
> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.
> 
> Or the simpler solution is that kisskb upgrades the ARC GNU compiler 

Some ideas, none of which are perfect:

- add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses
  .long with hardcoded opcodes in place of the mnemonics.

- instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file
  in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD
  is not set.

- add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if
  old binutils are found.

I think someone was suggesting in the past that Kconfig could be extended
to make decisions based on the gcc version, and the same thing could
be done for binutils. Don't remember who that was though. I think a number
of awkward hacks in the kernel could be simplified if we had this.

	And

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-17 21:02       ` Arnd Bergmann
@ 2016-10-17 22:37         ` Vineet Gupta
  -1 siblings, 0 replies; 35+ messages in thread
From: Vineet Gupta @ 2016-10-17 22:37 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Michal Marek, Peter Zijlstra, Michael Ellerman, linux-kernel,
	Geert Uytterhoeven, arcml

On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> +CC Arnd, Michal
>>
>> Hi Geert, Arnd
>>
>> Need some guidance here.
>>
>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>>>> 48 error regressions:
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>>
>> [snip...]
>>
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>>> arcv2/axs103_smp_defconfig
>>
>>
>> I'm thinking how to address this correctly.
>>
>> This is due to the older version of compiler.  The fix itself is trivial - add an
>> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD
>>
>> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
>> gets included in build comes from Kconfig (ISA supports them or not). How do we
>> tie the Makefile info into the Kconfig.
>>
>> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
>> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.
>>
>> Or the simpler solution is that kisskb upgrades the ARC GNU compiler 
> 
> Some ideas, none of which are perfect:
> 
> - add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses
>   .long with hardcoded opcodes in place of the mnemonics.
> 
> - instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file
>   in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD
>   is not set.
> 
> - add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if
>   old binutils are found.

I'm tending towards this one - seems cleanest, however...

@Michael can I bother you to upgrade the tools or is this absolutely must for you.

> 
> I think someone was suggesting in the past that Kconfig could be extended
> to make decisions based on the gcc version, and the same thing could
> be done for binutils. Don't remember who that was though. I think a number
> of awkward hacks in the kernel could be simplified if we had this.
> 
> 	And
> 

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-17 22:37         ` Vineet Gupta
  0 siblings, 0 replies; 35+ messages in thread
From: Vineet Gupta @ 2016-10-17 22:37 UTC (permalink / raw)
  To: linux-snps-arc

On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> +CC Arnd, Michal
>>
>> Hi Geert, Arnd
>>
>> Need some guidance here.
>>
>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>>>> 48 error regressions:
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>>
>> [snip...]
>>
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>>> arcv2/axs103_smp_defconfig
>>
>>
>> I'm thinking how to address this correctly.
>>
>> This is due to the older version of compiler.  The fix itself is trivial - add an
>> "call as-instr" construct in Makefile to get -DARC_TOOLS_SUPPORT_LLOCKD
>>
>> However the atomic64 API variant (CONFIG_GENERIC_ATOMIC64 or arch native) which
>> gets included in build comes from Kconfig (ISA supports them or not). How do we
>> tie the Makefile info into the Kconfig.
>>
>> We could trigger a build failure for invalid combinations of GENERIC_ATOMIC64 and
>> ARC_TOOLS_SUPPORT_LLOCKD but that would be less than ideal out of box experience.
>>
>> Or the simpler solution is that kisskb upgrades the ARC GNU compiler 
> 
> Some ideas, none of which are perfect:
> 
> - add an #ifndef ARC_TOOLS_SUPPORT_LLOCKD clause in asm/atomic.h that uses
>   .long with hardcoded opcodes in place of the mnemonics.
> 
> - instead of setting CONFIG_GENERIC_ATOMIC64 from Kconfig, add a file
>   in arch/arc/kernel/ that includes lib/atomic64.c if ARC_TOOLS_SUPPORT_LLOCKD
>   is not set.
> 
> - add "-DCONFIG_GENERIC_ATOMIC64" to cflags-y from arch/arc/Makefile if
>   old binutils are found.

I'm tending towards this one - seems cleanest, however...

@Michael can I bother you to upgrade the tools or is this absolutely must for you.

> 
> I think someone was suggesting in the past that Kconfig could be extended
> to make decisions based on the gcc version, and the same thing could
> be done for binutils. Don't remember who that was though. I think a number
> of awkward hacks in the kernel could be simplified if we had this.
> 
> 	And
> 

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-17 22:37         ` Vineet Gupta
@ 2016-10-19 11:50           ` Michael Ellerman
  -1 siblings, 0 replies; 35+ messages in thread
From: Michael Ellerman @ 2016-10-19 11:50 UTC (permalink / raw)
  To: Vineet Gupta, Arnd Bergmann
  Cc: Michal Marek, Peter Zijlstra, linux-kernel, Geert Uytterhoeven, arcml

Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
> On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>>>>> 48 error regressions:
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>>>
>>> [snip...]
>>>
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>>>> arcv2/axs103_smp_defconfig
>
> @Michael can I bother you to upgrade the tools or is this absolutely must for you.

Happy to, just short on time.

I tried building a new toolchain with buildroot, using the instructions
from last time, but the resulting toolchain doesn't relocate, ie. it has
hard-coded paths in it. Any ideas?

cheers

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-19 11:50           ` Michael Ellerman
  0 siblings, 0 replies; 35+ messages in thread
From: Michael Ellerman @ 2016-10-19 11:50 UTC (permalink / raw)
  To: linux-snps-arc

Vineet Gupta <Vineet.Gupta1 at synopsys.com> writes:
> On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>>>>> 48 error regressions:
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  => 475
>>>
>>> [snip...]
>>>
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>>>>>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>>>> arcv2/axs103_smp_defconfig
>
> @Michael can I bother you to upgrade the tools or is this absolutely must for you.

Happy to, just short on time.

I tried building a new toolchain with buildroot, using the instructions
from last time, but the resulting toolchain doesn't relocate, ie. it has
hard-coded paths in it. Any ideas?

cheers

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-19 11:50           ` Michael Ellerman
@ 2016-10-19 12:23             ` Alexey Brodkin
  -1 siblings, 0 replies; 35+ messages in thread
From: Alexey Brodkin @ 2016-10-19 12:23 UTC (permalink / raw)
  To: mpe, thomas.petazzoni
  Cc: arnd, linux-kernel, peterz, Vineet.Gupta1, geert, mmarek, linux-snps-arc

Hi Michael,

On Wed, 2016-10-19 at 22:50 +1100, Michael Ellerman wrote:
> Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
> > 
> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> > > 
> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> > > > 
> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> > > > > 
> > > > > > 
> > > > > > 48 error regressions:
> > > > > > > 
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  =>
> > > > > > > 475
> > > > 
> > > > [snip...]
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
> > > > > arcv2/axs103_smp_defconfig
> > 
> > @Michael can I bother you to upgrade the tools or is this absolutely must for you.
> 
> Happy to, just short on time.
> 
> I tried building a new toolchain with buildroot, using the instructions
> from last time, but the resulting toolchain doesn't relocate, ie. it has
> hard-coded paths in it. Any ideas?

Hm... that's strange - it used to work but doesn't work with newer Buildroot...

Anyways if something very simple (i.e. with no extra libraries) works for you just go
ahead and grab pre-built image that Thomas Petazzoni builds.

That's the most recent one:
http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

If I'm not mistaken Thomas runs some post-processing script to make these toolchains
relocatable.

Maybe Thomas may comment on that and even maybe will share his post-processing technique
so you'll be able to build your customized toolchain.

Regards,
Alexey

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-19 12:23             ` Alexey Brodkin
  0 siblings, 0 replies; 35+ messages in thread
From: Alexey Brodkin @ 2016-10-19 12:23 UTC (permalink / raw)
  To: linux-snps-arc

Hi Michael,

On Wed, 2016-10-19@22:50 +1100, Michael Ellerman wrote:
> Vineet Gupta <Vineet.Gupta1 at synopsys.com> writes:
> > 
> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> > > 
> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> > > > 
> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> > > > > 
> > > > > > 
> > > > > > 48 error regressions:
> > > > > > > 
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':??=> 476
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':??=>
> > > > > > > 475
> > > > 
> > > > [snip...]
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':??=> 516
> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':??=> 478
> > > > > arcv2/axs103_smp_defconfig
> > 
> > @Michael can I bother you to upgrade the tools or is this absolutely must for you.
> 
> Happy to, just short on time.
> 
> I tried building a new toolchain with buildroot, using the instructions
> from last time, but the resulting toolchain doesn't relocate, ie. it has
> hard-coded paths in it. Any ideas?

Hm... that's strange - it used to work but doesn't work with newer Buildroot...

Anyways if something very simple (i.e. with no extra libraries) works for you just go
ahead and grab pre-built image that Thomas Petazzoni builds.

That's the most recent one:
http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

If I'm not mistaken Thomas runs some post-processing script to make these toolchains
relocatable.

Maybe Thomas may comment on that and even maybe will share his post-processing technique
so you'll be able to build your customized toolchain.

Regards,
Alexey

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-19 12:23             ` Alexey Brodkin
@ 2016-10-19 20:32               ` Thomas Petazzoni
  -1 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-19 20:32 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: mpe, arnd, linux-kernel, peterz, Vineet.Gupta1, geert, mmarek,
	linux-snps-arc

Hello,

On Wed, 19 Oct 2016 12:23:12 +0000, Alexey Brodkin wrote:

> > I tried building a new toolchain with buildroot, using the instructions
> > from last time, but the resulting toolchain doesn't relocate, ie. it has
> > hard-coded paths in it. Any ideas?  
> 
> Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> 
> Anyways if something very simple (i.e. with no extra libraries) works for you just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
> 
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2
> 
> If I'm not mistaken Thomas runs some post-processing script to make these toolchains
> relocatable.
> 
> Maybe Thomas may comment on that and even maybe will share his post-processing technique
> so you'll be able to build your customized toolchain.

I simply have two patches on top of Buildroot to build the toolchains
available at http://autobuild.buildroot.org/toolchains/tarballs/ :

 - One patch that builds mpc, gmp and mpfr statically. This is needed
   since the host tools are built with an absolute rpath, so once the
   toolchain is moved, it can't find the host shared libraries that
   have been built for it. Using static linking is a temporary
   work-around, our idea is to fix the rpath to use relative path using
   $ORIGIN. There are some patches from Samuel Martin doing this, we
   have discussed them during the Buildroot Developers Meeting last
   week-end, and we proposed to Samuel to investigate a slightly
   different approach (namely add more features to the upstream
   patchelf utility).

 - One patch that fixes the toolchain wrapper logic so that it works
   fine when the toolchain is moved out of the usr/ sub-directory. We
   started discussing it during the meeting, but I got drowned into
   other discussions, so we haven't had the time to get to the bottom
   of it.

If people are interested, I can prepare a tutorial on how to build
re-usable and relocatable toolchains with Buildroot.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-19 20:32               ` Thomas Petazzoni
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-19 20:32 UTC (permalink / raw)
  To: linux-snps-arc

Hello,

On Wed, 19 Oct 2016 12:23:12 +0000, Alexey Brodkin wrote:

> > I tried building a new toolchain with buildroot, using the instructions
> > from last time, but the resulting toolchain doesn't relocate, ie. it has
> > hard-coded paths in it. Any ideas?  
> 
> Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> 
> Anyways if something very simple (i.e. with no extra libraries) works for you just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
> 
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2
> 
> If I'm not mistaken Thomas runs some post-processing script to make these toolchains
> relocatable.
> 
> Maybe Thomas may comment on that and even maybe will share his post-processing technique
> so you'll be able to build your customized toolchain.

I simply have two patches on top of Buildroot to build the toolchains
available at http://autobuild.buildroot.org/toolchains/tarballs/ :

 - One patch that builds mpc, gmp and mpfr statically. This is needed
   since the host tools are built with an absolute rpath, so once the
   toolchain is moved, it can't find the host shared libraries that
   have been built for it. Using static linking is a temporary
   work-around, our idea is to fix the rpath to use relative path using
   $ORIGIN. There are some patches from Samuel Martin doing this, we
   have discussed them during the Buildroot Developers Meeting last
   week-end, and we proposed to Samuel to investigate a slightly
   different approach (namely add more features to the upstream
   patchelf utility).

 - One patch that fixes the toolchain wrapper logic so that it works
   fine when the toolchain is moved out of the usr/ sub-directory. We
   started discussing it during the meeting, but I got drowned into
   other discussions, so we haven't had the time to get to the bottom
   of it.

If people are interested, I can prepare a tutorial on how to build
re-usable and relocatable toolchains with Buildroot.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-19 12:23             ` Alexey Brodkin
@ 2016-10-26 23:56               ` Michael Ellerman
  -1 siblings, 0 replies; 35+ messages in thread
From: Michael Ellerman @ 2016-10-26 23:56 UTC (permalink / raw)
  To: Alexey Brodkin, thomas.petazzoni
  Cc: arnd, linux-kernel, peterz, Vineet.Gupta1, geert, mmarek, linux-snps-arc

Alexey Brodkin <Alexey.Brodkin@synopsys.com> writes:
> On Wed, 2016-10-19 at 22:50 +1100, Michael Ellerman wrote:
>> Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
>> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> > > > > > 48 error regressions:
>> > > > > > > 
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':  => 476
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':  =>
>> > > > > > > 475
>> > > > 
>> > > > [snip...]
>> > > > > > > 
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':  => 516
>> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':  => 478
>> > > > > arcv2/axs103_smp_defconfig
>> > 
>> > @Michael can I bother you to upgrade the tools or is this absolutely must for you.
>> 
>> Happy to, just short on time.
>> 
>> I tried building a new toolchain with buildroot, using the instructions
>> from last time, but the resulting toolchain doesn't relocate, ie. it has
>> hard-coded paths in it. Any ideas?
>
> Hm... that's strange - it used to work but doesn't work with newer Buildroot...
>
> Anyways if something very simple (i.e. with no extra libraries) works for you just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
>
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

Thanks, I grabbed that and it works for axs103_smp_defconfig:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/


It doesn't work for axs101_defconfig, saying:

  arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.


So those are still failing:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12841194/


cheers

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-26 23:56               ` Michael Ellerman
  0 siblings, 0 replies; 35+ messages in thread
From: Michael Ellerman @ 2016-10-26 23:56 UTC (permalink / raw)
  To: linux-snps-arc

Alexey Brodkin <Alexey.Brodkin at synopsys.com> writes:
> On Wed, 2016-10-19@22:50 +1100, Michael Ellerman wrote:
>> Vineet Gupta <Vineet.Gupta1 at synopsys.com> writes:
>> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
>> > > > > > 48 error regressions:
>> > > > > > > 
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r0]':??=> 476
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `llockd r2,[r13]':??=>
>> > > > > > > 475
>> > > > 
>> > > > [snip...]
>> > > > > > > 
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r4,[r8]':??=> 516
>> > > > > > > ? + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad instruction `scondd r6,[r3]':??=> 478
>> > > > > arcv2/axs103_smp_defconfig
>> > 
>> > @Michael can I bother you to upgrade the tools or is this absolutely must for you.
>> 
>> Happy to, just short on time.
>> 
>> I tried building a new toolchain with buildroot, using the instructions
>> from last time, but the resulting toolchain doesn't relocate, ie. it has
>> hard-coded paths in it. Any ideas?
>
> Hm... that's strange - it used to work but doesn't work with newer Buildroot...
>
> Anyways if something very simple (i.e. with no extra libraries) works for you just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
>
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

Thanks, I grabbed that and it works for axs103_smp_defconfig:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/


It doesn't work for axs101_defconfig, saying:

  arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.


So those are still failing:

  http://kisskb.ellerman.id.au/kisskb/buildresult/12841194/


cheers

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-26 23:56               ` Michael Ellerman
@ 2016-10-27  7:07                 ` Thomas Petazzoni
  -1 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-27  7:07 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Alexey Brodkin, arnd, linux-kernel, peterz, Vineet.Gupta1, geert,
	mmarek, linux-snps-arc

Hello,

On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:

> > Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> >
> > Anyways if something very simple (i.e. with no extra libraries) works for you just go
> > ahead and grab pre-built image that Thomas Petazzoni builds.
> >
> > That's the most recent one:
> > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2  
> 
> Thanks, I grabbed that and it works for axs103_smp_defconfig:
> 
>   http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> 
> 
> It doesn't work for axs101_defconfig, saying:
> 
>   arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.

axs101 is using a 770 core, while the toolchain is built for the HS38
core. I'm somewhat surprised that a single ARC toolchain cannot produce
code for both 770 and HS38, but it seems to be the case.

So you need a separate toolchain for ARC770.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27  7:07                 ` Thomas Petazzoni
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-27  7:07 UTC (permalink / raw)
  To: linux-snps-arc

Hello,

On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:

> > Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> >
> > Anyways if something very simple (i.e. with no extra libraries) works for you just go
> > ahead and grab pre-built image that Thomas Petazzoni builds.
> >
> > That's the most recent one:
> > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2  
> 
> Thanks, I grabbed that and it works for axs103_smp_defconfig:
> 
>   http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> 
> 
> It doesn't work for axs101_defconfig, saying:
> 
>   arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.

axs101 is using a 770 core, while the toolchain is built for the HS38
core. I'm somewhat surprised that a single ARC toolchain cannot produce
code for both 770 and HS38, but it seems to be the case.

So you need a separate toolchain for ARC770.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  7:07                 ` Thomas Petazzoni
@ 2016-10-27  9:07                   ` Alexey Brodkin
  -1 siblings, 0 replies; 35+ messages in thread
From: Alexey Brodkin @ 2016-10-27  9:07 UTC (permalink / raw)
  To: mpe, thomas.petazzoni
  Cc: linux-snps-arc, linux-kernel, peterz, Vineet.Gupta1, arnd, geert, mmarek

Hi Thomas, Michael,

On Thu, 2016-10-27 at 09:07 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:
> 
> > 
> > > 
> > > Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> > > 
> > > Anyways if something very simple (i.e. with no extra libraries) works for you just go
> > > ahead and grab pre-built image that Thomas Petazzoni builds.
> > > 
> > > That's the most recent one:
> > > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2  
> > 
> > Thanks, I grabbed that and it works for axs103_smp_defconfig:
> > 
> >   http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> > 
> > 
> > It doesn't work for axs101_defconfig, saying:
> > 
> >   arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  Stop.
> 
> axs101 is using a 770 core, while the toolchain is built for the HS38
> core. I'm somewhat surprised that a single ARC toolchain cannot produce
> code for both 770 and HS38, but it seems to be the case.
> 
> So you need a separate toolchain for ARC770.

Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
which has ARCv2 ISA (binary incompatible with ARCompact).

Essentially both gcc and binutils will happily build for both architectures given
proper options were passed on the command line. But Linux kernel gets linked with
pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
to have multilibbed uClibc toolchain. Which we don't have.

I think we discussed it a couple of times already and probably at some point will have it
but for now we have to use 2 different toolchains for ARCompact and ARCv2 cores.

I hope explanation above makes some sense.

-Alexey

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27  9:07                   ` Alexey Brodkin
  0 siblings, 0 replies; 35+ messages in thread
From: Alexey Brodkin @ 2016-10-27  9:07 UTC (permalink / raw)
  To: linux-snps-arc

Hi Thomas, Michael,

On Thu, 2016-10-27@09:07 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:
> 
> > 
> > > 
> > > Hm... that's strange - it used to work but doesn't work with newer Buildroot...
> > > 
> > > Anyways if something very simple (i.e. with no extra libraries) works for you just go
> > > ahead and grab pre-built image that Thomas Petazzoni builds.
> > > 
> > > That's the most recent one:
> > > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2??
> > 
> > Thanks, I grabbed that and it works for axs103_smp_defconfig:
> > 
> > ? http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> > 
> > 
> > It doesn't work for axs101_defconfig, saying:
> > 
> > ? arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.??Stop.
> 
> axs101 is using a 770 core, while the toolchain is built for the HS38
> core. I'm somewhat surprised that a single ARC toolchain cannot produce
> code for both 770 and HS38, but it seems to be the case.
> 
> So you need a separate toolchain for ARC770.

Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
which has ARCv2 ISA (binary incompatible with ARCompact).

Essentially both gcc and binutils will happily build for both architectures given
proper options were passed on the command line. But Linux kernel gets linked with
pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
to have multilibbed uClibc toolchain. Which we don't have.

I think we discussed it a couple of times already and probably at some point will have it
but for now we have to use 2 different toolchains for ARCompact and ARCv2 cores.

I hope explanation above makes some sense.

-Alexey

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  9:07                   ` Alexey Brodkin
@ 2016-10-27  9:11                     ` Thomas Petazzoni
  -1 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-27  9:11 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: mpe, linux-snps-arc, linux-kernel, peterz, Vineet.Gupta1, arnd,
	geert, mmarek

Hello,

On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:

> > axs101 is using a 770 core, while the toolchain is built for the HS38
> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > code for both 770 and HS38, but it seems to be the case.
> > 
> > So you need a separate toolchain for ARC770.  
> 
> Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> which has ARCv2 ISA (binary incompatible with ARCompact).
> 
> Essentially both gcc and binutils will happily build for both architectures given
> proper options were passed on the command line. But Linux kernel gets linked with
> pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> to have multilibbed uClibc toolchain. Which we don't have.

Interesting. Why is libgcc linked with the kernel on ARC? I don't think
that's the case on other architectures: the kernel is freestanding and
provides everything that it needs without relying on the compiler
runtime.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27  9:11                     ` Thomas Petazzoni
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-27  9:11 UTC (permalink / raw)
  To: linux-snps-arc

Hello,

On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:

> > axs101 is using a 770 core, while the toolchain is built for the HS38
> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > code for both 770 and HS38, but it seems to be the case.
> > 
> > So you need a separate toolchain for ARC770.  
> 
> Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> which has ARCv2 ISA (binary incompatible with ARCompact).
> 
> Essentially both gcc and binutils will happily build for both architectures given
> proper options were passed on the command line. But Linux kernel gets linked with
> pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> to have multilibbed uClibc toolchain. Which we don't have.

Interesting. Why is libgcc linked with the kernel on ARC? I don't think
that's the case on other architectures: the kernel is freestanding and
provides everything that it needs without relying on the compiler
runtime.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  9:11                     ` Thomas Petazzoni
@ 2016-10-27  9:24                       ` Geert Uytterhoeven
  -1 siblings, 0 replies; 35+ messages in thread
From: Geert Uytterhoeven @ 2016-10-27  9:24 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Alexey Brodkin, mpe, linux-snps-arc, linux-kernel, peterz,
	Vineet.Gupta1, arnd, mmarek

On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
>
>> > axs101 is using a 770 core, while the toolchain is built for the HS38
>> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
>> > code for both 770 and HS38, but it seems to be the case.
>> >
>> > So you need a separate toolchain for ARC770.
>>
>> Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
>> axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
>> which has ARCv2 ISA (binary incompatible with ARCompact).
>>
>> Essentially both gcc and binutils will happily build for both architectures given
>> proper options were passed on the command line. But Linux kernel gets linked with
>> pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
>> to have multilibbed uClibc toolchain. Which we don't have.
>
> Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> that's the case on other architectures: the kernel is freestanding and
> provides everything that it needs without relying on the compiler
> runtime.

ARC is not the only one:

$ git grep print-libgcc-file-name
arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell
$(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS)
$(KCFLAGS) -print-libgcc-file-name)
arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/tile/Makefile:  $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS)
-print-libgcc-file-name)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC)
$(KBUILD_CFLAGS) -print-libgcc-file-name)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27  9:24                       ` Geert Uytterhoeven
  0 siblings, 0 replies; 35+ messages in thread
From: Geert Uytterhoeven @ 2016-10-27  9:24 UTC (permalink / raw)
  To: linux-snps-arc

On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
>
>> > axs101 is using a 770 core, while the toolchain is built for the HS38
>> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
>> > code for both 770 and HS38, but it seems to be the case.
>> >
>> > So you need a separate toolchain for ARC770.
>>
>> Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
>> axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
>> which has ARCv2 ISA (binary incompatible with ARCompact).
>>
>> Essentially both gcc and binutils will happily build for both architectures given
>> proper options were passed on the command line. But Linux kernel gets linked with
>> pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
>> to have multilibbed uClibc toolchain. Which we don't have.
>
> Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> that's the case on other architectures: the kernel is freestanding and
> provides everything that it needs without relying on the compiler
> runtime.

ARC is not the only one:

$ git grep print-libgcc-file-name
arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell
$(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS)
$(KCFLAGS) -print-libgcc-file-name)
arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/tile/Makefile:  $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS)
-print-libgcc-file-name)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
-print-libgcc-file-name)
arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC)
$(KBUILD_CFLAGS) -print-libgcc-file-name)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  9:11                     ` Thomas Petazzoni
@ 2016-10-27  9:32                       ` Arnd Bergmann
  -1 siblings, 0 replies; 35+ messages in thread
From: Arnd Bergmann @ 2016-10-27  9:32 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Alexey Brodkin, mpe, linux-snps-arc, linux-kernel, peterz,
	Vineet.Gupta1, geert, mmarek

On Thursday, October 27, 2016 11:11:18 AM CEST Thomas Petazzoni wrote:
> On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
> 
> > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > code for both 770 and HS38, but it seems to be the case.
> > > 
> > > So you need a separate toolchain for ARC770.  
> > 
> > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> > which has ARCv2 ISA (binary incompatible with ARCompact).
> > 
> > Essentially both gcc and binutils will happily build for both architectures given
> > proper options were passed on the command line. But Linux kernel gets linked with
> > pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> > to have multilibbed uClibc toolchain. Which we don't have.
> 
> Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> that's the case on other architectures: the kernel is freestanding and
> provides everything that it needs without relying on the compiler
> runtime.

A couple of other architectures do this as well:

$ git grep -w LIBGCC arch/*/Makefile
arch/arc/Makefile:LIBGCC        := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
arch/arc/Makefile:libs-y                += arch/arc/lib/ $(LIBGCC)
arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
arch/cris/Makefile:libs-y               += arch/cris/$(SARCH)/lib/ $(LIBGCC)
arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/hexagon/Makefile:libs-y += $(LIBGCC)
arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/m32r/Makefile:libs-y       += arch/m32r/lib/ $(LIBGCC)
arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
arch/nios2/Makefile:libs-y              += arch/nios2/lib/ $(LIBGCC)
arch/openrisc/Makefile:LIBGCC           := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/openrisc/Makefile:libs-y           += $(LIBGCC)
arch/parisc/Makefile:LIBGCC             = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/parisc/Makefile:libs-y     += arch/parisc/lib/ $(LIBGCC)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/xtensa/Makefile:libs-y             += arch/xtensa/lib/ $(LIBGCC)

It's also not always freestanding on the architectures that don't
include libgcc:

$ git grep ffreestanding arch/
arch/mips/Makefile:cflags-y += -ffreestanding
arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
arch/sh/Makefile:cflags-y       += $(isaflags-y) -ffreestanding
arch/x86/Makefile:        KBUILD_CFLAGS += -ffreestanding # temporary until string.h is fixed
arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__

(xtensa being the only one that apparently uses libgcc *and* passes
 -ffreestanding, for whatever reasons).

The other architectures tend to implement the parts of libgcc that they
need in the kernel.

	Arnd

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27  9:32                       ` Arnd Bergmann
  0 siblings, 0 replies; 35+ messages in thread
From: Arnd Bergmann @ 2016-10-27  9:32 UTC (permalink / raw)
  To: linux-snps-arc

On Thursday, October 27, 2016 11:11:18 AM CEST Thomas Petazzoni wrote:
> On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
> 
> > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > code for both 770 and HS38, but it seems to be the case.
> > > 
> > > So you need a separate toolchain for ARC770.  
> > 
> > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> > which has ARCv2 ISA (binary incompatible with ARCompact).
> > 
> > Essentially both gcc and binutils will happily build for both architectures given
> > proper options were passed on the command line. But Linux kernel gets linked with
> > pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> > to have multilibbed uClibc toolchain. Which we don't have.
> 
> Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> that's the case on other architectures: the kernel is freestanding and
> provides everything that it needs without relying on the compiler
> runtime.

A couple of other architectures do this as well:

$ git grep -w LIBGCC arch/*/Makefile
arch/arc/Makefile:LIBGCC        := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
arch/arc/Makefile:libs-y                += arch/arc/lib/ $(LIBGCC)
arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
arch/cris/Makefile:libs-y               += arch/cris/$(SARCH)/lib/ $(LIBGCC)
arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/hexagon/Makefile:libs-y += $(LIBGCC)
arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/m32r/Makefile:libs-y       += arch/m32r/lib/ $(LIBGCC)
arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
arch/nios2/Makefile:libs-y              += arch/nios2/lib/ $(LIBGCC)
arch/openrisc/Makefile:LIBGCC           := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/openrisc/Makefile:libs-y           += $(LIBGCC)
arch/parisc/Makefile:LIBGCC             = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/parisc/Makefile:libs-y     += arch/parisc/lib/ $(LIBGCC)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
arch/xtensa/Makefile:libs-y             += arch/xtensa/lib/ $(LIBGCC)

It's also not always freestanding on the architectures that don't
include libgcc:

$ git grep ffreestanding arch/
arch/mips/Makefile:cflags-y += -ffreestanding
arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
arch/sh/Makefile:cflags-y       += $(isaflags-y) -ffreestanding
arch/x86/Makefile:        KBUILD_CFLAGS += -ffreestanding # temporary until string.h is fixed
arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__

(xtensa being the only one that apparently uses libgcc *and* passes
 -ffreestanding, for whatever reasons).

The other architectures tend to implement the parts of libgcc that they
need in the kernel.

	Arnd

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  9:24                       ` Geert Uytterhoeven
@ 2016-10-27  9:39                         ` Alexey Brodkin
  -1 siblings, 0 replies; 35+ messages in thread
From: Alexey Brodkin @ 2016-10-27  9:39 UTC (permalink / raw)
  To: thomas.petazzoni
  Cc: linux-kernel, peterz, mmarek, Vineet.Gupta1, linux-snps-arc,
	arnd, geert, mpe

Hi Thomas,

On Thu, 2016-10-27 at 11:24 +0200, Geert Uytterhoeven wrote:
> On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > 
> > On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > > code for both 770 and HS38, but it seems to be the case.
> > > > 
> > > > So you need a separate toolchain for ARC770.
> > > 
> > > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> > > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> > > which has ARCv2 ISA (binary incompatible with ARCompact).
> > > 
> > > Essentially both gcc and binutils will happily build for both architectures given
> > > proper options were passed on the command line. But Linux kernel gets linked with
> > > pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> > > to have multilibbed uClibc toolchain. Which we don't have.
> > 
> > Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> > that's the case on other architectures: the kernel is freestanding and
> > provides everything that it needs without relying on the compiler
> > runtime.
> 
> ARC is not the only one:
> 
> $ git grep print-libgcc-file-name
> arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
> arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell
> $(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS)
> $(KCFLAGS) -print-libgcc-file-name)
> arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/tile/Makefile:  $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS)
> -print-libgcc-file-name)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC)
> $(KBUILD_CFLAGS) -print-libgcc-file-name)

Right.

I'm not 100% sure about all the details in case of Linux kernel on ARC
but I actually implemented decoupling from libgcc in U-Boot for ARC.
And from that experience I know what was required out of libgcc, see
http://git.denx.de/?p=u-boot.git;a=patch;h=a67ef280f46803e319639f5380ff8da6c6b7fbe7

And these are functions required by U-Boot (most probably the same is applied to kernel):
1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX
2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3

Indeed it is possible to have so-called private libgcc in kernel as well but
benefit will be only for people building kernels but not user-space because
in absence of multilibbed toolchain 2 separate toolchains will be required anyways.

Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
sync with the one from gcc.

-Alexey

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27  9:39                         ` Alexey Brodkin
  0 siblings, 0 replies; 35+ messages in thread
From: Alexey Brodkin @ 2016-10-27  9:39 UTC (permalink / raw)
  To: linux-snps-arc

Hi Thomas,

On Thu, 2016-10-27@11:24 +0200, Geert Uytterhoeven wrote:
> On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > 
> > On Thu, 27 Oct 2016 09:07:55 +0000, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > > code for both 770 and HS38, but it seems to be the case.
> > > > 
> > > > So you need a separate toolchain for ARC770.
> > > 
> > > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
> > > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
> > > which has ARCv2 ISA (binary incompatible with ARCompact).
> > > 
> > > Essentially both gcc and binutils will happily build for both architectures given
> > > proper options were passed on the command line. But Linux kernel gets linked with
> > > pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement
> > > to have multilibbed uClibc toolchain. Which we don't have.
> > 
> > Interesting. Why is libgcc linked with the kernel on ARC? I don't think
> > that's the case on other architectures: the kernel is freestanding and
> > provides everything that it needs without relying on the compiler
> > runtime.
> 
> ARC is not the only one:
> 
> $ git grep print-libgcc-file-name
> arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
> arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell
> $(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/nios2/Makefile:LIBGCC?????????:= $(shell $(CC) $(KBUILD_CFLAGS)
> $(KCFLAGS) -print-libgcc-file-name)
> arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/tile/Makefile:??$(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS)
> -print-libgcc-file-name)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS)
> -print-libgcc-file-name)
> arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC)
> $(KBUILD_CFLAGS) -print-libgcc-file-name)

Right.

I'm not 100% sure about all the details in case of Linux kernel on ARC
but I actually implemented decoupling from libgcc in U-Boot for ARC.
And from that experience I know what was required out of libgcc, see
http://git.denx.de/?p=u-boot.git;a=patch;h=a67ef280f46803e319639f5380ff8da6c6b7fbe7

And these are functions required by U-Boot (most probably the same is applied to kernel):
1) so-called millicode, stuff like?__ld_rX_to_rY,?__st_rX_to_rX
2) shifts: __ashldi3,?__ashrdi3,?__lshrdi3,?
3) divisions:?udivmodsi4,?__divsi3,?__modsi3,?__udivsi3,?__umodsi3

Indeed it is possible to have so-called private libgcc in kernel as well but
benefit will be only for people building kernels but not user-space because
in absence of multilibbed toolchain 2 separate toolchains will be required anyways.

Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
sync with the one from gcc.

-Alexey

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  9:32                       ` Arnd Bergmann
@ 2016-10-27 10:04                         ` Thomas Petazzoni
  -1 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-27 10:04 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Alexey Brodkin, mpe, linux-snps-arc, linux-kernel, peterz,
	Vineet.Gupta1, geert, mmarek

Hello,

On Thu, 27 Oct 2016 11:32:11 +0200, Arnd Bergmann wrote:

> A couple of other architectures do this as well:
> 
> $ git grep -w LIBGCC arch/*/Makefile
> arch/arc/Makefile:LIBGCC        := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
> arch/arc/Makefile:libs-y                += arch/arc/lib/ $(LIBGCC)
> arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
> arch/cris/Makefile:libs-y               += arch/cris/$(SARCH)/lib/ $(LIBGCC)
> arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/hexagon/Makefile:libs-y += $(LIBGCC)
> arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/m32r/Makefile:libs-y       += arch/m32r/lib/ $(LIBGCC)
> arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
> arch/nios2/Makefile:libs-y              += arch/nios2/lib/ $(LIBGCC)
> arch/openrisc/Makefile:LIBGCC           := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/openrisc/Makefile:libs-y           += $(LIBGCC)
> arch/parisc/Makefile:LIBGCC             = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/parisc/Makefile:libs-y     += arch/parisc/lib/ $(LIBGCC)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/xtensa/Makefile:libs-y             += arch/xtensa/lib/ $(LIBGCC)
> 
> It's also not always freestanding on the architectures that don't
> include libgcc:
> 
> $ git grep ffreestanding arch/
> arch/mips/Makefile:cflags-y += -ffreestanding
> arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
> arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
> arch/sh/Makefile:cflags-y       += $(isaflags-y) -ffreestanding
> arch/x86/Makefile:        KBUILD_CFLAGS += -ffreestanding # temporary until string.h is fixed
> arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
> 
> (xtensa being the only one that apparently uses libgcc *and* passes
>  -ffreestanding, for whatever reasons).
> 
> The other architectures tend to implement the parts of libgcc that they
> need in the kernel.

Thanks for the details, good to know!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27 10:04                         ` Thomas Petazzoni
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Petazzoni @ 2016-10-27 10:04 UTC (permalink / raw)
  To: linux-snps-arc

Hello,

On Thu, 27 Oct 2016 11:32:11 +0200, Arnd Bergmann wrote:

> A couple of other architectures do this as well:
> 
> $ git grep -w LIBGCC arch/*/Makefile
> arch/arc/Makefile:LIBGCC        := $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
> arch/arc/Makefile:libs-y                += arch/arc/lib/ $(LIBGCC)
> arch/cris/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
> arch/cris/Makefile:libs-y               += arch/cris/$(SARCH)/lib/ $(LIBGCC)
> arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/hexagon/Makefile:libs-y += $(LIBGCC)
> arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/m32r/Makefile:libs-y       += arch/m32r/lib/ $(LIBGCC)
> arch/nios2/Makefile:LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
> arch/nios2/Makefile:libs-y              += arch/nios2/lib/ $(LIBGCC)
> arch/openrisc/Makefile:LIBGCC           := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/openrisc/Makefile:libs-y           += $(LIBGCC)
> arch/parisc/Makefile:LIBGCC             = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/parisc/Makefile:libs-y     += arch/parisc/lib/ $(LIBGCC)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> arch/xtensa/Makefile:libs-y             += arch/xtensa/lib/ $(LIBGCC)
> 
> It's also not always freestanding on the architectures that don't
> include libgcc:
> 
> $ git grep ffreestanding arch/
> arch/mips/Makefile:cflags-y += -ffreestanding
> arch/s390/boot/compressed/Makefile:KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
> arch/score/Makefile:    -D__linux__ -ffunction-sections -ffreestanding
> arch/sh/Makefile:cflags-y       += $(isaflags-y) -ffreestanding
> arch/x86/Makefile:        KBUILD_CFLAGS += -ffreestanding # temporary until string.h is fixed
> arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
> 
> (xtensa being the only one that apparently uses libgcc *and* passes
>  -ffreestanding, for whatever reasons).
> 
> The other architectures tend to implement the parts of libgcc that they
> need in the kernel.

Thanks for the details, good to know!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27  9:39                         ` Alexey Brodkin
@ 2016-10-27 17:21                           ` Vineet Gupta
  -1 siblings, 0 replies; 35+ messages in thread
From: Vineet Gupta @ 2016-10-27 17:21 UTC (permalink / raw)
  To: Alexey Brodkin, thomas.petazzoni
  Cc: mmarek, arnd, peterz, mpe, Claudiu Zissulescu, linux-kernel,
	geert, linux-snps-arc

+CC Claudiu

On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
>
> And these are functions required by U-Boot (most probably the same is applied to kernel):
> 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX

This kicks in only at -Os and even there can be inhibited with a toggle.
I don't like it anyways, seems like a costly contraption in terms of microarch
cost of 2 extra long branches for both prologue and epilogue.

> 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
> 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3

Note that this list is not constant. I recently had to export another libgcc
symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly
building the same kernel code.

> Indeed it is possible to have so-called private libgcc in kernel as well but
> benefit will be only for people building kernels but not user-space because
> in absence of multilibbed toolchain 2 separate toolchains will be required anyways.

True, but a lot of people only care about builds (and not actually run), so for
them having to carry only one toolchain is an improvement.

> Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
> sync with the one from gcc.

True, but libgcc math emulation is likely one off thing. GNU folks will write them
once and we use a snapshot - syncing back changes - if any around major gnu releases.

So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know
of any potential licensing issues ?

-Vineet

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-27 17:21                           ` Vineet Gupta
  0 siblings, 0 replies; 35+ messages in thread
From: Vineet Gupta @ 2016-10-27 17:21 UTC (permalink / raw)
  To: linux-snps-arc

+CC Claudiu

On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
>
> And these are functions required by U-Boot (most probably the same is applied to kernel):
> 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX

This kicks in only at -Os and even there can be inhibited with a toggle.
I don't like it anyways, seems like a costly contraption in terms of microarch
cost of 2 extra long branches for both prologue and epilogue.

> 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
> 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3

Note that this list is not constant. I recently had to export another libgcc
symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly
building the same kernel code.

> Indeed it is possible to have so-called private libgcc in kernel as well but
> benefit will be only for people building kernels but not user-space because
> in absence of multilibbed toolchain 2 separate toolchains will be required anyways.

True, but a lot of people only care about builds (and not actually run), so for
them having to carry only one toolchain is an improvement.

> Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
> sync with the one from gcc.

True, but libgcc math emulation is likely one off thing. GNU folks will write them
once and we use a snapshot - syncing back changes - if any around major gnu releases.

So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know
of any potential licensing issues ?

-Vineet

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

* Re: Build regressions/improvements in v4.9-rc1
  2016-10-27 17:21                           ` Vineet Gupta
@ 2016-10-28 10:42                             ` Arnd Bergmann
  -1 siblings, 0 replies; 35+ messages in thread
From: Arnd Bergmann @ 2016-10-28 10:42 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Alexey Brodkin, thomas.petazzoni, mmarek, peterz, mpe,
	Claudiu Zissulescu, linux-kernel, geert, linux-snps-arc

On Thursday, October 27, 2016 10:21:16 AM CEST Vineet Gupta wrote:
> 
> On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
> >
> > And these are functions required by U-Boot (most probably the same is applied to kernel):
> > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX
> 
> This kicks in only at -Os and even there can be inhibited with a toggle.
> I don't like it anyways, seems like a costly contraption in terms of microarch
> cost of 2 extra long branches for both prologue and epilogue.
> 
> > 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
> > 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3
> 
> Note that this list is not constant. I recently had to export another libgcc
> symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly
> building the same kernel code.
> 
> > Indeed it is possible to have so-called private libgcc in kernel as well but
> > benefit will be only for people building kernels but not user-space because
> > in absence of multilibbed toolchain 2 separate toolchains will be required anyways.
> 
> True, but a lot of people only care about builds (and not actually run), so for
> them having to carry only one toolchain is an improvement.
> 
> > Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
> > sync with the one from gcc.
> 
> True, but libgcc math emulation is likely one off thing. GNU folks will write them
> once and we use a snapshot - syncing back changes - if any around major gnu releases.
> 
> So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know
> of any potential licensing issues ?
> 

I'd be surprised if there were any licensing issues, as libgcc is intentionally
meant to be included in everything built by gcc, and the architectures that don't
link against it tend to have a direct copy.

The main advantage of copying libgcc sources into the kernel instead of linking
directly to it is probably that you have better control over which functions
are actually used, as not everything in libgcc makes sense in kernel space.

The most common example is probably the 64-bit division, which is a libgcc
function on most architectures, and in the kernel we intentionally don't
implement that function in order to catch drivers trying to do that (and
change them to either explicit div_u64() or not do a 64-bit division).

Another example of a libgcc function you don't want is anything calling
abort(), which makes no sense in the kernel.

	Arnd

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

* Build regressions/improvements in v4.9-rc1
@ 2016-10-28 10:42                             ` Arnd Bergmann
  0 siblings, 0 replies; 35+ messages in thread
From: Arnd Bergmann @ 2016-10-28 10:42 UTC (permalink / raw)
  To: linux-snps-arc

On Thursday, October 27, 2016 10:21:16 AM CEST Vineet Gupta wrote:
> 
> On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
> >
> > And these are functions required by U-Boot (most probably the same is applied to kernel):
> > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX
> 
> This kicks in only at -Os and even there can be inhibited with a toggle.
> I don't like it anyways, seems like a costly contraption in terms of microarch
> cost of 2 extra long branches for both prologue and epilogue.
> 
> > 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 
> > 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3
> 
> Note that this list is not constant. I recently had to export another libgcc
> symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly
> building the same kernel code.
> 
> > Indeed it is possible to have so-called private libgcc in kernel as well but
> > benefit will be only for people building kernels but not user-space because
> > in absence of multilibbed toolchain 2 separate toolchains will be required anyways.
> 
> True, but a lot of people only care about builds (and not actually run), so for
> them having to carry only one toolchain is an improvement.
> 
> > Still we'll have to pay an additional maintenance price to keep kernel's libgcc in
> > sync with the one from gcc.
> 
> True, but libgcc math emulation is likely one off thing. GNU folks will write them
> once and we use a snapshot - syncing back changes - if any around major gnu releases.
> 
> So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know
> of any potential licensing issues ?
> 

I'd be surprised if there were any licensing issues, as libgcc is intentionally
meant to be included in everything built by gcc, and the architectures that don't
link against it tend to have a direct copy.

The main advantage of copying libgcc sources into the kernel instead of linking
directly to it is probably that you have better control over which functions
are actually used, as not everything in libgcc makes sense in kernel space.

The most common example is probably the 64-bit division, which is a libgcc
function on most architectures, and in the kernel we intentionally don't
implement that function in order to catch drivers trying to do that (and
change them to either explicit div_u64() or not do a 64-bit division).

Another example of a libgcc function you don't want is anything calling
abort(), which makes no sense in the kernel.

	Arnd

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

end of thread, other threads:[~2016-10-28 10:43 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-17  7:21 Build regressions/improvements in v4.9-rc1 Geert Uytterhoeven
2016-10-17  7:34 ` Geert Uytterhoeven
2016-10-17  7:34   ` Geert Uytterhoeven
2016-10-17 16:59   ` Vineet Gupta
2016-10-17 16:59     ` Vineet Gupta
2016-10-17 21:02     ` Arnd Bergmann
2016-10-17 21:02       ` Arnd Bergmann
2016-10-17 22:37       ` Vineet Gupta
2016-10-17 22:37         ` Vineet Gupta
2016-10-19 11:50         ` Michael Ellerman
2016-10-19 11:50           ` Michael Ellerman
2016-10-19 12:23           ` Alexey Brodkin
2016-10-19 12:23             ` Alexey Brodkin
2016-10-19 20:32             ` Thomas Petazzoni
2016-10-19 20:32               ` Thomas Petazzoni
2016-10-26 23:56             ` Michael Ellerman
2016-10-26 23:56               ` Michael Ellerman
2016-10-27  7:07               ` Thomas Petazzoni
2016-10-27  7:07                 ` Thomas Petazzoni
2016-10-27  9:07                 ` Alexey Brodkin
2016-10-27  9:07                   ` Alexey Brodkin
2016-10-27  9:11                   ` Thomas Petazzoni
2016-10-27  9:11                     ` Thomas Petazzoni
2016-10-27  9:24                     ` Geert Uytterhoeven
2016-10-27  9:24                       ` Geert Uytterhoeven
2016-10-27  9:39                       ` Alexey Brodkin
2016-10-27  9:39                         ` Alexey Brodkin
2016-10-27 17:21                         ` Vineet Gupta
2016-10-27 17:21                           ` Vineet Gupta
2016-10-28 10:42                           ` Arnd Bergmann
2016-10-28 10:42                             ` Arnd Bergmann
2016-10-27  9:32                     ` Arnd Bergmann
2016-10-27  9:32                       ` Arnd Bergmann
2016-10-27 10:04                       ` Thomas Petazzoni
2016-10-27 10:04                         ` Thomas Petazzoni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.