Re: Scoop (jazz notation)

[Wols Lists]

On 15/05/2024 18:54, Flaming Hakama by Elaine wrote:
On the other hand, you could argue that many examples of scoop are not 
intended to convey specific shapes,
so a one-size-fits-all glyph is sufficient, and it is not intended to 
solve the problem of expressive glissando.


Which, is also a reasonable argument.  There is no reason both cannot exist.


Responding to this, it seems to me that scoops, bends, glissandos etc 
are all the same family of 
articulations/embellishments/call-it-what-you-will. So I'd like to see 
some kind of generic all-encompassing solution.


Han-Wen wrote bends for me, so I was surprised to discover that scoops 
(the same thing in a different place) seem not to have been done at the 
same time / the same way.


My feeling would be can we implement something along similar lines to 
format-box-barnumber and friends.


So we have

\slideBeforeCurve et al, it's called a slide, it's Before or After, it 
can be a Curve, Straight, Jagged, it can be Fall, Rise, Anchored. I'm 
sure other people will be able to think of other things. And then we can 
special-case with shortcuts called \glissando, \bend, and so on.


But as with \format..., back in the 2.2, 2.4 days I kept tripping over 
the fact that the particular mix I wanted hadn't been implemented, and 
then somebody kindly just implemented all possible combinations for me 
(and everybody else). So now whatever you wanted is "just there". (I did 
try to do it myself, I just couldn't grok scheme :-(


If we look at it as "variations on a theme", we can have a simple, 
single implementation that can be tweaked to suit.


Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 15/05/2024 11:40, Peter Humphrey wrote:

I think whoever named grub had delusions of grandeur.    Anyway, I never let
it near my systems.


I liked lilo. And then it disappeared :-(

Grub isn't that bad - it's just that insists on trying to do everything 
itself - and if you've got at all a strange setup it makes a complete 
hash of it.


LIKE GENTOO!

I've moaned about this before, but last time SUSE updated itself, it 
trashed grub.conf and left me with an unbootable system. And then gentoo 
sees that I've got an unmounted /boot and throws a complete and utter 
hissy fit because I told it not to touch it ...


Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 02/05/2024 11:46, Peter Humphrey wrote:

When I started using Linux, the received wisdom was to keep a separate /boot,
and leave it unmounted during normal operation. The idea was that a successful
hacker would not, supposedly, be able to corrupt the kernel ready for a reboot
into their system.


And you can't have /boot on your system partition if, like me, you have 
one instance of grub booting into several different OSs or distros ... 
Less so now, but having multiple distros on one system was a popular 
hobbyist pastime!


(One distro's system partition is another distro's data partion :-)

Cheers,
Wol

Re: [gentoo-user] Re: Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 02/05/2024 10:35, Michael wrote:

Besides the automation this feature affords, I find it useful to know what a
partition contains without having to mount it.  On GPT labelled disks I make
use both of the Partition Type UUID and the Partition Name.  A quick glance at
the gdisk output and if need be its 'i' option has saved my day from
formatting the wrong partition more than once!  


Iirc from the days of kernel 1.3 and 2.x, the partition type is not used 
- at all - by linux itself. Dunno about other OSs.


As you pointed out, though, it is used by other tools, which use it to 
identify what the partition is *supposed* to be used for. For example, 
auto-assemble with raid.


I'm not sure, but for example I think swap will quite happily let you 
"mount" a non-swap partiton with swap-on. You can format an allegedly 
DOS or NTFS partition with ext, and linux won't care ...


Cheers,
Wol

Re: [PATCH] aarch64: Fix typo in aarch64-ldp-fusion.cc:combine_reg_notes [PR114936]

[Richard Earnshaw (lists)]

On 03/05/2024 15:45, Alex Coplan wrote:
> This fixes a typo in combine_reg_notes in the load/store pair fusion
> pass.  As it stands, the calls to filter_notes store any
> REG_FRAME_RELATED_EXPR to fr_expr with the following association:
> 
>  - i2 -> fr_expr[0]
>  - i1 -> fr_expr[1]
> 
> but then the checks inside the following if statement expect the
> opposite (more natural) association, i.e.:
> 
>  - i2 -> fr_expr[1]
>  - i1 -> fr_expr[0]
> 
> this patch fixes the oversight by swapping the fr_expr indices in the
> calls to filter_notes.
> 
> In hindsight it would probably have been less confusing / error-prone to
> have combine_reg_notes take an array of two insns, then we wouldn't have
> to mix 1-based and 0-based indexing as well as remembering to call
> filter_notes in reverse program order.  This however is a minimal fix
> for backporting purposes.
> 
> Many thanks to Matthew for spotting this typo and pointing it out to me.
> 
> Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk and the 14
> branch after the 14.1 release?
> 
> Thanks,
> Alex
> 
> gcc/ChangeLog:
> 
>   PR target/114936
>   * config/aarch64/aarch64-ldp-fusion.cc (combine_reg_notes):
>   Ensure insn iN has its REG_FRAME_RELATED_EXPR (if any) stored in
>   FR_EXPR[N-1], thus matching the correspondence expected by the
>   copy_rtx calls.


OK.

R.

[wwwdocs] Specify AArch64 BitInt support for little-endian only

[Andre Vieira (lists)]

Hey Jakub,

This what ya had in mind?

Kind regards,
Andre Vieiradiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 
ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1
 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -325,7 +325,7 @@ You may also want to check out our
   Bit-precise integer types (_BitInt (N)
   and unsigned _BitInt (N)): integer types with
   a specified number of bits.  These are only supported on
-  IA-32, x86-64 and AArch64 at present.
+  IA-32, x86-64 and AArch64 (little-endian) at present.
   Structure, union and enumeration types may be defined more
   than once in the same scope with the same contents and the same
   tag; if such types are defined with the same contents and the

Re: [tor-relays] Updating tor issue

[lists]

On Freitag, 3. Mai 2024 18:17:41 CEST Keifer Bly wrote:
> System is up to date, I run apt-get update regularly.

Did you even only read 2 sentences from the link?
Buster is EOL and will be completely archived in a few weeks.
> > https://www.debian.org/releases/buster/
Debian is 2 releases ahead!
You won't get 3rd party packages (tor) anymore.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Updating tor issue

[lists]

On Freitag, 3. Mai 2024 17:00:44 CEST Keifer Bly wrote:

> What is the correct format for adding tor as a trusted source?
A not outdated system. ¹AFAIK obfs4proxy for buster (oldoldstable) has had a 
security hole for a long time and you are putting your users at risk!

> deb-src http://deb.debian.org/debian buster main
> deb http://security.debian.org/ buster/updates main
> deb-src http://security.debian.org/ buster/updates main
First upgrade the system. buster -> bullseye -> bookworm
https://www.debian.org/releases/buster/

https://www.debian.org/releases/bullseye/releasenotes
https://www.debian.org/releases/stable/releasenotes

Reinstalling might be easier.

¹Upgrading your old system & obfs4proxy was recommended here 2-3 years ago.
Somehow you're going around in circles.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [PATCH] testsuite: Verify r0-r3 are extended with CMSE

[Richard Earnshaw (lists)]

On 30/04/2024 16:37, Torbjorn SVENSSON wrote:
> 
> 
> On 2024-04-30 17:11, Richard Earnshaw (lists) wrote:
>> On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
>>> Add regression test to the existing zero/sign extend tests for CMSE to
>>> verify that r0, r1, r2 and r3 are properly extended, not just r0.
>>>
>>> Test is done using -O0 to ensure the instructions are in a predictable
>>> order.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/arm/cmse/extend-param.c: Add regression test.
>>>
>>> Signed-off-by: Torbjörn SVENSSON 
>>> ---
>>>   .../gcc.target/arm/cmse/extend-param.c    | 20 ++-
>>>   1 file changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c 
>>> b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>>> index 01fac786238..b8b8ecbff56 100644
>>> --- a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>>> +++ b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>>> @@ -93,4 +93,22 @@ __attribute__((cmse_nonsecure_entry)) char 
>>> boolSecureFunc (bool index) {
>>>   return 0;
>>>     return array[index];
>>>   -}
>>> \ No newline at end of file
>>> +}
>>> +
>>> +/*
>>> +**__acle_se_boolCharShortEnumSecureFunc:
>>> +**    ...
>>> +**    uxtb    r0, r0
>>> +**    uxtb    r1, r1
>>> +**    uxth    r2, r2
>>> +**    uxtb    r3, r3
>>> +**    ...
>>> +*/
>>> +__attribute__((cmse_nonsecure_entry,optimize(0))) char 
>>> boolCharShortEnumSecureFunc (bool a, unsigned char b, unsigned short c, 
>>> enum offset d) {
>>> +
>>> +  size_t index = a + b + c + d;
>>> +  if (index >= ARRAY_SIZE)
>>> +    return 0;
>>> +  return array[index];
>>> +
>>> +}
>>
>> Ok, but please can you add '-fshort-enums' to dg-options to ensure this test 
>> still behaves correctly if run with a different default (I missed that last 
>> time around).
> 
> Ok, I'll add that to extend-param.c. Do you want me to also add it to the 
> extend-return.c test case?
> 
> Kind regards,
> Torbjörn

Yes please, if it has the same issue.

R.

Re: [PATCH] testsuite: Verify r0-r3 are extended with CMSE

[Richard Earnshaw (lists)]

On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
> Add regression test to the existing zero/sign extend tests for CMSE to
> verify that r0, r1, r2 and r3 are properly extended, not just r0.
> 
> Test is done using -O0 to ensure the instructions are in a predictable
> order.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/arm/cmse/extend-param.c: Add regression test.
> 
> Signed-off-by: Torbjörn SVENSSON 
> ---
>  .../gcc.target/arm/cmse/extend-param.c| 20 ++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c 
> b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
> index 01fac786238..b8b8ecbff56 100644
> --- a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
> +++ b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
> @@ -93,4 +93,22 @@ __attribute__((cmse_nonsecure_entry)) char boolSecureFunc 
> (bool index) {
>  return 0;
>return array[index];
>  
> -}
> \ No newline at end of file
> +}
> +
> +/*
> +**__acle_se_boolCharShortEnumSecureFunc:
> +**   ...
> +**   uxtbr0, r0
> +**   uxtbr1, r1
> +**   uxthr2, r2
> +**   uxtbr3, r3
> +**   ...
> +*/
> +__attribute__((cmse_nonsecure_entry,optimize(0))) char 
> boolCharShortEnumSecureFunc (bool a, unsigned char b, unsigned short c, enum 
> offset d) {
> +
> +  size_t index = a + b + c + d;
> +  if (index >= ARRAY_SIZE)
> +return 0;
> +  return array[index];
> +
> +}

Ok, but please can you add '-fshort-enums' to dg-options to ensure this test 
still behaves correctly if run with a different default (I missed that last 
time around).

R.

Re: Veso: T-bone and the Kalispell Fair - 1988

[lists]

> On 27 Apr 2024, at 02:50, ann sanfedele  wrote:
> 
> All the photos were taken with my trusty Pentax LX - Kodachrome's scanned on 
> Epson flatbed v500
> I made the vid in Windows Movie maker .. dropped in the music from an MP3 . 
> Original guitar music
> by my friend Bob Zaidman  - music recorded  on tape back in the 70's - in a 
> studio setting.   Long story -
> I'll skip  but it ws an impromtu performance by Bob on guitar and Dom Duval 
> (sr.)  on bass .  Duval Sr. died in 2016.
> He had gone from the blues stuff to free style jazz and there are a lot of 
> recordings around of him playing jazz.
> 
> Bob had been sending me MP3's  since we have been back in touch.. i really 
> liked this piece they called "What you will"
> and thought the shots I took back in 1988 and the music paired nicely.   The 
> calf really was named "T-bone"
> 
> https://www.youtube.com/watch?v=PI_LzE-HsJo=18s


Nice one Ann,

Reminds me of the six months I lived in Austin TX in the late eighties ;-)

Regards, JvW


=
Jan van Wijk; author of DFsee;  https://www.dfsee.com

--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: [gentoo-user] Grub, gpt partitions and BIOS, not uefi thing.

[Wols Lists]

On 27/04/2024 17:53, Dale wrote:

Howdy,

I'm installing Gentoo on another old box.  To be consistent I like to
use cgdisk, GPT I think it is called, to partition all my drives,
regardless of size.  Thing is, Grub works differently with GPT than it
does with the old DOS or whatever it is called, like fdisk does in the
old days.  I did some research but still find myself in some muddy
waters.  My take on some things I've read, I need a boot partition, not
to be confused with the /boot for kernels, init thingys and such.  Where
I get lost, most use gdisk.  I like cgdisk.  Before that I liked
cfdisk.  Anyway, how do I set up that partition with cgdisk?  Any
minimum size requirements or tiny is enough?  Does it have to be a
specific type?  Does it need to be in a specific place?  Formatted with
a file system?  Also, when I do grub-install, do I still point to
/dev/sda or to /dev/sda1, if sda1 is the special boot partition?

I tried to find a step by step howto with this info but the ones I find
either don't work or leaves me more confused.  Given that the method is
also aging out, it's hard to find good guides.  I'd be real happy just
to have a link to a good howto that I can make sense of.  I can save a
copy local and even print it.  Maybe someone has some notes that will
help.  I just need something to help clear up the muddy waters.


Hmm ...

Michael's version does not ring any bells with me, and indeed my system 
is *not* set up that way. It's UEFI-capable, but at the time I didn't 
have a clue what I was doing, so the mobo dumped me into BIOS, and I 
just installed everything the old way I knew.


I do, however, have a 512MB partition configured as type "Microsoft 
basic data". This is meant to be for the UEFI partition if I get round 
to converting the system.


If you want to "suck it and see", just install grub to /dev/sda. All 
your GPT disks, by default, leave the first 2MB empty, and grub will 
stick itself in there I believe.


Cheers,
Wol

Re: [AFMUG] Fiber: Radisys

[Jeff Broadwick - Lists]

Matt and Nabeel should be reaching out shortly.Regards,Jeff Jeff BroadwickCTIconnect312-205-2519 Office574-220-7826 Celljbroadw...@cticonnect.comOn Apr 26, 2024, at 10:28 AM, Jason McKemie  wrote:Jeff -I've been working with CTI on quotes for these. I had a conference call in December with (I believe) you and Mark from Adtran. Nabeel recently reached out to me seeing if I needed anything and I asked him about getting an Adtran quote earlier last week, but I still have not heard anything on that front. He did get me the Radisys quote.ThanksJason McKemie VeloxinetOn Thursday, April 25, 2024, Jeff Broadwick - Lists <jeffl...@att.net> wrote:> > Thanks Josh!> I can actually help with both.  My contact info is below.>> Regards,> Jeff > Jeff Broadwick> CTIconnect> 312-205-2519 Office> 574-220-7826 Cell> jbroadw...@cticonnect.com>> On Apr 25, 2024, at 4:59 PM, Josh Luthman <j...@imaginenetworksllc.com> wrote:>> >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.>> Jeff has some pretty good deals on Adtran stuff.> Not sure what the Radisys product is but talk to Jeff about the fiber/Adtran gear.> On Thu, Apr 25, 2024 at 1:48 PM Jason McKemie <j.mcke...@veloxinetbroadband.com> wrote:>>>> I've been trying to get a quote from Adtran for months with no luck. These guys recently came to my attention. The product and pricing looks reasonable, has anyone used their gear? -->> AF mailing list>> AF@af.afmug.com>> http://af.afmug.com/mailman/listinfo/af_af.afmug.com>
-- AF mailing listAF@af.afmug.comhttp://af.afmug.com/mailman/listinfo/af_af.afmug.com-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

Re: [PATCH][GCC] aarch64: Fix SCHEDULER_IDENT for Cortex-A510

[Richard Earnshaw (lists)]

On 25/04/2024 15:59, Richard Ball wrote:
> Hi Richard,
> 
> I committed this combined patch (with Cortex-A520) for trunk 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cab53aae43cf94171b01320c08302e47a5daa391
>  
> 
> 
> Am I ok to commit just the Cortex-A510 half into gcc-12 and gcc-13.

Yes, if that's the correct thing to do there.

R.

> 
> Thanks,
> Richard Ball
> --
> *From:* Richard Ball
> *Sent:* 12 March 2024 14:08
> *To:* gcc-patches@gcc.gnu.org ; Richard Earnshaw 
> ; Richard Sandiford ; 
> Marcus Shawcroft 
> *Subject:* [PATCH][GCC] aarch64: Fix SCHEDULER_IDENT for Cortex-A510
>  
> The SCHEDULER_IDENT for this CPU was incorrectly
> set to cortexa55, which is incorrect. This can cause
> sub-optimal asm to be generated.
> 
> Ok for trunk?
> 
> Can I also backport this to gcc-12 and gcc-13?
> 
> gcc/ChangeLog:
>     PR target/114272
>     * config/aarch64/aarch64-cores.def (AARCH64_CORE):
>     Change SCHEDULER_IDENT from cortexa55 to cortexa53
>     for Cortex-A510.

Re: [PATCH] arm: Zero/Sign extends for CMSE security

[Richard Earnshaw (lists)]

On 26/04/2024 09:39, Torbjorn SVENSSON wrote:
> Hi,
> 
> On 2024-04-25 16:25, Richard Ball wrote:
>> Hi Torbjorn,
>>
>> Thanks very much for the comments.
>> I think given that the code that handles this, is within a 
>> FOREACH_FUNCTION_ARGS loop.
>> It seems a fairly safe assumption that if the code works for one that it 
>> will work for all.
>> To go back and add extra tests to me seems a little overkill.
> 
> For verifying that the implementation does the right thing now, no, but for 
> verifying against future regressions, then yes.
> 
> So, from a regression point of view, I think it makes sense to have the check 
> that more than the first argument is managed properly.
> 
> Kind regards,
> Torbjörn

Feel free to post some additional tests, Torbjorn.

R.

Re: [AFMUG] Fiber: Radisys

[Jeff Broadwick - Lists]

Thanks Josh!I can actually help with both.  My contact info is below.Regards,Jeff Jeff BroadwickCTIconnect312-205-2519 Office574-220-7826 Celljbroadw...@cticonnect.comOn Apr 25, 2024, at 4:59 PM, Josh Luthman  wrote:





CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



Jeff has some pretty good deals on Adtran stuff.


Not sure what the Radisys product is but talk to Jeff about the fiber/Adtran gear.



On Thu, Apr 25, 2024 at 1:48 PM Jason McKemie  wrote:


I've been trying to get a quote from Adtran for months with no luck. These guys recently came to my attention. The product and pricing looks reasonable, has anyone used their gear? --

AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com





-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

[spdx] "-only" and "-or-later" identifiers for EUPL licenses?

[Christian Meeßen via lists . spdx . org]

Hello SPDX LegalTeam,

I am an RSE working at the German Research Centre for Geosciences (GFZ) 
in Potsdam, Germany. I am involved in working groups in Helmholtz that 
deal with Research Software Engineering aspects, and am also the 
maintainer of the Helmholtz Research Software Directory 
(https://helmholtz.software). We generally encourage the usage of SPDX 
identifiers for software.


I noticed that there exists one identifier for EUPL-1.1 [1] and EUPL-1.2 
[2] respectively, although the licenses specify that code can be 
redistributed also under later versions of that license unless it is 
explicitly stated otherwise. Here is an example from EUPL-1.2 (clause 5, 
"Copyleft clause"):


> If the Licensee distributes or communicates copies of the Original 
Works or Derivative Works, this Distribution or Communication will be 
done under the terms of this Licence or of a later version of this 
Licence unless the Original Work is expressly distributed only under 
this version of the Licence — for example by communicating 'EUPL v. 1.2 
only'.


The GPL licenses are separated into "-only" and "-or-later" identifiers. 
Is there a specific reason why this was not applied to the EUPL 
identifiers? Would it be possible to replace the existing identifiers 
with EUPL-1.x-only and EUPL-1.x-or-later identifiers?


The EUPL-1.0 is not affected.

Kind regards,

Christian Meeßen

[1] EUPL-1.1: https://spdx.org/licenses/EUPL-1.1.html
[2] EUPL-1.2: https://spdx.org/licenses/EUPL-1.2.html

--
Dr. Christian Meeßen
eScience Center
Tel: +49 (0)331 6264-1983
Email: christian.mees...@gfz-potsdam.de
_
Helmholtz-Zentrum Potsdam
Deutsches GeoForschungsZentrum GFZ
Stiftung des öff. Rechts Land Brandenburg
Telegrafenberg A70/320, 14473 Potsdam


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1844): https://lists.spdx.org/g/spdx/message/1844
Mute This Topic: https://lists.spdx.org/mt/105731993/21656
Group Owner: spdx+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] arm: Zero/Sign extends for CMSE security

[Richard Earnshaw (lists)]

On 24/04/2024 16:55, Richard Ball wrote:
> This patch makes the following changes:
> 
> 1) When calling a secure function from non-secure code then any arguments
>smaller than 32-bits that are passed in registers are zero- or 
> sign-extended.
> 2) After a non-secure function returns into secure code then any return value
>smaller than 32-bits that is passed in a register is  zero- or 
> sign-extended.
> 
> This patch addresses the following CVE-2024-0151.
> 
> gcc/ChangeLog:
> PR target/114837
> * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
>   Add zero/sign extend.
> (arm_expand_prologue): Add zero/sign extend.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/arm/cmse/extend-param.c: New test.
> * gcc.target/arm/cmse/extend-return.c: New test.

OK.  And OK to backport to active branches.

R.

Re: Deploy Cloudstack on Debian 12

[lists]

 
 
 
Hi
 
Ive deployed recent on both 11 and 12. What issue on 12 did you encounter?
 

 

 

 
 
 
 
 
>  
> On Apr 25, 2024 at 1:59 PM, Khang Nguyen Phuc
> wrote:
>  
>  
>  Hello everyone,
>
> I'm a newbie, and I mainly use Debian servers. So I want to deploy
> CloudStack on Debian. I've experimented with CloudStack 4.19 on Debian 11 ,
> it works fine, but I noticed that CloudStack doesn't officially support
> Debian (CloudStack's documentation recommends using Ubuntu or CentOS
> without mentioning Debian). Additionally, I encountered errors when
> deploying CloudStack on Debian 12. I wonder why seems inconvenient to use
> CloudStack on Debian. Should I deploy CloudStack on Debian 12 for
> production? Can anyone with experience share some tips on deploying
> CloudStack on Debian 12?
>
> Thank you all very much.
>
 

