Re: [PATCH] arm: Fix CASE_VECTOR_SHORTEN_MODE for thumb2.

[Richard Earnshaw (lists)]

On 06/06/2024 15:40, Richard Ball wrote:
> The CASE_VECTOR_SHORTEN_MODE query is missing some equals signs
> which causes suboptimal codegen due to missed optimisation
> opportunities. This patch also adds a test for thumb2
> switch statements as none exist currently.
> 
> gcc/ChangeLog:
>   PR target/115353
>   * config/arm/arm.h (enum arm_auto_incmodes):
>   Correct CASE_VECTOR_SHORTEN_MODE query.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/arm/thumb2-switchstatement.c: New test.

OK.

R.

Re: arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

[Richard Earnshaw (lists)]

On 05/06/2024 17:07, Andre Vieira (lists) wrote:
> Hi,
> 
> This patch adds missing assembly directives to the CMSE library wrapper to 
> call functions with attribute cmse_nonsecure_call.  Without the .type 
> directive the linker will fail to produce the correct veneer if a call to 
> this wrapper function is to far from the wrapper itself.  The .size was added 
> for completeness, though we don't necessarily have a usecase for it.
> 
> I did not add a testcase as I couldn't get dejagnu to disassemble the linked 
> binary to check we used an appropriate branch instruction, I did however test 
> it locally and with this change the GNU linker now generates an appropriate 
> veneer and call to that veneer when __gnu_cmse_nonsecure_call is too far.
> 
> OK for trunk and backport to any release branches still in support (after 
> waiting a week or so)?
> 
> libgcc/ChangeLog:
> 
> PR target/115360
> * config/arm/cmse_nonsecure_call.S: Add .type and .size directives.

OK.

R.

Re: Looking for some pre-buying verification: will an external display actually work with a Lenovo Thinkpad P16 Gen 2?

[Lists]

On 2024-06-03 23:50, Felix Miata wrote:

Lists composed on 2024-06-03 22:39 (UTC+0200):


I am thinking of replacing my old workstation with a Lenovo Thinkpad P16
Gen 2.


That's a model line, not a model. It's available with multiple CPU/GPU 
combinations.


You are correct. That slipped by me when I wrote my mail.


To use it as described, I suggest to get one with only one GPU. Most problems
laptop users want help with have hybrid graphics, and/or NVidia graphics as part
of their mix. The reason for hybrid graphics is basically for maximizing both
battery life and graphics performance. The former has no material relevance when
rarely running on battery.


Thanks for that idea. As I don't do anything remotely graphically taxing 
I don't need a speedy GPU. Most of my work on this machine will be 
programming and remote admin. Apart from watching a 4K video once in a 
while I dabble a bit in CAD, but those are fairly simple drawings that 
would in no way require a super-duper GPU.


I'll try to find out if they allow for a configuration with an Intel 
graphics iGPU only, or otherwise the simplest dGPU. Ada 1000 seems to be 
the lowest spec available if I remember correctly. That should be more 
than sufficient.


Grx HdV

Re: [tor-relays] Onion Services operators please enable tor PoW defense

[lists]

On Mittwoch, 5. Juni 2024 14:50:20 CEST gus wrote:
> Hi,
> 
> As some of you might have noticed, we have a high load situation on the
> network for a couple of weeks now affecting in particular onion services
> (but not only them).[1]
> 
> We recommend Onion Services operators to enable our Proof of Work (PoW)
> defense[2][3] and finetune their torrc[4].
> 

As a little help, defaults from 0.4.8.11

### IntroDoSDefense & PoWDefenses are disabled by default
#
# https://community.torproject.org/onion-services/ecosystem/technology/pow/
# More details, see: 'man torrc' DENIAL OF SERVICE MITIGATION OPTIONS
# Tor Network values set by the consensus, if any, can be found here:
# https://consensus-health.torproject.org/#consensusparams

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 80 [::1]:80

# HiddenService options are per onion service:
HiddenServiceEnableIntroDoSDefense 1
#HiddenServiceEnableIntroDoSBurstPerSec 200 # (Default: 200)
#HiddenServiceEnableIntroDoSRatePerSec 25   # (Default: 25)

HiddenServicePoWDefensesEnabled 1
#HiddenServicePoWQueueRate 250  # (Default: 250)
#HiddenServicePoWQueueBurst 2500# (Default: 2500)
#CompiledProofOfWorkHash auto   # (Default: auto)

HiddenServiceDir /var/lib/tor/other_hidden_service/
HiddenServicePort 22 127.0.0.1:22
HiddenServicePort 22 [::1]:22
HiddenServiceEnableIntroDoSDefense 1
...


For larger websites and forums like Dread:
https://blog.nihilism.network/servers/endgame/index.html

-- 
╰_╯ 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: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 20:15, Meowie Gamer wrote:

I must've taken too long to join the mailing list because I missed the first 
part of whatever's happening here. How did this turn from python 3.12 to a 
conversation about USE?



Because they're using USE or whatever to force packages to stay on 3.11, 
because they won't build with 3.12.


So it's not necessarily about USE, but about the tactics people use to 
make emerge work the way they want. It might be MASK, or any of the 
other package... directories.


Cheers,
Wol

Re: [gentoo-user] python 3.12 update

[Wols Lists]

On 05/06/2024 13:12, Eli Schwartz wrote:

Which I think is fine, if people want that, but not everyone does, so
delaying the update altogether might be preferable to those people.


Ie people like me who don't give a monkeys about python, and consider it 
a necessary evil.


