Re: Can someone explain containers, pods, docker, etc. please
On 2024-11-08 16:51, Chris Green wrote: Well, yes, it sounds like it doesn't it. However, apparently, there are various things that prevent one from creating a python 2.x virtual environment on a system that has only Python 3. Not to be a bother, but did you look into pyenv en pyenv-installer?
Re: [PATCH v2] testsuite: arm: Use check-function-bodies in epilog-1.c test
On 08/11/2024 12:12, Torbjorn SVENSSON wrote: On 2024-11-08 11:33, Richard Earnshaw (lists) wrote: On 08/11/2024 08:54, Torbjörn SVENSSON wrote: Changes since v1: - Added generated assembler in commit message. - Added comments in test case when each block is relevant. Ok for trunk and
Re: [PATCH] testsuite: arm: Update expected asm in no-literal-pool-m0.c
On 14/10/2024 16:28, Christophe Lyon wrote: On 10/14/24 16:40, Torbjorn SVENSSON wrote: Hi Christophe, On 2024-10-14 14:16, Christophe Lyon wrote: Hi Torbjörn, On 10/13/24 19:37, Torbjörn SVENSSON wrote: Ok for trunk? -- With the changes in r15-1579-g792f97b44ff, the constants have been
Re: Can someone explain containers, pods, docker, etc. please
On 2024-11-08 13:57, Chris Green wrote: songbird wrote: Chris Green wrote: songbird wrote: Chris Green wrote: ... i haven't needed them and also haven't gotten into them. I'm particularly interested in a way to run (say) Debian Bullseye within my Debian Bookworm system. I'm looking f
Re: [PATCH v2] testsuite: arm: Use effective-target for pr84556.cc test
On 08/11/2024 11:48, Torbjörn SVENSSON wrote: Changes since v1: - Clarified the commit message to include where the descision is taken and why it's a bad idea to use "dg-do run" in a test case. Note: This does not only fix it for arm-none-eabi. I see the same kind of construct used by f
Re: [PATCH] testsuite: arm: Require 16-bit float support
On 05/11/2024 20:06, Torbjörn SVENSSON wrote: Based on how these functions are used in test cases, I think it's correct to require 16-bit float support in both functions. Without this change, the checks passes for armv8-m and armv8.1-m, but the test cases that uses them fails due to the incorrec
Re: [PATCH] testsuite: arm: Use effective-target for pr84556.cc test
On 06/11/2024 09:39, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-14? -- Using "dg-do run" with a selector breaks testing arm-none-eabi for any architecture when check_effective_target_arm_neon_hw returns 0. gcc/testsuite/ChangeLog: * g++.dg/vect/pr84556.cc: Change from "dg-
Re: [PATCH] testsuite: arm: Allow vst1.32 instruction in pr40457-2.c
On 07/11/2024 17:15, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-14? -- When building the test case with neon, the 'vst1.32' instruction is used instead of 'strd'. Allow both variants to make the test pass. gcc/testsuite/ChangeLog: * gcc.target/arm/pr40457-2.c: Add vst1.32
Re: [PATCH v2] testsuite: arm: Use effective-target arm_libc_fp_abi for pr68620.c test
On 07/11/2024 17:48, Torbjörn SVENSSON wrote: Changes since v1: - Switch to arm_libc_fp_abi from arm_fp @Christophe, can you test this patch in the linaro farm to ensure that it does not fail again? Ok for trunk and releases/gcc-14? -- This fixes reported regression at https://linaro.atlassi
Re: [PATCH v2] testsuite: arm: Use check-function-bodies in epilog-1.c test
On 08/11/2024 08:54, Torbjörn SVENSSON wrote: Changes since v1: - Added generated assembler in commit message. - Added comments in test case when each block is relevant. Ok for trunk and releases/gcc-14? This is OK. I'm not sure how useful this test really is (the mailing list history sugg
Re: [PATCH] testsuite: arm: Use effective-target arm_fp for pr68620.c test
On 06/11/2024 19:50, Torbjorn SVENSSON wrote: > > > On 2024-11-06 19:06, Richard Earnshaw (lists) wrote: >> On 06/11/2024 13:50, Torbjorn SVENSSON wrote: >>> >>> >>> On 2024-11-06 14:04, Richard Earnshaw (lists) wrote: >>>> On 06/11/2024 12:
Re: [PRQ#65428] Orphan Request for prismlauncher-qt5-bin
This package hasn't been updated because the release asset that it depended on has been discontinued. Use prismlauncher[0] from the official Arch repos instead. [0]: https://archlinux.org/packages/extra/x86_64/prismlauncher/ -- txtsd https://ihavea.quest On 11/7/24 1:57 AM, not...@aur.archlin
Re: [PATCH] testsuite: arm: Use effective-target arm_fp for pr68620.c test
On 06/11/2024 13:50, Torbjorn SVENSSON wrote: > > > On 2024-11-06 14:04, Richard Earnshaw (lists) wrote: >> On 06/11/2024 12:23, Torbjorn SVENSSON wrote: >>> >>> >>> On 2024-11-06 12:26, Richard Earnshaw (lists) wrote: >>>> On 06/11/2024 07:
Re: [PATCH] testsuite: arm: Use effective-target arm_fp for pr68620.c test
On 06/11/2024 12:23, Torbjorn SVENSSON wrote: > > > On 2024-11-06 12:26, Richard Earnshaw (lists) wrote: >> On 06/11/2024 07:44, Christophe Lyon wrote: >>> On Wed, 6 Nov 2024 at 07:20, Torbjörn SVENSSON >>> wrote: >>>> >>>> While
Re: [PATCH v2] testsuite: arm: Use effective-target for attr-neon* tests
On 05/11/2024 20:28, Torbjörn SVENSSON wrote: > Changes since v1: > > - Changed from arm_neon to arm_arch_v7a for the required effective target. > > Ok for trunk and releases/gcc-14? > > -- > > Force armv7-a as the tests require a neon compatible architecture. > > gcc/testsuite/ChangeLog: > >
Re: [emacs-tangents] 2024-11-04 Emacs news
2024-11-06
Thread
James Thomas via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists
Sacha Chua wrote: > * Marcin Borkowski: Persisting variables across Emacs sessions >> the persist package There's (info "(elisp) Multisession Variables"). > * Irreal: TSV To Table Honourable mention: 'yank' in (info "(ses) Copy/cut/paste"). > * Creating Info Manuals And Adding Them Into Ema
Re: [PATCH] testsuite: arm: Use effective-target arm_fp for pr68620.c test
On 06/11/2024 07:44, Christophe Lyon wrote: > On Wed, 6 Nov 2024 at 07:20, Torbjörn SVENSSON > wrote: >> >> While the regression was reported on GCC15, I'm sure that same >> regression will be seen on GCC14 when it's tested in the >> arm-linux-gnueabihf configuration. >> >> Ok for trunk and releas
Re: [PATCH v2] testsuite: arm: Use effective-target for pr68620 and pr78041 tests
On 05/11/2024 18:26, Torbjörn SVENSSON wrote: > Changes since v1: > > - Force arm_arch_v7a as a baseline for pr68620.c. > > Ok for trunk and releases/gcc-14? > > -- > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/pr68620.c: Use effective-target arm_neon. > * gcc.target/arm/pr7804
Re: [PATCH] testsuite: arm: Use effective-target for pr68620 and pr78041 tests
On 04/11/2024 20:34, Torbjorn SVENSSON wrote: > > > On 2024-11-04 17:03, Richard Earnshaw (lists) wrote: >> On 31/10/2024 18:26, Torbjörn SVENSSON wrote: >>> Ok for trunk and releases/gcc-14? >>> >>> -- >>> >>> Tests uses neon, so ad
Re: [PATCH] testsuite: arm: Use effective-target for attr-neon* tests
On 04/11/2024 20:14, Torbjorn SVENSSON wrote: > > > On 2024-11-04 16:47, Richard Earnshaw (lists) wrote: >> On 20/10/2024 16:51, Torbjörn SVENSSON wrote: >>> Ok for trunk and releases/gcc-14? >>> >>> -- >>> >>> The tests assume that
Re: [PATCH] testsuite: arm: Use effective-target for pr98636.c test
On 05/11/2024 07:49, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > The test case assumes that -mfp16-format=alternative is accepted for the > target, but not all targets support this flag. One such target is > Cortex-M85 that does support FP16, but not the alternative fo
Re: [PATCH] testsuite: arm: Use effective-target for pr68620 and pr78041 tests
On 31/10/2024 18:26, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > Tests uses neon, so add effective-target arm_neon. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/pr68620.c: Use effective-target arm_neon. > * gcc.target/arm/pr78041.c: Likewise. > > Si
Re: [PATCH] testsuite: arm: Force hard ABI for pr51534.c test
On 31/10/2024 18:24, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > The test case is written in a way that it should be using hard float > ABI, but the use of -mfloat-abi=hard could be overriden by > dg-add-options arm_neon. Ensure that -mfloat-abi=hard is always after. >
Re: [PATCH] testsuite: arm: Use effective-target for attr-neon* tests
On 20/10/2024 16:51, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > The tests assume that a neon fpu is avialable and fails it not, so > explicitly require it. > diff --git a/gcc/testsuite/gcc.target/arm/attr-neon2.c > b/gcc/testsuite/gcc.target/arm/attr-neon2.c > index
Re: [PATCH] testsuite: arm: Use effective-target for memset-inline* tests
On 04/11/2024 12:28, Torbjorn SVENSSON wrote: > > > On 2024-11-04 12:44, Richard Earnshaw (lists) wrote: >> On 01/11/2024 19:18, Torbjorn SVENSSON wrote: >>> >>> >>> On 2024-11-01 19:40, Richard Earnshaw (lists) wrote: >>>> On 24/10/2024
Re: [PATCH] testsuite: arm: Use effective-target for memset-inline* tests
On 01/11/2024 19:18, Torbjorn SVENSSON wrote: > > > On 2024-11-01 19:40, Richard Earnshaw (lists) wrote: >> On 24/10/2024 09:50, Torbjörn SVENSSON wrote: >>> Ok for trunk and releases/gcc-14? >>> >>> -- >>> >>> As these tests are se
Re: Memory alignment for arrays in GCC for ARM
On 02/11/2024 00:55, Oren Zvi via Gcc wrote: > Hi, > > Was wondering about a curious thing that the compiler does. > For the code > > static void createX() > { > static char ; > static uint8_t y; > > printf("%c %c\r\n", y, ); > } > > I am getting the following lines in the m
Re: [gentoo-user] format usb as ext4
On 04/11/2024 02:11, Matt Jolly wrote: Hi, On 4/11/24 09:35, Wol wrote: Seeing as it's removable media I would expect most of those to have problems if you DID have a partition table. It's linux that's unusual in being happy with a partition table on removable media. That is not the case
Re: [gentoo-user] Re: Firefox and clang
On 01/11/2024 17:50, Michael wrote: Thanks! From what I read briefly, I understand clang is recommended upstream and therefore was set as a default flag. However, a rust Vs rust-bin version clash can occur and since FF patched their code to work with gcc, setting clang as the default compiler i
Re: [arch-dev-public] [RFC] archweb nvchecker integration
I honestly interpreted archweb as aurweb, and thought this was about the AUR. -- txtsd https://ihavea.quest On 11/3/24 3:59 AM, Jelle van der Waa wrote: On 02-11-2024 11:15, lists.archlinux@ihavea.quest wrote: Has there been any update/activity in this regard? This was an excellent idea! A
Re: [gentoo-user] Portage improved
On 31/10/2024 11:56, Peter Humphrey wrote: the load steadies out at about 4, with several more in merge-wait. This is with i24 l30 in make.conf. How many cores does your CPU have. I've found that load is an approximation to "how many cores are running at 100%". It's very noticeable running x
Re: [arch-dev-public] [RFC] archweb nvchecker integration
Has there been any update/activity in this regard? This was an excellent idea! -- txtsd https://ihavea.quest On 2/1/22 1:55 AM, Jelle van der Waa wrote: We’ve wanted automatic flagging packages out of date for a while and currently every packager has to come up with it’s own solution. Let’s so
Re: [PATCH] testsuite: arm: Use effective-target for data-intrinsics-assembly test
On 19/10/2024 19:11, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > The expected assembler in the test case assumes -marm, so explicily > require it. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/acle/data-intrinsics-assembly.c: Use > effective-target ar
Re: [PATCH] testsuite: arm: Update expected asm in armv8_2-fp16-neon-2.c
On 24/10/2024 20:12, Torbjörn SVENSSON wrote: > Ok for trunk? > > -- > > With the changes in r15-1579-g792f97b44ff, the test_vmul_n_16x8 function > does not contain any vdup.16 q* r* instruction with -mfloat-abi=softfp. > > The differnce between r15-1578-g5185274c76c and r15-1579-g792f97b44ff >
Re: [PATCH] testsuite: arm: Use effective-target for memset-inline* tests
On 24/10/2024 09:50, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > As these tests are set to execute and require neon hardware to do so, > add the missing dg-require-effective-target arm_neon_hw. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/memset-inline-4.c
Re: [PATCH] testsuite: arm: Relax cbranch tests to accept inverted branches
On 19/10/2024 18:23, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > Similar to PR113502, but for non-aarch64 test. > The test started to fail after r14-7243-gafac1bd3365. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/vect-early-break-cbranch.c: Ignore exact >
Re: [PATCH v2] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
On 01/11/2024 11:22, Jakub Jelinek wrote: > On Fri, Nov 01, 2024 at 11:12:29AM +, Richard Earnshaw (lists) wrote: >> As Jakub said in the PR, this is really just papering over a general problem >> in the compiler. As such, it's OK for the gcc-14 branch, if we really
Re: [PATCH v2] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
On 18/10/2024 13:57, Andre Vieira (lists) wrote: > Hi, > > This looks like an acceptable work around. We special case behavior that I'm > not sure we can express in ways GCC can understand or will make use of, > whilst at the same time we keep expressing behavior it does u
Re: RFA: Deprecate the ARM simulator
On 01/11/2024 09:52, Nick Clifton wrote: > Hi Guys, > > I recently applied a patch to the top level configure script in the > binutils-gdb repository to deprecate the ARM simulator and I would > like to apply a similar one to the GCC repository so that the two > configure systems are kept
Re: libstdc++-v3: do not duplicate some math functions when using newlib
On 31/10/2024 08:23, Alexandre Oliva wrote: On Oct 25, 2024, "Andre Vieira (lists)" wrote: I have to admit I am not super familiar with long doubles, either than knowing they are 128-bit FP representations... but bisect has pointed me to this patch when investigating a reg
Re: libstdc++-v3: do not duplicate some math functions when using newlib
On 31/10/2024 08:23, Alexandre Oliva wrote: On Oct 25, 2024, "Andre Vieira (lists)" wrote: I have to admit I am not super familiar with long doubles, either than knowing they are 128-bit FP representations... but bisect has pointed me to this patch when investigating a reg
Re: [AFMUG] OTDR Recommendations
equipment looks interesting, but I have a feeling it isn't going to fit the budget. Plus I need something that can be portable.On Tuesday, October 29, 2024, Jeff Broadwick - Lists <jeffl...@att.net> wrote:> Adtran/ADVA’s ALM. >> Will work in any network.>> OTDR on steroids
Re: [AFMUG] OTDR Recommendations
Adtran/ADVA’s ALM. Will work in any network. OTDR on steroids. Regards, Jeff Jeff Broadwick CTIconnect 312-205-2519 Office 574-220-7826 Cell jbroadw...@cticonnect.com > On Oct 29, 2024, at 4:40 PM, Jason McKemie > wrote: > > Does anyone have any recommendations for an OTDR that won't b
[ceph-users] Ceph Crash Module "RADOS permission denied"
Hey Cephers, i was investigating some other issue, when I stumbled across this. I am not sure, if this is "as intended" or faulty. This is a cephadm cluster on reef 18.2.4, containerized with docker. The ceph-crash module states that it cant find its key and that it cant access RADOS. Pre-
Re: [emacs-tangents] 2024-10-28 Emacs news
2024-10-28
Thread
James Thomas via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists
Sacha Chua wrote: > * TheMKat: Read documentation from the comfort of Emacs - man-pages, > developer documentation and more >> Man-pages in Emacs >> .. >> tldr - More concise version of man-pages >> .. >> DevDocs - More long-form documentation The built-in info in better for the last one IMO,
arandr/xrandr only dectecting 1 of 2 amdgpu(4) video cards
Hello Everybody, On a system running -current with 2 video cards, I want to use arandr to configure grafically at least 10 monitors and because the "Option Rotate" settings in xorg.conf is not working. [25.614] (--) PCI:*(3@0:0:0) 1002:7312:1002:031e rev 0, Mem @ 0xa000/268435456, 0xb
Re: [PATCH v2 5/5] arm: [MVE intrinsics] Rework MVE vld/vst intrinsics
On 25/10/2024 19:47, Christophe Lyon wrote: > From: Alfie Richards > > Implement the mve vld and vst intrinsics using the MVE builtins framework. > > The main part of the patch is to reimplement to vstr/vldr patterns > such that we now have much fewer of them: > - non-truncating stores > - predi
Re: [PATCH 2/8] aarch64: Add new +fcma flag
On 08/10/2024 17:18, Richard Sandiford wrote: Andrew Carlotti writes: This includes +fcma as a dependency of +sve, and means that we can finally support fcma intrinsics on a64fx. Also add fcma to the Features list in several cpunative testcases that incorrectly included sve without fcma. g
Re: libstdc++-v3: do not duplicate some math functions when using newlib
Hey, I have to admit I am not super familiar with long doubles, either than knowing they are 128-bit FP representations... but bisect has pointed me to this patch when investigating a regression on aarch64_be-none-elf for the libstdc++ testcase: 26_numerics/complex/13450.cc After some reduct
Re: libstdc++-v3: do not duplicate some math functions when using newlib
Hey, I have to admit I am not super familiar with long doubles, either than knowing they are 128-bit FP representations... but bisect has pointed me to this patch when investigating a regression on aarch64_be-none-elf for the libstdc++ testcase: 26_numerics/complex/13450.cc After some reduct
Re: [PATCH] arm: Support -mfdpic for more targets
On 24/02/2024 03:33, Fangrui Song wrote: > From: Fangrui Song > > Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c > -mfdpic does not pass --fdpic to gas. This is an unnecessary > restriction. Just define the ASM_SPEC in bpabi.h. > > Additionally, use armelf[b]_linux_fdp
Re: arm: Improvements to arm_noce_conversion_profitable_p call [PR 116444]
On 18/10/2024 16:53, Andre Vieira (lists) wrote: > Sorry for the delay, some other work popped up in between and this had some > latent issues. They should all be addressed now in this new patch. > > > When not dealing with the special armv8.1-m.main conditional instructions &
Re: [PATCH v2] testsuite: Sanitize pacbti test cases for Cortex-M
On 14/10/2024 13:23, Christophe Lyon wrote: > > > On 10/13/24 19:50, Torbjörn SVENSSON wrote: >> Ok for trunk and releases/gcc-14? >> >> Changes since v1: >> >> - Dropped changes to dg- instructions. These will be addressed in a separate >> set of patches later. > > LGTM, let's avoid mixing cha
Re: [PATCH v3] testsuite: Avoid running incompatible Arm tests
On 17/07/2024 14:26, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > Changes since v2: > > - The case when -mfpu and/or -mfloat-abi is defined to an incompatible value. > With v3, > the defined multilib wins the race and the flag is no longer overridden if > set. > > Changes
Re: Automatic URLs in forgejo? (was Re: Sourceware forge experiment)
On 24/10/2024 16:29, David Malcolm wrote: > On Mon, 2024-10-21 at 03:22 +0200, Mark Wielaard wrote: >> As an experiment Sourceware is now running an forgejo v9 instance at >> https://forge.sourceware.org >> >> Everybody with an @sourceware.org, @cygwin.com or @gcc.gnu.org >> address >> can register
Re: [emacs-tangents] [External] : Emacs website, Lisp, and other
2024-10-23
Thread
Drew Adams via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists
> License does not prohibit selling. Motivation we know. > But it is sellable product, just as many other products. Yes. It's about the motivation - how and why a product gets produced. That you can sell something doesn't mean it's developed _for_ sale/profit. And it's not about whether it's _l
Re: [emacs-tangents] [External] : Emacs website, Lisp, and other
2024-10-23
Thread
Drew Adams via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists
> > > So the Emacs website and documentation should not sell elisp short. > > > > "marketing", "marketing", "marketing", > > "marketing", "marketing", "marketing". > > > > FWIW, a description, accurate or inaccurate, isn't > > necessarily marketing. We're not selling Emacs or > > Elisp. There's n
Re: iwx(4) / Intel Wi-Fi 6 AX210 not configured
iwlwifi ii firmware-iwlwifi 20240709-2 all Binary firmware for Intel Wireless cards On 21/10/2024 16:25, Stefan Sperling wrote: On Mon, Oct 21, 2024 at 03:57:19PM +0200, Alexis de BRUYN [Mailing Lists] wrote: Hello everyone, With a Lenovo
Re: [PATCH] testsuite: arm: Relax expected asm in bitfield* and union-2 tests
On 20/10/2024 16:49, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-14? -- Below -O2, lsls/lsrs are prefered. For -O2 and above, lsl/lsr are prefered. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c: Allow lsl and lsr instructions. * g
Re: [PATCH] testsuite: arm: Use check-function-bodies in fp16-aapcs-* tests
On 20/10/2024 16:48, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-14? -- Converted the tests to use check-function-bodies in order to ensure that the sequence is correct. gcc/testsuite/ChangeLog: * gcc.target/arm/fp16-aapcs-1.c: Use check-function-bodies. * gcc.targe
Re: [PATCH] testsuite: arm: Use check-function-bodies in cmse-5 tests
On 20/10/2024 16:45, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-14? -- Converted the tests to use check-function-bodies in order to ensure that the sequence is correct. This also allows both APSR_nzcvq and APSR_nzcvqg as target selector does not work when the -march and/or -mcpu ove
Re: Ot Mac OS upgrade
> On 20 Oct 2024, at 18:26, David J Brooks wrote: > > Hey all, I have a current iMac running Sonoma with m3 chip, I’m not big on > upgrading os’s but just wondering if many of the Mac people have moved to > 15 and if so was it a smooth transition? > I’m on several Mac Facebook sites and some re
[ceph-users] Re: Issue with Recovery Throughput Not Visible in Ceph Dashboard After Upgrade to 19.2.0 (Squid)
Hey there, i've that problem too, although I got it from updating 17.2.7 to 18.2.4. After i read this mail I've just fiddled around a bit aaand Prometheus does not have ceph_osd_recovery_ops. Then i looked into the files in /var/lib/ceph/xyz/prometheus.node-name/etc/prometheus/prometheus.yml
iwx(4) / Intel Wi-Fi 6 AX210 not configured
Hello everyone, With a Lenovo ThinkPad X1 Carbon Gen 12 (21KC-CTO1WW, BIOS and firmware up to date) and a -current fresh install (with a dock), I can't get the Intel AX200 wireless network device working. No iwx interface is listed with ifconfig(8). And in dmesg(8): "Intel Wi-Fi 6 AX210" rev
arm: Improvements to arm_noce_conversion_profitable_p call [PR 116444]
Sorry for the delay, some other work popped up in between and this had some latent issues. They should all be addressed now in this new patch. When not dealing with the special armv8.1-m.main conditional instructions case make sure it uses the default_noce_conversion_profitable_p call to dete
Re: [PATCH v2] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
Hi, This looks like an acceptable work around. We special case behavior that I'm not sure we can express in ways GCC can understand or will make use of, whilst at the same time we keep expressing behavior it does understand and can optimize. Nice idea! LGTM, needs maintainer approval though
[netsurf-users] Re: Weird bug
In article <7faf12b15b.br...@helpful-demon.co.uk>, Bryan Hogan wrote: > I think I've found the cause - the two pictures that don't display have > the word "advert" in their description, so NetSurf's ad blocker is > blocking them! > If you go into NetSurf's configuration, in the Content secti
Re: [PATCH v2] [testsuite] [arm] add effective target and options for pacbti tests
On 19/04/2024 17:37, Alexandre Oliva wrote: > Hello, Richard, > > Thanks, your response was very informative. > > Here's a revised patch. > > arm pac and bti tests that use -march=armv8.1-m.main get an implicit > -mthumb, that is incompatible with vxworks kernel mode. Declaring the > requiremen
Re: [PATCH 5/5] arm: [MVE intrinsics] Rework MVE vld/vst intrinsics
On 16/09/2024 10:38, Christophe Lyon wrote: > From: Alfie Richards > > Implement the mve vld and vst intrinsics using the MVE builtins framework. > > The main part of the patch is to reimplement to vstr/vldr patterns > such that we now have much fewer of them: > - non-truncating stores > - predi
Re: [PATCH 4/5] arm: [MVE intrinsics] Add support for predicated contiguous loads and stores
On 16/09/2024 10:38, Christophe Lyon wrote: > From: Alfie Richards > > This patch extends > function_expander::use_contiguous_load_insn and > function_expander::use_contiguous_store_insn functions to > support predicated versions. > > 2024-09-11 Alfie Richards > Christophe Lyon >
Re: [PATCH 3/5] arm: [MVE intrinsics] Add load_extending and store_truncating function bases
On 16/09/2024 10:38, Christophe Lyon wrote: > From: Alfie Richards > > This patch adds the load_extending and store_truncating function bases > for MVE intrinsics. > > The constructors have parameters describing the memory element > type/width which is part of the function base name (e.g. "h" in
Re: [PATCH 2/5] arm: [MVE intrinsics] Add load_ext intrinsic shape
On 16/09/2024 10:38, Christophe Lyon wrote: > From: Alfie Richards > > This patch adds the extending load shape. > It also adds/fixes comments for the load and store shapes. > > 2024-09-11 Alfie Richards > Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes
Re: [PATCH 1/5] arm: [MVE intrinsics] fix vst tests
On 16/09/2024 10:38, Christophe Lyon wrote: > From: Alfie Richards > > The tests for vst* instrinsics use functions which return a void > expression which can generate a warning. This hasn't come up previously > as the inlining presumably prevents the warning. > > This change removed the unecces
Re: [yocto] How to install a debian package in the host. Having problems with tar subprocess with dpkg-native
Adrian Freihofer via lists.yoctoproject.org schrieb am Fr 11. Okt, 21:33 (GMT): > Maybe you can extract the Deb file independently from bitbake with tar and > provide the binaries as a simple tar archive. This would allow to use > bitbake's fetcher to download the tar and unpack the binaries into W
Re: [PATCH v2 00/36] arm: [MVE intrinsics] Re-implement more intrinsics
On 04/09/2024 14:26, Christophe Lyon wrote: > Hi, > > This is v2 of the patch series I sent in > https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657065.html. > > I have taken into account the feedback I received, and added more > patches to the series, converting more MVE intrinsics to the ne
Re: [PATCH v2 36/36] arm: [MVE intrinsics] use long_type_suffix / half_type_suffix helpers
On 04/09/2024 14:26, Christophe Lyon wrote: > In several places we are looking for a type twice or half as large as > the type suffix: this patch introduces helper functions to avoid code > duplication. long_type_suffix is similar to the SVE counterpart, but > adds an 'expected_tclass' parameter.
Re: [PATCH v2 35/36] arm: [MVE intrinsics] rework vsbcq vsbciq
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vsbcq vsbciq using the new MVE builtins framework. > > We re-use most of the code introduced by the previous patches. > > 2024-08-28 Christophe Lyon > > gcc/ > > * config/arm/arm-mve-builtins-base.cc (class vadc_vsbc_impl):
Re: [PATCH v2 34/36] arm: [MVE intrinsics] rework vadcq
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vadcq using the new MVE builtins framework. > > We re-use most of the code introduced by the previous patch to support > vadciq: we just need to initialize carry from the input parameter. > > 2024-08-28 Christophe Lyon > > gcc/ >
Re: [PATCH v2 32/36] arm: [MVE intrinsics] factorize vadc vadci vsbc vsbci
On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vadc/vsbc and vadci/vsbci so that they use the same > parameterized names. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/iterators.md (mve_insn): Add VADCIQ_M_S, VADCIQ_M_U, > VADCIQ_U, VADCIQ_S, VADCQ_M_S, VADC
Re: [PATCH v2 33/36] arm: [MVE intrinsics] rework vadciq
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vadciq using the new MVE builtins framework. > > 2024-08-28 Christophe Lyon > gcc/ > > * config/arm/arm-mve-builtins-base.cc (class vadc_vsbc_impl): New. > (vadciq): New. > * config/arm/arm-mve-builtins-base.def (v
Re: [PATCH v2 31/36] arm: [MVE intrinsics] add vadc_vsbc shape
On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vadc_vsbc shape description. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (vadc_vsbc): New. > * config/arm/arm-mve-builtins-shapes.h (vadc_vsbc): New. OK. R. > --- > gcc
Re: [PATCH v2 30/36] arm: [MVE intrinsics] remove vshlcq useless expanders
On 04/09/2024 14:26, Christophe Lyon wrote: > Since we rewrote the implementation of vshlcq intrinsics, we no longer > need these expanders. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-builtins.cc > (arm_ternop_unone_none_unone_imm_qualifiers) > (-arm_ter
Re: [PATCH v2 29/36] arm: [MVE intrinsics] rework vshlcq
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vshlc using the new MVE builtins framework. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (class vshlc_impl): New. > (vshlc): New. > * config/arm/arm-mve-builtins-base.def (vshlcq)
Re: [PATCH v2 28/36] arm: [MVE intrinsics] add vshlc shape
On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vshlc shape description. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-shapes.cc (vshlc): New. > * config/arm/arm-mve-builtins-shapes.h (vshlc): New. OK. R. > --- > gcc/config/arm/
Re: [PATCH v2 23/36] arm: [MVE intrinsics] factorize vdwdup viwdup
On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vdwdup and viwdup so that they use the same parameterized > names. > > Like with vddup and vidup, we do not bother with the corresponding > expanders, as we stop using them in a subsequent patch. > > The patch also adds the missing attribute
Re: [PATCH v2 27/36] arm: [MVE intrinsics] remove useless v[id]wdup expanders
On 04/09/2024 14:26, Christophe Lyon wrote: > Like with vddup/vidup, we use code_for_mve_q_wb_u_insn, so we can drop > the expanders and their declarations as builtins, now useless. > > 2024-08-28 Christophe Lyon > > gcc/ > * config/arm/arm-builtins.cc > (arm_quinop_unone_uno
Re: [PATCH v2 26/36] arm: [MVE intrinsics] update v[id]wdup tests
On 04/09/2024 14:26, Christophe Lyon wrote: > Testing v[id]wdup overloads with '1' as argument for uint32_t* does > not make sense: this patch adds a new 'unit32_t *a' parameter to foo2 > in such tests. > > The difference with v[id]dup tests (where we removed 'foo2') is that > in 'foo1' we test th
Re: [PATCH v2 25/36] arm: [MVE intrinsics] rework vdwdup viwdup
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vdwdup and viwdup using the new MVE builtins framework. > > In order to share more code with viddup_impl, the patch swaps operands > 1 and 2 in @mve_v[id]wdupq_m_wb_u_insn, so that the parameter > order is similar to what @mve_v[id]dupq_m_wb_
Re: [PATCH v2 24/36] arm: [MVE intrinsics] add vidwdup shape
On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the vidwdup shape description for vdwdup and viwdup. > > It is very similar to viddup, but accounts for the additional 'wrap' > scalar parameter. > > 2024-08-21 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-s
Re: [PATCH v2 22/36] arm: [MVE intrinsics] fix checks of immediate arguments
On 04/09/2024 14:26, Christophe Lyon wrote: > As discussed in [1], it is better to use "su64" for immediates in > intrinsics signatures in order to provide better diagnostics > (erroneous constants are not truncated for instance). This patch thus > uses su64 instead of ss32 in binary_lshift_unsign
Re: [PATCH v2 21/36] arm: [MVE intrinsics] remove v[id]dup expanders
On 04/09/2024 14:26, Christophe Lyon wrote: > We use code_for_mve_q_u_insn, rather than the expanders used by the > previous implementation, so we can remove the expanders and their > declaration as builtins. > > 2024-08-21 Christophe Lyon > > gcc/ > * config/arm/arm_mve_builtins.d
Re: [PATCH v2 20/36] arm: [MVE intrinsics] update v[id]dup tests
On 04/09/2024 14:26, Christophe Lyon wrote: > Testing v[id]dup overloads with '1' as argument for uint32_t* does not > make sense: instead of choosing the '_wb' overload, we choose the > '_n', but we already do that in the '_n' tests. > > This patch removes all such bogus foo2 functions. > > 2024
Re: [PATCH v2 19/36] arm: [MVE intrinsics] rework vddup vidup
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vddup and vidup using the new MVE builtins framework. > > We generate better code because we take advantage of the two outputs > produced by the v[id]dup instructions. > > For instance, before: > ldr r3, [r0] > sub r2, r3
Re: [PATCH v2 18/36] arm: [MVE intrinsics] add viddup shape
On 04/09/2024 14:26, Christophe Lyon wrote: > This patch adds the viddup shape description for vidup and vddup. > > This requires the addition of report_not_one_of and > function_checker::require_immediate_one_of to > gcc/config/arm/arm-mve-builtins.cc (they are copies of the aarch64 SVE > counter
Re: [PATCH v2 17/36] arm: [MVE intrinsics] factorize vddup vidup
On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vddup and vidup so that they use the same parameterized > names. > > This patch updates only the (define_insn > "@mve_q_u_insn") patterns and does not bother with the > (define_expand "mve_vidupq_n_u") ones, because a subsequent > patch avoid
Re: [PATCH v2 16/36] arm: [MVE intrinsics] rework vctp
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vctp using the new MVE builtins framework. > > 2024-08-21 Christophe Lyon > > gcc/ChangeLog: > > * config/arm/arm-mve-builtins-base.cc (class vctpq_impl): New. > (vctp16q): New. > (vctp32q): New. > (vctp64q): New.
Re: [PATCH v2 15/36] arm: [MVE intrinsics] rework vorn
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vorn using the new MVE builtins framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (vornq): New. > * config/arm/arm-mve-builtins-base.def (vornq): New. > * config/arm/arm-mve
Re: [PATCH v2 14/36] arm: [MVE intrinsics] factorize vorn
On 04/09/2024 14:26, Christophe Lyon wrote: > Factorize vorn so that they use parameterized names. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/iterators.md (MVE_INT_M_BINARY_LOGIC): Add VORNQ_M_S, > VORNQ_M_U. > (MVE_FP_M_BINARY_LOGIC): Add VORNQ_M_F. >
Re: [PATCH v2 13/36] arm: [MVE intrinsics] rework vbicq
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vbicq using the new MVE builtins framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (vbicq): New. > * config/arm/arm-mve-builtins-base.def (vbicq): New. > * config/arm/arm-mv
Re: [PATCH v2 12/36] arm: [MVE intrinsics] rework vcvtaq vcvtmq vcvtnq vcvtpq
On 04/09/2024 14:26, Christophe Lyon wrote: > Implement vcvtaq vcvtmq vcvtnq vcvtpq using the new MVE builtins > framework. > > 2024-07-11 Christophe Lyon > > gcc/ > * config/arm/arm-mve-builtins-base.cc (vcvtaq): New. > (vcvtmq): New. > (vcvtnq): New. > (vcvtpq):