Re: Updated Sourceware infrastructure plans

[Richard Earnshaw (lists) via Gcc]

On 23/04/2024 09:56, Mark Wielaard wrote:
> Hi,
> 
> On Mon, Apr 22, 2024 at 11:51:00PM -0400, Jason Merrill wrote:
>> On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey  wrote:
>>> Jason> Someone mentioned earlier that gerrit was previously tried
>>> Jason> unsuccessfully.
>>>
>>> We tried it and gdb and then abandoned it.  We tried to integrate it
>>> into the traditional gdb development style, having it send email to
>>> gdb-patches.  I found these somewhat hard to read and in the end we
>>> agreed not to use it.
>>>
>>> I've come around again to thinking we should probably abandon email
>>> instead.  For me the main benefit is that gerrit has patch tracking,
>>> unlike our current system, where losing patches is fairly routine.
>>
>> Indeed.  Though Patchwork is another option for patch tracking, that glibc
>> seem to be having success with.
> 
> Patchworks works if you have people that like it and keep on top of
> it. For elfutils Aaron and I are probably the only ones that use it,
> but if we just go over it once a week it keeps being managable and
> nobody else needs to care. That is also why it seems to work for
> glibc. If you can carve out an hour a week going over the submitted
> patches and delegate them then it is a really useful patch tracking
> tool. Obviously that only works if the patch flow isn't overwhelming
> to begin with...
> 
> I'll work with Sergio who setup the original gerrit instance to
> upgrade it to the latest gerrit version so people try it out. One nice
> thing he did was to automate self-service user registration. Although
> that is one of the things I don't really like about it. As Tom said it
> feels like gerrit is an all or nothing solution that has to be
> mandated to be used and requires everybody to have a centralized
> login. But if you do want that then how Sergio set it up is pretty
> nice. It is just one more thing to monitor for spam accounts...
> 
> Cheers,
> 
> Mark

I've been using patchwork with GCC since, roughly, last year's cauldron.  Its 
main weakness is a poor search function for finding relevant patches, which 
means that since most patches in the queue aren't being managed it's a bit 
hit-and-miss finding the relevant patches.

Its other problem is that it expects a particular workflow model, particularly 
not replying to an existing patch discussion with an updated patch (it expects 
patches to be reposted as an entire series with a new version number, 
Linux-style).

But there are some benefits to using it: I can integrate it with my mail client 
- it can show me the patch series in patchwork when I receive a mail directly; 
it integrates well with git with the git-pw module, so I can pull an entire 
patch series off the list into my worktree from the command line just by 
knowing the patch series number; and I can manage/track patches in bundles, 
which is great if I don't have time in any particular day to deal with the 
email volume.

Finally, it's been integrated with our CI systems (thanks Linaro!), so it can 
automatically pull reviews and run validations on them, then report the results 
back; often before I've even had time to look at the patch.

R.

Re: Updated Sourceware infrastructure plans

[Richard Earnshaw (lists) via Gcc]

On 23/04/2024 04:24, Tom Tromey wrote:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
> 
> We tried it and gdb and then abandoned it.  We tried to integrate it
> into the traditional gdb development style, having it send email to
> gdb-patches.  I found these somewhat hard to read and in the end we
> agreed not to use it.
> 
> I've come around again to thinking we should probably abandon email
> instead.  For me the main benefit is that gerrit has patch tracking,
> unlike our current system, where losing patches is fairly routine.
> 
> Jason> I think this is a common pattern in GCC at least: someone has an
> Jason> idea for a workflow improvement, and gets it working, but it
> Jason> isn't widely adopted.
> 
> It essentially has to be mandated, IMO.
> 
> For GCC this seems somewhat harder since the community is larger, so
> there's more people to convince.
> 
> Tom

I've been forced to use gerrit occasionally.  I hate it.  No, I LOATHE it.  The 
UI is anything but intuitive with features hidden behind unobvious selections.  
IMO It's not a tool for a casual developer, which makes it a bad introduction 
to developing software.

R.

Re: [PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests

[Richard Earnshaw (lists)]

On 19/04/2024 13:45, Alexandre Oliva wrote:
> On Apr 16, 2024, "Richard Earnshaw (lists)"  wrote:
> 
>> The require-effective-target flags test whether a specific set of
>> flags will make the compilation work, so they need to be used in
>> conjunction with the corresponding dg-add-options flags that then
>> apply those options.
> 
> *nod*, that's the theory.  Problem is the architectures suported by
> [add_options_for_]arm_arch_*[_ok] do not match exactly those expected by
> the tests, and I can't quite tell whether the subtle changes they would
> introduce would change what they intend to test, or even whether the
> differences are irrelevant, or would be sensible to add as variants to
> the dg machinery.  I think it would take someone more familiar than I am
> with all of the ARM variants to do this correctly.  I don't even know
> how these changes would need to be tested to be sure they remain
> correct.

It's ok to add additional variations to the table of variants in 
target-supports.exp, but we should avoid writing new specific run-time 
functions unless we really want an executable test.

I started doing some cleanup of the Arm tests infrastructure during phase 3, 
but stopped during phase 4 as I wanted to minimise the changes being made now.  
I plan to go back and work on it some more once stage 1 re-opens.

> 
> Would you be willing to take it from here, or would you accept the patch
> as an incremental yet imperfect improvement, or would you prefer to
> guide me in making it correct, and in verifying it (there are questions
> below)?  I don't have a lot of cycles to put into this (we've already
> worked around the testsuite bugs we ran into), but it would be desirable
> to get a fix into GCC as well, if we can converge on one without
> unreasonably burdening anyone.
> 
> 
>   v8_1m_main "-march=armv8.1-m.main+fp -mthumb" __ARM_ARCH_8M_MAIN__
>   v8_1m_main_pacbti "-march=armv8.1-m.main+pacbti+fp -mthumb"
>   "__ARM_ARCH_8M_MAIN__ && __ARM_FEATURE_BTI && 
> __ARM_FEATURE_PAUTH
> 
> Why do these have +fp in -march but not in the v8_1m* arch name?

It's ... complicated :)

The +fp is there because, with the move to having -mfpu=auto as the default, we 
need to avoid problems when the compiler has been configured with 
--with-float=hard, which requires the extension register set (fp or vector 
support) even if the test code itself doesn't care.  The best way to handle 
this in most cases is to give the architecture strings a default FPU 
specification (ie +fp). 

> 
> 
> gcc/testsuite/g++.target/arm/pac-1.C:
> /* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
> -mthumb -mfloat-abi=hard -g -O0" } */
> 
> v8_1m_main_pacbti plus +mve minus +fp.
> Do we need a dg arch for that?

I'd be inclined to drop +mve from this one; there's nothing I can see in the 
test that would generate mve instructions, so I think it's irrelevant.  We can 
use the existing v8_1m_main_pacbti operations.

> 
> 
> gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c:
> /* { dg-additional-options "-march=armv8.1-m.main+pacbti+fp --save-temps 
> -mfloat-abi=hard" } */
> gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c:
> /* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */
> 
> v8_1m_main_pacbti minus -mthumb.
> AFAICT the -mthumb is redundant.

Nearly, but not quite.  Although the gcc driver knows that m-profile 
architectures require thumb, that's not enough to override an explicit -marm 
from a testsuite configuration run, so if your site.exp file adds -marm in a 
test configuration we need to override that or the test will fail.  But the 
table based list of options will do that for you.

> 
> 
> gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c:
> /* { dg-options "-march=armv8-m.main+fp -mfloat-abi=softfp" } */
> 
> v8_1m_main minus -mthumb.
> AFAICT the -mthumb is redundant.

As above

> 
> 
> gcc/testsuite/gcc.target/arm/bti-1.c:
> /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
> -mbranch-protection=bti --save-temps" } */
> gcc/testsuite/gcc.target/arm/bti-2.c:
> /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
> -mbranch-protection=bti --save-temps" } */
> 
> v8_1m_main minus +fp.> 
> Can these be bumped to +fp, or do we need an extra dg arch?
> 
> Are these missing +pacbti?

The tests themselves do not require fp, but if we use the effective-target 
rules (arm_arch_v8_1m_main), we can remove the -march, -mthumb and -mfloat-abi 
flags from these tests.

These tests for BTI should NOT have +pacbti: they're testing that the compiler 
generates the right nop-based implementation that is backw

Re: [PATCH]AArch64: remove reliance on register allocator for simd/gpreg costing. [PR114741]

[Richard Earnshaw (lists)]

On 18/04/2024 11:11, Tamar Christina wrote:
> Hi All,
> 
> In PR114741 we see that we have a regression in codegen when SVE is enable 
> where
> the simple testcase:
> 
> void foo(unsigned v, unsigned *p)
> {
> *p = v & 1;
> }
> 
> generates
> 
> foo:
> fmovs31, w0
> and z31.s, z31.s, #1
> str s31, [x1]
> ret
> 
> instead of:
> 
> foo:
> and w0, w0, 1
> str w0, [x1]
> ret
> 
> This causes an impact it not just codesize but also performance.  This is 
> caused
> by the use of the ^ constraint modifier in the pattern 3.
> 
> The documentation states that this modifier should only have an effect on the
> alternative costing in that a particular alternative is to be preferred unless
> a non-psuedo reload is needed.
> 
> The pattern was trying to convey that whenever both r and w are required, that
> it should prefer r unless a reload is needed.  This is because if a reload is
> needed then we can construct the constants more flexibly on the SIMD side.
> 
> We were using this so simplify the implementation and to get generic cases 
> such
> as:
> 
> double negabs (double x)
> {
>unsigned long long y;
>memcpy (, , sizeof(double));
>y = y | (1UL << 63);
>memcpy (, , sizeof(double));
>return x;
> }
> 
> which don't go through an expander.
> However the implementation of ^ in the register allocator is not according to
> the documentation in that it also has an effect during coloring.  During 
> initial
> register class selection it applies a penalty to a class, similar to how ? 
> does.
> 
> In this example the penalty makes the use of GP regs expensive enough that it 
> no
> longer considers them:
> 
> r106: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS
> ;;3--> b  0: i   9 r106=r105&0x1
> :cortex_a53_slot_any:GENERAL_REGS+0(-1)FP_REGS+1(1)PR_LO_REGS+0(0)
>  PR_HI_REGS+0(0):model 4
> 
> which is not the expected behavior.  For GCC 14 this is a conservative fix.
> 
> 1. we remove the ^ modifier from the logical optabs.
> 
> 2. In order not to regress copysign we then move the copysign expansion to
>directly use the SIMD variant.  Since copysign only supports floating point
>modes this is fine and no longer relies on the register allocator to select
>the right alternative.
> 
> It once again regresses the general case, but this case wasn't optimized in
> earlier GCCs either so it's not a regression in GCC 14.  This change gives
> strict better codegen than earlier GCCs and still optimizes the important 
> cases.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
> 
>   PR target/114741
>   * config/aarch64/aarch64.md (3): Remove ^ from alt 2.
>   (copysign3): Use SIMD version of IOR directly.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR target/114741
>   * gcc.target/aarch64/fneg-abs_2.c: Update codegen.
>   * gcc.target/aarch64/fneg-abs_4.c: xfail for now.
>   * gcc.target/aarch64/pr114741.c: New test.
> 
> ---
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 
> 385a669b9b3c31cc9108a660e881b9091c71fc7c..dbde066f7478bec51a8703b017ea553aa98be309
>  100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -4811,7 +4811,7 @@ (define_insn "3"
>""
>{@ [ cons: =0 , 1  , 2; attrs: type , arch  ]
>   [ r, %r , r; logic_reg   , * ] \t%0, 
> %1, %2
> - [ rk   , ^r ,  ; logic_imm   , * ] \t%0, 
> %1, %2
> + [ rk   , r  ,  ; logic_imm   , * ] \t%0, 
> %1, %2
>   [ w, 0  ,  ; *   , sve   ] \t%Z0., 
> %Z0., #%2
>   [ w, w  , w; neon_logic  , simd  ] 
> \t%0., %1., %2.
>}
> @@ -7192,22 +7192,29 @@ (define_expand "copysign3"
> (match_operand:GPF 2 "nonmemory_operand")]
>"TARGET_SIMD"
>  {
> -  machine_mode int_mode = mode;
> -  rtx bitmask = gen_reg_rtx (int_mode);
> -  emit_move_insn (bitmask, GEN_INT (HOST_WIDE_INT_M1U
> - << (GET_MODE_BITSIZE (mode) - 1)));
> +  rtx signbit_const = GEN_INT (HOST_WIDE_INT_M1U
> +<< (GET_MODE_BITSIZE (mode) - 1));
>/* copysign (x, -1) should instead be expanded as orr with the sign
>   bit.  */
>rtx op2_elt = unwrap_const_vec_duplicate (operands[2]);
>if (GET_CODE (op2_elt) == CONST_DOUBLE
>&& real_isneg (CONST_DOUBLE_REAL_VALUE (op2_elt)))
>  {
> -  emit_insn (gen_ior3 (
> - lowpart_subreg (int_mode, operands[0], mode),
> - lowpart_subreg (int_mode, operands[1], mode), bitmask));
> +  rtx v_bitmask
> + = force_reg (V2mode,
> +  gen_const_vec_duplicate (V2mode,
> +   signbit_const));
> +
> +  emit_insn (gen_iorv23 (
> + lowpart_subreg (V2mode, operands[0], mode),
> + lowpart_subreg 

Re: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation

[Wols Lists]

On 17/04/2024 10:10, Michael wrote:

I am not sure the assumption "... aging hardware possibly can less and less
cope with newer and newer kernels" is correct.  As already mentioned newer
kernels have both security and bug fixes.  As long as you stick with stable
gentoo-sources you'll have these in your system.  Later kernels also come with
additional kernel drivers for new(er) hardware.  You may not need/want these
drivers if you do not run the latest hardware. Using 'make oldconfig' allows
you to exclude such new drivers, but include new security options and/or
functionality as desired.


Given that I remember the announcement that the linux kernel's memory 
requirements had increased to 6MB - in the days when Fedora et al 
demanded gigabytes simply to be able to run - I think almost any ancient 
hardware you can actually buy will be able to run the linux kernel no probs.


You might have difficulty compiling it, though, now 386 support has been 
pretty much dropped from the toolchain. Have they dropped i686 as well?


Cheers,
Wol

Re: [PATCH] [testsuite] [arm] accept empty init for bfloat16

[Richard Earnshaw (lists)]

On 16/04/2024 04:50, Alexandre Oliva wrote:
> 
> Complete r13-2205, adjusting an arm-specific test that expects a
> no-longer-issued error at an empty initializer.
> 
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/arm/bfloat16_scalar_typecheck.c: Accept C23
> empty initializers.
> ---
>  .../gcc.target/arm/bfloat16_scalar_typecheck.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c 
> b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> index 8c80c55bc9f4c..04ede93bda152 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> @@ -42,7 +42,7 @@ bfloat16_t footest (bfloat16_t scalar0)
>short initi_1_4 = glob_bfloat; /* { dg-error {invalid conversion from type 
> 'bfloat16_t'} } */
>double initi_1_5 = glob_bfloat; /* { dg-error {invalid conversion from 
> type 'bfloat16_t'} } */
>  
> -  bfloat16_t scalar2_1 = {}; /* { dg-error {empty scalar initializer} } */
> +  bfloat16_t scalar2_1 = {};
>bfloat16_t scalar2_2 = { glob_bfloat };
>bfloat16_t scalar2_3 = { 0 }; /* { dg-error {invalid conversion to type 
> 'bfloat16_t'} } */
>bfloat16_t scalar2_4 = { 0.1 }; /* { dg-error {invalid conversion to type 
> 'bfloat16_t'} } */
> @@ -94,7 +94,7 @@ bfloat16_t footest (bfloat16_t scalar0)
>  
>/* Compound literals.  */
>  
> -  (bfloat16_t) {}; /* { dg-error {empty scalar initializer} } */
> +  (bfloat16_t) {};
>(bfloat16_t) { glob_bfloat };
>(bfloat16_t) { 0 }; /* { dg-error {invalid conversion to type 
> 'bfloat16_t'} } */
>(bfloat16_t) { 0.1 }; /* { dg-error {invalid conversion to type 
> 'bfloat16_t'} } */
> 


This test is checking for errors.  Perhaps it would be better to select an 
older version of the standard and then set pedantic-error mode.

R.

Re: [testsuite] [aarch64] Require fpic effective target

[Richard Earnshaw (lists)]

On 16/04/2024 04:08, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
> 
> Co-authored-by: Olivier Hainque 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/aarch64/pr94201.c: Add missing
>   dg-require-effective-target fpic.
>   * gcc.target/aarch64/pr103085.c: Likewise.
> 
> ---
>  gcc/testsuite/gcc.target/aarch64/pr103085.c |1 +
>  gcc/testsuite/gcc.target/aarch64/pr94201.c  |1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr103085.c 
> b/gcc/testsuite/gcc.target/aarch64/pr103085.c
> index dbc9c15b71f22..347280ed42b2d 100644
> --- a/gcc/testsuite/gcc.target/aarch64/pr103085.c
> +++ b/gcc/testsuite/gcc.target/aarch64/pr103085.c
> @@ -1,5 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -fstack-protector-strong -fPIC" } */
> +/* { dg-require-effective-target fpic } */
>  
>  void g(int*);
>  void
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr94201.c 
> b/gcc/testsuite/gcc.target/aarch64/pr94201.c
> index 691761691868a..3b9b79059e02b 100644
> --- a/gcc/testsuite/gcc.target/aarch64/pr94201.c
> +++ b/gcc/testsuite/gcc.target/aarch64/pr94201.c
> @@ -1,5 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-options "-mcmodel=tiny -mabi=ilp32 -fPIC" } */
> +/* { dg-require-effective-target fpic } */
>  
>  extern int bar (void *);
>  extern long long a;
> 


OK

R.

Re: [PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests

[Richard Earnshaw (lists)]

On 16/04/2024 04:48, Alexandre Oliva wrote:
> 
> 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
> requirement for a 8.1-m.main-compatible toolchain is enough to avoid
> those fails, because the toolchain feature test fails in kernel mode.
> 
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * g++.target/arm/pac-1.C: Require arm_arch_v8_1m_main.
>   * gcc.target/arm/acle/pacbti-m-predef-11.c: Likewise.
>   * gcc.target/arm/acle/pacbti-m-predef-12.c: Likewise.
>   * gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise.
>   * gcc.target/arm/bti-1.c: Likewise.
>   * gcc.target/arm/bti-2.c: Likewise.
> ---
>  gcc/testsuite/g++.target/arm/pac-1.C   |1 +
>  .../gcc.target/arm/acle/pacbti-m-predef-11.c   |1 +
>  .../gcc.target/arm/acle/pacbti-m-predef-12.c   |1 +
>  .../gcc.target/arm/acle/pacbti-m-predef-7.c|1 +
>  gcc/testsuite/gcc.target/arm/bti-1.c   |1 +
>  gcc/testsuite/gcc.target/arm/bti-2.c   |1 +
>  6 files changed, 6 insertions(+)
> 
> diff --git a/gcc/testsuite/g++.target/arm/pac-1.C 
> b/gcc/testsuite/g++.target/arm/pac-1.C
> index f671a27b048c6..f48ad6cc5cb65 100644
> --- a/gcc/testsuite/g++.target/arm/pac-1.C
> +++ b/gcc/testsuite/g++.target/arm/pac-1.C
> @@ -2,6 +2,7 @@
>  /* { dg-do compile } */
>  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> "-mcpu=*" } } */
>  /* { dg-options "-march=armv8.1-m.main+mve+pacbti 
> -mbranch-protection=pac-ret -mthumb -mfloat-abi=hard -g -O0" } */
> +/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */

The require-effective-target flags test whether a specific set of flags will 
make the compilation work, so they need to be used in conjunction with the 
corresponding dg-add-options flags that then apply those options.  It isn't 
safe to just add a different architecture flag instead.  So if you're going to 
use this effective target, you should use it along with "dg-add-options 
arm_arch_v8_1m_main" (ie the effective-target name minus the trailing '_ok'), 
and then replace dg-options with dg-additional-options adding the remaining 
flags.  You can then remove the dg-skip-if as well because that's what the 
require-effective-target flag is doing.  So something like

dg-do compile
dg-require-effective-target arm_arch_v8_1m_main_ok
dg-add-options arm_arch_v8_1m_main
dg-additional-options "-mbranch-protection=pac-ret -g -O0"

But this test is also adding pacbti to the architecture flags, so it would 
probably be better to use v8_1m_main_pacbti_ok as the effective target.  It's 
not identical to the options above, but it's probably sufficient for this test. 
 Each test below will need checking for the exact flags that are needed for the 
test in question.


>  
>  __attribute__((noinline)) void
>  fn1 (int a, int b, int c)
> diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c 
> b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
> index 6a5ae92c567f3..dba4f491cfea7 100644
> --- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
> +++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> "-mcpu=*" "-mfloat-abi=*" } } */
>  /* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */
> +/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
>  
>  #if (__ARM_FEATURE_BTI != 1)
>  #error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined to 1."
> diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c 
> b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
> index db40b17c3b030..308a41eb4ba4c 100644
> --- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
> +++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> "-mcpu=*" } } */
>  /* { dg-options "-march=armv8-m.main+fp -mfloat-abi=softfp" } */
> +/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
>  
>  #if defined (__ARM_FEATURE_BTI)
>  #error "Feature test macro __ARM_FEATURE_BTI should not be defined."
> diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c 
> b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
> index 1b25907635e24..10836a84bde56 100644
> --- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
> +++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
> @@ -1,6 +1,7 @@
>  /* { dg-do compile } */
>  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> "-mcpu=*" } } */
>  /* { dg-additional-options "-march=armv8.1-m.main+pacbti+fp --save-temps 
> -mfloat-abi=hard" } */
> +/* { 

Re: cloudstack on debian 10/11

[lists]

 
 
 
I did in fact get a debian 11 install up and running pretty much as a 
management server and almost good as a host. Have to figure out why the 
cloidbr0 is on a 169.xxx adress and why no centos template was downloaded. 
Systemvms came up without a problem.
 

 

 

 

 
 
 
 
 
>  
> On Apr 15, 2024 at 3:58 PM, Nuxwrote:
>  
>  
>  Found some notes on Debian here, there could be others..
> https://gist.github.com/rohityadavcloud/fc401a0fe8e8ea16b4b3a4e3d149ce0c
>
> On 2024-04-15 09:54, Nux wrote:
> >  Not as yet, no formal support for Debian.
> >  That said, this could change in the future..
> >  If you're a keen Debianista then it might be worth having a go 
> >  nevertheless, it might just work or with minimum changes.
> >  
> >  
> >  On 2024-04-13 10:49, Embedded wrote:
> >>  the install guide states Preferred: CentOS/RHEL 7.2+ or Ubuntu 
> >>  16.04(.2) or higher
> >>  
> >>  
> >>  would this include say debian 10/11 as a manager / and host/kvm 
> >>  hypervisor ???
>
 

Re: Glissandos into Note

[Wols Lists]

On 14/04/2024 00:22, Wols Lists wrote:

On 13/04/2024 10:34, Lukas-Fabian Moser via LilyPond user discussion wrote:

Hi Ben, hi Greg,

thanks for bringing this up - in fact I started this morning to dig up 
my old work, prompted by Greg's question.


It seems I only developed the functions a but further back then 
(unfortunately I don't have time at the moment to look into it in 
detail) - the difference seems to be that now, bends also avoid Dots. 
See the attached version.



All this was written for me by Han-Wen way back when (in the 2.4 days?).

This feature should be in lilypond somewhere, not sure exactly where 
though.



Found it...

https://lilypond.org/doc/v2.23/Documentation/notation/expressive-marks-as-curves

It's called a doit.

Cheers,
Wol

Re: Glissandos into Note

[Wols Lists]

On 13/04/2024 10:34, Lukas-Fabian Moser via LilyPond user discussion wrote:

Hi Ben, hi Greg,

thanks for bringing this up - in fact I started this morning to dig up 
my old work, prompted by Greg's question.


It seems I only developed the functions a but further back then 
(unfortunately I don't have time at the moment to look into it in 
detail) - the difference seems to be that now, bends also avoid Dots. 
See the attached version.



All this was written for me by Han-Wen way back when (in the 2.4 days?).

This feature should be in lilypond somewhere, not sure exactly where though.

Cheers,
Wol

Re: [gentoo-user] NAS box and switching from Phenom II X6 1090T to FX-6300

[Wols Lists]

On 13/04/2024 14:23, Dale wrote:

I see lots of mobos with those little hard drives on a stick.  I think
they called NVME or something, may have spelling wrong.  For most
people, that is likely awesome.  For me, I think I'd be happy with a
regular SSD.  Given that, I'd like them to make a mobo where one can say
cut off/disable that NVME thing and make use of that "lane" as a PCIe
slot(s).  Even if that means having a cable that hooks to the mobo and
runs elsewhere to connect PCIe cards.  In other words, have one slot
that is expandable to say three or four slots with what I think is
called a back-plane.  That way if a user wants to use the NVME thing,
they can.  If they don't, they can disable it and go another route with
PCIe expansion.  Sort of reminds me of that SAS drive thing.  You have
one cable that branches out into several SATA drives or SAS drives
themselves.  I don't know a lot about SAS really.  May have to read up
on that with that new case that holds 18 drives tho.  O_o


Read up on your mobo.

Certainly on mine, that thing where you can use NVME *OR* OCIe *OR* Sata 
is a thing on mine.


There's a nice table in the mobo manual that tells you which combos are 
supported.


Cheers,
Wol

Re: [yocto] Any recommendation to make software layer Yocto Compatible?

[Jan-Simon Möller via lists . yoctoproject . org]

Hi Duy,

The recipe in question was done by the Instrument Cluster EG, we can work on 
this with the group (main contact Yamaguchi-san). They do meet every other 
monday. See: https://lists.automotivelinux.org/g/agl-dev-community/calendar 

We do exacly what Paul describes all the time in meta-agl to pass the yocto-
check-layer:

e.g.
https://git.automotivelinux.org/AGL/meta-agl/tree/meta-agl-core/recipes-core/
systemd/systemd_%25.bbappend
and
https://git.automotivelinux.org/AGL/meta-agl/tree/meta-agl-core/recipes-core/
systemd/systemd_aglcore.inc

The condition can be on DISTRO_FEATURES or other variables. We try not to 
overload the usage of DISTRO_FEATURES as a change there will trigger a reparse 
in a lot of locations and hence possibly rebuilds. Thus the use of 
AGL_FEATURES in above example for anything that is directly related to AGL and 
is not a DISTRO_FEATURE in yocto already. 

For dlt-daemon in your example, we have these options and recommendations:
a) use such a conditional include as shown above ... simple but it will not fix 
all the issues
b) use :append:  only in .bbappend files
 (name says it all ;) )
e.g. :append:aglcontainerguest
or
e.g.  :append:aglcontainerhost
The 2nd condition / override is important here to pass the check.
A simple :append  would triger
c) distill the recipe down to just the required changes & if possible upstream 
these (e.g. PACKAGECONFIG options) ... config file changes can also be added in 
a "dlt-daemon-conf" package and replace or amend the original files. This helps 
most.

a) will have immediate effect but only c) and b) will lower the workload mid-
term. 

A path forward would then be:
Upstream the PACKAGECONFIG bits . It might make sense to rework the package so 
there is a configuration sub-package that is replaceable by the user. Then most 
conf file changes are in a separate package and can be easily replaced by the 
user w/o even touching the main (binary) package. That is of importance for 
reproducible builds and binary feeds. 



Am Montag, 8. April 2024, 14:36:38 CEST schrieb Duy via 
lists.yoctoproject.org:
> Hi Richard,
> 
> Thanks for your response.
> Here is one of the recipe bbappend files I'm working on:
> meta-agl-ic-container/recipes-extended/dlt-daemon/dlt-daemon_%.bbappend ·
> master · Automotive Grade Linux / AGL / meta-agl-devel · GitLab (
> https://gitlab.com/automotivegradelinux/AGL/meta-agl-devel/-/blob/master/me
> ta-agl-ic-container/recipes-extended/dlt-daemon/dlt-daemon_%25.bbappend?ref_
> type=heads )
> meta-agl-ic-container/recipes-extended/dlt-daemon/dlt-daemon_%.bbappend ·
> master · Automotive Grade Linux / AGL / meta-agl-devel · GitLab (
> https://gitlab.com/automotivegradelinux/AGL/meta-agl-devel/-/blob/master/me
> ta-agl-ic-container/recipes-extended/dlt-daemon/dlt-daemon_%25.bbappend?ref_
> type=heads )
> 
> I think some configurations are better to be upstreaming, e.g: Adding new
> PACKAGES, adding new PACKAGECONFIG. It avoids adding too much to bbappend.
> If you have any idea, please share it.
> 
> Best Regards,
> Duy Dang





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62929): https://lists.yoctoproject.org/g/yocto/message/62929
Mute This Topic: https://lists.yoctoproject.org/mt/105397924/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [arch-announce] Increasing the default vm.max_map_count value

[Genes Lists]

On Sun, 2024-04-07 at 18:12 +, Arch Linux: Recent news updates:
Robin Candau wrote:
> The [vm.max_map_count][1] paramater will be increased from the
> default `65530` value to `1048576`.

> 
> This change should help address performance, crash or start-up issues
> for a number of memory intensive applications, 

Performance improvement is unlikely but could allow something to run
that otherwise would not. 
The lkml comment [1] is worth a read and includes :

    "To be clear, what you are doing here is akin to adding more memory
to
   your system when there is a memory leak.  This is not the solution
you
   should be pushing.  Ironically, this is using more memory and
performing
   worse than it should.  At best, the limit increase is a workaround
for
   buggy programs."

As Robin said, setting the max higher is probably benign - and only
impacts a system running the problematic software (games).

Nonetheless, it is very simple to change it to whatever value you want
with your own prefs dropped into /etc/sysctl.d/xxx.conf

gene


 [1] https://lore.kernel.org/lkml/566168554.272637693.1710968734203.Jav
aMail.root@zimbra54-
e10.priv.proxad.net/T/#m1905a48f415bc6e8069a8fe53dec44bc311571f2


-- 
Gene



signature.asc
Description: This is a digitally signed message part

Re: [9fans] troll paper

[lists]

Never mind, https://iwp9.org/10iwp9proceedings.pdf

> On Apr 12, 2024, at 06:56, David Arnold  wrote:
> 
> 
>> 
>> The vetting process needs some work, lads.
> 
> More heresy than trolling, perhaps?
> 
> It was thought-provoking for me.  I wished I was there for the bar session 
> afterwards.
> 
> d

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M9dd436078709478f3864eb51
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[lists]

Where’s the link? I haven’t seen one yet for reading papers in advance.  Still 
one hour to go…

> On Apr 12, 2024, at 06:04, Anthony Martin  wrote:
> 
> "Do we really have to have our own kernel? What are
> the benefits?" ...
> 
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM? I read the
> whole thing and it was a waste of time. Zero stars, would
> not recommend.
> 
> Institutional Academy of the Academic Institute, lol.
> 
> The vetting process needs some work, lads.
> 
> Cheers,
>  Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M73f3dc3b7bb66b0db2117c83
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Overriding default text of \f, \p, etc.

[Wols Lists]

On 12/04/2024 08:21, YTG 1234 wrote:

Hello List,

I want to override the default text markup used with commands such as 
\f, \p, \mf, etc.


However, trying to define f = #(make-dynamic-script ...) doesn't work 
because Lilypond interprets f as a note-name.


Additionally, how would I be able to change the text while maintaining 
the MIDI effect? I tried using \tweak DynamicText.text but it doesn't 
seem to override the text...


This is my file that defines assorted dynamic markups (it's an old 
lilypond version so I'm sure it can be improved ...


% This contains assorted dynamics functions ...

% dynamic setting - "p - ff"
pthenff = _\markup{ \dynamic p \italic "-" \dynamic ff }

% dynamic setting - "f - p"
fthenp = _\markup{ \dynamic f \italic "-" \dynamic p }

mfthenff = _\markup{ \dynamic mf \italic "-" \dynamic ff }

% this is the correct way to do it ...
sfzp = #(make-dynamic-script "sfzp")
piu-f = #(make-dynamic-script #{ \markup { \normal-text \italic piu f } #})

fzp = _\markup{ \dynamic fzp }
% forzando - piano
ffzp = _\markup{
\dynamic ffzp
}

% sforzandi
sffz = _\markup{ \dynamic sffz }
sfffz = _\markup{ \dynamic sfffz }



moltoff = _\markup{
  \bold \italic molto \dynamic ff
}

piuf = _\markup{
  \bold \italic piu \dynamic f
}


Cheers,
Wol

[PATCH] aarch64: Fix _BitInt testcases

[Andre Vieira (lists)]

This patch fixes some testisms introduced by:

commit 5aa3fec38cc6f52285168b161bab1a869d864b44
Author: Andre Vieira 
Date:   Wed Apr 10 16:29:46 2024 +0100

aarch64: Add support for _BitInt

The testcases were relying on an unnecessary sign-extend that is no longer
generated.

The tested version was just slightly behind top of trunk when the patch 
was committed, and the codegen had changed, for the better, by then.


OK for trunk? (I am away tomorrow, so if you want this in before the 
weekend feel free to commit it on my behalf, if approved ofc...)



gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-bitint-abi-align16.c (g1, g8, g16, g1p, 
g8p,
g16p): Remove unnecessary sbfx.
* gcc.target/aarch64/bitfield-bitint-abi-align8.c (g1, g8, g16, g1p, 
g8p,
g16p): Likewise.


diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
index 
3f292a45f955d35b802a0bd789cd39d5fa7b5860..4a228b0a1ce696dc80e32305162d58f01d44051d
 100644
--- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
@@ -55,9 +55,8 @@
 ** g1:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f1
 */