As far as I'm concerned, python just happens to be a dependency of 
things I *am* interested in, so any grief updating it is "pure grief and 
no benefit".


That said, I probably haven't run "emerge" since all this shit hit, so I 
haven't noticed anything ... :-)


Cheers,
Wol

Re: [gentoo-user] Re: python 3.12 update

[Wols Lists]

On 05/06/2024 13:28, Rich Freeman wrote:

Implementing dynamic USE management would take somebody a fair bit of
effort, and for all I know it would make every emerge you run take an
hour to recompute the dependency tree.  The ability to configure USE
flags, along with the ability to dynamically decide the version of
dynamically linked packages, makes Gentoo have a dependency tree that
is MUCH larger than basically any other distro out there.  This is why
portage takes so long to decide what to install compared to basically
everything else.


What I at least try to do is use "autounmask-write", or whatever the 
appropriate option is. This does I believe flag individual versions of 
whatever.


Then I DON'T let etc-update append the changes to J Random File in 
whatever package... directory is appropriate !!!


I rename the ._ file to usually the name of the package I'm interested 
in, or maybe the current date, or whatever. Point is, I don't get some 
humungous file full of assorted unrelated dependencies. And then when 
I'm bored I go through deleting loads of files maybe 6 months old or 
more. Seeing as the packages have usually been replaced by then, it 
rarely affects anything.


Yes it's a minor pain I have to go through this for pretty much every 
package update if I've got a problem package, but I do a --update once a 
week at most, so it's very little hassle.


And occasionally I'll add the flag to make.conf, instead ... :-)

Cheers,
Wol

[ceph-users] Re: CORS Problems

[mailing-lists]

Hi,

so there is a problem, alright!

I do not have a separate nginx proxy in front of my rgw/ingress. As far 
as I understand, the "ingress" service is only keepalived and haproxy. I 
am not sure how to strip the OPTIONS method within those containers...


I will probably just disable the redirect on the website and relay the 
upload for the time until it gets fixed.


Thank you for your input, this keeps me from spending more time 
investigating!



Best

inDane



On 05.06.24 18:13, Reid Guyett wrote:

Hi,

There is a bug with preflight on PUT requests: 
https://tracker.ceph.com/issues/64308.


We have worked around it by stripping the query parameters of OPTIONS 
requests to the RGWs.

Nginx proxy config:
if ($request_method = OPTIONS) {
    rewrite ^\/(.+)$ /$1? break;
}

Regards,
Reid

On Wed, Jun 5, 2024 at 12:10 PM mailing-lists 
 wrote:


OK, sorry for spam, apparently this hasn't been working for a month...

Forget this mail. Sorry!


On 05.06.24 17:41, mailing-lists wrote:
> Dear Cephers,
>
> I am facing a Problem. I have updated our ceph cluster form
17.2.3 to
> 17.2.7 last week and i've just gotten complains about a website
that
> is not able to use s3 via CORS anymore. (GET works, PUT does not).
>
> I am using cephadm and i have deployed 3 rgws + 2 ingress services.
>
> The bucket shows:
>
> aws s3api get-bucket-cors
>
> {
>     "CORSRules": [
>     {
>     "AllowedHeaders": [
>     "*"
>     ],
>     "AllowedMethods": [
>     "GET",
>     "PUT"
>     ],
>     "AllowedOrigins": [
>     "*"
>     ],
>     "ExposeHeaders": [
>     "ETag",
>     "Accept-Ranges",
>     "Content-Encoding",
>     "Content-Range"
>     ]
>     }
>     ]
> }
>
> Which is supposed to be a working config (at least this was working
> until the update).
>
> Cross-Origin Request Blocked: The Same Origin Policy disallows
reading
> the remote resource at https:/EXAMPLE.com[.] (Reason: CORS
header
> ‘Access-Control-Allow-Origin’ missing). Status code: 403.
>
>
> I can not 100% say that the update is the culprit, but I haven't
> touched anything else and before the update it was working.
>
> Did I miss an important change?
>
>
> Best
>
> inDane
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io


___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: CORS Problems

[mailing-lists]

OK, sorry for spam, apparently this hasn't been working for a month...

Forget this mail. Sorry!


On 05.06.24 17:41, mailing-lists wrote:

Dear Cephers,

I am facing a Problem. I have updated our ceph cluster form 17.2.3 to 
17.2.7 last week and i've just gotten complains about a website that 
is not able to use s3 via CORS anymore. (GET works, PUT does not).


I am using cephadm and i have deployed 3 rgws + 2 ingress services.

The bucket shows:

aws s3api get-bucket-cors

{
    "CORSRules": [
    {
    "AllowedHeaders": [
    "*"
    ],
    "AllowedMethods": [
    "GET",
    "PUT"
    ],
    "AllowedOrigins": [
    "*"
    ],
    "ExposeHeaders": [
    "ETag",
    "Accept-Ranges",
    "Content-Encoding",
    "Content-Range"
    ]
    }
    ]
}

Which is supposed to be a working config (at least this was working 
until the update).


Cross-Origin Request Blocked: The Same Origin Policy disallows reading 
the remote resource at https:/EXAMPLE.com[.] (Reason: CORS header 
‘Access-Control-Allow-Origin’ missing). Status code: 403.



I can not 100% say that the update is the culprit, but I haven't 
touched anything else and before the update it was working.


Did I miss an important change?


Best

inDane
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

[Andre Vieira (lists)]

Hi,