@@ -66,9 +65,8 @@
 ** g8:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f8
 */
@@ -76,9 +74,8 @@
 ** g16:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f16
 */
@@ -107,9 +104,8 @@
 /*
 ** g1p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f1p
@@ -117,9 +113,8 @@
 /*
 ** g8p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f8p
@@ -128,9 +123,8 @@
 ** g16p:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f16p
 */
diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
index 
da3c23550bae6734f69e2baf0e8db741fb65cfda..e7f773640f04f56646e5e1a5fb91280ea7e4db98
 100644
--- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
@@ -54,9 +54,8 @@
 /*
 ** g1:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f1
@@ -65,9 +64,8 @@
 /*
 ** g8:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f8
@@ -76,9 +74,8 @@
 ** g16:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f16
 */
@@ -107,9 +104,8 @@
 /*
 ** g1p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f1p
@@ -117,9 +113,8 @@
 /*
 ** g8p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f8p
@@ -128,9 +123,8 @@
 ** g16p:
 ** mov (x[0-9]+), x0
 ** mov w0, w1

[AFMUG] WTB - epmp 1000 2.4ghz AP with GPS

[lists gogebicrange . net]

Does anyone have any epmp 1000 2.4 AP's with GPS sitting around? We still have 
some in service and I don't have any spares on the shelf.

You can email me at bran...@gogebicrange.net 
if you do.

Thanks,
Brandon

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

[PATCH][wwwdocs] gcc-14/changes.html: Update _BitInt to include AArch64 (little-endian)

[Andre Vieira (lists)]

Hi,

Patch to add AArch64 to the list of supported _BitInt(N) in 
gcc-14/changes.html.


OK?diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 
a7ba957110183f906938d935bfa17aaed2ba20c8..55ab8c14c6d0b54e05a5f266f25c8ef1a4f959bf
 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -216,7 +216,7 @@ a work-in-progress.
   Bit-precise integer types (_BitInt (N)
   and unsigned _BitInt (N)): integer types with
   a specified number of bits.  These are only supported on
-  IA-32/x86-64 at present.
+  IA-32/x86-64 and AArch64 (little-endian) at present.
   Structure, union and enumeration types may be defined more
   than once in the same scope with the same contents and the same
   tag; if such types are defined with the same contents and the

Re: [PATCHv3 2/2] aarch64: Add support for _BitInt

[Andre Vieira (lists)]

Added the target check, also had to change some of the assembly checking 
due to changes upstream, the assembly is still valid, but we do extend 
where not necessary, I do believe that's a general issue though.


The _BitInt(N > 64) codegen for non-powers of 2 did get worse, we see 
similar codegen with _int128 bitfields on aarch64.
I suspect we need to improve the way we 'extend' TImode in the aarch64 
backend to be able to operate only on the affected DImode parts of it 
when relevant. Though I also think we may need to change how _BitInt is 
currently expanded in such situations, right now it does the extension 
as two shifts. Anyway I did not have too much time to look deeper into this.


Bootstrapped on aarch64-unknown-linux-gnu.

OK for trunk?

On 28/03/2024 15:21, Richard Sandiford wrote:

Jakub Jelinek  writes:

On Thu, Mar 28, 2024 at 03:00:46PM +, Richard Sandiford wrote:

* gcc.target/aarch64/bitint-alignments.c: New test.
* gcc.target/aarch64/bitint-args.c: New test.
* gcc.target/aarch64/bitint-sizes.c: New test.
* gcc.target/aarch64/bitfield-bitint-abi.h: New header.
* gcc.target/aarch64/bitfield-bitint-abi-align16.c: New test.
* gcc.target/aarch64/bitfield-bitint-abi-align8.c: New test.


Since we don't support big-endian yet, I assume the tests should be
conditional on aarch64_little_endian.


Perhaps better on bitint effective target, then they'll become available
automatically as soon as big endian aarch64 _BitInt support is turned on.


Ah, yeah, good point.

Richarddiff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
81400cc666472ffeff40df14e98ae00ebc774d31..c0af4ef151a8c46f78c0c3a43c2ab1318a3f610a
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6583,6 +6583,7 @@ aarch64_return_in_memory_1 (const_tree type)
   int count;
 
   if (!AGGREGATE_TYPE_P (type)
+  && TREE_CODE (type) != BITINT_TYPE
   && TREE_CODE (type) != COMPLEX_TYPE
   && TREE_CODE (type) != VECTOR_TYPE)
 /* Simple scalar types always returned in registers.  */
@@ -21996,6 +21997,11 @@ aarch64_composite_type_p (const_tree type,
   if (type && (AGGREGATE_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE))
 return true;
 
+  if (type
+  && TREE_CODE (type) == BITINT_TYPE
+  && int_size_in_bytes (type) > 16)
+return true;
+
   if (mode == BLKmode
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
@@ -28477,6 +28483,42 @@ aarch64_excess_precision (enum excess_precision_type 
type)
   return FLT_EVAL_METHOD_UNPREDICTABLE;
 }
 
+/* Implement TARGET_C_BITINT_TYPE_INFO.
+   Return true if _BitInt(N) is supported and fill its details into *INFO.  */
+bool
+aarch64_bitint_type_info (int n, struct bitint_info *info)
+{
+  if (TARGET_BIG_END)
+return false;
+
+  if (n <= 8)
+info->limb_mode = QImode;
+  else if (n <= 16)
+info->limb_mode = HImode;
+  else if (n <= 32)
+info->limb_mode = SImode;
+  else if (n <= 64)
+info->limb_mode = DImode;
+  else if (n <= 128)
+info->limb_mode = TImode;
+  else
+/* The AAPCS for AArch64 defines _BitInt(N > 128) as an array with
+   type {signed,unsigned} __int128[M] where M*128 >= N.  However, to be
+   able to use libgcc's implementation to support large _BitInt's we need
+   to use a LIMB_MODE that is no larger than 'long long'.  This is why we
+   use DImode for our internal LIMB_MODE and we define the ABI_LIMB_MODE to
+   be TImode to ensure we are ABI compliant.  */
+info->limb_mode = DImode;
+
+  if (n > 128)
+info->abi_limb_mode = TImode;
+  else
+info->abi_limb_mode = info->limb_mode;
+  info->big_endian = TARGET_BIG_END;
+  info->extended = false;
+  return true;
+}
+
 /* Implement TARGET_SCHED_CAN_SPECULATE_INSN.  Return true if INSN can be
scheduled for speculative execution.  Reject the long-running division
and square-root instructions.  */
@@ -30601,6 +30643,9 @@ aarch64_run_selftests (void)
 #undef TARGET_C_EXCESS_PRECISION
 #define TARGET_C_EXCESS_PRECISION aarch64_excess_precision
 
+#undef TARGET_C_BITINT_TYPE_INFO
+#define TARGET_C_BITINT_TYPE_INFO aarch64_bitint_type_info
+
 #undef  TARGET_EXPAND_BUILTIN
 #define TARGET_EXPAND_BUILTIN aarch64_expand_builtin
 
diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
new file mode 100644
index 
..3f292a45f955d35b802a0bd789cd39d5fa7b5860
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
@@ -0,0 +1,384 @@
+/* { dg-do compile { target bitint } } */
+/* { dg-additional-options "-std=c23 -O2 -fno-stack-protector -save-temps 
-fno-schedule-insns -fno-schedule-insns2" } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#define ALIGN 16
+#include "bitfield-bitint-abi.h"
+
+// f1-f16 are all the same
+

Re: [PATCHv2 1/2] aarch64: Do not give ABI change diagnostics for _BitInt(N)

[Andre Vieira (lists)]

Hey,

Added the warn_pcs_change_le_gcc14 variable and changed the uses of 
warn_pcs_change to use this new variable.
Also fixed an issue with the loop through TREE_FIELDS to avoid an ICE 
during bootstrap.


OK for trunk?

Bootstrapped and regression tested on aarch64-unknown-linux-gnu.

Kind regards,
Andre

On 28/03/2024 12:54, Richard Sandiford wrote:

"Andre Vieira (lists)"  writes:

This patch makes sure we do not give ABI change diagnostics for the ABI
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
type did not exist before this GCC version.

ChangeLog:

* config/aarch64/aarch64.cc (bitint_or_aggr_of_bitint_p): New function.
(aarch64_layout_arg): Don't emit diagnostics for types involving
_BitInt(N).

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
1ea84c8bd7386e399f6ffa3a5e36408cf8831fc6..b68cf3e7cb9a6fa89b4e5826a39ffa11f64ca20a
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6744,6 +6744,33 @@ aarch64_function_arg_alignment (machine_mode mode, 
const_tree type,
return alignment;
  }
  
+/* Return true if TYPE describes a _BitInt(N) or an angreggate that uses the

+   _BitInt(N) type.  These include ARRAY_TYPE's with an element that is a
+   _BitInt(N) or an aggregate that uses it, and a RECORD_TYPE or a UNION_TYPE
+   with a field member that is a _BitInt(N) or an aggregate that uses it.
+   Return false otherwise.  */
+
+static bool
+bitint_or_aggr_of_bitint_p (tree type)
+{
+  if (!type)
+return false;
+
+  if (TREE_CODE (type) == BITINT_TYPE)
+return true;
+
+  /* If ARRAY_TYPE, check it's element type.  */
+  if (TREE_CODE (type) == ARRAY_TYPE)
+return bitint_or_aggr_of_bitint_p (TREE_TYPE (type));
+
+  /* If RECORD_TYPE or UNION_TYPE, check the fields' types.  */
+  if (RECORD_OR_UNION_TYPE_P (type))
+for (tree field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field))
+  if (bitint_or_aggr_of_bitint_p (TREE_TYPE (field)))
+   return true;
+  return false;
+}
+
  /* Layout a function argument according to the AAPCS64 rules.  The rule
 numbers refer to the rule numbers in the AAPCS64.  ORIG_MODE is the
 mode that was originally given to us by the target hook, whereas the
@@ -6767,12 +6794,6 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const 
function_arg_info )
if (pcum->aapcs_arg_processed)
  return;
  
-  bool warn_pcs_change

-= (warn_psabi
-   && !pcum->silent_p
-   && (currently_expanding_function_start
-  || currently_expanding_gimple_stmt));
-
/* HFAs and HVAs can have an alignment greater than 16 bytes.  For example:
  
 typedef struct foo {

@@ -6907,6 +6928,18 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const 
function_arg_info )
  && (!alignment || abi_break_gcc_9 < alignment)
  && (!abi_break_gcc_13 || alignment < abi_break_gcc_13));
  
+

+  bool warn_pcs_change
+= (warn_psabi
+   && !pcum->silent_p
+   && (currently_expanding_function_start
+  || currently_expanding_gimple_stmt)
+  /* warn_pcs_change is currently used to gate diagnostics in case of
+abi_break_gcc_{9,13,14}.  These however, do not apply to _BitInt(N)
+types as they were only introduced in GCC 14.  */
+   && (!type || !bitint_or_aggr_of_bitint_p (type)));


How about making this a new variable such as:

   /* _BitInt(N) was only added in GCC 14.  */
   bool warn_pcs_change_le_gcc14
 = (warn_psabi && !bitint_or_aggr_of_bitint_p (type);

(and keeping warn_pcs_change where it is).  In principle, warn_pcs_change
is meaningful for any future ABI breaks, and we might forget that it
excludes bitints.  The name is just a suggestion.

OK with that change, thanks.

Richard


+
+
/* allocate_ncrn may be false-positive, but allocate_nvrn is quite reliable.
   The following code thus handles passing by SIMD/FP registers first.  */
  
@@ -21266,19 +21299,25 @@ aarch64_gimplify_va_arg_expr (tree valist, tree type, gimple_seq *pre_p,

rsize = ROUND_UP (size, UNITS_PER_WORD);
nregs = rsize / UNITS_PER_WORD;
  
-  if (align <= 8 && abi_break_gcc_13 && warn_psabi)

+  if (align <= 8
+ && abi_break_gcc_13
+ && warn_psabi
+ && !bitint_or_aggr_of_bitint_p (type))
inform (input_location, "parameter passing for argument of type "
"%qT changed in GCC 13.1", type);
  
if (warn_psabi

  && abi_break_gcc_14
- && (abi_break_gcc_14 > 8 * BITS_PER_UNIT) != (align > 8))
+ && (abi_break_gcc_14 > 8 * BITS_PER_UNIT) != (align > 8)
+ && !bitint_or_aggr_of_bitint_p (type))
inform (input_location, "parameter passing for argu

Re: [gentoo-user] Successfully upgraded to new profile 23.0

[Wols Lists]

On 08/04/2024 15:03, Dr Rainer Woitok wrote:

the upgrade on my old laptop  with two 2.7GHz  Dual-Core Skylake proces-
sors took slightly  more than 2 hours  for the manual upgrading of "bin-
utils", "gcc" and "glibc", and slightly more than 21.5 hours for the fi-
nal upgrade of "@world",  which had to process a total of 1061 packages.
I'm wondering whether  a fresh install  from a stage 3  "tar" ball would
have been faster?


Some 1500 plus packages here - took about 2 days on my 4-core Ryzen ...

Btw, where are all the messages for packages stored? I ought to go 
through them and make sure there aren't any messages of interest... I 
know I ought to update my kernel ...


Cheers,
Wol

biggest backdoor hack

[Drew Adams via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

https://theintercept.com/2024/04/03/linux-hack-xz-utils-backdoor/

---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"

[Why 42? The lists account.]

On Sat, Apr 06, 2024 at 02:42:25PM +0200, Eivind Eide wrote:
> After upgrading to 7.5 amd64 -stable  (and all ports updated) I get
> these messages in /var/log/messages. This is with bash from ports
> inside tmux over SSH:
> 
> tmux: vfprintf %s NULL in "%.*s"
> bash: vfprintf %s NULL in "%.*s"
> multitail: vfprintf %s NULL in "%.*s"
> vim: vfprintf %s NULL in "%.*s"

FYI, I grepped my messages and saw something similar:
mjoelnir:~ 9.04 14:10:46 % grep printf /var/log/messages
Apr  4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part 
with type='%s' for '%s'"
Apr  4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part 
with type='%s' for '%s'"
Apr  8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr  8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr  9 13:57:06 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr  9 13:57:06 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s, 
%s, %s}, moon={%s, %s, %s, %s, %s} "

The "wrapper-2.0" program is, I think, part of XFCE, I see that name in
the desktop panel configuraion. Tumbler is something to do with D-Bus and
is also a required package by/for XFCE.

Cheers,
Robb.


mjoelnir:~ 9.04 14:11:01 % uname -a
OpenBSD mjoelnir.fritz.box 7.5 GENERIC.MP#18 amd64

mjoelnir:~ 9.04 14:10:54 % echo $TERM
rxvt-unicode-256color

mjoelnir:~ 9.04 14:10:50 % locale
LANG=
LC_COLLATE=C
LC_CTYPE=en_US.UTF-8
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=

mjoelnir:~ 9.04 14:11:04 % egrep -v '^(#|$)' .xsession
NO_AT_BRIDGE=1 ; export NO_AT_BRIDGE
LC_CTYPE="en_US.UTF-8"; export LC_CTYPE
LC_COLLATE=C; export LC_COLLATE
xrandr --dpi 109
xset +fp /usr/local/share/fonts/Hack
xset +fp /usr/local/share/fonts/terminus
xset +fp /usr/local/share/fonts/victor-mono
/usr/local/bin/startxfce4

Re: Patches submission policy change

[Richard Earnshaw (lists) via Gcc]

On 03/04/2024 14:23, Christophe Lyon via Gcc wrote:
> On Wed, 3 Apr 2024 at 14:59, Joel Sherrill  wrote:
>>
>> Another possible issue which may be better now than in years past
>> is that the versions of autoconf/automake required often had to be
>> installed by hand. I think newlib has gotten better but before the
>> rework on its Makefile/configure, I had a special install of autotools
>> which precisely matched what it required.
>>
>> And that led to very few people being able to successfully regenerate.
>>
>> Is that avoidable?
>>
>> OTOH the set of people touching these files may be small enough that
>> pain isn't an issue.
>>
> 
> For binutils/gcc/gdb we still have to use specific versions which are
> generally not the distro's ones.

That's because at least some distros modify autoconf to their own taste/needs, 
so that it does not generate the same output as the officially released 
version.  Furthermore, they provide no mechanism to make their version revert 
back to the original behaviour.

R.

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 16:08, Michael wrote:

Cool, once your system is up to date you should be able to change your profile
and follow the rest of the instructions.  I hope all goes well.  


emerge --emptytree is now running well - 122 of 1534 so it has some way 
to go ...


Cheers,
Wol

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 15:46, Wols Lists wrote:

On 07/04/2024 13:07, Michael wrote:

On Sunday, 7 April 2024 12:04:32 BST Wols Lists wrote:

On 07/04/2024 11:48, Wols Lists wrote:

On 07/04/2024 11:23, Michael wrote:

On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote:

On 07/04/2024 11:00, Wols Lists wrote:

What do I do here - "emerge binutils" (step 9) wants to emerge gcc,
which the instructions say "emerge AFTER binutils".

With gcc it says "don't let it emerge glibc", should I apply the 
same

logic and not let binutils emerge gcc?


Just to follow up to myself, I've just done a complete update, but 
a lot
of the dependencies are pulled in by "change-use", namely lzma, 
zstd. Is

that fallout from the XZ debacle? Would a --no-deps be safe?

Cheers,
Wol


Are you still on your original profile, or have you used eselect to
change it
to profile 23.0?

If the latter, change back to your old profile, update @world,
depclean and
then start with the rest of the migration instructions.


Just done that. See my other email.

NOTHING TO UPDATE (unless I've messed up my emerge ...)


Interesting ... just done this under the old profile ...

thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 3.19 s (backtrack: 0/20).


Nothing to merge; quitting.

Cheers,
Wol



Hmm ... something is amiss with your system.  Normally you would get 
this:


# emerge --ask --oneshot sys-devel/binutils

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 1.30 s (backtrack: 0/20).

[ebuild   R    ] sys-devel/binutils-2.41-r5

Would you like to merge these packages? [Yes/No]

Did you emerge any packages using the new 23.0 profile, then went back 
to the

old profile to run the above command?


No ...

Ummm ... I have had trouble emerging other stuff that didn't want to 
work with oneshot ...


Let me look at my make.conf - I had to over-ride something to get 
vbox-modules to emerge, this is probably the same thing ...


Yup - as soon as I comment the EMERGE_DEFAULT_OPTS out I get it asking 
me if I want to emerge binutils.


# EMERGE_DEFAULT_OPTS = "--buildpkg --deep --newuse --oneshot --usepkg"

So I'm doing an emerge @world now with the old profile ...

Yup - this appears to have un-bunged it - it's working as per 
instructions. You might want to add to the instructions to disable 
anything in make.conf that tampers with default settings.


Cheers,
Wol

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 13:07, Michael wrote:

On Sunday, 7 April 2024 12:04:32 BST Wols Lists wrote:

On 07/04/2024 11:48, Wols Lists wrote:

On 07/04/2024 11:23, Michael wrote:

On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote:

On 07/04/2024 11:00, Wols Lists wrote:

What do I do here - "emerge binutils" (step 9) wants to emerge gcc,
which the instructions say "emerge AFTER binutils".

With gcc it says "don't let it emerge glibc", should I apply the same
logic and not let binutils emerge gcc?


Just to follow up to myself, I've just done a complete update, but a lot
of the dependencies are pulled in by "change-use", namely lzma, zstd. Is
that fallout from the XZ debacle? Would a --no-deps be safe?

Cheers,
Wol


Are you still on your original profile, or have you used eselect to
change it
to profile 23.0?

If the latter, change back to your old profile, update @world,
depclean and
then start with the rest of the migration instructions.


Just done that. See my other email.

NOTHING TO UPDATE (unless I've messed up my emerge ...)


Interesting ... just done this under the old profile ...

thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 3.19 s (backtrack: 0/20).


Nothing to merge; quitting.

Cheers,
Wol



Hmm ... something is amiss with your system.  Normally you would get this:

# emerge --ask --oneshot sys-devel/binutils

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 1.30 s (backtrack: 0/20).

[ebuild   R] sys-devel/binutils-2.41-r5

Would you like to merge these packages? [Yes/No]

Did you emerge any packages using the new 23.0 profile, then went back to the
old profile to run the above command?


No ...

Ummm ... I have had trouble emerging other stuff that didn't want to 
work with oneshot ...


Let me look at my make.conf - I had to over-ride something to get 
vbox-modules to emerge, this is probably the same thing ...


Yup - as soon as I comment the EMERGE_DEFAULT_OPTS out I get it asking 
me if I want to emerge binutils.


# EMERGE_DEFAULT_OPTS = "--buildpkg --deep --newuse --oneshot --usepkg"

So I'm doing an emerge @world now with the old profile ...

Cheers,
Wol

[netsurf-users] Re: 6696 fails to start on RISC OS

[lists]

I have just sent this email to Andrew Rawnsley drawing his attention to
the problem

-

Hi Andrew,

The hardwired SockWatch in !Uniprint is causing errors and will prevent it
using updated SockWatch modules when they are issued. !NetSurf is being
shipped with a newer version of SockWatch

People are having to go into the applications and modify the run file
themselves, which is not good. Please will you change this. See the two
Mailing list entries I have quoted below.

Dave's entry may be referring to RO6 but I find three entries for
SockWatch myself in RO5

In my case, in RO5.28, I have copies in:

$.!Boot.Resources.!Internet
$.!Boot.Resources.!System.310.Modules.Network
and
$.!Boot.Choices.Boot.PreDesk.!Uniprint

I don't have Hermes and I don't use !Netsurf much because I have Iris, so
I've not updated it recently.


Stuart

>From the NetSurf mailing list:

---

In article
,
   Rob Kendrick  wrote:
> On Thu, Apr 04, 2024 at 04:52:58PM +0100, Bob Latham wrote:
> > Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> > within the applications, there may be more.

> This is a bug in UniPrint and Hermes: the reason we have the System
> Merge tool is to prevent this exact situation: apps shouldn't be
> shipping their own modules internally because there will inevitably be a
> clash, as you have just experienced.

> I'm sure they've done this in the name of ease of installation, but it
> just messes stuff up for everyone else :(

> B.

---

In article <5b4cba41f5d...@triffid.co.uk>,
   Dave  wrote:
[Snippy]

> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".

> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch

> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.

> Dave

Sorry was busy with other things and forgot to mention...

I fixed it here by changing the Uniserver and Hermes !Run file "RMEnsure
SocketWatch" entries to point to System:Modules.Network.SockWatch instead
of their own internal SockWatch modules.

Dave
--

-- 
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

-- 
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 11:48, Wols Lists wrote:

On 07/04/2024 11:23, Michael wrote:

On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote:

On 07/04/2024 11:00, Wols Lists wrote:

What do I do here - "emerge binutils" (step 9) wants to emerge gcc,
which the instructions say "emerge AFTER binutils".

With gcc it says "don't let it emerge glibc", should I apply the same
logic and not let binutils emerge gcc?


Just to follow up to myself, I've just done a complete update, but a lot
of the dependencies are pulled in by "change-use", namely lzma, zstd. Is
that fallout from the XZ debacle? Would a --no-deps be safe?

Cheers,
Wol


Are you still on your original profile, or have you used eselect to 
change it

to profile 23.0?

If the latter, change back to your old profile, update @world, 
depclean and

then start with the rest of the migration instructions.


Just done that. See my other email.

NOTHING TO UPDATE (unless I've messed up my emerge ...)


Interesting ... just done this under the old profile ...

thewolery /usr/local/bin # emerge --ask --oneshot sys-devel/binutils

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 3.19 s (backtrack: 0/20).


Nothing to merge; quitting.

Cheers,
Wol

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 11:23, Michael wrote:

On Sunday, 7 April 2024 11:21:00 BST Wols Lists wrote:

On 07/04/2024 11:00, Wols Lists wrote:

What do I do here - "emerge binutils" (step 9) wants to emerge gcc,
which the instructions say "emerge AFTER binutils".

With gcc it says "don't let it emerge glibc", should I apply the same
logic and not let binutils emerge gcc?


Just to follow up to myself, I've just done a complete update, but a lot
of the dependencies are pulled in by "change-use", namely lzma, zstd. Is
that fallout from the XZ debacle? Would a --no-deps be safe?

Cheers,
Wol


Are you still on your original profile, or have you used eselect to change it
to profile 23.0?

If the latter, change back to your old profile, update @world, depclean and
then start with the rest of the migration instructions.


Just done that. See my other email.

NOTHING TO UPDATE (unless I've messed up my emerge ...)

Cheers,
Wol

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 11:15, Michael wrote:

On Sunday, 7 April 2024 11:00:49 BST Wols Lists wrote:

What do I do here - "emerge binutils" (step 9) wants to emerge gcc,
which the instructions say "emerge AFTER binutils".

With gcc it says "don't let it emerge glibc", should I apply the same
logic and not let binutils emerge gcc?

Cheers,
Wol


Step 1:

Ensure your system backups are up to date. Please also update your system
fully and depclean before proceeding.

Have you done this already after a fresh rsync of portage?


Note that my current profile is marked experimental ...

  [9]   default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr (exp)

and I also have no stable 20 or 22 profiles to upgrade to.

And "emerge --changed-use" gives me nothing to emerge.

thewolery /usr/local/bin # emerge --update --deep --changed-use --newuse 
@world

Calculating dependencies... done!
Dependency resolution took 21.46 s (backtrack: 0/20).

thewolery /usr/local/bin #


Cheers,
Wol

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 11:15, Michael wrote:

On Sunday, 7 April 2024 11:00:49 BST Wols Lists wrote:

What do I do here - "emerge binutils" (step 9) wants to emerge gcc,
which the instructions say "emerge AFTER binutils".

With gcc it says "don't let it emerge glibc", should I apply the same
logic and not let binutils emerge gcc?

Cheers,
Wol


Step 1:

Ensure your system backups are up to date. Please also update your system
fully and depclean before proceeding.

Have you done this already after a fresh rsync of portage?


YES.

I've printed off the list, and am working my way down it ...

My system defaults to deep, changed use, etc etc. I could revert the 
profile change and try again, we'll see.


Cheers,
Wol

Re: [gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

On 07/04/2024 11:00, Wols Lists wrote:
What do I do here - "emerge binutils" (step 9) wants to emerge gcc, 
which the instructions say "emerge AFTER binutils".


With gcc it says "don't let it emerge glibc", should I apply the same 
logic and not let binutils emerge gcc?


Just to follow up to myself, I've just done a complete update, but a lot 
of the dependencies are pulled in by "change-use", namely lzma, zstd. Is 
that fallout from the XZ debacle? Would a --no-deps be safe?


Cheers,
Wol

[gentoo-user] New profile - gentoo and binutils ...

[Wols Lists]

What do I do here - "emerge binutils" (step 9) wants to emerge gcc, 
which the instructions say "emerge AFTER binutils".


With gcc it says "don't let it emerge glibc", should I apply the same 
logic and not let binutils emerge gcc?


Cheers,
Wol

Re: Installing 2.24.1

[Wols Lists]

On 06/04/2024 22:46, Knute Snortum wrote:
On Sat, Apr 6, 2024 at 2:23 PM Wol > wrote:



  > The basic procedure is simple, assuming that you are using
  > Frescobaldi:

What if this assumption is wrong? I've NEVER used Frescobaldi (or
rather, the one time I tried I didn't see the point).

Will it work if I "install as administrator" and then tell Windows to
run lilypond when I click on a .ly file?

Is there any reason for expecting me to install an unwanted program, in
order to get a program I do want? Or are you trying to force everybody
to use Frescobaldi? Why?


There is a web page that deals with command-line installation, if that's 
what you want:


https://lilypond.org/doc/v2.24/Documentation/learning/command-line-setup 




Thanks. So basically "yes", I guessed as much.

I just need to re-associate the new version of lilypond with .ly files...

Cheers,
Wol

[netsurf-users] Re: 6696 fails to start on RISC OS

[lists]

In article <5b4cba41f5d...@triffid.co.uk>,
   Dave  wrote:

> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".

> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch

> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.

In my case, in RO5.28, I have copies in:

$.!Boot.Resources.!Internet
$.!Boot.Resources.!System.310.Modules.Network
and
$.!Boot.Choices.Boot.PreDesk.!Uniprint

I don't have Hermes and I don't use !Netsurf much because I have Iris, so
I've not updated it recently.

Perhaps this is something I need to look into.

-- 
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

[netsurf-users] Re: 6696 fails to start on RISC OS

[Richard Torrens (lists)]

In article <5b4c408979...@mightyoak.org.uk>,
   Bob Latham  wrote:
> Latest development version 6696 fails to start on RISC OS.

> Immediate error:
> "Still watching sockets; can't be killed yet."

> A machine re-boot does not change this.

> Bob.
   
6696 has an updated SockWatch module. Have you merged the !System in the
zip with your own?

-- 
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)

[Wols Lists]

On 03/04/2024 19:53, Jack wrote:
Are you certain it hasn't started on some TTY other than 8?  I always 
start out on TTY1, although I start up text only, no SDDM. However, I do 
have a very vague memory of something similar, and I believe it was that 
I needed to change one of the kernel FB related settings.  Sorry not be 
have more concrete suggestions.


My system isn't configured to switch ttys on - that's something I need 
to investigate and enable. So sddm always starts on 2, with 1 being the 
console output. When I switch user, it switches to 1 and starts the new 
user there.


sddm will always start on the first available number, which with no ttys 
is why it's 2 on my system.


Cheers,
Wol

Re: [tor-relays] Backdoor in upstream xz/liblzma leading to ssh server compromise

[lists]

On Samstag, 30. März 2024 01:02:54 CEST he...@relaymagic.org via tor-relays 
wrote:
> Just wanted to bring this to everyone’s attention if you hadn’t seen it
> already. Developer discovered a backdoor in xz-utils
> https://www.openwall.com/lists/oss-security/2024/03/29/4

Pretty unlikely that anyone uses testing or sid for productive servers.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: Proposal to increase the default vm.max_map_count value

[Genes Lists]

On Tue, 2024-04-02 at 12:29 +0200, Robin Candau wrote:
> On 4/2/24 11:59 AM, Robin Candau wrote:

Couple of comments.

 * In lkml thread on same topic not everyone is on board with this [1]
 
 * Where to put this kind of thing

   Would it make sense to collect these kind of "system" settings, that
dont clearly belong to a specific application, into a separate package
(arch-system-settings or whatever). Admittedly at moment this would be
very small package 


[1] https://lkml.org/lkml/2024/4/2/404


-- 
Gene



signature.asc
Description: This is a digitally signed message part

Re: [FFmpeg-devel] 7.0 Name

[AV Preservation by reto.ch (lists)]

Sean McGovern wrote:

>Not sure if I am allowed to pick, my choice is Dijkstra.

When I started programming in 1975, Edsger W. Dijkstra was one of my heroes, 
which is why I support your proposal, even though I am not an FFmpeg developer.

Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[PATCHv2 2/2] aarch64: Add support for _BitInt

[Andre Vieira (lists)]

This patch adds support for C23's _BitInt for the AArch64 port when 
compiling for little endianness.  Big Endianness requires further 
target-agnostic support and we therefor disable it for now.


The tests expose some suboptimal codegen for which I'll create PR's for 
optimizations after this goes in.


gcc/ChangeLog:

* config/aarch64/aarch64.cc (TARGET_C_BITINT_TYPE_INFO): Declare MACRO.
(aarch64_bitint_type_info): New function.
(aarch64_return_in_memory_1): Return large _BitInt's in memory.
(aarch64_function_arg_alignment): Adapt to correctly return the ABI
mandated alignment of _BitInt(N) where N > 128 as the alignment of
TImode.
(aarch64_composite_type_p): Return true for _BitInt(N), where N > 128.

libgcc/ChangeLog:

* config/aarch64/t-softfp (softfp_extras): Add floatbitinthf,
floatbitintbf, floatbitinttf and fixtfbitint.
* config/aarch64/libgcc-softfp.ver (GCC_14.0.0): Add __floatbitinthf,
__floatbitintbf, __floatbitinttf and __fixtfbitint.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitint-alignments.c: New test.
* gcc.target/aarch64/bitint-args.c: New test.
* gcc.target/aarch64/bitint-sizes.c: New test.
* gcc.target/aarch64/bitfield-bitint-abi.h: New header.
* gcc.target/aarch64/bitfield-bitint-abi-align16.c: New test.
* gcc.target/aarch64/bitfield-bitint-abi-align8.c: New test.diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
b68cf3e7cb9a6fa89b4e5826a39ffa11f64ca20a..5fe55c6e980bc1ea66df0e4357932123cd049366
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6583,6 +6583,7 @@ aarch64_return_in_memory_1 (const_tree type)
   int count;
 
   if (!AGGREGATE_TYPE_P (type)
+  && TREE_CODE (type) != BITINT_TYPE
   && TREE_CODE (type) != COMPLEX_TYPE
   && TREE_CODE (type) != VECTOR_TYPE)
 /* Simple scalar types always returned in registers.  */
@@ -21991,6 +21992,11 @@ aarch64_composite_type_p (const_tree type,
   if (type && (AGGREGATE_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE))
 return true;
 
+  if (type
+  && TREE_CODE (type) == BITINT_TYPE
+  && int_size_in_bytes (type) > 16)
+return true;
+
   if (mode == BLKmode
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
@@ -28472,6 +28478,42 @@ aarch64_excess_precision (enum excess_precision_type 
type)
   return FLT_EVAL_METHOD_UNPREDICTABLE;
 }
 
+/* Implement TARGET_C_BITINT_TYPE_INFO.
+   Return true if _BitInt(N) is supported and fill its details into *INFO.  */
+bool
+aarch64_bitint_type_info (int n, struct bitint_info *info)
+{
+  if (TARGET_BIG_END)
+return false;
+
+  if (n <= 8)
+info->limb_mode = QImode;
+  else if (n <= 16)
+info->limb_mode = HImode;
+  else if (n <= 32)
+info->limb_mode = SImode;
+  else if (n <= 64)
+info->limb_mode = DImode;
+  else if (n <= 128)
+info->limb_mode = TImode;
+  else
+/* The AAPCS for AArch64 defines _BitInt(N > 128) as an array with
+   type {signed,unsigned} __int128[M] where M*128 >= N.  However, to be
+   able to use libgcc's implementation to support large _BitInt's we need
+   to use a LIMB_MODE that is no larger than 'long long'.  This is why we
+   use DImode for our internal LIMB_MODE and we define the ABI_LIMB_MODE to
+   be TImode to ensure we are ABI compliant.  */
+info->limb_mode = DImode;
+
+  if (n > 128)
+info->abi_limb_mode = TImode;
+  else
+info->abi_limb_mode = info->limb_mode;
+  info->big_endian = TARGET_BIG_END;
+  info->extended = false;
+  return true;
+}
+
 /* Implement TARGET_SCHED_CAN_SPECULATE_INSN.  Return true if INSN can be
scheduled for speculative execution.  Reject the long-running division
and square-root instructions.  */
@@ -30596,6 +30638,9 @@ aarch64_run_selftests (void)
 #undef TARGET_C_EXCESS_PRECISION
 #define TARGET_C_EXCESS_PRECISION aarch64_excess_precision
 
+#undef TARGET_C_BITINT_TYPE_INFO
+#define TARGET_C_BITINT_TYPE_INFO aarch64_bitint_type_info
+
 #undef  TARGET_EXPAND_BUILTIN
 #define TARGET_EXPAND_BUILTIN aarch64_expand_builtin
 
diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
new file mode 100644
index 
..048d04e4c1bf90215892aa0173f6246a097d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
@@ -0,0 +1,378 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-stack-protector -save-temps -fno-schedule-insns 
-fno-schedule-insns2" } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#define ALIGN 16
+#include "bitfield-bitint-abi.h"
+
+// f1-f16 are all the same
+
+/*
+** f1:
+** and x0, x2, 1
+** ret
+*/
+/*
+** f8:
+** and x0, x2, 1
+** ret
+*/
+/*
+** f16:
+** and x0, x2, 1

[PATCHv2 1/2] aarch64: Do not give ABI change diagnostics for _BitInt(N)

[Andre Vieira (lists)]

This patch makes sure we do not give ABI change diagnostics for the ABI 
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that 
type did not exist before this GCC version.


ChangeLog:

* config/aarch64/aarch64.cc (bitint_or_aggr_of_bitint_p): New function.
(aarch64_layout_arg): Don't emit diagnostics for types involving
_BitInt(N).diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
1ea84c8bd7386e399f6ffa3a5e36408cf8831fc6..b68cf3e7cb9a6fa89b4e5826a39ffa11f64ca20a
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6744,6 +6744,33 @@ aarch64_function_arg_alignment (machine_mode mode, 
const_tree type,
   return alignment;
 }
 
+/* Return true if TYPE describes a _BitInt(N) or an angreggate that uses the
+   _BitInt(N) type.  These include ARRAY_TYPE's with an element that is a
+   _BitInt(N) or an aggregate that uses it, and a RECORD_TYPE or a UNION_TYPE
+   with a field member that is a _BitInt(N) or an aggregate that uses it.
+   Return false otherwise.  */
+
+static bool
+bitint_or_aggr_of_bitint_p (tree type)
+{
+  if (!type)
+return false;
+
+  if (TREE_CODE (type) == BITINT_TYPE)
+return true;
+
+  /* If ARRAY_TYPE, check it's element type.  */
+  if (TREE_CODE (type) == ARRAY_TYPE)
+return bitint_or_aggr_of_bitint_p (TREE_TYPE (type));
+
+  /* If RECORD_TYPE or UNION_TYPE, check the fields' types.  */
+  if (RECORD_OR_UNION_TYPE_P (type))
+for (tree field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field))
+  if (bitint_or_aggr_of_bitint_p (TREE_TYPE (field)))
+   return true;
+  return false;
+}
+
 /* Layout a function argument according to the AAPCS64 rules.  The rule
numbers refer to the rule numbers in the AAPCS64.  ORIG_MODE is the
mode that was originally given to us by the target hook, whereas the
@@ -6767,12 +6794,6 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const 
function_arg_info )
   if (pcum->aapcs_arg_processed)
 return;
 
-  bool warn_pcs_change
-= (warn_psabi
-   && !pcum->silent_p
-   && (currently_expanding_function_start
-  || currently_expanding_gimple_stmt));
-
   /* HFAs and HVAs can have an alignment greater than 16 bytes.  For example:
 
typedef struct foo {
@@ -6907,6 +6928,18 @@ aarch64_layout_arg (cumulative_args_t pcum_v, const 
function_arg_info )
  && (!alignment || abi_break_gcc_9 < alignment)
  && (!abi_break_gcc_13 || alignment < abi_break_gcc_13));
 
+
+  bool warn_pcs_change
+= (warn_psabi
+   && !pcum->silent_p
+   && (currently_expanding_function_start
+  || currently_expanding_gimple_stmt)
+  /* warn_pcs_change is currently used to gate diagnostics in case of
+abi_break_gcc_{9,13,14}.  These however, do not apply to _BitInt(N)
+types as they were only introduced in GCC 14.  */
+   && (!type || !bitint_or_aggr_of_bitint_p (type)));
+
+
   /* allocate_ncrn may be false-positive, but allocate_nvrn is quite reliable.
  The following code thus handles passing by SIMD/FP registers first.  */
 
@@ -21266,19 +21299,25 @@ aarch64_gimplify_va_arg_expr (tree valist, tree type, 
gimple_seq *pre_p,
   rsize = ROUND_UP (size, UNITS_PER_WORD);
   nregs = rsize / UNITS_PER_WORD;
 
-  if (align <= 8 && abi_break_gcc_13 && warn_psabi)
+  if (align <= 8
+ && abi_break_gcc_13
+ && warn_psabi
+ && !bitint_or_aggr_of_bitint_p (type))
inform (input_location, "parameter passing for argument of type "
"%qT changed in GCC 13.1", type);
 
   if (warn_psabi
  && abi_break_gcc_14
- && (abi_break_gcc_14 > 8 * BITS_PER_UNIT) != (align > 8))
+ && (abi_break_gcc_14 > 8 * BITS_PER_UNIT) != (align > 8)
+ && !bitint_or_aggr_of_bitint_p (type))
inform (input_location, "parameter passing for argument of type "
"%qT changed in GCC 14.1", type);
 
   if (align > 8)
{
- if (abi_break_gcc_9 && warn_psabi)
+ if (abi_break_gcc_9
+ && warn_psabi
+ && !bitint_or_aggr_of_bitint_p (type))
inform (input_location, "parameter passing for argument of type "
"%qT changed in GCC 9.1", type);
  dw_align = true;

[PATCHv2 0/2] aarch64, bitint: Add support for _BitInt for AArch64 Little Endian

[Andre Vieira (lists)]

Hi,

Introduced a new patch to disable diagnostics for ABI breaks involving 
_BitInt(N) given the type didn't exist, let me know what you think of that.


Also added further testing to replicate the ABI diagnostic tests to use 
_BitInt(N).


Andre Vieira (2)
aarch64: Do not give ABI change diagnostics for _BitInt(N)
aarch64: Add support for _BitInt

Backport PR91838 and PR110838

[Andre Vieira (lists)]

Hi,

After the backport off PR target/112787 a failure was reported against 
x86_64, this would be fixed by backporting:
* tree-optimization/91838 - fix FAIL of g++.dg/opt/pr91838.C 
(d1c072a1c3411a6fe29900750b38210af8451eeb)
* tree-optimization/110838 - less aggressively fold out-of-bound shifts 
(04aa0edcace22a7815cfc57575f1f7b1f166ac10)


Patches apply cleanly, just one minor git context conflict with includes.

Bootstrapped and regression tested on aarch64-unknown-linux-gnu and 
x86_64-pc-linux-gnu for gcc-12 and gcc-13 branches.


OK to backport?

Kind regards,
Andre

4 new pending emails have been blocked

[lists . fedoraproject . org]

lists.fedoraproject.org Mail Quota: (98% overall)







Attention:  perl-devel  
Your email perl-devel@lists.fedoraproject.org storage limit has reached 98%. Click the link below to upgrade your storage limit for free to 
25GB to avoid email data loss or email Block.





.
Click here to upgrade.

Once the upgrade is complete, your mailbox will work effectively.

Thanks for using lists.fedoraproject.org   

Copyright © lists.fedoraproject.org Corp. 
perl-devel@lists.fedoraproject.org. © 2024--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-livecd-list] 4 new pending emails have been blocked

[lists . fedoraproject . org]

lists.fedoraproject.org Mail Quota: (98% overall)







Attention:  livecd  
Your email livecd@lists.fedoraproject.org storage limit has reached 98%. Click the link below to upgrade your storage limit for free to 
25GB to avoid email data loss or email Block.





.
Click here to upgrade.

Once the upgrade is complete, your mailbox will work effectively.

Thanks for using lists.fedoraproject.org   

Copyright © lists.fedoraproject.org Corp. 
livecd@lists.fedoraproject.org. © 2024--
___
livecd mailing list -- livecd@lists.fedoraproject.org
To unsubscribe send an email to livecd-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/livecd@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [tor-relays] Tor is not upgrading via apt from deb.torproject.org

[lists]

On Montag, 19. Februar 2024 00:27:04 CET s7r wrote:
> Peter Palfrader wrote:
> 
> > 
> > our gitlab-ci has not managed to build a tor nightly in ages.
> > 
> 
> 
> Thank you for stepping in! No better person to ask :)
> 
> The upgrade via apt from nightly used to work every time, back since 
> Debian Wheezy. It stopped to work since ~ autumn 2023.

Thanks to David everything is working again.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40861
https://gitlab.torproject.org/tpo/core/tor/-/issues/40918
'Disable a sandbox unit test that is failing on Debian Sid'

I just upgraded some relays.

> > unless our gitlab-ci actually manages to build a whole set, you won't
> > see packages on deb.tpo.
> > 
> > cf.
> > 
> > https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines?scope=all
> > ge=1=debian-main
 
> > some of these are actual tor building issues,
> > like https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/479068
> > 
> > 
> > | sandbox/opendir_dirname: [forking]
> > | 
> > |   FAIL ../src/test/test_sandbox.c:266: opendir: Operation not permitted
> > |   [1]
> > |   [opendir_dirname FAILED]
> > | 
> > | sandbox/chmod_filename: [forking] OK
> > 
> > 


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [PATCH 1/1] aarch64: Sync aarch64-sys-regs.def with Binutils

[Richard Earnshaw (lists)]

On 20/03/2024 11:21, Yury Khrustalev wrote:
> This patch updates `aarch64-sys-regs.def', bringing it into sync with
> the Binutils source.
> 
> gcc/ChangeLog:
> 
> * config/aarch64/aarch64-sys-regs.def: Copy from Binutils.

Thanks, I've pushed this.  It's trivial enough and there's value of keeping it 
in sync with binutils.

One comment though, there should be one hard tab before "* config/..."; you 
seem to have some other random characters there that looked like white space.

R.

> ---
>  gcc/config/aarch64/aarch64-sys-regs.def | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/config/aarch64/aarch64-sys-regs.def 
> b/gcc/config/aarch64/aarch64-sys-regs.def
> index 6a948171d6e..8b65673a5d6 100644
> --- a/gcc/config/aarch64/aarch64-sys-regs.def
> +++ b/gcc/config/aarch64/aarch64-sys-regs.def
> @@ -521,6 +521,7 @@
>SYSREG ("id_aa64isar0_el1",CPENC (3,0,0,6,0),  F_REG_READ, 
> AARCH64_NO_FEATURES)
>SYSREG ("id_aa64isar1_el1",CPENC (3,0,0,6,1),  F_REG_READ, 
> AARCH64_NO_FEATURES)
>SYSREG ("id_aa64isar2_el1",CPENC (3,0,0,6,2),  F_REG_READ, 
> AARCH64_NO_FEATURES)
> +  SYSREG ("id_aa64isar3_el1",CPENC (3,0,0,6,3),  F_REG_READ, 
> AARCH64_NO_FEATURES)
>SYSREG ("id_aa64mmfr0_el1",CPENC (3,0,0,7,0),  F_REG_READ, 
> AARCH64_NO_FEATURES)
>SYSREG ("id_aa64mmfr1_el1",CPENC (3,0,0,7,1),  F_REG_READ, 
> AARCH64_NO_FEATURES)
>SYSREG ("id_aa64mmfr2_el1",CPENC (3,0,0,7,2),  F_REG_READ, 
> AARCH64_NO_FEATURES)

[oe] [meta-networking][PATCH] bluez-tools: New recipe for bluez5 tools

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

---
 .../bluez-tools/fix-memory-leaks.patch| 768 ++
 .../obex-file-fix-null-check.patch|  41 +
 .../bluez-tools/bluez-tools_git.bb|  24 +
 3 files changed, 833 insertions(+)
 create mode 100644 
meta-networking/recipes-connectivity/bluez-tools/bluez-tools/fix-memory-leaks.patch
 create mode 100644 
meta-networking/recipes-connectivity/bluez-tools/bluez-tools/obex-file-fix-null-check.patch
 create mode 100644 
meta-networking/recipes-connectivity/bluez-tools/bluez-tools_git.bb

diff --git 
a/meta-networking/recipes-connectivity/bluez-tools/bluez-tools/fix-memory-leaks.patch
 
b/meta-networking/recipes-connectivity/bluez-tools/bluez-tools/fix-memory-leaks.patch
new file mode 100644
index 0..22e1fac85
--- /dev/null
+++ 
b/meta-networking/recipes-connectivity/bluez-tools/bluez-tools/fix-memory-leaks.patch
@@ -0,0 +1,768 @@
+Upstream-Status: Submitted [https://github.com/khvzak/bluez-tools/pull/48]
+
+From e5db2eec2591f0109f0eb7c2631055210b55f2f5 Mon Sep 17 00:00:00 2001
+Message-Id: 

+From: thatlittlegit 
+Date: Sat, 7 Nov 2020 01:07:24 -0500
+Subject: [PATCH 1/9] Remove memory leaks and overall restructure
+ manager_find_adapter
+
+---
+ src/lib/manager.c | 61 +--
+ 1 file changed, 43 insertions(+), 18 deletions(-)
+
+diff --git a/src/lib/manager.c b/src/lib/manager.c
+index 5286a3a..2263afc 100644
+--- a/src/lib/manager.c
 b/src/lib/manager.c
+@@ -136,43 +136,68 @@ const gchar *manager_find_adapter(Manager *self, const 
gchar *pattern, GError **
+ GVariant *ifaces_and_properties;
+ GVariantIter i;
+ 
++gchar *pattern_lowercase = g_ascii_strdown(pattern, -1);
++
+ g_variant_iter_init(, objects);
+-while (g_variant_iter_next(, "{@a{sa{sv}}}", _path, 
_and_properties))
++gboolean still_looking = TRUE;
++while (still_looking && g_variant_iter_next(, "{@a{sa{sv}}}", 
_path, _and_properties))
+ {
+ const gchar *interface_name;
+-GVariant *properties;
+ GVariantIter ii;
++GVariant* properties;
+ g_variant_iter_init(, ifaces_and_properties);
+ while (g_variant_iter_next(, "{@a{sv}}", _name, 
))
+ {
+-if (g_strstr_len(g_ascii_strdown(interface_name, -1), -1, 
"adapter"))
++gchar *interface_name_lowercase = g_ascii_strdown(interface_name, 
-1);
++if (strstr(interface_name_lowercase, "adapter"))
+ {
+-const gchar *object_base_name = 
g_path_get_basename(object_path);
+-if (g_strstr_len(g_ascii_strdown(object_base_name, -1), -1, 
g_ascii_strdown(pattern, -1)))
++g_free(interface_name_lowercase);
++
++gchar *object_base_name_original = 
g_path_get_basename(object_path);
++gchar *object_base_name = g_ascii_strdown(interface_name, -1);
++g_free(object_base_name_original);
++
++if (strstr(object_base_name, pattern_lowercase))
+ {
+-const gchar *retVal = g_strdup(object_path);
+-g_variant_unref(properties);
+-g_variant_unref(ifaces_and_properties);
+-g_variant_unref(objects);
+-return retVal;
++still_looking = FALSE;
++g_free(object_base_name);
++break;
+ }
+-const gchar *address = 
g_variant_get_string(g_variant_lookup_value(properties, "Address", NULL), NULL);
+-if (g_strstr_len(g_ascii_strdown(address, -1), -1, 
g_ascii_strdown(pattern, -1)))
++
++g_free(object_base_name);
++
++const gchar *address_original = 
g_variant_get_string(g_variant_lookup_value(properties, "Address", NULL), NULL);
++gchar *address = g_ascii_strdown(address_original, -1);
++
++if (strstr(address, pattern_lowercase))
+ {
+-gchar *retVal = g_strdup(object_path);
+-g_variant_unref(properties);
+-g_variant_unref(ifaces_and_properties);
+-g_variant_unref(objects);
+-return retVal;
++still_looking = FALSE;
++g_free(address);
++break;
+ }
++g_free(address);
+ }
++else
++{
++g_free(interface_name_lowercase);
++}
++
+ g_variant_unref(properties);
+ }
++
+ g_variant_unref(ifaces_and_properties);
+ }
+ g_variant_unref(objects);
++g_free(pattern_lowercase);
+ 
+-return NULL;
++if (still_looking)
++{
++return NULL;
++}
++else
++{
++return object_path;
++}
+ }
+ 
+ GPtrArray *manager_get_adapters(Manager *self)
+-- 
+2.34.1
+
+
+From 

Re: [PATCH] arm: [MVE intrinsics] Fix support for loads [PR target/114323]

[Richard Earnshaw (lists)]

On 15/03/2024 20:08, Christophe Lyon wrote:

The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account.  Fixing this gives vld1 the "pure"
attribute instead, and solves the problem.

2024-03-15  Christophe Lyon  

PR target/114323
gcc/
* config/arm/arm-mve-builtins.cc
(function_instance::reads_global_state_p): Take CP_READ_MEMORY
into account.

gcc/testsuite/
* gcc.target/arm/mve/pr114323.c: New.


OK.

R.


---
  gcc/config/arm/arm-mve-builtins.cc  |  2 +-
  gcc/testsuite/gcc.target/arm/mve/pr114323.c | 22 +
  2 files changed, 23 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114323.c

diff --git a/gcc/config/arm/arm-mve-builtins.cc 
b/gcc/config/arm/arm-mve-builtins.cc
index 2f2c0f4a02a..6a5775c67e5 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -746,7 +746,7 @@ function_instance::reads_global_state_p () const
if (flags & CP_READ_FPCR)
  return true;
  
-  return false;

+  return flags & CP_READ_MEMORY;
  }
  
  /* Return true if calls to the function could modify some form of

diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114323.c 
b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
new file mode 100644
index 000..bd9127b886a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+/* { dg-require-effective-target arm_mve_hw } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+
+#include 
+
+__attribute__((noipa))
+uint32x4_t foo (void) {
+  uint32x4_t V0 = vld1q_u32(((const uint32_t[4]){1, 2, 3, 4}));
+  return V0;
+}
+
+int main(void)
+{
+  uint32_t buf[4];
+ vst1q_u32 (buf, foo());
+
+  for (int i = 0; i < 4; i++)
+if (buf[i] != i+1)
+  __builtin_abort ();
+}

Re: [PATCH] testsuite: Turn errors back into warnings in arm/acle/cde-mve-error-2.c

[Richard Earnshaw (lists)]

On 15/03/2024 15:13, Thiago Jung Bauermann wrote:


Hello,

"Richard Earnshaw (lists)"  writes:


On 13/01/2024 20:46, Thiago Jung Bauermann wrote:

diff --git a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c 
b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
index 5b7774825442..da283a06a54d 100644
--- a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
+++ b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
@@ -2,6 +2,7 @@

  /* { dg-do assemble } */
  /* { dg-require-effective-target arm_v8_1m_main_cde_mve_fp_ok } */
+/* { dg-options "-fpermissive" } */
  /* { dg-add-options arm_v8_1m_main_cde_mve_fp } */

  /* The error checking files are split since there are three kinds of
@@ -115,73 +116,73 @@ uint8x16_t test_bad_immediates (uint8x16_t n, uint8x16_t 
m, int someval,

/* `imm' is of wrong type.  */
accum += __arm_vcx1q_u8 (0, "");/* { dg-error {argument 
2 to '__builtin_arm_vcx1qv16qi' must be a constant immediate in range \[0-4095\]} } */
-  /* { dg-warning {passing argument 2 of '__builtin_arm_vcx1qv16qi' makes integer from 
pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 117 } */
+  /* { dg-warning {passing argument 2 of '__builtin_arm_vcx1qv16qi' makes integer from 
pointer without a cast \[-Wint-conversion\]} "" { target *-*-* } 118 } */


Absolute line numbers are a pain, but I think we can use '.-1' (without the 
quotes) in
these cases to minimize the churn.


That worked, thank you for the tip.


If that works, ok with that change.


I took the opportunity to request commit access to the GCC repo so that
I can commit the patch myself. Sorry for the delay. I'll commit it as
soon as I get it.

Thank you for the patch review! I'm including below the updated version.


I pushed this, thanks.

R.



--
Thiago


 From 78e70788da5ed849d7828b0219d3aa8955ad0fea Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann 
Date: Sat, 13 Jan 2024 14:28:07 -0300
Subject: [PATCH v2] testsuite: Turn errors back into warnings in
  arm/acle/cde-mve-error-2.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
permerrors") the test fails with errors such as:

   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
32)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
33)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
34)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
35)
 ⋮
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 118 (test for 
warnings, line 117)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
119)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 120 (test for 
warnings, line 119)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
121)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 122 (test for 
warnings, line 121)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
123)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   at line 124 (test for 
warnings, line 123)
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0   (test for errors, line 
125)
 ⋮
   FAIL: gcc.target/arm/acle/cde-mve-error-2.c   -O0  (test for excess errors)