This patch adds missing assembly directives to the CMSE library wrapper 
to call functions with attribute cmse_nonsecure_call.  Without the .type 
directive the linker will fail to produce the correct veneer if a call 
to this wrapper function is to far from the wrapper itself.  The .size 
was added for completeness, though we don't necessarily have a usecase 
for it.


I did not add a testcase as I couldn't get dejagnu to disassemble the 
linked binary to check we used an appropriate branch instruction, I did 
however test it locally and with this change the GNU linker now 
generates an appropriate veneer and call to that veneer when 
__gnu_cmse_nonsecure_call is too far.


OK for trunk and backport to any release branches still in support 
(after waiting a week or so)?


libgcc/ChangeLog:

PR target/115360
* config/arm/cmse_nonsecure_call.S: Add .type and .size directives.diff --git a/libgcc/config/arm/cmse_nonsecure_call.S 
b/libgcc/config/arm/cmse_nonsecure_call.S
index 
f93ce6bb4f9f679020c9684c56f5916f1c0bf73c..fef37b955af673fb975dd64229d5e0647afe0d00
 100644
--- a/libgcc/config/arm/cmse_nonsecure_call.S
+++ b/libgcc/config/arm/cmse_nonsecure_call.S
@@ -33,6 +33,7 @@
 #endif
 
 .thumb
+.type __gnu_cmse_nonsecure_call, %function
 .global __gnu_cmse_nonsecure_call
 __gnu_cmse_nonsecure_call:
 #if defined(__ARM_ARCH_8M_MAIN__)
@@ -142,3 +143,4 @@ pop {r5-r7, pc}
 #else
 #error "This should only be used for armv8-m base- and mainline."
 #endif
+.size __gnu_cmse_nonsecure_call, .-__gnu_cmse_nonsecure_call

[ceph-users] CORS Problems

[mailing-lists]

Dear Cephers,

I am facing a Problem. I have updated our ceph cluster form 17.2.3 to 
17.2.7 last week and i've just gotten complains about a website that is 
not able to use s3 via CORS anymore. (GET works, PUT does not).


I am using cephadm and i have deployed 3 rgws + 2 ingress services.

The bucket shows:

aws s3api get-bucket-cors

{
    "CORSRules": [
    {
    "AllowedHeaders": [
    "*"
    ],
    "AllowedMethods": [
    "GET",
    "PUT"
    ],
    "AllowedOrigins": [
    "*"
    ],
    "ExposeHeaders": [
    "ETag",
    "Accept-Ranges",
    "Content-Encoding",
    "Content-Range"
    ]
    }
    ]
}

Which is supposed to be a working config (at least this was working 
until the update).


Cross-Origin Request Blocked: The Same Origin Policy disallows reading 
the remote resource at https:/EXAMPLE.com[.] (Reason: CORS header 
‘Access-Control-Allow-Origin’ missing). Status code: 403.



I can not 100% say that the update is the culprit, but I haven't touched 
anything else and before the update it was working.


Did I miss an important change?


Best

inDane
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [tor-relays] Relay migration

[lists]

On Dienstag, 4. Juni 2024 23:24:50 CEST Roger Dingledine wrote:
> On Tue, Jun 04, 2024 at 04:42:50PM +, Eldalië via tor-relays wrote:

> > I have to move somewhere else a a (middle) relay I have been running for a
> > few years. It will be down for 2-4 weeks, then be back online in a
> > different location, with different ISP, at better speed. But it will run
> > on the same hardware and software. Should I keep the same keys, or start
> > from scratch?

> Having a relay downtime of 2-4 weeks though could really increase the
> time until you get flags like Guard back, due to some design flaws in
> how the directory authorities track stability. (The simple version of the
> issue is: we treat downtime as much more serious than not-existing-yet.)

Thanks for the info, Roger.

@Eldalië If you want to keep your history on Tor metrics, go with the old 
keys.
If you generate new keys and have a new IP, you can let your relay run as a 
bridge for a few weeks or months and then reconfigure it later. That would be 
very helpful, especially if the IP is accessible from Turkmenistan. It's been 
a year, but internet censorship is still there:
https://forum.torproject.org/t/tor-relays-help-turkmens-to-bypass-internet-censorship-run-an-obfs4-bridge/7002/8#torrc-example-6

-- 
╰_╯ 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: RFC: Support for pragma clang loop interleave_count(N)

[Andre Vieira (lists)]

On 04/06/2024 12:50, Richard Biener wrote:

On Tue, 4 Jun 2024, Andre Vieira (lists) wrote:


Hi,

We got a question as to whether GCC had something similar to llvm's pragma
clang loop interleave_count(N), see
https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations

I did a quick hack, using 'GCC interleaves N', just as a proof of concept, to
see whether we could connect this to the suggested_unroll_factor in the
vectorizer and to test the waters regarding having something like this
upstream.

For the real thing I'd suggest we use the same pragma syntax as clang's so its
easier to port code.  It is my understanding that the main use for this is for
doing performance tuning of HPC kernels and performance tuning of CPU's cost
models.

This seems to work (TM), though with the move to slp-only I guess this will
stop working? Though I suspect we will want to have similar capabilities in
SLP, or maybe we have already and I didn't look hard enough.


suggested-unroll-factor also works with SLP, at least I don't see a
reason why it should not.



I think I may have misread what this (see below) was trying to say and 
assumed we didn't support it.


  /* If the slp decision is false when suggested unroll factor is worked
 out, and we are applying suggested unroll factor, we can simply skip
 all slp related analyses this time.  */
  bool slp = !applying_suggested_uf || slp_done_for_suggested_uf;