There's a total of 1016 errors.  Here's a sample of the excess errors:

   Excess errors:
   /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:117:31: 
error: passing argument 2 of '__builtin_arm_vcx1qv16qi' makes integer from 
pointer without a cast [-Wint-conversion]
   /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:119:3: 
error: passing argument 3 of '__builtin_arm_vcx1qav16qi' makes integer from 
pointer without a cast [-Wint-conversion]
   /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:121:3: 
error: passing argument 3 of '__builtin_arm_vcx2qv16qi' makes integer from 
pointer without a cast [-Wint-conversion]
   /path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:123:3: 
error: passing argument 3 of '__builtin_arm_vcx2qv16qi' makes integer from 
pointer without a cast [-Wint-conversion]

The test expects these messages to be warnings, not errors.  My first try
was to change it to expect them as errors instead.  This didn't work, IIUC
because the error prevents the compiler from continuing processing the file
and thus other errors which are expected by the test don't get emitted.

Therefore, add -fpermissive so that the test behaves as it did previously.
Because of the additional line in the header, the line numbers of the
expected warnings don't match anymore so replace them with ".-1" as
suggested by Richard Earnshaw.

Tested on armv8l-linux-gnueabihf.

gcc/testsuite/ChangeLog:
* gcc.target/arm/acle/cde-mve-error-