RFC: Support for pragma clang loop interleave_count(N)

[Andre Vieira (lists)]

Hi,

We got a question as to whether GCC had something similar to llvm's 
pragma clang loop interleave_count(N), see

https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations

I did a quick hack, using 'GCC interleaves N', just as a proof of 
concept, to see whether we could connect this to the 
suggested_unroll_factor in the
vectorizer and to test the waters regarding having something like this 
upstream.


For the real thing I'd suggest we use the same pragma syntax as clang's 
so its easier to port code.  It is my understanding that the main use 
for this is for doing performance tuning of HPC kernels and performance 
tuning of CPU's cost models.


This seems to work (TM), though with the move to slp-only I guess this 
will stop working? Though I suspect we will want to have similar 
capabilities in SLP, or maybe we have already and I didn't look hard enough.


Also only implemented it for C and C++, have not looked at Fortran.

WDYT?

Kind regards,
Andrediff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
index 
ce93a52fa578127f1eade05dbafdf52021fd61fe..945c314d31c715522e56141ef9b616e52b466261
 100644
--- a/gcc/c-family/c-pragma.h
+++ b/gcc/c-family/c-pragma.h
@@ -87,6 +87,7 @@ enum pragma_kind {
   PRAGMA_GCC_PCH_PREPROCESS,
   PRAGMA_IVDEP,
   PRAGMA_UNROLL,
+  PRAGMA_INTERLEAVES,
   PRAGMA_NOVECTOR,
 
   PRAGMA_FIRST_EXTERNAL
diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc
index 
1237ee6e62b9d501a7f9ad1cc267061ed068b920..facfb75c1eb9f184f05f4476a3aa04b45c21fd9a
 100644
--- a/gcc/c-family/c-pragma.cc
+++ b/gcc/c-family/c-pragma.cc
@@ -1828,6 +1828,10 @@ init_pragma (void)
 cpp_register_deferred_pragma (parse_in, "GCC", "unroll", PRAGMA_UNROLL,
  false, false);
 
+  if (!flag_preprocess_only)
+cpp_register_deferred_pragma (parse_in, "GCC", "interleaves", 
PRAGMA_INTERLEAVES,
+ false, false);
+
   if (!flag_preprocess_only)
 cpp_register_deferred_pragma (parse_in, "GCC", "novector", PRAGMA_NOVECTOR,
  false, false);
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 
00f8bf4376e537e04ea8e468a05dade3c7212d8b..69b36d196bd74b494ffb6186be5240e3d2431407
 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -1665,11 +1665,12 @@ static tree c_parser_c99_block_statement (c_parser *, 
bool *,
  location_t * = NULL);
 static void c_parser_if_statement (c_parser *, bool *, vec *);
 static void c_parser_switch_statement (c_parser *, bool *);
-static void c_parser_while_statement (c_parser *, bool, unsigned short, bool,
- bool *);
-static void c_parser_do_statement (c_parser *, bool, unsigned short, bool);
-static void c_parser_for_statement (c_parser *, bool, unsigned short, bool,
-   bool *);
+static void c_parser_while_statement (c_parser *, bool, unsigned short,
+ unsigned short, bool, bool *);
+static void c_parser_do_statement (c_parser *, bool, unsigned short,
+  unsigned short,bool);
+static void c_parser_for_statement (c_parser *, bool, unsigned short,
+   unsigned short, bool, bool *);
 static tree c_parser_asm_statement (c_parser *);
 static tree c_parser_asm_operands (c_parser *);
 static tree c_parser_asm_goto_operands (c_parser *);
@@ -7603,13 +7604,13 @@ c_parser_statement_after_labels (c_parser *parser, bool 
*if_p,
  c_parser_switch_statement (parser, if_p);
  break;
case RID_WHILE:
- c_parser_while_statement (parser, false, 0, false, if_p);
+ c_parser_while_statement (parser, false, 0, 0, false, if_p);
  break;
case RID_DO:
- c_parser_do_statement (parser, false, 0, false);
+ c_parser_do_statement (parser, false, 0, 0, false);
  break;
case RID_FOR:
- c_parser_for_statement (parser, false, 0, false, if_p);
+ c_parser_for_statement (parser, false, 0, 0, false, if_p);
  break;
case RID_GOTO:
  c_parser_consume_token (parser);
@@ -8105,7 +8106,7 @@ c_parser_switch_statement (c_parser *parser, bool *if_p)
 
 static void
 c_parser_while_statement (c_parser *parser, bool ivdep, unsigned short unroll,
- bool novector, bool *if_p)
+ unsigned short interleaves, bool novector, bool *if_p)
 {
   tree block, cond, body;
   unsigned char save_in_statement;
@@ -8135,6 +8136,11 @@ c_parser_while_statement (c_parser *parser, bool ivdep, 
unsigned short unroll,
   build_int_cst (integer_type_node,
  annot_expr_unroll_kind),
   build_int_cst (integer_type_node, unroll));
+  if (interleaves && cond != error_mark_node)
+cond = build3 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
+  

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 03/06/2024 16:34, Dale wrote:

The way I did my last two rigs is this.  Find the fastest CPU.  Drop
down about 2 models.  That is not the fastest but very close to it but a
LOT cheaper.  Then buy a mobo and memory to go with it.  You get a
system that is likely close to 90% of the fastest you can get but a lot
cheaper.  Nowadays, even if you drop down a lot, it still costs a arm
and a leg and you get a lot less.


:-)

I look at tech as having two pricing models - the champagne model for 
the new stuff, where doubling performance doubles the price. And the 
coke model for older tech, where transport costs dominate, and different 
specs don't differ much in price. If I can get my tech at the "knee", 
where champagne prices become coke prices, I'm happy.


Cheers,
Wol

Looking for some pre-buying verification: will an external display actually work with a Lenovo Thinkpad P16 Gen 2?

[Lists]

Hi all,

I am thinking of replacing my old workstation with a Lenovo Thinkpad P16 
Gen 2. There's one thing that makes me hesitate though: on my current 
laptop (Thinkpad P1 Gen 1) the external display is hardwired to a 
specific port. Sadly, I have never been able to use any external display 
with that laptop. Not with the integrated graphics, nor with the 
discrete graphics.


I am hoping to prevent this from happening again, as in this case that 
would be a critical "failure". The idea is that this machine will run 
with the lid closed using a large external monitor.


In case that might be relevant: I am planning to buy the Universal 
Thunderbolt 4 Dock with this laptop.


Are there any users of this laptop here on the list that can tell me if 
this exact type of Thinkpad can actually drive external displays when 
running Debian? I can't find any definite information regarding this 
issue on the Lenovo website and Google didn't get me any further either.


Thanks in advance for any helpful information!

Grx HdV

Re: [gentoo-user] Re: Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 03/06/2024 12:07, MasterP wrote:

*NOTE*: Almost minutes after I wrote this, and before posting it, AMD
announced at Computex that the new gen will be available next month. So
maybe waiting for the new processors could be a good idea. Although at the
launch, both the new boards and cpus are probably going to be very
expensive. Still, most new mid-to-high end boards will now have USB4
ports.


My reaction - even if you buy the older version, this announcement will 
push down the "old tech" prices. Don't wait too long though, as a lot of 
stuff could be "end-of-lifed" and sold off cheap, rather than kept in 
production at a lower price point.


Cheers.
Wol

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 02/06/2024 14:27, Dale wrote:

Should I put
the portage work directory on a spinning rust drive to save wear and
tear on the SSD or have they got to the point now that doesn't matter
anymore?  I know all the SSD devices have improved a lot since the first
ones came out.


The stuff I've seen says that SSDs have now reached the point where 
their typical life expectancy *exceeds* spinning rust.


The problem is they are typically programmed to do apoptosis (destroy 
themselves when things go wrong), which means once a drive fails it is DEAD.


I've recovered several apparently-dead spinning rust drives (and made a 
few quid that way), but whereas I backed up, and then binned, the zombie 
drives it looks like an SSD won't give you the opportunity.