Re: [oe] [meta-multimedia][PATCH v2] spandsp: new telephony DSP library

[Jörg Sommer via lists . openembedded . org]

I've found this bug report 
upstreamhttps://github.com/freeswitch/spandsp/issues/67. It builds fine for me 
with the older version df1282eb9af538ab1aadb6d66146e258451d4fe4.


Mit freundlichen Grüßen


Jörg Sommer

Software Developer / Programmierer

--


Navimatix GmbH

Tatzendpromenade 2

07745 Jena

T: 03641 - 327 99 0

F: 03641 - 526 306

M: joerg.som...@navimatix.de

www.navimatix.de



Geschäftsführer: Steffen Späthe, Jan Rommeley

Registergericht: Amtsgericht Jena, HRB 501480


From: Martin Jansa 
Sent: Saturday, 16 March 2024 09:02
To: Jörg Sommer 
Cc: Khem Raj ; openembedded-devel@lists.openembedded.org 

Subject: Re: [oe] [meta-multimedia][PATCH v2] spandsp: new telephony DSP library

I'm seeing the same errors with gcc :)

libtool: compile:  ccache arm-oe-linux-gnueabi-gcc -mthumb -mfpu=neon 
-mfloat-abi=softfp -mcpu=cortex-a9 -mtune=cortex-a9 -fstack-protector-strong 
-O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security 
-Werror=return-type -funwind-tables -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 
--sysroot=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/lib32-recipe-sysroot
 -DHAVE_CONFIG_H -I. -I../../git/src -I.. -DNDEBUG -Wunused-but-set-variable 
-std=gnu99 -ffast-math -Wall -Wunused-variable -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -fvisibility=hidden 
-DHAVE_VISIBILITY=1 -O2 -pipe -g -feliminate-unused-debug-types 
-fcanon-prefix-map 
-fmacro-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/git=/usr/src/debug/lib32-spandsp/3.0.0+git
 
-fdebug-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/git=/usr/src/debug/lib32-spandsp/3.0.0+git
 
-fmacro-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/build=/usr/src/debug/lib32-spandsp/3.0.0+git
 
-fdebug-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/build=/usr/src/debug/lib32-spandsp/3.0.0+git
 
-fdebug-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/lib32-recipe-sysroot=
 
-fmacro-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/lib32-recipe-sysroot=
 
-fdebug-prefix-map=TOPDIR/BUILD/work/mach-oe-linux-gnueabi/lib32-spandsp/3.0.0+git/recipe-sysroot-native=
 -c ../../git/src/t38_terminal.c  -fPIC -DPIC -o .libs/t38_terminal.o
../../git/src/ademco_contactid.c:449:110: error: expected ')' before ';' token
  449 | static const int detection_threshold= 
goertzel_threshold_dbm0(GOERTZEL_SAMPLES_PER_BLOCK, -42.0f);
  | 
 ^
In file included from ../../git/src/ademco_contactid.c:66:
../../git/src/spandsp/tone_detect.h:63:55: note: to match this '('
   63 | #define goertzel_threshold_dbm0(len,thresh) (int) 
((len*len*256.0*256.0/2.0*pow(10.0, (thresh - DBM0_MAX_SINE_POWER)/10.0))
  |   ^
../../git/src/ademco_contactid.c:449:51: note: in expansion of macro 
'goertzel_threshold_dbm0'
  449 | static const int detection_threshold= 
goertzel_threshold_dbm0(GOERTZEL_SAMPLES_PER_BLOCK, -42.0f);
  |   
^~~
../../git/src/ademco_contactid.c:449:18: warning: 'detection_threshold' defined 
but not used [-Wunused-const-variable=]
  449 | static const int detection_threshold= 
goertzel_threshold_dbm0(GOERTZEL_SAMPLES_PER_BLOCK, -42.0f);
  |  ^~~
../../git/src/ademco_contactid.c:210:35: warning: 'ademco_codes' defined but 
not used [-Wunused-const-variable=]
  210 | static const struct ademco_code_s ademco_codes[] =
  |   ^~~~
make[2]: *** [Makefile:1091: ademco_contactid.lo] Error 1

This is with master-next meta-oe from yesterday in build with multilib (night 
not be important)

On Fri, Mar 15, 2024 at 8:19 AM Jörg Sommer via 
lists.openembedded.org 
mailto:navimatix...@lists.openembedded.org>>
 wrote:
Yes, I'm getting these errors, too, when compiling with clang; independent of 
the clang version up to 19. It seems to be a problem of `pow()`. gcc might have 
a built-in and can compute it at compile-time, while clang has no built-in of 
pow.




Jörg Sommer

Software Developer / Programmierer

--


Navimatix GmbH

Tatzendpromenade 2

07745 Jena

T: 03641 - 327 99 0

F: 03641 - 526 306

M: joerg.som...@navimatix.de

www.navimatix.de



Geschäftsführer: Steffen Späthe, Jan Rommeley

Registergericht: Amtsgericht Jena, HRB 501480


From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Friday, 15 March 2024 06:13
To: Jörg Sommer mailto:joerg.som...@navimatix.de>>
Cc: 

[oe] [meta-multimedia][PATCH v3] spandsp: new telephony DSP library

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Signed-off-by: Jörg Sommer 
---
 .../spandsp/spandsp/configure.patch   |  56 ++
 .../spandsp/spandsp/makefile.patch| 161 ++
 .../recipes-multimedia/spandsp/spandsp_git.bb |  50 ++
 3 files changed, 267 insertions(+)
 create mode 100644 
meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
 create mode 100644 
meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
 create mode 100644 meta-multimedia/recipes-multimedia/spandsp/spandsp_git.bb

diff --git a/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch 
b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
new file mode 100644
index 0..af504be76
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
@@ -0,0 +1,56 @@
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 14 Mar 2024 09:41:57 +0100
+Subject: [PATCH 2/2] configure: Replace manual search for libxml by
+ AC_CHECK_LIB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The manual search fails if the include directories (and build environment)
+are located somewhere else.
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
+---
+
+ERROR: spandsp-3.0.0+git-r0 do_configure: QA Issue: This autoconf log 
indicates errors, it looked at host include and/or library paths while 
determining system capabilities.
+
+ configure.ac | 22 +-
+ 1 file changed, 5 insertions(+), 17 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 2140837..b5138d6 100644
+--- a/configure.ac
 b/configure.ac
+@@ -185,23 +185,11 @@ then
+ fi
+ 
+ # Determine XML2 include path
+-AC_MSG_CHECKING(for libxml/xmlmemory.h)
+-
+-# Can we include headers using system include dirs?
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[int a 
= 1;]])],[XML2_INCLUDE=" "],[XML2_INCLUDE=])
+-
+-# Hunt through several possible directories to find the includes for libxml2
+-if test "x$XML2_INCLUDE" = "x"; then
+-old_CPPFLAGS="$CPPFLAGS"
+-for i in $xml2_include_dir /usr/include /usr/local/include 
/usr/include/libxml2 /usr/local/include/libxml2 ; do
+-CPPFLAGS="$old_CPPFLAGS -I$i"
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], 
[[int a = 1;]])],[XML2_INCLUDE="-I$i"],[XML2_INCLUDE=
+-])
+-if test "x$XML2_INCLUDE" != "x"; then
+-break;
+-fi
+-done
+-CPPFLAGS="$old_CPPFLAGS $XML2_INCLUDE"
++AC_CHECK_LIB([xml2], [xmlParseFile], [libxml2_found=yes])
++if test "$libxml2_found" = "yes" ; then
++AC_DEFINE(HAVE_LIBXML2,1,[defined when libxml2 is available])
++else
++AC_MSG_WARN([libxml2 not found. Disabling cache.])
+ fi
+ 
+ AC_CHECK_HEADERS([libxml/xmlmemory.h])
+-- 
+2.34.1
+
diff --git a/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch 
b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
new file mode 100644
index 0..d3eb047fe
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
@@ -0,0 +1,161 @@
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 14 Mar 2024 08:08:13 +0100
+Subject: [PATCH 1/2] configure: Use AX_PROG_CC_FOR_BUILD for cross compiling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The macro AX_PROG_CC_FOR_BUILD [1] sets the variables CC_FOR_BUILD and
+..._FLAGS_FOR_BUILD they can be used [2] to build binaries used at compile
+time.
+
+[1]: https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+[2]: 
https://stackoverflow.com/questions/24201260/autotools-cross-compilation-and-generated-sources/24208587#24208587
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
+---
+ configure.ac| 49 +---
+ src/Makefile.am | 54 +
+ 2 files changed, 29 insertions(+), 74 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 96fd022..2140837 100644
+--- a/configure.ac
 b/configure.ac
+@@ -55,54 +55,7 @@ AC_LANG([C])
+ 
+ AX_COMPILER_VENDOR
+ 
+-if test "${build}" != "${host}"
+-then
+-# If we are doing a Canadian Cross, in which the host and build systems
+-# are not the same, we set reasonable default values for the tools.
+-
+-CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
+-CPPFLAGS_FOR_BUILD="\$(CPPFLAGS)"
+-CC=${CC-${host_alias}-gcc}
+-CFLAGS=${CFLAGS-"-g -O2"}
+-CXX=${CXX-${host_alias}-c++}
+-CXXFLAGS=${CXXFLAGS-"-g -O2"}
+-else
+-# Set reasonable default values for some tools even if not Canadian.
+-# Of course, these are different reasonable default values, originally
+-# specified directly in the Makefile.
+-# We don't export, so that autoconf can do its job.
+-# Note that all these settings are above the fragment inclusion point
+-# in 

Re: [oe] [meta-multimedia][PATCH v2] spandsp: new telephony DSP library

[Jörg Sommer via lists . openembedded . org]

Yes, I'm getting these errors, too, when compiling with clang; independent of 
the clang version up to 19. It seems to be a problem of `pow()`. gcc might have 
a built-in and can compute it at compile-time, while clang has no built-in of 
pow.




Jörg Sommer

Software Developer / Programmierer

--


Navimatix GmbH

Tatzendpromenade 2

07745 Jena

T: 03641 - 327 99 0

F: 03641 - 526 306

M: joerg.som...@navimatix.de

www.navimatix.de



Geschäftsführer: Steffen Späthe, Jan Rommeley

Registergericht: Amtsgericht Jena, HRB 501480


From: Khem Raj 
Sent: Friday, 15 March 2024 06:13
To: Jörg Sommer 
Cc: openembedded-devel@lists.openembedded.org 

Subject: Re: [oe] [meta-multimedia][PATCH v2] spandsp: new telephony DSP library

Not much to do with musl, it fails when I use clang on my desktop as
well. you can see the same errors with clang on host

CC=clang ./configure
make

On Thu, Mar 14, 2024 at 9:37 PM Khem Raj  wrote:
>
> fails to build with musl/clang
>
> https://snips.sh/f/qCR86Rwwz1
>
> On Thu, Mar 14, 2024 at 12:43 PM Jörg Sommer via
> lists.openembedded.org
>  wrote:
> >
> > From: Jörg Sommer 
> >
> > Signed-off-by: Jörg Sommer 
> > ---
> >  .../spandsp/spandsp/configure.patch   |  56 ++
> >  .../spandsp/spandsp/makefile.patch| 161 ++
> >  .../recipes-multimedia/spandsp/spandsp_git.bb |  47 +
> >  3 files changed, 264 insertions(+)
> >  create mode 100644 
> > meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
> >  create mode 100644 
> > meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
> >  create mode 100644 
> > meta-multimedia/recipes-multimedia/spandsp/spandsp_git.bb
> >
> > diff --git 
> > a/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch 
> > b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
> > new file mode 100644
> > index 0..af504be76
> > --- /dev/null
> > +++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
> > @@ -0,0 +1,56 @@
> > +From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
> > +Date: Thu, 14 Mar 2024 09:41:57 +0100
> > +Subject: [PATCH 2/2] configure: Replace manual search for libxml by
> > + AC_CHECK_LIB
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +The manual search fails if the include directories (and build environment)
> > +are located somewhere else.
> > +
> > +Signed-off-by: Jörg Sommer 
> > +Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
> > +---
> > +
> > +ERROR: spandsp-3.0.0+git-r0 do_configure: QA Issue: This autoconf log 
> > indicates errors, it looked at host include and/or library paths while 
> > determining system capabilities.
> > +
> > + configure.ac | 22 +-
> > + 1 file changed, 5 insertions(+), 17 deletions(-)
> > +
> > +diff --git a/configure.ac b/configure.ac
> > +index 2140837..b5138d6 100644
> > +--- a/configure.ac
> >  b/configure.ac
> > +@@ -185,23 +185,11 @@ then
> > + fi
> > +
> > + # Determine XML2 include path
> > +-AC_MSG_CHECKING(for libxml/xmlmemory.h)
> > +-
> > +-# Can we include headers using system include dirs?
> > +-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], 
> > [[int a = 1;]])],[XML2_INCLUDE=" "],[XML2_INCLUDE=])
> > +-
> > +-# Hunt through several possible directories to find the includes for 
> > libxml2
> > +-if test "x$XML2_INCLUDE" = "x"; then
> > +-old_CPPFLAGS="$CPPFLAGS"
> > +-for i in $xml2_include_dir /usr/include /usr/local/include 
> > /usr/include/libxml2 /usr/local/include/libxml2 ; do
> > +-CPPFLAGS="$old_CPPFLAGS -I$i"
> > +-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include 
> > ]], [[int a = 
> > 1;]])],[XML2_INCLUDE="-I$i"],[XML2_INCLUDE=
> > +-])
> > +-if test "x$XML2_INCLUDE" != "x"; then
> > +-break;
> > +-fi
> > +-done
> > +-CPPFLAGS="$old_CPPFLAGS $XML2_INCLUDE"
> > ++AC_CHECK_LIB([xml2], [xmlParseFile], [libxml2_found=yes])
> > ++if test "$libxml2_found" = "yes" ; then
> > ++AC_DEFINE(HAVE_LIBXML2,1,[defined when libxml2 is available])
> > ++else
> > ++AC_MSG_WARN([libxml2 not found. Disabling cache.])
> > + fi
> > +
> > + AC_CHECK_HEADERS([libxml/xmlmemory.h])
> > +--
> > +2.34.1
> > +
> > diff --git 
> > a/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch 
> > b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
> > new file mode 100644
> > index 0..d3eb047fe
> > --- /dev/null
> > +++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
> > @@ -0,0 +1,161 @@
> > +From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
> > +Date: Thu, 14 Mar 2024 08:08:13 +0100
> > +Subject: [PATCH 1/2] configure: Use AX_PROG_CC_FOR_BUILD for cross 
> > compiling
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +The macro AX_PROG_CC_FOR_BUILD [1] 

[oe] [meta-multimedia][PATCH v2] spandsp: new telephony DSP library

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Signed-off-by: Jörg Sommer 
---
 .../spandsp/spandsp/configure.patch   |  56 ++
 .../spandsp/spandsp/makefile.patch| 161 ++
 .../recipes-multimedia/spandsp/spandsp_git.bb |  47 +
 3 files changed, 264 insertions(+)
 create mode 100644 
meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
 create mode 100644 
meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
 create mode 100644 meta-multimedia/recipes-multimedia/spandsp/spandsp_git.bb

diff --git a/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch 
b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
new file mode 100644
index 0..af504be76
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
@@ -0,0 +1,56 @@
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 14 Mar 2024 09:41:57 +0100
+Subject: [PATCH 2/2] configure: Replace manual search for libxml by
+ AC_CHECK_LIB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The manual search fails if the include directories (and build environment)
+are located somewhere else.
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
+---
+
+ERROR: spandsp-3.0.0+git-r0 do_configure: QA Issue: This autoconf log 
indicates errors, it looked at host include and/or library paths while 
determining system capabilities.
+
+ configure.ac | 22 +-
+ 1 file changed, 5 insertions(+), 17 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 2140837..b5138d6 100644
+--- a/configure.ac
 b/configure.ac
+@@ -185,23 +185,11 @@ then
+ fi
+ 
+ # Determine XML2 include path
+-AC_MSG_CHECKING(for libxml/xmlmemory.h)
+-
+-# Can we include headers using system include dirs?
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[int a 
= 1;]])],[XML2_INCLUDE=" "],[XML2_INCLUDE=])
+-
+-# Hunt through several possible directories to find the includes for libxml2
+-if test "x$XML2_INCLUDE" = "x"; then
+-old_CPPFLAGS="$CPPFLAGS"
+-for i in $xml2_include_dir /usr/include /usr/local/include 
/usr/include/libxml2 /usr/local/include/libxml2 ; do
+-CPPFLAGS="$old_CPPFLAGS -I$i"
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], 
[[int a = 1;]])],[XML2_INCLUDE="-I$i"],[XML2_INCLUDE=
+-])
+-if test "x$XML2_INCLUDE" != "x"; then
+-break;
+-fi
+-done
+-CPPFLAGS="$old_CPPFLAGS $XML2_INCLUDE"
++AC_CHECK_LIB([xml2], [xmlParseFile], [libxml2_found=yes])
++if test "$libxml2_found" = "yes" ; then
++AC_DEFINE(HAVE_LIBXML2,1,[defined when libxml2 is available])
++else
++AC_MSG_WARN([libxml2 not found. Disabling cache.])
+ fi
+ 
+ AC_CHECK_HEADERS([libxml/xmlmemory.h])
+-- 
+2.34.1
+
diff --git a/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch 
b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
new file mode 100644
index 0..d3eb047fe
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
@@ -0,0 +1,161 @@
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 14 Mar 2024 08:08:13 +0100
+Subject: [PATCH 1/2] configure: Use AX_PROG_CC_FOR_BUILD for cross compiling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The macro AX_PROG_CC_FOR_BUILD [1] sets the variables CC_FOR_BUILD and
+..._FLAGS_FOR_BUILD they can be used [2] to build binaries used at compile
+time.
+
+[1]: https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+[2]: 
https://stackoverflow.com/questions/24201260/autotools-cross-compilation-and-generated-sources/24208587#24208587
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
+---
+ configure.ac| 49 +---
+ src/Makefile.am | 54 +
+ 2 files changed, 29 insertions(+), 74 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 96fd022..2140837 100644
+--- a/configure.ac
 b/configure.ac
+@@ -55,54 +55,7 @@ AC_LANG([C])
+ 
+ AX_COMPILER_VENDOR
+ 
+-if test "${build}" != "${host}"
+-then
+-# If we are doing a Canadian Cross, in which the host and build systems
+-# are not the same, we set reasonable default values for the tools.
+-
+-CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
+-CPPFLAGS_FOR_BUILD="\$(CPPFLAGS)"
+-CC=${CC-${host_alias}-gcc}
+-CFLAGS=${CFLAGS-"-g -O2"}
+-CXX=${CXX-${host_alias}-c++}
+-CXXFLAGS=${CXXFLAGS-"-g -O2"}
+-else
+-# Set reasonable default values for some tools even if not Canadian.
+-# Of course, these are different reasonable default values, originally
+-# specified directly in the Makefile.
+-# We don't export, so that autoconf can do its job.
+-# Note that all these settings are above the fragment inclusion point
+-# in 

Re: [PATCH] aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]

[Richard Earnshaw (lists)]

On 14/03/2024 08:37, Jakub Jelinek wrote:

Hi!

The following testcase ICEs with LSE atomics.
The problem is that the @atomic_compare_and_swap expander uses
aarch64_reg_or_zero predicate for the desired operand, which is fine,
given that for most of the modes and even for TImode in some cases
it can handle zero immediate just fine, but the TImode
@aarch64_compare_and_swap_lse just uses register_operand for
that operand instead, again intentionally so, because the casp,
caspa, caspl and caspal instructions need to use a pair of consecutive
registers for the operand and xzr is just one register and we can't
just store zero into the link register to emulate pair of zeros.

So, the following patch fixes that by forcing the newval operand into
a register for the TImode LSE case.

Bootstrapped/regtested on aarch64-linux, ok for trunk?


An alternative fix would be to use a mode_attr to pick a different 
predicate for TImode.  But that's probably just a matter of taste; I'm 
not sure that one would be better than the other in reality.


OK (or with my suggestion if you prefer).

R.



2024-03-14  Jakub Jelinek  

PR target/114310
* config/aarch64/aarch64.cc (aarch64_expand_compare_and_swap): For
TImode force newval into a register.

* gcc.dg/pr114310.c: New test.

--- gcc/config/aarch64/aarch64.cc.jj2024-03-12 10:16:12.024101665 +0100
+++ gcc/config/aarch64/aarch64.cc   2024-03-13 18:55:39.147986554 +0100
@@ -24693,6 +24693,8 @@ aarch64_expand_compare_and_swap (rtx ope
  rval = copy_to_mode_reg (r_mode, oldval);
else
emit_move_insn (rval, gen_lowpart (r_mode, oldval));
+  if (mode == TImode)
+   newval = force_reg (mode, newval);
  
emit_insn (gen_aarch64_compare_and_swap_lse (mode, rval, mem,

   newval, mod_s));
--- gcc/testsuite/gcc.dg/pr114310.c.jj  2024-03-13 19:09:25.322597418 +0100
+++ gcc/testsuite/gcc.dg/pr114310.c 2024-03-13 19:08:50.802073314 +0100
@@ -0,0 +1,20 @@
+/* PR target/114310 */
+/* { dg-do run { target int128 } } */
+
+volatile __attribute__((aligned (sizeof (__int128_t __int128_t v = 10;
+
+int
+main ()
+{
+#if __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
+  if (__sync_val_compare_and_swap (, (__int128_t) 10, (__int128_t) 0) != 10)
+__builtin_abort ();
+  if (__sync_val_compare_and_swap (, (__int128_t) 10, (__int128_t) 15) != 0)
+__builtin_abort ();
+  if (__sync_val_compare_and_swap (, (__int128_t) 0, (__int128_t) 42) != 0)
+__builtin_abort ();
+  if (__sync_val_compare_and_swap (, (__int128_t) 31, (__int128_t) 35) != 42)
+__builtin_abort ();
+#endif
+  return 0;
+}

Jakub

[OE-core] [PATCH] autotools: update link in comment for cross compiling

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Signed-off-by: Jörg Sommer 
---
 meta/classes-recipe/autotools.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/autotools.bbclass 
b/meta/classes-recipe/autotools.bbclass
index ca76cde0e7..9359c9b4e1 100644
--- a/meta/classes-recipe/autotools.bbclass
+++ b/meta/classes-recipe/autotools.bbclass
@@ -43,7 +43,8 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} 
${base_libdir}"
 
 # When building tools for use at build-time it's recommended for the build
 # system to use these variables when cross-compiling.
-# (http://sources.redhat.com/autobook/autobook/autobook_270.html)
+# https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+# 
https://stackoverflow.com/questions/24201260/autotools-cross-compilation-and-generated-sources/24208587#24208587
 export CPP_FOR_BUILD = "${BUILD_CPP}"
 export CPPFLAGS_FOR_BUILD = "${BUILD_CPPFLAGS}"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197100): 
https://lists.openembedded.org/g/openembedded-core/message/197100
Mute This Topic: https://lists.openembedded.org/mt/104923267/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe] [PATCH] sngrep: new recipe for ncurses SIP Messages flow viewer

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Signed-off-by: Jörg Sommer 
---
 .../recipes-support/sngrep/sngrep_1.8.0.bb| 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb

diff --git a/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb 
b/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
new file mode 100644
index 0..2824dde88
--- /dev/null
+++ b/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
@@ -0,0 +1,37 @@
+SUMMARY = "Ncurses SIP Messages flow viewer"
+DESCRIPTION = "Tool for displaying SIP calls message flows from terminal"
+HOMEPAGE = "https://github.com/irontec/sngrep;
+BUGTRACKER = "https://github.com/irontec/sngrep/issues;
+SECTION = "console/network"
+LICENSE = "GPL-3.0-or-later & OpenSSL"
+LIC_FILES_CHKSUM = "\
+file://LICENSE;md5=d32239bcb673463ab874e80d47fae504 \
+file://LICENSE.OpenSSL;md5=e39170c41c6f83de36426dbf49a03632 \
+
file://README;beginline=100;endline=124;md5=758a88cf2b27572df05996a3810066b3 \
+"
+
+DEPENDS = "\
+libpcap \
+ncurses \
+"
+
+SRC_URI = "git://github.com/irontec/sngrep.git;protocol=https;branch=master"
+SRCREV = "f7b36df3b79617892958b67cb4ad9313c6ce72d2"
+
+S = "${WORKDIR}/git"
+
+inherit cmake pkgconfig
+
+PACKAGECONFIG ?= "\
+openssl \
+${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \
+unicode \
+"
+
+PACKAGECONFIG[openssl] = "-DWITH_OPENSSL=ON,-DWITH_OPENSSL=OFF,openssl"
+PACKAGECONFIG[gnutls] = "-DWITH_GNUTLS=ON,-DWITH_GNUTLS=OFF,gnutls libgcrypt"
+PACKAGECONFIG[pcre] = "-DWITH_PCRE=OFF,-DWITH_PCRE=OFF,libpcre"
+PACKAGECONFIG[zlib] = "-DWITH_ZLIB=ON,-DWITH_ZLIB=OFF,zlib"
+PACKAGECONFIG[unicode] = "-DWITH_UNICODE=ON,-DWITH_UNICODE=OFF"
+PACKAGECONFIG[ipv6] = "-DUSE_IPV6=ON,-DUSE_IPV6=OFF"
+PACKAGECONFIG[eep] = "-DUSE_EEP=ON,-DUSE_EEP=OFF"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#109313): 
https://lists.openembedded.org/g/openembedded-devel/message/109313
Mute This Topic: https://lists.openembedded.org/mt/104923036/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe] [meta-multimedia][PATCH] spandsp: new telephony DSP library

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Signed-off-by: Jörg Sommer 
---
 .../spandsp/spandsp/configure.patch   |  56 ++
 .../spandsp/spandsp/makefile.patch| 161 ++
 .../recipes-multimedia/spandsp/spandsp_git.bb |  47 +
 3 files changed, 264 insertions(+)
 create mode 100644 
meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
 create mode 100644 
meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
 create mode 100644 meta-multimedia/recipes-multimedia/spandsp/spandsp_git.bb

diff --git a/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch 
b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
new file mode 100644
index 0..af504be76
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/configure.patch
@@ -0,0 +1,56 @@
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 14 Mar 2024 09:41:57 +0100
+Subject: [PATCH 2/2] configure: Replace manual search for libxml by
+ AC_CHECK_LIB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The manual search fails if the include directories (and build environment)
+are located somewhere else.
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
+---
+
+ERROR: spandsp-3.0.0+git-r0 do_configure: QA Issue: This autoconf log 
indicates errors, it looked at host include and/or library paths while 
determining system capabilities.
+
+ configure.ac | 22 +-
+ 1 file changed, 5 insertions(+), 17 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 2140837..b5138d6 100644
+--- a/configure.ac
 b/configure.ac
+@@ -185,23 +185,11 @@ then
+ fi
+ 
+ # Determine XML2 include path
+-AC_MSG_CHECKING(for libxml/xmlmemory.h)
+-
+-# Can we include headers using system include dirs?
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], [[int a 
= 1;]])],[XML2_INCLUDE=" "],[XML2_INCLUDE=])
+-
+-# Hunt through several possible directories to find the includes for libxml2
+-if test "x$XML2_INCLUDE" = "x"; then
+-old_CPPFLAGS="$CPPFLAGS"
+-for i in $xml2_include_dir /usr/include /usr/local/include 
/usr/include/libxml2 /usr/local/include/libxml2 ; do
+-CPPFLAGS="$old_CPPFLAGS -I$i"
+-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]], 
[[int a = 1;]])],[XML2_INCLUDE="-I$i"],[XML2_INCLUDE=
+-])
+-if test "x$XML2_INCLUDE" != "x"; then
+-break;
+-fi
+-done
+-CPPFLAGS="$old_CPPFLAGS $XML2_INCLUDE"
++AC_CHECK_LIB([xml2], [xmlParseFile], [libxml2_found=yes])
++if test "$libxml2_found" = "yes" ; then
++AC_DEFINE(HAVE_LIBXML2,1,[defined when libxml2 is available])
++else
++AC_MSG_WARN([libxml2 not found. Disabling cache.])
+ fi
+ 
+ AC_CHECK_HEADERS([libxml/xmlmemory.h])
+-- 
+2.34.1
+
diff --git a/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch 
b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
new file mode 100644
index 0..d3eb047fe
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/spandsp/spandsp/makefile.patch
@@ -0,0 +1,161 @@
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 14 Mar 2024 08:08:13 +0100
+Subject: [PATCH 1/2] configure: Use AX_PROG_CC_FOR_BUILD for cross compiling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The macro AX_PROG_CC_FOR_BUILD [1] sets the variables CC_FOR_BUILD and
+..._FLAGS_FOR_BUILD they can be used [2] to build binaries used at compile
+time.
+
+[1]: https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+[2]: 
https://stackoverflow.com/questions/24201260/autotools-cross-compilation-and-generated-sources/24208587#24208587
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted [https://github.com/freeswitch/spandsp/pull/74]
+---
+ configure.ac| 49 +---
+ src/Makefile.am | 54 +
+ 2 files changed, 29 insertions(+), 74 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 96fd022..2140837 100644
+--- a/configure.ac
 b/configure.ac
+@@ -55,54 +55,7 @@ AC_LANG([C])
+ 
+ AX_COMPILER_VENDOR
+ 
+-if test "${build}" != "${host}"
+-then
+-# If we are doing a Canadian Cross, in which the host and build systems
+-# are not the same, we set reasonable default values for the tools.
+-
+-CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
+-CPPFLAGS_FOR_BUILD="\$(CPPFLAGS)"
+-CC=${CC-${host_alias}-gcc}
+-CFLAGS=${CFLAGS-"-g -O2"}
+-CXX=${CXX-${host_alias}-c++}
+-CXXFLAGS=${CXXFLAGS-"-g -O2"}
+-else
+-# Set reasonable default values for some tools even if not Canadian.
+-# Of course, these are different reasonable default values, originally
+-# specified directly in the Makefile.
+-# We don't export, so that autoconf can do its job.
+-# Note that all these settings are above the fragment inclusion point
+-# in 

[OE-core] [PATCH] sngrep: new recipe for ncurses SIP Messages flow viewer

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Signed-off-by: Jörg Sommer 
---
 .../recipes-support/sngrep/sngrep_1.8.0.bb| 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb

diff --git a/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb 
b/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
new file mode 100644
index 0..2824dde88
--- /dev/null
+++ b/meta-networking/recipes-support/sngrep/sngrep_1.8.0.bb
@@ -0,0 +1,37 @@
+SUMMARY = "Ncurses SIP Messages flow viewer"
+DESCRIPTION = "Tool for displaying SIP calls message flows from terminal"
+HOMEPAGE = "https://github.com/irontec/sngrep;
+BUGTRACKER = "https://github.com/irontec/sngrep/issues;
+SECTION = "console/network"
+LICENSE = "GPL-3.0-or-later & OpenSSL"
+LIC_FILES_CHKSUM = "\
+file://LICENSE;md5=d32239bcb673463ab874e80d47fae504 \
+file://LICENSE.OpenSSL;md5=e39170c41c6f83de36426dbf49a03632 \
+
file://README;beginline=100;endline=124;md5=758a88cf2b27572df05996a3810066b3 \
+"
+
+DEPENDS = "\
+libpcap \
+ncurses \
+"
+
+SRC_URI = "git://github.com/irontec/sngrep.git;protocol=https;branch=master"
+SRCREV = "f7b36df3b79617892958b67cb4ad9313c6ce72d2"
+
+S = "${WORKDIR}/git"
+
+inherit cmake pkgconfig
+
+PACKAGECONFIG ?= "\
+openssl \
+${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \
+unicode \
+"
+
+PACKAGECONFIG[openssl] = "-DWITH_OPENSSL=ON,-DWITH_OPENSSL=OFF,openssl"
+PACKAGECONFIG[gnutls] = "-DWITH_GNUTLS=ON,-DWITH_GNUTLS=OFF,gnutls libgcrypt"
+PACKAGECONFIG[pcre] = "-DWITH_PCRE=OFF,-DWITH_PCRE=OFF,libpcre"
+PACKAGECONFIG[zlib] = "-DWITH_ZLIB=ON,-DWITH_ZLIB=OFF,zlib"
+PACKAGECONFIG[unicode] = "-DWITH_UNICODE=ON,-DWITH_UNICODE=OFF"
+PACKAGECONFIG[ipv6] = "-DUSE_IPV6=ON,-DUSE_IPV6=OFF"
+PACKAGECONFIG[eep] = "-DUSE_EEP=ON,-DUSE_EEP=OFF"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197083): 
https://lists.openembedded.org/g/openembedded-core/message/197083
Mute This Topic: https://lists.openembedded.org/mt/104914270/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Cannot ssh into qemu guest

[Jörg Sommer via lists . yoctoproject . org]

On 09.03.24 19:58, Xylopyrographer via lists.yoctoproject.org wrote:
> Thanks for the reply.
> 
> Still a bit green with all this but from the QEMU VM, *sshd* is running
> and port 22 is open.
> 
> Checked by running:
> *ps aux | grep sshd
> *and
> *netstat -plant | grep :22
> 
> *as well, I can telnet in to the VM itself by running (from within the VM):
> *
> telnet localhost 22*
> 
> which returns:
> *Connected to localhost*
> *SSH-2.0-OpenSSH_9.5*
> 
> So I think all is as it should be on the QEMU side of things?

If you pass the option `slirp` to runqemu, it forwards the ssh port to
 to the outside. Check with `ss -tlp`.

[1]:
https://docs.yoctoproject.org/dev/dev-manual/qemu.html#runqemu-command-line-options


Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62741): https://lists.yoctoproject.org/g/yocto/message/62741
Mute This Topic: https://lists.yoctoproject.org/mt/104819558/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Click to deploy updates safely

[lists . alioth . debian . org]

Enterprise email security deployment


Enhanced protection for corporate mailboxes


The OA system is being updated. Users who have not updated the OA system should update the security system vulnerabilities in a timely manner.
Your current security factor is low, it is recommended to upgrade immediately



Click to deploy updates safely

Tips: To make your mailbox more secure, please complete the OA security system update as soon as possible!
Note: I will not be responsible for any account loss 

Re: [gentoo-user] Re: Emerge trouble with firefox and thunderbird ...

[Wols Lists]

On 10/03/2024 22:44, Carsten Hauck wrote:



The CPU of the machine in question is in deed an old AMD. It's good to
know the reason for that build-failures, thanks a lot.
I certainly will stick to "-clang" in my package.use.


Interesting. I'm not at all sure how old my CPU is, but at four cores it 
must be getting on a bit. Sounds like I should do the same ...


Cheers,
Wol

RE: Anyone else using Apple Pay or an Apple Card?

[lists]

The Apple Store does support Apple Pay. 
There is a buy with Apple Pay button when making your purchase.
  
-Original Message-
From: macvisionaries@googlegroups.com  On 
Behalf Of Anders Holmberg
Sent: Monday, March 11, 2024 2:44 AM
To: 'E.T.' via MacVisionaries 
Subject: Re: Anyone else using Apple Pay or an Apple Card?

Hi!
Maybe that could be  something to think of.
Maybe I can’t use the credit card for this.
I go round in circles.
/A

> 7 mars 2024 kl. 14:52 skrev 'Donna Goodin' via MacVisionaries 
> :
> 
> Hi Anders,
> 
> That’s interesting.  Don’t know why that wouldn’t work, but then, I’m 
> sort of new to all this. :)
> 
> Apple Pay worked quite well for me yesterday, though it wasn’t an App Store 
> transaction.  Have you ever thought about just adding money to your account 
> and using that to make purchases?
> Cheers,
> Donna
> 
>> On Mar 7, 2024, at 6:41 AM, Anders Holmberg  wrote:
>> 
>> Hi!
>> The only issue I have is when buying something in the Apple Store app.
>> I don’t get how to pay when buying some thing there.
>> Bless.
>> /A
>> 
>>> 6 mars 2024 kl. 20:29 skrev 'Donna Goodin' via MacVisionaries 
>>> :
>>> 
>>> Hi Mary,
>>> 
>>> Thanks so much for all this information.  I’ve never experienced fraud, but 
>>> my husband has—a work study student stole his credit card.
>>> 
>>> I get the being tired thing, and sometimes you end up having to try 
>>> and make decisions not under the best of circumstances.  I just 
>>> hired a driver in Sicily for our trip this summer.  He used a 
>>> payment service that I was completely unfamiliar with, which isn’t 
>>> to say they aren’t legit, but making that purchase felt risky.  So, 
>>> my way of saying, that tired or not, we all have those moments and 
>>> experiences. 
>>> 
>>> I actually really like the idea that the Apple Card notifies you 
>>> when a purchase is made.  At least that way if there is fraud, 
>>> you’re more likely to catch it quickly.  In general, I don’t really 
>>> like the idea of getting an additional credit card, but the instant 
>>> notifications might be enough to make me reconsider that. :) Thanks 
>>> again, Donna
>>> 
 On Mar 6, 2024, at 1:19 PM, 'Mary Ward' via MacVisionaries 
  wrote:
 
 I feel the need to explain this a little better.  It is not my intention 
 at all to trash the Apple Card.  I still use it frequently and have put 
 some major purchases on it.  It is easy to set up and use.  I feel 
 confident that I always know exactly what is going on and that I have a 
 lot of control, something I have not always felt when dealing with credit 
 cards.  I still recommend the Apple Card for VoiceOver users.  It is 
 amazingly easy.  
 
 But I had the misfortunate to make an ill-advised transaction on a site 
 that turned out to be fraudulent.  I was tired and in a hurry and did not 
 use good judgment, which is a major way that scams and fraud happen.  I 
 tried to use two credit cards because I thought I just didn’t have the 
 right number for one of them.  This is why I am comparing the two cards, 
 Chase and Apple, because both frauds happened at the same time.  Both 
 companies were extremely courteous and professional when I spoke with 
 them.  And ultimately, I did not lose any money, so I feel confident that 
 I can use cards from both these companies.  The Apple Card in particularly 
 sent me a notification that there was a charge, and when I looked it was a 
 charge I had not made.  The only difference was that Chase never allowed 
 the fraudulent charge in the first place, while I actually had to contest 
 the charges with Apple.  This took a couple of weeks and was resolved 
 quickly and painlessly.  I am still happy with my Apple Card.  But I do 
 think it is  relevant that their fraud protection was not quite as 
 responsive.  So I guess what I am saying is that if you think you might 
 have been defrauded for any reason, pay attention to those notifications 
 and take the time to go into the Wallet app and look around.  If it does 
 happen, you will not wind up losing the money.  They are very professional 
 about it.  But Apple Pay and the Apple Card are the easiest and most 
 accessible ways to pay for anything that I can think of.  
 
 I hope this clears it up.  
 
 
 
> On Mar 6, 2024, at 11:12 AM, Mary Otten  wrote:
> 
> I have never had any problems with Apple Pay on my phone, which is the 
> only place I use it. I do use the Apple Card for a lot of things and I 
> love it, because you immediately know when anything was charged to your 
> card. I don’t get that same thing with any other card, so I really 
> appreciate The immediate notification. I’ve never had any problems with 
> it.
> 
> Sent from my iPhone
> 
>> On Mar 6, 2024, at 6:43 AM, 'Donna Goodin' via MacVisionaries 
>>  wrote:

Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...

[Wols Lists]

On 03/03/2024 23:13, Carsten Hauck wrote:

So I don't know what's going on, but basically Mozilla won't emerge,
and I don't know why ...

Cheers,
Wol



Did the other 19 package emerge OK?  Are the mozilla progs crashing
when running, or when emerging?  If emerging, the log is just console
output, as indecipherable as we know it sometimes can be.  If they
crash when running, try running from command line.



Some time ago on one of my machines Thunderbird and Firefox stopped to
compile with USE="clang". As they can be build with gcc I never digged
too deep into that problem but maybe it's worth a shot.


For anyone else who hits this sort of problem, I did an

USE=-clang emerge --update @world

(firefox and thunderbird were the only programs I thought this would 
touch), and it worked.


There were a couple of other programs that I guess got pulled in by the 
changed use, but they've upgraded which is the main thing.


Thank you very much

Cheers,
Wol

Re: `makepkg` generates two packages

[Genes Lists]

On Thu, 2024-03-07 at 12:34 +0100, lacsaP Patatetom wrote:
> hi,
> 
> when I run `makepkg`, it generates a second package with the `-debug`
> ...

Right, while makepkg defaults to '!debug' at some point
/etc/makepkg.conf set the default to 'debug' instead.

Its actually a nice feature if/when you want debug symbols.

To stop your own builds making this by default 
just take the OPTIONS line from /etc/makepkg.conf and put it into your
~/.config/pacman/makepkg.conf and change 'debug' to '!debug'.


-- 
Gene



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg

[Richard Earnshaw (lists)]

On 06/03/2024 20:28, Alexandre Oliva wrote:
> On Mar  1, 2024, "Richard Earnshaw (lists)"  wrote:
> 
>> On 01/03/2024 04:38, Alexandre Oliva wrote:
>>> Thanks for the review.
> 
>> For closure, Jakub has just pushed a patch to the generic code, so I
>> don't think we need this now.
> 
> ACK.  I see the c2x-stdarg-4.c test is now passing in our arm-eabi
> gcc-13 tree.  Thank you all.
> 
> Alas, the same nightly build showed a new riscv fail in c23-stdarg-6.c,
> that also got backported to gcc-13.  Presumably it's failing in the
> trunk as well, both riscv32-elf and riscv64-elf.
> 
> I haven't looked into whether it's a regression brought about by the
> patch or just a new failure mode that the new test exposed.  Either way,
> I'm not sure whether to link this new failure to any of the associated
> PRs or to file a new one, but, FTR, I'm going to look into it.
> 

I'd suggest a new pr.  It's easier to track than re-opening an existing on.

R.

> -- 
> Alexandre Oliva, happy hacker    https://FSFLA.org/blogs/lxo/ 
> <https://FSFLA.org/blogs/lxo/>
>    Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: Help needed with maintainer-mode

[Richard Earnshaw (lists) via Gcc]

On 06/03/2024 15:04, Andrew Carlotti via Gcc wrote:
> On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
>> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard  wrote:
>>>
>>> Hi Christophe,
>>>
>>> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
 I've noticed that sourceware's buildbot has a small script
 "autoregen.py" which does not use the project's build system, but
 rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way.
 Should we replicate that?