About the only thing spinning rust has in its favour nowadays is bang 
for buck - the cost per GB is noticeably cheaper. Even there, an SSD is 
likely to be cheaper to run, so "always on" swings the pendulum away 
from rust ...


Cheers,
Wol

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Wols Lists]

On 02/06/2024 06:38, Dale wrote:

My plan is the CPU above for now.  Later, I will upgrade to the Ryzen 9
7900X to get even more speed.  I'll also max the memory out too.  I'm
unclear on the max memory tho.  One place shows 128GB, hence two 32GB
sticks.


Go on the manufacturer's website, find the mobo, and download the manual 
from the support page.


The other thing is, if you know the chipset (it should say), see what 
other mobos with the same chipset can do.


Cheers,
Wol

Re: [OE-core] New to the group

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

faganronan via lists.openembedded.org schrieb am Do 23. Mai, 12:58 (GMT):
> I'm brand new to the group, apologies if this is not the right spot. I've
> been working a lot with SBOMs for embedded devices lately and been playing
> around with the recipes for spdx and cve with limited success. The SPDX on
> even a minimal image creates 500ish SPDX files and then it has to be with
> the CPE data. I've had some good success with CycloneDX. Anyone else
> running in to this?

Yes, I'm using CycloneDX with DependencyTrack, and wrote a converter of spdx
to CycloneDX. The script also handles the upload to DependencyTrack, which
is not that easy, because you have to wait for the end of the processing,
before going on.

A better approach would we a cyclonedx class, and I plan to create one, but
didn't found the time to do.

Here is the current version of the script:

```
#!/bin/sh

# There will never again be support for SPDX by DependencyTrack
# https://github.com/DependencyTrack/dependency-track/issues/1053

set -e -u -C

no_upload=false
recipe_filter=\*
skip_sbom=false
skip_vex=false

while test $# -gt 0
do
case "$1" in
--no-upload) no_upload=true;;
--skip-sbom) skip_sbom=true;;
--skip-vex) skip_vex=true;;
--recipe-filter)
shift
recipe_filter=${1:?Argument for --recipe-filter missing}
;;
*) break;;
esac

shift
done

if ! $no_upload && test -z "${DT_API_KEY:-}"
then
echo 'Environment variable DT_API_KEY not set' >&2
exit 1
fi

if test $# -ne 4
then
echo "Usage: $0 [OPTIONS] HOST_URL PROJECT_NAME SPDX_TAR_ZST 
PROJECT_VERSION" >&2
echo >&2
echo 'OPTIONS:' >&2
echo '--no-uploaddo not upload, but print to stdout' >&2
echo '--recipe-filter FILTER only process recipes matched by 
wildcard FILTER' >&2
echo '--skip-sbomdo not generate the SBOM' >&2
echo '--skip-vex do not generate the VEX' >&2
exit 1
fi

dt_host_url=$1
dt_project=$2
spdx_tar=$3
dt_version=$4

api_req() (
path=${1:?API path}
shift

if out=$(curl --no-progress-meter --fail-with-body -H "X-Api-Key: 
$DT_API_KEY" \
"$@" "$dt_host_url/api/v1$path")
then
printf '%s' "$out"
else
rc=$?
echo "curl $dt_host_url/api/v1$path failed with exit code $rc: $out" >&2
return $rc
fi
)

api_req_prj() {
api_req "$@" -F "projectName=$dt_project" -F "projectVersion=$dt_version"
}

spdx_to_cydx_sbom() {
# 
https://github.com/CycloneDX/specification/blob/1.5/schema/bom-1.5.schema.json
# https://docs.dependencytrack.org/usage/cicd/

tar -x -f "$spdx_tar" --to-stdout --wildcards 
recipe-"$recipe_filter".spdx.json | \
jq --slurp 'map(.packages) |flatten
|map(select(.name |startswith("packagegroup-") |not)) | {
bomFormat: "CycloneDX",
specVersion: "1.5",
serialNumber: "urn:uuid:'"$(uuidgen)"'",
version: 1,

metadata: {
timestamp: "'"$(date --iso-8601=seconds)"'",
component: {
name: "'"$dt_project"'",
version: "'"$dt_version"'",
type: "operating-system",
},
},

components: map({
type: "application",
name,
"bom-ref": .name,
supplier: { name: .supplier },
version: .versionInfo,
description,
licenses: [{
expression: .licenseDeclared,
}],
externalReferences: ([
{ type: "vcs", url: .downloadLocation },
{ type: "website", url: .homepage }
] |map(select(.url != null and .url != "NOASSERTION"))),
} + (
.externalRefs[0].referenceLocator
| if . != null then { cpe: . } else { } end
)),
}'
}

spdx_to_cydx_vex() {
# https://github.com/CycloneDX/bom-examples/blob/master/VEX/vex.json

tar -x -f "$spdx_tar" --to-stdout --wildcards 
recipe-"$recipe_filter".spdx.json | \
jq --slurp 'map(.packages) |flatten
|map(select(.name |startswith("packagegroup-") |not))
|map(select(.sourceInfo != null)) | {
bomFormat: "CycloneDX",
specVersion: "1.5",
serialNumber: "urn:uuid:'"$(uuidgen)"'",
version: 1,
metadata: {
timestamp: "'"$(date --iso-8601=seconds)"'",
component: {
name: "'"$dt_project"'",
version: "'"$dt_version"'",
type: "operating-system",
"bom-ref": "project",
},
},

vulnerabilities: map(. as { name: $name, versionInfo: $version }
| .sourceInfo |match("CVE-\\S+"; "g") | .string
| {
id: .,

Re: [gentoo-user] hardware disk description

[Wols Lists]

On 28/05/2024 20:51, Jude DaShiell wrote:

My machine has protected mbr with gpt partitions on it.  Are those kind of
partitions hybrid?



This is completely standard nowadays. I think the "protected MBR" just 
points to the first four GPT partitions.


This is basically down to the fact that (a) the MBR can no longer 
describe a modern large disk (I'm not sure what the limit is, 2TB? 
4TB?), and also older formatting tools - if they don't see an MBR - are 
known for assuming the disk is empty and trashing the start of it. Yeah 
they shouldn't, but they do ...


Cheers,
Wol

Re: How to transpose?

[Wols Lists]

On 25/05/2024 18:44, bobr...@centrum.is wrote:

Wol,

The bit about trombones in bass and Bb treble; I've only ever heard of 
Bb treble clef trombone in British brass band music.  What is the 
"American bass part" in Bb?  I've never heard of such a thing.  I know 
that Richard Strauß wrote tenor tuba parts in Bb bass clef.


I only remember me hitting it with one piece, but I got the vibes (on 
this list, iirc) that that this may be rare but certainly not unheard of.


This piece was printed with NO KEY SIGNATURE, and a bass clef part that 
had been transposed. Boy did it cause hell until we realised what was 
going on!!!


Cheers,
Wol

Re: How to transpose?

[Wols Lists]

On 23/05/2024 12:26, Kenneth Flak wrote:

Great, thanks to both of you! Very clarifying. \transposition is, thus,
going in the direction of instrument -> playback, whereas \transpose
goes in the opposite direction, if I understand it correctly.


I do a lot of brass stuff. And as you've realised, it's \transpose not 
\transposition.


I just think "\transpose for printed music, \transposition for midi". 
How accurate that is I don't know.


The other trick I always use (given that a trombone plays both bass clef 
in C, and treble clef in Bb, and worse when you get an American bass 
part in Bb ?!?!?!), is I transpose on input as well as output.


When copying a part IN to lilypond, I'll wrap it in "\transpose c c" or 
"\transpose bf c'" depending on whether it's a bass or treble part. So I 
know all my music fragments in lilypond are in C.


Then I'll wrap them the other way on output to put them in the correct 
printed pitch. That way I never have to transpose in my head to make 
sure things are correct.


Cheers,
Wol

Re: Q: Problems forwarding traffic using pf ...

[Why 42? The lists account.]

Hi Guys,

Thanks for the feedback, to address your points:

1> Possibly stupid question, but did you set the sysctl(s) to enable forwarding?

Yes I tried this pf rule change with version 4 forwarding
(net.inet.ip.forwarding) both enabled and disabled.

Either way the pf "pass out tagged" rule is never matched.

I didn't reboot after changing this setting. It's not clear to me if that
is necessary. For the version 6 variable (net.inet6.ip6.forwarding) "man
2 sysctl" states: 

"... changing this variable during operation may cause serious trouble.
 Hence, this variable should only be set at bootstrap time."

Whatever that might mean. Anyway, for the version 4 variable there no
similar remark.


2> And there is also mforwarding
3> And multicast=YES rc.conf.local

In this first simple proof/test I just tried to forward some UDP. So this
is not yet relevant. But I think you are both right, if I get as far as
doing multicasting, I'll probably need those.

Out of interest I grepped in /etc and it seems that setting multicast=YES
influences the netstart script. When multicast is not "YES" then the
route for 224.0.0.0/4 is deleted and re-added to the IP loopback address
with an option "reject".

Cheers,
Robb.

Q: Problems forwarding traffic using pf ...

[Why 42? The lists account.]

Hi All,

I need to quickly create a solution for forwarding multicast traffic
between two systems, so I though perhaps I could use pf to do just that
by writing some rules along the lines of:

1. pass in on iface A proto UDP ... tag mcast
2. pass out on iface B tagged mcast

And another pair of rules for the reverse direction B -> A.

(Obviously I'd add more options to filter specific addresses, etc.)

So I tried to do a quick test / proof of concept. Here is the pf.conf:
# cat pf.conf
set skip on lo0
set block-policy return
set debug warning

# Begin by blocking everything
block log all   # Begin by blocking everything
pass  in  log on em0proto udp from 192.168.178.166 tag UDP
pass  out log on ure0   tagged UDP
###match route dup-to ure0 tagged TAG_UP

# Allow all outbound
#pass out log modulate state

The two "pass" lines are the basis of the idea. This seems to be pretty
much identical to the tagging example "INTNET" in the pf.conf man page.

pfctl reports:
# pfctl -vvs rules | grep @
@0 block return log all
@1 pass in log on em0 inet proto udp from 192.168.178.166 to any tag UDP
@2 pass out log on ure0 all flags S/SA tagged UDP

I see that rule 1 is matched, but never rule 2. E.g.
...
May 23 10:32:06.602759 rule 0/(match) block in on em0: 192.168.178.179.5353 > 
224.0.0.251.5353: 46[|domain] (DF)
May 23 10:32:06.603963 rule 0/(match) block in on em0: 
fe80::4434:8bff:fecd:b116.5353 > ff02::fb.5353: 46[|domain] [flowlabel 0xbaff9]
May 23 10:32:09.700212 rule 0/(match) block in on em0: 192.168.178.254 > 
224.0.0.1: igmp query [len 12] (DF) [tos 0xc0] [ttl 1]
May 23 10:32:13.267374 rule 1/(match) pass in on em0: 192.168.178.166.56334 > 
192.168.178.11.54321: udp 7
May 23 10:32:20.592971 rule 0/(match) block in on em0: 192.168.178.179.5353 > 
224.0.0.251.5353: 16 [3q][|domain] (DF)
May 23 10:32:21.136275 rule 0/(match) block in on em0: 192.168.178.252.5353 > 
224.0.0.251.5353: 48084+[|domain]
May 23 10:32:21.137074 rule 0/(match) block in on em0: 192.168.178.252.5353 > 
224.0.0.251.5353: 0* [0q] 3/0/3[|domain]
...
May 23 10:32:48.588466 rule 1/(match) pass in on em0: 192.168.178.166.56335 > 
192.168.178.11.54321: udp 42
May 23 10:32:49.705282 rule 0/(match) block in on em0: 192.168.178.179.5353 > 
224.0.0.251.5353: 0[|domain] (DF)
May 23 10:32:49.705839 rule 0/(match) block in on em0: 
fe80::4434:8bff:fecd:b116.5353 > ff02::fb.5353: 0[|domain] [flowlabel 0xbaff9]
...

I must be missing something, but what?

Both interfaces are up and configured with IP addresses.
I'm running the current snapshot i.e. 7.5 GENERIC.MP#77 amd64.

Thanks in advance!

Cheers,
Robb.

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

[Richard Earnshaw (lists)]

On 22/05/2024 12:14, Torbjorn SVENSSON wrote:
> Hello Richard,
> 
> Thanks for the reply.
> 
> From my point of view, at least the -fshort-enums part should be on all 
> branches. Just to be clean, maybe it's easier to backport the entire patch?

Yes, that's a fair point.  I was only thinking about the broadening of the test 
to the other argument registers when I said that.

So, just to be clear, OK all.

R.

> 
> Unless you have an objection, I would like to go ahead and just backport it 
> to all branches.
> 
> Kind regards,
> Torbjörn
> 
> On 2024-05-22 12:55, Richard Earnshaw (lists) wrote:
>> On 06/05/2024 12:50, Torbjorn SVENSSON wrote:
>>> Hi,
>>>
>>> Forgot to mention when I sent the patch that I would like to commit it to 
>>> the following branches:
>>>
>>> - releases/gcc-11
>>> - releases/gcc-12
>>> - releases/gcc-13
>>> - releases/gcc-14
>>> - trunk
>>>
>>
>> Well you can [commit it to the release branches], but I'm not sure it's 
>> essential.  It seems pretty unlikely to me that this would regress on a 
>> release branch without having first regressed on trunk.
>>
>> R.
>>
>>> Kind regards,
>>> Torbjörn
>>>
>>> On 2024-05-02 12:50, 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.
>>>>
>>>> boolCharShortEnumSecureFunc 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. Add
>>>>    -fshort-enums.
>>>>  * gcc.target/arm/cmse/extend-return.c: Add -fshort-enums option.
>>>>
>>>> Signed-off-by: Torbjörn SVENSSON 
>>>> ---
>>>>    .../gcc.target/arm/cmse/extend-param.c    | 21 +++
>>>>    .../gcc.target/arm/cmse/extend-return.c   |  4 ++--
>>>>    2 files changed, 19 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c 
>>>> b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>>>> index 01fac786238..d01ef87e0be 100644
>>>> --- a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>>>> +++ b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>>>> @@ -1,5 +1,5 @@
>>>>    /* { dg-do compile } */
>>>> -/* { dg-options "-mcmse" } */
>>>> +/* { dg-options "-mcmse -fshort-enums" } */
>>>>    /* { dg-final { check-function-bodies "**" "" "" } } */
>>>>      #include 
>>>> @@ -78,7 +78,6 @@ __attribute__((cmse_nonsecure_entry)) char 
>>>> enumSecureFunc (enum offset index) {
>>>>  if (index >= ARRAY_SIZE)
>>>>    return 0;
>>>>  return array[index];
>>>> -
>>>>    }
>>>>      /*
>>>> @@ -88,9 +87,23 @@ __attribute__((cmse_nonsecure_entry)) char 
>>>> enumSecureFunc (enum offset index) {
>>>>    **    ...
>>>>    */
>>>>    __attribute__((cmse_nonsecure_entry)) char boolSecureFunc (bool index) {
>>>> -
>>>>  if (index >= ARRAY_SIZE)
>>>>    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];
>>>> +}
>>>> diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-return.c 
>>>> b/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
>>>> index cf731ed33df..081de0d699f 100644
>>>> --- a/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
>>>> +++ b/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
>>>> @@ -1,5 +1,5 @@
>>>>    /* { dg-do compile } */
>>>> -/* { dg-options "-mcmse" } */
>>>> +/* { dg-options "-mcmse -fshort-enums" } */
>>>>    /* { dg-final { check-function-bodies "**" "" "" } } */
>>>>      #include 
>>>> @@ -89,4 +89,4 @@ unsigned char __attribute__((noipa)) enumNonsecure0 
>>>> (ns_enum_foo_t * ns_foo_p)
>>>>    unsigned char boolNonsecure0 (ns_bool_foo_t * ns_foo_p)
>>>>    {
>>>>  return ns_foo_p ();
>>>> -}
>>>> \ No newline at end of file
>>>> +}
>>

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

[Richard Earnshaw (lists)]

On 06/05/2024 12:50, Torbjorn SVENSSON wrote:
> Hi,
> 
> Forgot to mention when I sent the patch that I would like to commit it to the 
> following branches:
> 
> - releases/gcc-11
> - releases/gcc-12
> - releases/gcc-13
> - releases/gcc-14
> - trunk
> 

Well you can [commit it to the release branches], but I'm not sure it's 
essential.  It seems pretty unlikely to me that this would regress on a release 
branch without having first regressed on trunk.

R.

> Kind regards,
> Torbjörn
> 
> On 2024-05-02 12:50, 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.
>>
>> boolCharShortEnumSecureFunc 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. Add
>>   -fshort-enums.
>> * gcc.target/arm/cmse/extend-return.c: Add -fshort-enums option.
>>
>> Signed-off-by: Torbjörn SVENSSON 
>> ---
>>   .../gcc.target/arm/cmse/extend-param.c    | 21 +++
>>   .../gcc.target/arm/cmse/extend-return.c   |  4 ++--
>>   2 files changed, 19 insertions(+), 6 deletions(-)
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c 
>> b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>> index 01fac786238..d01ef87e0be 100644
>> --- a/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>> +++ b/gcc/testsuite/gcc.target/arm/cmse/extend-param.c
>> @@ -1,5 +1,5 @@
>>   /* { dg-do compile } */
>> -/* { dg-options "-mcmse" } */
>> +/* { dg-options "-mcmse -fshort-enums" } */
>>   /* { dg-final { check-function-bodies "**" "" "" } } */
>>     #include 
>> @@ -78,7 +78,6 @@ __attribute__((cmse_nonsecure_entry)) char enumSecureFunc 
>> (enum offset index) {
>>     if (index >= ARRAY_SIZE)
>>   return 0;
>>     return array[index];
>> -
>>   }
>>     /*
>> @@ -88,9 +87,23 @@ __attribute__((cmse_nonsecure_entry)) char enumSecureFunc 
>> (enum offset index) {
>>   **    ...
>>   */
>>   __attribute__((cmse_nonsecure_entry)) char boolSecureFunc (bool index) {
>> -
>>     if (index >= ARRAY_SIZE)
>>   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];
>> +}
>> diff --git a/gcc/testsuite/gcc.target/arm/cmse/extend-return.c 
>> b/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
>> index cf731ed33df..081de0d699f 100644
>> --- a/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
>> +++ b/gcc/testsuite/gcc.target/arm/cmse/extend-return.c
>> @@ -1,5 +1,5 @@
>>   /* { dg-do compile } */
>> -/* { dg-options "-mcmse" } */
>> +/* { dg-options "-mcmse -fshort-enums" } */
>>   /* { dg-final { check-function-bodies "**" "" "" } } */
>>     #include 
>> @@ -89,4 +89,4 @@ unsigned char __attribute__((noipa)) enumNonsecure0 
>> (ns_enum_foo_t * ns_foo_p)
>>   unsigned char boolNonsecure0 (ns_bool_foo_t * ns_foo_p)
>>   {
>>     return ns_foo_p ();
>> -}
>> \ No newline at end of file
>> +}

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-