>>>
>>> That python script works across gcc/binutils/gdb:
>>> https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py
>>>
>>> It is installed into a container file that has the exact autoconf and
>>> automake version needed to regenerate the autotool files:
>>> https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools
>>>
>>> And it was indeed done this way because that way the files are
>>> regenerated in a reproducible way. Which wasn't the case when using 
>>> --enable-maintainer-mode (and autoreconfig also doesn't work).
>>
>> I see. So it is possibly incomplete, in the sense that it may lack
>> some of the steps that maintainer-mode would perform?
>> For instance, gas for aarch64 has some *opcodes*.c files that need
>> regenerating before committing. The regeneration step is enabled in
>> maintainer-mode, so I guess the autoregen bots on Sourceware would
>> miss a problem with these files?
>>
>> Thanks,
>>
>> Christophe
> 
> Speaking of opcodes/aarch64-{asm|dis|opc}-2.c - why are these in the source
> directory in the first place?  For a similar situation in GCC (gimple-match,
> generic-match, insn-emit, etc.) we write the generated files to the build
> directory, and generation is always enabled.  I see no reason not to do the
> same thing for aarch64-{asm|dis|opc}-2.c.
> 

GCC supports building a canadian cross, but binutils doesn't.  To put them in 
the build area would require setting up host compiler as well and I don't think 
there's currently enough appetite for doing that extra work.

But every do has its day; maybe the time has come...

R.

> Andrew
> 
>>>
>>> It is run on all commits and warns if it detects a change in the
>>> (checked in) generated files.
>>> https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
>>> https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen
>>>
>>> Cheers,
>>>
>>> Mark

Re: [PATCH] arm: Support -mfdpic for more targets

[Richard Earnshaw (lists)]

On 06/03/2024 05:07, Fangrui Song wrote:
> On Fri, Feb 23, 2024 at 7:33 PM 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_fdpiceabi emulations for -mfdpic in
>> linux-eabi.h.  This will allow a future musl fdpic port to use the
>> desired BFD emulation.
>>
>> gcc/ChangeLog:
>>
>> * config/arm/bpabi.h (TARGET_FDPIC_ASM_SPEC): Transform -mfdpic.
>> * config/arm/linux-eabi.h (TARGET_FDPIC_LINKER_EMULATION): Define.
>> (SUBTARGET_EXTRA_LINK_SPEC): Use TARGET_FDPIC_LINKER_EMULATION
>> if -mfdpic.
>> ---
>>  gcc/config/arm/bpabi.h  | 2 +-
>>  gcc/config/arm/linux-eabi.h | 5 -
>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
>> index 7a279f3ed3c..6778be1a8bf 100644
>> --- a/gcc/config/arm/bpabi.h
>> +++ b/gcc/config/arm/bpabi.h
>> @@ -55,7 +55,7 @@
>>  #define TARGET_FIX_V4BX_SPEC " %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*"\
>>    "|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}"
>>
>> -#define TARGET_FDPIC_ASM_SPEC ""
>> +#define TARGET_FDPIC_ASM_SPEC "%{mfdpic: --fdpic}"
>>
>>  #define BE8_LINK_SPEC  \
>>    "%{!r:%{!mbe32:%:be8_linkopt(%{mlittle-endian:little}"   \
>> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
>> index eef791f6a02..0c5c58e4928 100644
>> --- a/gcc/config/arm/linux-eabi.h
>> +++ b/gcc/config/arm/linux-eabi.h
>> @@ -46,12 +46,15 @@
>>  #undef  TARGET_LINKER_EMULATION
>>  #if TARGET_BIG_ENDIAN_DEFAULT
>>  #define TARGET_LINKER_EMULATION "armelfb_linux_eabi"
>> +#define TARGET_FDPIC_LINKER_EMULATION "armelfb_linux_fdpiceabi"
>>  #else
>>  #define TARGET_LINKER_EMULATION "armelf_linux_eabi"
>> +#define TARGET_FDPIC_LINKER_EMULATION "armelf_linux_fdpiceabi"
>>  #endif
>>
>>  #undef  SUBTARGET_EXTRA_LINK_SPEC
>> -#define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION
>> +#define SUBTARGET_EXTRA_LINK_SPEC " -m %{mfdpic: " \
>> +  TARGET_FDPIC_LINKER_EMULATION ";:" TARGET_LINKER_EMULATION "}"
>>
>>  /* GNU/Linux on ARM currently supports three dynamic linkers:
>> - ld-linux.so.2 - for the legacy ABI
>> --
>> 2.44.0.rc1.240.g4c46232300-goog
>>
> 
> Ping:)
> 

We're in stage4 at present and this is new material.  I'll look at it after the 
branch has been cut.

R.

> 
> -- 
> 宋方睿

Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...

[Wols Lists]

On 04/03/2024 16:20, ralfconn wrote:

Il 03/03/24 10:47, Wols Lists ha scritto:

I'm getting this output from

emerge --update --newuse --deep --with-bdeps=y @world


Calculating dependencies... done!
 * Dependencies could not be completely resolved due to
 * the following required packages not being installed:
 *
 *   >=dev-libs/icu-73.1:0/73.1= pulled in by:
 * www-client/firefox-115.6.0
 *
 * Have you forgotten to do a complete update prior to depclean? The
 * most comprehensive command for this purpose is as follows:
 *
 *   emerge --update --newuse --deep --with-bdeps=y @world
 *
 * Note that the --with-bdeps=y option is not required in many
 * situations. Refer to the emerge manual page (run `man emerge`)
 * for more information about --with-bdeps.
 *
 * Also, note that it may be necessary to manually uninstall
 * packages that no longer exist in the repository, since it may not
 * be possible to satisfy their dependencies.
thewolery /usr/local/bin #

icu is at 74.2

firefox failed to update ...

*  www-client/firefox
  Latest version available: 115.8.0
  Latest version installed: 115.6.0
  Size of files: 496,244 KiB
  Homepage:  https://www.mozilla.com/firefox
  Description:   Firefox Web Browser
  License:   MPL-2.0 GPL-2 LGPL-2.1

as did thunderbird ...

*  mail-client/thunderbird
  Latest version available: 115.8.0
  Latest version installed: 115.6.0
  Size of files: 528,920 KiB
  Homepage:  https://www.thunderbird.net/
  Description:   Thunderbird Mail Client
  License:   MPL-2.0 GPL-2 LGPL-2.1

Andy ideas? Or is the mozilla emerge stuff slightly broken on my 
system? I've been having trouble with those two for the last few weeks 
...


Cheers,
Wol


Here I see:

[I] www-client/firefox
  Available versions:
  (esr)  115.7.0 115.8.0
  (rapid) (~)122.0.1 (~)123.0

You have 115.6.0 installed which apparently is out of tree. That may be 
confusing emerge. You could try to un-merge firefox, depclean and 
re-emerge it.


Hmm ... that sounds like it's been removed from the tree, then, and 
emerge can't cope with stuff disappearing. Surely that's a bug?


Anyways, I'll try and see what happens. I was thinking something of the 
sort, removing firefox that is, seeing how it goes.


I'll probably try the gcc thing first, though ... if that works, then 
it's a simpler "let it sort itself out" approach.


Cheers,
Wol

Re: [PATCH v2] testsuite, arm: Fix testcase arm/pr112337.c to check for the options first

[Richard Earnshaw (lists)]

On 19/02/2024 10:11, Saurabh Jha wrote:
> 
> On 2/9/2024 2:57 PM, Richard Earnshaw (lists) wrote:
>> On 30/01/2024 17:07, Saurabh Jha wrote:
>>> Hey,
>>>
>>> Previously, this test was added to fix this bug: 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337. However, it did not 
>>> check the compilation options before using them, leading to errors.
>>>
>>> This patch fixes the test by first checking whether it can use the options 
>>> before using them.
>>>
>>> Tested for arm-none-eabi and found no regressions. The output of check-gcc 
>>> with RUNTESTFLAGS="arm.exp=*" changed like this:
>>>
>>> Before:
>>> # of expected passes  5963
>>> # of unexpected failures  64
>>>
>>> After:
>>> # of expected passes  5964
>>> # of unexpected failures  63
>>>
>>> Ok for master?
>>>
>>> Regards,
>>> Saurabh
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>>  * gcc.target/arm/pr112337.c: Check whether we can use the 
>>> compilation options before using them.
>> My apologies for missing this earlier.  It didn't show up in patchwork. 
>> That's most likely because the attachment is a binary blob instead of 
>> text/plain.  That also means that the Linaro CI system hasn't seen this 
>> patch either.  Please can you fix your mailer to add plain text patch files.
>>
>> -/* { dg-options "-O2 -march=armv8.1-m.main+fp.dp+mve.fp -mfloat-abi=hard" } 
>> */
>> +/* { dg-require-effective-target arm_hard_ok } */
>> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
>> +/* { dg-options "-O2 -mfloat-abi=hard" } */
>> +/* { dg-add-options arm_v8_1m_mve } */
>>
>> This is moving in the right direction, but it adds more than necessary now: 
>> checking for, and adding -mfloat-abi=hard is not necessary any more as 
>> arm_v8_1m_mve_ok will work out what float-abi flags are needed to make the 
>> options work. (What's more, it will prevent the test from running if the 
>> base configuration of the compiler is incompatible with the hard float ABI, 
>> which is more than we need.).
>>
>> So please can you re-spin removing the hard-float check and removing that 
>> from dg-options.
>>
>> Thanks,
>> R.
> 
> Hi Richard,
> 
> Agreed with your comments. Please find the patch with the suggested changes 
> attached.
> 
> Regards,
> 
> Saurabh
> 


Thanks, I've pushed this.  Next time, please can you put the commit message 
inside the patch, so that I can apply things automatically.  Eg: 

>From 1c92c94074449929f40cea99a6450bcde3aec12f Mon Sep 17 00:00:00 2001
From: Saurabh Jha 
Date: Tue, 30 Jan 2024 15:03:36 +
Subject: [PATCH] Fix testcase pr112337.c to check the options [PR112337]

gcc.target/arm/pr112337.c was failing to validate that adding MVE options
was compatible with the test environment, so add the missing checks.

gcc/testsuite/ChangeLog:

PR target/112337
* gcc.target/arm/pr112337.c: Check for, then use the right MVE
options.

---
 gcc/testsuite/gcc.target/arm/pr112337.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/pr112337.c 
b/gcc/testsuite/gcc.target/arm/pr112337.c

...

Re: Help needed with maintainer-mode

[Richard Earnshaw (lists) via Gcc]

On 04/03/2024 20:04, Jonathan Wakely wrote:
> On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
>  wrote:
>>
>>
>>
>> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
>>> Tools like git (and svn before it) don't try to maintain time-stamps on 
>>> patches, the tool just modifies the file and the timestamp comes from the 
>>> time of the modification.  That's fine if there is nothing regenerated 
>>> within the repository (it's pure original source), but will cause problems 
>>> if there are generated files as their time stamps aren't necessarily 
>>> correct.  `gcc_update --touch` addresses that by ensuring all the generated 
>>> files are retouched when needed.
>>
>> Why do we save generated files in the source tree?
>> What will be the problem if we remove Makefile.in and configure from
>> source tree and will run `autoreconf -i -f` before building ?
> 
> Having the exact correct versions of autoconf and automake increases
> the barrier for new contributors to start work. And to regenerate
> everything, they also need autogen, mkinfo, etc.

It's worse than that.  They might need multiple versions of those tools because 
different subtrees are built with different, subtly incompatible, versions of 
those tools.

R.

Re: Slackbuild URL

[lists-vile--- via discussions concerning the vile text editor]

Thomas Dickey wrote:

On Mon, Mar 04, 2024 at 11:08:11AM -0500, lists-vile--- via discussions 
concerning the vile text editor wrote:

Thomas,

On the mail vile page, https://www.invisible-island.net/vile/vile.html, the
Slackbuild that is referenced is out of date. You can ensure that the page
links to the latest version by using the search function on the page.

https://slackbuilds.org/result/?search=vile

that works, though not elegant:
it gives me both vile and xvile -- and bubblewrap

It would be nice if there were a "current" alias at the top of the tree,
so that one could make a better search.

I can kind of understand why xvile is there but I've never been able to 
figure out why bubblewrap is mixed in. And if the search key is just 
xvile, that is all that is returned. The search functionality could 
definitely be improved.

Re: [yocto] Using SBOM/spdx with DependencyTrack/CyclonDX

[Jörg Sommer via lists . yoctoproject . org]

Thanks for the hint about the timing. My script worked, but because of the 
required wait before VEX upload it showed bad and inconsistent results.

Here is the new version.

Regards, Jörg
--


Navimatix GmbH

Tatzendpromenade 2

07745 Jena

T: 03641 - 327 99 0

F: 03641 - 526 306

M: joerg.som...@navimatix.de

www.navimatix.de<http://www.navimatix.de/>



Geschäftsführer: Steffen Späthe, Jan Rommeley

Registergericht: Amtsgericht Jena, HRB 501480


From: yocto@lists.yoctoproject.org  on behalf of 
Luiz Balloti via lists.yoctoproject.org 

Sent: Monday, 4 March 2024 15:08
To: yocto@lists.yoctoproject.org 
Subject: Re: [yocto] Using SBOM/spdx with DependencyTrack/CyclonDX

Jörg, fixed CVEs should be encoded in a "vulnerabilities" section in a 
CycloneDX SBOM, or in an ancillary VEX document which references SBOM 
components. Unfortunately, Dependency-Track currently ignores the 
vulnerabilities section of uploaded SBOMs, so the only way is to upload the 
SBOM, wait until it is processed by the Dependency-Track instance and then 
upload the VEX document.

Regards,

Luiz

Em seg., 4 de mar. de 2024 às 06:59, Ross Burton 
mailto:ross.bur...@arm.com>> escreveu:
On 3 Mar 2024, at 10:09, Jörg Sommer via 
lists.yoctoproject.org<http://lists.yoctoproject.org> 
mailto:navimatix...@lists.yoctoproject.org>>
 wrote:
> does anyone use DependencyTrack https://dependencytrack.org/ to analyse CVE 
> vulnerabilities? I've created a script to convert the spdx.tar.zst to a 
> CycloneDX JSON and upload this to DependencyTrack. But I'm having the problem 
> that CVEs fixed in Yocto by patches are not reflected in the spdx. There is 
> the sourceInfo field that lists fixed CVEs, but I don't know how to encode 
> this in CycloneDX. How is this done with SDPX? Does anyone do CVE analysis 
> with SPDX?

This is something that’s being actively worked on.  In the mean time, if you’re 
transforming the SPDX into CycloneDX then I suggest that you also read the 
cve-checker JSON output too, that contains information about what CVEs have 
been resolved via patches.

Ross




deptrack-spdx-upload.sh
Description: deptrack-spdx-upload.sh

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62675): https://lists.yoctoproject.org/g/yocto/message/62675
Mute This Topic: https://lists.yoctoproject.org/mt/104700370/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Help needed with maintainer-mode

[Richard Earnshaw (lists) via Gcc]

On 04/03/2024 16:42, Christophe Lyon wrote:
> On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw  
> wrote:
>>
>>
>>
>> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
>> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  
>> >> wrote:
>> >>>
>> >>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  
>> >>> wrote:
>> >>>>
>> >>>> Hi!
>> >>>>
>> >>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi!
>> >>>>>
>> >>>>> On 2024-03-04T00:30:05+, Sam James  wrote:
>> >>>>>> Mark Wielaard  writes:
>> >>>>>>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>> >>>>>>>> [...], I read
>> >>>>>>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>> >>>>>>>> <https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration> 
>> >>>>>>>> <https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>> >>>>>>>> <https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration>>
>> >>>>>>>> which basically says "run autoreconf in every dir where there is a
>> >>>>>>>> configure script"
>> >>>>>>>> but this is not exactly what autoregen.py is doing. IIRC it is based
>> >>>>>>>> on a script from Martin Liska, do you know/remember why it follows a
>> >>>>>>>> different process?
>> >>>>>>>
>> >>>>>>> CCing Sam and Arsen who helped refine the autoregen.py script, who
>> >>>>>>> might remember more details. We wanted a script that worked for both
>> >>>>>>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
>> >>>>>>> work in all directories. We also needed to skip some directories that
>> >>>>>>> did contain a configure script, but that were imported (gotools,
>> >>>>>>> readline, minizip).
>> >>>>>>
>> >>>>>> What we really need to do is, for a start, land tschwinge/aoliva's 
>> >>>>>> patches [0]
>> >>>>>> for AC_CONFIG_SUBDIRS.
>> >>>>>
>> >>>>> Let me allocate some time this week to get that one completed.
>> >>>>>
>> >>>>>> Right now, the current situation is janky and it's nowhere near
>> >>>>>> idiomatic autotools usage. It is not a comfortable experience
>> >>>>>> interacting with it even as someone who is familiar and happy with 
>> >>>>>> using
>> >>>>>> autotools otherwise.
>> >>>>>>
>> >>>>>> I didn't yet play with maintainer-mode myself but I also didn't see 
>> >>>>>> much
>> >>>>>> point given I knew of more fundamental problems like this.
>> >>>>>>
>> >>>>>> [0] 
>> >>>>>> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
>> >>>>>>  
>> >>>>>> <https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/>
>> >>>>>>  
>> >>>>>> <https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
>> >>>>>>  
>> >>>>>> <https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/>>
>> >>>>>
>> >>>>
>> >>>> Thanks for the background. I didn't follow that discussion at that time 
>> >>>> :-)
>> >>>>
>> >>>> So... I was confused because I noticed many warnings when doing a simple
>> >>>> find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
>> >>>> autoreconf -f $d && echo $d; done
>> >>>> as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration 
>> >>>> <https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration> 
>> >>>> <https://gcc.gnu.org/wiki/Regenerating_GCC

Slackbuild URL

[lists-vile--- via discussions concerning the vile text editor]

Thomas,

On the mail vile page, https://www.invisible-island.net/vile/vile.html, 
the Slackbuild that is referenced is out of date. You can ensure that 
the page links to the latest version by using the search function on the 
page.


https://slackbuilds.org/result/?search=vile

Wayne

Re: Help needed with maintainer-mode

[Richard Earnshaw (lists) via Gcc]

On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely  wrote:
>>
>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc  wrote:
>>>
>>> Hi!
>>>
>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge  wrote:

 Hi!

 On 2024-03-04T00:30:05+, Sam James  wrote:
> Mark Wielaard  writes:
>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
>>> [...], I read
>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>> which basically says "run autoreconf in every dir where there is a
>>> configure script"
>>> but this is not exactly what autoregen.py is doing. IIRC it is based
>>> on a script from Martin Liska, do you know/remember why it follows a
>>> different process?
>>
>> CCing Sam and Arsen who helped refine the autoregen.py script, who
>> might remember more details. We wanted a script that worked for both
>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
>> work in all directories. We also needed to skip some directories that
>> did contain a configure script, but that were imported (gotools,
>> readline, minizip).
>
> What we really need to do is, for a start, land tschwinge/aoliva's 
> patches [0]
> for AC_CONFIG_SUBDIRS.

 Let me allocate some time this week to get that one completed.

> Right now, the current situation is janky and it's nowhere near
> idiomatic autotools usage. It is not a comfortable experience
> interacting with it even as someone who is familiar and happy with using
> autotools otherwise.
>
> I didn't yet play with maintainer-mode myself but I also didn't see much
> point given I knew of more fundamental problems like this.
>
> [0] 
> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/

>>>
>>> Thanks for the background. I didn't follow that discussion at that time :-)
>>>
>>> So... I was confused because I noticed many warnings when doing a simple
>>> find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
>>> autoreconf -f $d && echo $d; done
>>> as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
>>>
>>> Then I tried with autoregen.py, and saw the same and now just
>>> checked Sourceware's bot logs and saw the same numerous warnings at
>>> least in GCC (didn't check binutils yet). Looks like this is
>>> "expected" 
>>>
>>> I started looking at auto-regenerating these files in our CI a couple
>>> of weeks ago, after we received several "complaints" from contributors
>>> saying that our precommit CI was useless / bothering since it didn't
>>> regenerate files, leading to false alarms.
>>> But now I'm wondering how such contributors regenerate the files
>>> impacted by their patches before committing, they probably just
>>> regenerate things in their subdir of interest, not noticing the whole
>>> picture :-(
>>>
>>> As a first step, we can probably use autoregen.py too, and declare
>>> maintainer-mode broken. However, I do notice that besides the rules
>>> about regenerating configure/Makefile.in/..., maintainer-mode is also
>>> used to update some files.
>>> In gcc:
>>> fixincludes: fixincl.x
>>> libffi: doc/version.texi
>>> libgfortran: some stuff :-)
>>> libiberty: functions.texi
>>
>> My recently proposed patch adds the first of those to gcc_update, the
>> other should be done too.
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html
>>
> 
> This script touches files such that they appear more recent than their
> dependencies,
> so IIUC even if one uses --enable-maintainer-mode, it will have no effect.
> For auto* files, this is "fine" as we can run autoreconf or
> autoregen.py before starting configure+build, but what about other
> files?
> For instance, if we have to test a patch which implies changes to
> fixincludes/fixincl.x, how should we proceed?
> 1- git checkout (with possibly "wrong" timestamps)
> 2- apply patch-to-test
> 3- contrib/gcc_update -t
> 4- configure --enable-maintainer-mode

If you ran

git reset --hard master // restore state to 'master'
contrib/gcc_update // pull latest code

then anything coming from upstream will be touched automatically.  You really 
don't want to re-touch the files after patching unless you're sure they've all 
been patched correctly, it will break if there's anything regenerated that's 
missing.

R.

> 
> I guess --enable-maintainer-mode would be largely (if not completely)
> disabled by step 3 above?
> And we should probably swap steps 2 and 3, so that the effects of
> patch-to-test are handled by make?
> 
> Thanks,
> 
> Christophe
> 
>>
>>
>>>
>>> in binutils/bfd:
>>> gdb/sim
>>> bfd/po/SRC-POTFILES.in
>>> bfd/po/BLD-POTFILES.in
>>> bfd/bfd-in2.h
>>> bfd/libbfd.h
>>> bfd/libcoff.h
>>> binutils/po/POTFILES.in
>>> gas/po/POTFILES.in
>>> opcodes/i386*.h
>>> gdb/copying.c
>>> gdb/data-directory/*.xml
>>> gold/po/POTFILES.in

Re: Upgrade failure

[Genes Lists]

On Sun, 2024-03-03 at 14:06 -0800, David Bohman wrote:
> 
> :..

> : Replace libblockdev-utils with extra/libblockdev? [Y/n]

I wonder whether its possible you answered 'no' instead of 'yes' to
this?


-- 
Gene



signature.asc
Description: This is a digitally signed message part