RE: Audio sink to "wire"
Thanks, I’ll try advices from this mail and thread. I am contributing to development of software for RP2040 to transmit WSPR and I need just the simple monitoring tool. So I designed simple flowgraph in GNU radio, which just receives given frequency using SDR, filters it by narrow band LP filter and sends the tone (approximately 1500 +-4 Hz) to Audio sink. Nothing complicated. I run it on the notebook which plays the tone from speakers and microphone on the same notebook is listening to it and is sending the digitized sound to WSJT-X. It work as intended. I just wanted to get the signal from the audio output of the GNU radio to the audio input of the WSJT-X a little better way than "scratching with my left hand behind my right ear" So no communication with transceiver, no WSPR transmission (my RP2040 is the monitored transmitter). Jakub Šerých From: Marcus Müller Sent: Thursday, June 6, 2024 2:38 PM To: Kevin McQuiggin ; discuss >> GNURadio Discussion List ; dave_a...@bigpond.com; Šerých Jakub Subject: Re: Audio sink to "wire" Hi everyone, trying to get the discussion back under one email thread (hint: it's easier to deal with the mailing list if you *don't* get the digest but each email individually, and set up your email client or -service to file emails from the mailing list into their own folder). So, Dave pointed out: Under Linux, a simple approach is to use a loopback (essentially establish a Virtual Audio Cable). The loopback is established by sudo modprobe snd_aloop enable=1,1 index=10,11 The WJST-X audio input is then plughw:CARD=Loopback_1,DEV=1 and the GNU Radio audio sink device can be left as default. right! That works with every sound system. However, if the intent is to use WSJT-X, there is some extra complexity. WSJT-X assumes it is communicating with a transceiver (a rig) and will look to check that the rig is configured consistently with what WSJT-X expects. So you need another program that emulates a chosen type of transceiver (eg a Kenwood TS-2000) and responds to those WSJT-X checks. Switching between Tx and Rx requires some similar complexity. Indeed, and that's why Henning Paul has his own CAT/hamlib proxy for interfacing with WSJT-X to emulate his own hardware frontend, see [1] slide 22. Luckily, I don't think you'll have to go that far, usually. Depends, really, on what you want to control from WSJT-X; you'd choose CAT as transceiver/rig type, probably. However, I'm not deeply into these ham radio applications. If there's demand to talk about ham affairs like plugging WSJT-X to GNU Radio (and maybe ask whether someone can talk about their experiences doing something specific), I do recommend heading over to our Matrix chat room for GNU Radio in amateur radio, #HamRadio:gnuradio.org you can easily access that, if you've never used Matrix before, using, for example, [2]. Note that there's a lot of knowledge out there – and a lot of implementations that not everyone knows about. For example, I think someone has implemented FT-8 in GNU Radio (can't find the link right now). And: there's a series of talk recordings, organized by Barry Duggan himself, which I find worth watching [3]. Best, Marcus [1] https://github.com/hennichodernich/talks/blob/main/SDR_Selbstbau.pdf [2] https://app.element.io/#/room/#HamRadio:gnuradio.org (account necessary for writing messages, you can sign up for free there, or anywhere else on the matrix network; do join [2a] while you're there) [2a] https://app.element.io/#/room/#gnuradio-space:gnuradio.org [3] https://wiki.gnuradio.org/index.php/Talk:HamRadio On 05.06.24 23:21, Kevin McQuiggin wrote: Hi Jakub and Marcus: On the Mac, use the BlackHole virtual audio driver. It’s at https://github.com/ExistentialAudio/BlackHole. You can create a virtual audio device and point WSJT-X at it for input, output, or both. It works well and the developer is responsive to questions and suggestions. Kevin On Jun 5, 2024, at 1:12 PM, Marcus Müller <mailto:marcus.muel...@ettus.com> wrote: Uff, please don't recommend such stunts :) This can be solved easily in software at zero cost. If you're on a modern Linux, you use the pipewire audio system. Install `qpwgraph`, start WSJT-X and just use qwpgraph to connect the output of your GNU Radio flow graph to the input of your WSJT-X. (or vice versa, really!) If you're using an older Linux distribution, you might still be using pulseaudio. No problem, you just 1. create a "black hole" audio sink, then 2. form a virtual microphone input from that: 1. pactl load-module module-null-sink sink_name=cable_out sink_properties=device.description=cable_out 2. pactl load-module module-remap-source master=cable_out.monitor source_name=cable_in source_properties=device.description=cable_in You'd then use `cable_out` as device name in your GNU Radio Audio sink. That's it. On Windows, I'm no expert, but there's many lo
Re: Service monitoring in CommuniShift/OpenShift?
Thank you very much for the reply Kevin, > Another option there is to make some kind of health check, and have > openshift monitor it and alert/take the app down if something was > unhealthy. I have limited experience with OpenShift so I am not sure what is possible or not but I've been reading about health checks and the documentation always mentioned restarting the "unhealthy" container instead of sending an email notification. That wouldn't be helpful for me. > There's currently no monitoring setup for communishift items. > Once it's moved to staging / production, nagios checks can be added. > Also, in our stg/prod clusters we have some simple monitoring like > mailing you when a pod crashes or a build or cronjob fails. Seems like the right course of action would be migrating to the production OpenShift instance. My questions regarding the migration process were answered in https://pagure.io/fedora-infrastructure/issue/11814 so I will just have to prioritize that. Then I will get back to you in regards to the Nagios configuration. Thank you again, Jakub On Sun, Jun 2, 2024 at 7:35 PM Kevin Fenzi wrote: > On Sat, Jun 01, 2024 at 08:48:32PM GMT, Jakub Kadlcik wrote: > > I am running a service in Fedora CommuniShift (planning to move it to > > Fedora production OpenShift instance in case it is relevant). > > > > Can anybody please help me understand how to configure some monitoring > for > > it? Is it possible to configure nagios.fedoraproject.org for it? Or is > > there any other recommended approach? > > There's currently no monitoring setup for communishift items. > Once it's moved to staging / production, nagios checks can be added. > > Also, in our stg/prod clusters we have some simple monitoring like > mailing you when a pod crashes or a build or cronjob fails. > > > Basically, I would like to have some custom commands (checking if auth > > tokens are up-to-date, parsing a log file for specific errors, etc) and > > periodically run them on my deployed container. Or spawning a separate > > container in my project to run them. If they find any problem, I'd like > to > > be notified via email. > > Another option there is to make some kind of health check, and have > openshift monitor it and alert/take the app down if something was > unhealthy. I guess that might not be what you want for transitory errors > or where you don't want the app to stop working on some errors. > > kevin > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 58368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58368=edit gcc15-pr115352.patch Full so far just lightly tested patch.
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352
--- Comment #2 from Jakub Jelinek ---
I've first tried
--- gcc/gimple-lower-bitint.cc.jj 2024-04-12 10:59:48.233153262 +0200
+++ gcc/gimple-lower-bitint.cc 2024-06-06 11:05:29.845597763 +0200
@@ -4324,7 +4324,8 @@ bitint_large_huge::lower_addsub_overflow
else
g = gimple_build_assign (this_ovf, NE_EXPR, l, cmp);
insert_before (g);
- if (cmp_code == GT_EXPR)
+ if (cmp_code == GT_EXPR
+ || (cmp_code == GE_EXPR && single_comparison))
{
tree t = make_ssa_name (boolean_type_node);
g = gimple_build_assign (t, BIT_IOR_EXPR, ovf, this_ovf);
which fixes the #c0 testcase. But on the reduced
int
foo (_BitInt (385) b)
{
return __builtin_sub_overflow_p (0, b, (_BitInt (65)) 0);
}
int
main ()
{
if (!foo (-(_BitInt (385))
0x0c377e8a3fd1881fff035bb487a51c9ed1f7350befa7ec445a3cf8d1ebb723981wb))
__builtin_abort ();
if (!foo
(-0x1c377e8a3fd1881fff035bb487a51c9ed1f7350befa7ec445a3cf8d1ebb723981uwb))
__builtin_abort ();
if (!foo (-(_BitInt (385))
0x0a3cf8d1ebb723981wb))
__builtin_abort ();
if (!foo
(-0x1a3cf8d1ebb723981uwb))
__builtin_abort ();
}
testcase it only fixes the first 2 calls but not the last 2.
So, I'm afraid I just need to kill the optimization instead:
--- gcc/gimple-lower-bitint.cc.jj 2024-04-12 10:59:48.233153262 +0200
+++ gcc/gimple-lower-bitint.cc 2024-06-06 12:06:57.065717651 +0200
@@ -4286,11 +4286,7 @@ bitint_large_huge::lower_addsub_overflow
bool single_comparison
= (startlimb + 2 >= fin || (startlimb & 1) != (i & 1));
if (!single_comparison)
- {
- cmp_code = GE_EXPR;
- if (!check_zero && (start % limb_prec) == 0)
- single_comparison = true;
- }
+ cmp_code = GE_EXPR;
else if ((startlimb & 1) == (i & 1))
cmp_code = EQ_EXPR;
else
The idea behind the optimization was that arith_overflow_extract_bits in those
cases is the same, we just extract all bits from the limb, whether it is the
limb at the boundary (i.e. EQ_EXPR to the compared limb index) or above
(GT_EXPR), so GE_EXPR would do. Except without the first patch it completely
ignored the previously accumulated mismatches (i.e. overflows) from lower
limbs, and while that no longer is the case with the first patch, it still
ignores whether the upper bits were all 0s or all 1s previously and as long as
they are again all 0s or all 1s, it happily makes it non-overflow case and what
the next limb should compare against.
[committed] libgomp: Mark Loop transformation constructs as implemented in the implementation status
Hi!
The implementation has been committed in r15-1037.
2024-06-06 Jakub Jelinek
* libgomp.texi (OpenMP 5.1 status): Mark Loop transformation constructs
as implemented.
--- libgomp/libgomp.texi
+++ libgomp/libgomp.texi
@@ -302,7 +302,7 @@ The OpenMP 4.5 specification is fully supported.
@item @code{error} directive @tab Y @tab
@item @code{masked} construct @tab Y @tab
@item @code{scope} directive @tab Y @tab
-@item Loop transformation constructs @tab N @tab
+@item Loop transformation constructs @tab Y @tab
@item @code{strict} modifier in the @code{grainsize} and @code{num_tasks}
clauses of the @code{taskloop} construct @tab Y @tab
@item @code{align} clause in @code{allocate} directive @tab P
Jakub
[gcc r15-1052] libgomp: Mark Loop transformation constructs as implemented in the implementation status
https://gcc.gnu.org/g:6a6bab4ba36c5d190b3151055e683e7067be92c1
commit r15-1052-g6a6bab4ba36c5d190b3151055e683e7067be92c1
Author: Jakub Jelinek
Date: Thu Jun 6 08:30:42 2024 +0200
libgomp: Mark Loop transformation constructs as implemented in the
implementation status
The implementation has been committed in r15-1037.
2024-06-06 Jakub Jelinek
* libgomp.texi (OpenMP 5.1 status): Mark Loop transformation
constructs
as implemented.
Diff:
---
libgomp/libgomp.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index d612488ad10..c52bb2672c6 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -302,7 +302,7 @@ The OpenMP 4.5 specification is fully supported.
@item @code{error} directive @tab Y @tab
@item @code{masked} construct @tab Y @tab
@item @code{scope} directive @tab Y @tab
-@item Loop transformation constructs @tab N @tab
+@item Loop transformation constructs @tab Y @tab
@item @code{strict} modifier in the @code{grainsize} and @code{num_tasks}
clauses of the @code{taskloop} construct @tab Y @tab
@item @code{align} clause in @code{allocate} directive @tab P
[Bug libgomp/115367] The implementation of OMP_DYNAMIC is not dynamic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115367 --- Comment #1 from Jakub Jelinek --- (In reply to Niklas Hambüchen from comment #0) > Those docs sound like the behaviour is nice "runtime-dynamic" when in fact > it is fixed across the process's liftime, and based on ultra-slow rolling > averages. That is not the case. It really calls getloadavg each time when trying to determine the number of threads and uses the 15min average then. Using say 1min average is IMHO highly undesirable for decisions in a program that usually will last longer than that.
Re: [PATCH net-next] selftests: hsr: Extend the hsr_redbox.sh test to use fixed MAC addresses
On Mon, 3 Jun 2024 11:33:22 +0200 Lukasz Majewski wrote: > Fixed MAC addresses help with debugging as last four bytes identify the > network namespace. > > Moreover, it allows to mimic the real life setup with for example bridge > having the same MAC address on each port. Doesn't seem like a particularly scalable method of making tests more debugable but alright...
Re: [Intel-wired-lan] [PATCH iwl-next v1 0/5] ice: add standard stats
On Tue, 4 Jun 2024 15:13:20 -0700 Jesse Brandeburg wrote: > The main point of this series is to implement the standard stats for the > ice driver, but also add a related documentation fix and finish the > series off with a cleanup that removes a bunch of code. With the nit on patch 1 fixed: Reviewed-by: Jakub Kicinski queue stats next? :]
Re: [Intel-wired-lan] [PATCH iwl-next v1 1/5] net: docs: add missing features that can have stats
On Tue, 4 Jun 2024 15:13:21 -0700 Jesse Brandeburg wrote: > - - `ETHTOOL_MSG_PAUSE_GET` >- `ETHTOOL_MSG_FEC_GET` > + - 'ETHTOOL_MSG_LINKSTATE_GET' >- `ETHTOOL_MSG_MM_GET` > + - `ETHTOOL_MSG_PAUSE_GET` > + - 'ETHTOOL_MSG_TSINFO_GET' I was going to steal this directly but: ` vs ' so I'll let it go via the Intel tree :)
Bug#1071939: taskwarrior: Naming conflict with go-task task tool
Control: forwarded -1 https://github.com/GothenburgBitFactory/taskwarrior/issues/3463 FWIW, go-task is not in Debian, but it's been ITP-ed: #1032658 -- Jakub Wilk
Bug#1032658: ITP: go-task -- A task runner / simpler Make alternative written in Go
* Mark E. Fuller , 2023-03-10 17:30: * URL : https://github.com/go-task/task The executable name is "task", but this name is already taken by taskwarrior; see bug #1071939. -- Jakub Wilk
Bug#1032658: ITP: go-task -- A task runner / simpler Make alternative written in Go
* Mark E. Fuller , 2023-03-10 17:30: * URL : https://github.com/go-task/task The executable name is "task", but this name is already taken by taskwarrior; see bug #1071939. -- Jakub Wilk
Re: [PATCH] c++: Handle erroneous DECL_LOCAL_DECL_ALIAS in duplicate_decls [PR107575]
On Wed, Jun 05, 2024 at 08:13:14AM +, Simon Martin wrote:
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl, bool
> hiding, bool was_hidden)
> retrofit_lang_decl (newdecl);
> tree alias = DECL_LOCAL_DECL_ALIAS (newdecl)
> = DECL_LOCAL_DECL_ALIAS (olddecl);
> - DECL_ATTRIBUTES (alias)
> - = (*targetm.merge_decl_attributes) (alias, newdecl);
> - if (TREE_CODE (newdecl) == FUNCTION_DECL)
> - merge_attribute_bits (newdecl, alias);
> + if (alias != error_mark_node)
> + {
> + DECL_ATTRIBUTES (alias) =
> + (*targetm.merge_decl_attributes) (alias, newdecl);
Formatting nit, = should be on the next line, not at the end of a line.
See https://gcc.gnu.org/codingconventions.html and
https://gcc.gnu.org/codingconventions.html
Jakub
Re: How to avoid some built-in expansions in gcc?
On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> (Well, and without reverse-recognition of isfinite-like idioms in the
> sources. That's orthogonal as well.)
Why? If isfinite is better done by a libcall, why isn't isfinite-like
idiom also better done as a libcall?
Jakub
[Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345 --- Comment #8 from Jakub Jelinek --- Also, if building with GCC 11 works and with GCC 12 doesn't, can you build two trees, one with either compiler and then bisect first among the shared libraries or binaries (find out which shared library or binary is affected), among the static libraries (GCC 11 and 12 ought to be ABI compatible, so try linking some *.a libraries from one build and other from another build, among the object files (start with linking half of the objects built by one compiler and another half by another compiler and depending on if it works as expected or not change the set of objects to link). If you get to one object file which when compiled with GCC 11 works even when everything else has been compiled with GCC 12 or vice versa, you can then try different options on that one (e.g. the -fno-strict-aliasing Andrew mentioned, -O0 etc.), and/or bisect inside of the source using #pragma GCC optimize(0) etc. Anyway, if there is a single translation unit like that and ideally if you find out which function is problematic, trying to stub functions it calls and add a caller which calls that single function with the right arguments turns it into a self-contained reproducer.
[Bug c/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-06-04 Summary|[12/13/14 REGRESSION] / |[12/13/14/15 Regression] |Different outputs compared |Different outputs compared |to GCC 11- and MSVC/Clang |to GCC 11- and MSVC/Clang Status|UNCONFIRMED |WAITING CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Please see https://gcc.gnu.org/bugs/ for what we need, we need a self-contained preprocessed testcase, which you haven't provided. You should start by compiling the code with -fsanitize=undefined and/or -fsanitize=address, see if it reports anything, if not, create a minimal self-contained reproducer.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #12 from Jakub Jelinek --- Should be fixed now. I think we want to backport the fold-const.cc first patch to older branches too, but it will be different there.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- .
[Bug target/115324] [12/13 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13 Regression] PCH of |PCH of rs6000 builtins |rs6000 builtins broken |broken | --- Comment #5 from Jakub Jelinek --- Should be fixed for 14.2+/15.1+ for now.
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 Bug 115092 depends on bug 114902, which changed state. Bug 114902 Summary: [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/114902] [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Jakub Jelinek --- Fixed.
[gcc r14-10280] fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]
https://gcc.gnu.org/g:a88e13bd7e0f50011e7f7f6e05c6f5e2a031143c
commit r14-10280-ga88e13bd7e0f50011e7f7f6e05c6f5e2a031143c
Author: Jakub Jelinek
Date: Tue Jun 4 15:49:41 2024 +0200
fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]
The function currently incorrectly assumes all the __builtin_clz* and .CLZ
calls have non-negative result. That is the case of the former which is UB
on zero and has [0, prec-1] return value otherwise, and is the case of the
single argument .CLZ as well (again, UB on zero), but for two argument
.CLZ is the case only if the second argument is also nonnegative (or if we
know the argument can't be zero, but let's do that just in the ranger IMHO).
The following patch does that.
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* fold-const.cc (tree_call_nonnegative_warnv_p) :
If arg1 is non-NULL, RECURSE on it, otherwise return true.
* gcc.dg/bitint-106.c: New test.
(cherry picked from commit b82a816000791e7a286c7836b3a473ec0e2a577b)
Diff:
---
gcc/fold-const.cc | 6 +-
gcc/testsuite/gcc.dg/bitint-106.c | 29 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 7b268964acc..f496b3436df 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15241,7 +15241,6 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn
fn, tree arg0, tree arg1,
CASE_CFN_FFS:
CASE_CFN_PARITY:
CASE_CFN_POPCOUNT:
-CASE_CFN_CLZ:
CASE_CFN_CLRSB:
case CFN_BUILT_IN_BSWAP16:
case CFN_BUILT_IN_BSWAP32:
@@ -15250,6 +15249,11 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn
fn, tree arg0, tree arg1,
/* Always true. */
return true;
+CASE_CFN_CLZ:
+ if (arg1)
+ return RECURSE (arg1);
+ return true;
+
CASE_CFN_SQRT:
CASE_CFN_SQRT_FN:
/* sqrt(-0.0) is -0.0. */
diff --git a/gcc/testsuite/gcc.dg/bitint-106.c
b/gcc/testsuite/gcc.dg/bitint-106.c
new file mode 100644
index 000..a36e8836690
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/bitint-106.c
@@ -0,0 +1,29 @@
+/* PR tree-optimization/115337 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-O2" } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+#define N 128
+#else
+#define N 63
+#endif
+
+_BitInt (N) g;
+int c;
+
+void
+foo (unsigned _BitInt (N + 1) z, _BitInt (N) *ret)
+{
+ c = __builtin_stdc_first_leading_one (z << N);
+ _BitInt (N) y = *(_BitInt (N) *) __builtin_memset (, c, 5);
+ *ret = y;
+}
+
+int
+main ()
+{
+ _BitInt (N) x;
+ foo (0, );
+ if (c || g || x)
+__builtin_abort ();
+}
[gcc r14-10278] invoke.texi: Clarify -march=lujiazui
https://gcc.gnu.org/g:1c1bc2553f6cb6d104f1f1b749aac0f39c4a3959
commit r14-10278-g1c1bc2553f6cb6d104f1f1b749aac0f39c4a3959
Author: Jakub Jelinek
Date: Tue Jun 4 12:20:13 2024 +0200
invoke.texi: Clarify -march=lujiazui
I was recently searching which exact CPUs are affected by the PR114576
wrong-code issue and went from the PTA_* bitmasks in GCC, so arrived
at the goldmont, goldmont-plus, tremont and lujiazui CPUs (as -march=
cases which do enable -maes and don't enable -mavx).
But when double-checking that against the invoke.texi documentation,
that was true for the first 3, but lujiazui said it supported AVX.
I was really confused by that, until I found the
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604407.html
explanation. So, seems the CPUs do have AVX and F16C but -march=lujiazui
doesn't enable those and even activelly attempts to filter those out from
the announced CPUID features, in glibc as well as e.g. in libgcc.
Thus, I think we should document what actually happens, otherwise
users could assume that
gcc -march=lujiazui predefines __AVX__ and __F16C__, which it doesn't.
2024-06-04 Jakub Jelinek
* doc/invoke.texi (lujiazui): Clarify that while the CPUs do support
AVX and F16C, -march=lujiazui actually doesn't enable those.
(cherry picked from commit 09b4ab53155ea16e1fb12c2afcd9b6fe29a31c74)
Diff:
---
gcc/doc/invoke.texi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9456ced468a..a916d618960 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -34732,8 +34732,10 @@ instruction set support.
@item lujiazui
ZHAOXIN lujiazui CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
-SSE4.2, AVX, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
-ABM, BMI, BMI2, F16C, FXSR, RDSEED instruction set support.
+SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
+ABM, BMI, BMI2, FXSR, RDSEED instruction set support. While the CPUs
+do support AVX and F16C, these aren't enabled by @code{-march=lujiazui}
+for performance reasons.
@item yongfeng
ZHAOXIN yongfeng CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
[gcc r14-10279] builtins: Force SAVE_EXPR for __builtin_{add, sub, mul}_overflow and __builtin{add, sub}c [PR108789]
https://gcc.gnu.org/g:f9af4a05e027a8b797628f1a2c39ef0b28dc36d9
commit r14-10279-gf9af4a05e027a8b797628f1a2c39ef0b28dc36d9
Author: Jakub Jelinek
Date: Tue Jun 4 12:28:01 2024 +0200
builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow and
__builtin{add,sub}c [PR108789]
The following testcase is miscompiled, because we use save_expr
on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first
two operands are not INTEGER_CSTs (in that case we just fold it right away)
but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually
create a SAVE_EXPR at all and so we lower it to
*arg2 = REALPART_EXPR (.ADD_OVERFLOW (arg0, arg1)), \
IMAGPART_EXPR (.ADD_OVERFLOW (arg0, arg1))
which evaluates the ifn twice and just hope it will be CSEd back.
As *arg2 aliases *arg0, that is not the case.
The builtins are really never const/pure as they store into what
the third arguments points to, so after handling the INTEGER_CST+INTEGER_CST
case, I think we should just always use SAVE_EXPR. Just building SAVE_EXPR
by hand and setting TREE_SIDE_EFFECTS on it doesn't work, because
c_fully_fold optimizes it away again, so the following patch marks the
ifn calls as TREE_SIDE_EFFECTS (but doesn't do it for the
__builtin_{add,sub,mul}_overflow_p case which were designed for use
especially in constant expressions and don't really evaluate the
realpart side, so we don't really need a SAVE_EXPR in that case).
2024-06-04 Jakub Jelinek
PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr.
(fold_builtin_addc_subc): Set TREE_SIDE_EFFECTS on call before
calling save_expr.
* gcc.c-torture/execute/pr108789.c: New test.
(cherry picked from commit b8e28381cb5c0cddfe5201faf799d8b27f5d7d6c)
Diff:
---
gcc/builtins.cc| 22 ++-
gcc/testsuite/gcc.c-torture/execute/pr108789.c | 39 ++
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index f8d94c4b435..7c1497561f7 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -10042,7 +10042,21 @@ fold_builtin_arith_overflow (location_t loc, enum
built_in_function fcode,
tree ctype = build_complex_type (type);
tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
arg0, arg1);
- tree tgt = save_expr (call);
+ tree tgt;
+ if (ovf_only)
+ {
+ tgt = call;
+ intres = NULL_TREE;
+ }
+ else
+ {
+ /* Force SAVE_EXPR even for calls which satisfy tree_invariant_p_1,
+as while the call itself is const, the REALPART_EXPR store is
+certainly not. And in any case, we want just one call,
+not multiple and trying to CSE them later. */
+ TREE_SIDE_EFFECTS (call) = 1;
+ tgt = save_expr (call);
+ }
intres = build1_loc (loc, REALPART_EXPR, type, tgt);
ovfres = build1_loc (loc, IMAGPART_EXPR, type, tgt);
ovfres = fold_convert_loc (loc, boolean_type_node, ovfres);
@@ -10354,11 +10368,17 @@ fold_builtin_addc_subc (location_t loc, enum
built_in_function fcode,
tree ctype = build_complex_type (type);
tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
args[0], args[1]);
+ /* Force SAVE_EXPR even for calls which satisfy tree_invariant_p_1,
+ as while the call itself is const, the REALPART_EXPR store is
+ certainly not. And in any case, we want just one call,
+ not multiple and trying to CSE them later. */
+ TREE_SIDE_EFFECTS (call) = 1;
tree tgt = save_expr (call);
tree intres = build1_loc (loc, REALPART_EXPR, type, tgt);
tree ovfres = build1_loc (loc, IMAGPART_EXPR, type, tgt);
call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
intres, args[2]);
+ TREE_SIDE_EFFECTS (call) = 1;
tgt = save_expr (call);
intres = build1_loc (loc, REALPART_EXPR, type, tgt);
tree ovfres2 = build1_loc (loc, IMAGPART_EXPR, type, tgt);
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr108789.c
b/gcc/testsuite/gcc.c-torture/execute/pr108789.c
new file mode 100644
index 000..32ee19be1c4
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr108789.c
@@ -0,0 +1,39 @@
+/* PR middle-end/108789 */
+
+int
+add (unsigned *r, const unsigned *a, const unsigned *b)
+{
+ return __builtin_add_overflow (*a, *b, r);
+}
+
+int
+mul (unsigned *r, const unsigned *a, const unsigned *b)
+{
+ return __builtin_mul_overflow (*a, *b, r);
+}
+
+int
+main ()
+{
+ unsigned x;
+
+ /* 1073741824U + 1073741824U should not overflow. */
+ x
[gcc r14-10277] rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
https://gcc.gnu.org/g:a7dd44c02ec1047166b4bacc3faa6255c816da2a
commit r14-10277-ga7dd44c02ec1047166b4bacc3faa6255c816da2a
Author: Jakub Jelinek
Date: Mon Jun 3 23:11:06 2024 +0200
rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or _instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them back
in full. While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.
So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.
Size-wise in .data sections it is (in bytes):
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.
Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.
When I applied
void
rs6000_init_generated_builtins ()
{
+ bifdata *rs6000_builtin_info_p;
+ tree *rs6000_builtin_info_fntype_p;
+ ovlddata *rs6000_instance_info_p;
+ tree *rs6000_instance_info_fntype_p;
+ ovldrecord *rs6000_overload_info_p;
+ __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+ __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+ __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+ __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+ __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+ #define rs6000_builtin_info rs6000_builtin_info_p
+ #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+ #define rs6000_instance_info rs6000_instance_info_p
+ #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+ #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
2024-06-03 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members. Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *. Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_in
[gcc r14-10276] combine: Fix up simplify_compare_const [PR115092]
https://gcc.gnu.org/g:14a7296d04474055bfe1d7f130dceac6dabf390d
commit r14-10276-g14a7296d04474055bfe1d7f130dceac6dabf390d
Author: Jakub Jelinek
Date: Wed May 15 18:37:17 2024 +0200
combine: Fix up simplify_compare_const [PR115092]
The following testcases are miscompiled (with tons of GIMPLE
optimization disabled) because combine sees GE comparison of
1-bit sign_extract (i.e. something with [-1, 0] value range)
with (const_int -1) (which is always true) and optimizes it into
NE comparison of 1-bit zero_extract ([0, 1] value range) against
(const_int 0).
The reason is that simplify_compare_const first (correctly)
simplifies the comparison to
GE (ashift:SI something (const_int 31)) (const_int -2147483648)
and then an optimization for when the second operand is power of 2
triggers. That optimization is fine for power of 2s which aren't
the signed minimum of the mode, or if it is NE, EQ, GEU or LTU
against the signed minimum of the mode, but for GE or LT optimizing
it into NE (or EQ) against const0_rtx is wrong, those cases
are always true or always false (but the function doesn't have
a standardized way to tell callers the comparison is now unconditional).
The following patch just disables the optimization in that case.
2024-05-15 Jakub Jelinek
PR rtl-optimization/114902
PR rtl-optimization/115092
* combine.cc (simplify_compare_const): Don't optimize
GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or
EQ op0 const0_rtx.
* gcc.dg/pr114902.c: New test.
* gcc.dg/pr115092.c: New test.
(cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)
Diff:
---
gcc/combine.cc | 6 --
gcc/testsuite/gcc.dg/pr114902.c | 23 +++
gcc/testsuite/gcc.dg/pr115092.c | 16
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 92b8d98e6c1..60afe043578 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -11841,8 +11841,10 @@ simplify_compare_const (enum rtx_code code,
machine_mode mode,
`and'ed with that bit), we can replace this with a comparison
with zero. */
if (const_op
- && (code == EQ || code == NE || code == GE || code == GEU
- || code == LT || code == LTU)
+ && (code == EQ || code == NE || code == GEU || code == LTU
+ /* This optimization is incorrect for signed >= INT_MIN or
+< INT_MIN, those are always true or always false. */
+ || ((code == GE || code == LT) && const_op > 0))
&& is_a (mode, _mode)
&& GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT
&& pow2p_hwi (const_op & GET_MODE_MASK (int_mode))
diff --git a/gcc/testsuite/gcc.dg/pr114902.c b/gcc/testsuite/gcc.dg/pr114902.c
new file mode 100644
index 000..60684faa25d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114902.c
@@ -0,0 +1,23 @@
+/* PR rtl-optimization/114902 */
+/* { dg-do run } */
+/* { dg-options "-O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp
-fno-tree-dominator-opts" } */
+
+__attribute__((noipa))
+int foo (int x)
+{
+ int a = ~x;
+ int t = a & 1;
+ int e = -t;
+ int b = e >= -1;
+ if (b)
+return 0;
+ __builtin_trap ();
+}
+
+int
+main ()
+{
+ foo (-1);
+ foo (0);
+ foo (1);
+}
diff --git a/gcc/testsuite/gcc.dg/pr115092.c b/gcc/testsuite/gcc.dg/pr115092.c
new file mode 100644
index 000..c9047f4d321
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr115092.c
@@ -0,0 +1,16 @@
+/* PR rtl-optimization/115092 */
+/* { dg-do run } */
+/* { dg-options "-O1 -fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre
-fno-guess-branch-probability" } */
+
+int a, b, c = 1, d, e;
+
+int
+main ()
+{
+ int f, g = a;
+ b = -2;
+ f = -(1 >> ((c && b) & ~a));
+ if (f <= b)
+d = g / e;
+ return 0;
+}
[gcc r15-1014] ranger: Improve CLZ fold_range [PR115337]
https://gcc.gnu.org/g:591d30c5c97e757f63ce0d99ae9a3dbe8c75a50a
commit r15-1014-g591d30c5c97e757f63ce0d99ae9a3dbe8c75a50a
Author: Jakub Jelinek
Date: Tue Jun 4 16:16:49 2024 +0200
ranger: Improve CLZ fold_range [PR115337]
cfn_ctz::fold_range includes special cases for the case where .CTZ has
two arguments and so is well defined at zero, and the second argument is
equal to prec or -1, but cfn_clz::fold_range does that only for the prec
case. -1 is fairly common as well though, because the builtins
do use it now, so I think it is worth special casing that.
If we don't know anything about the argument, the difference for
.CLZ (arg, -1) is that previously the result was varying, now it will be
[-1, prec-1]. If we knew arg can't be zero, it used to be optimized before
as well into e.g. [0, prec-1] or similar.
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* gimple-range-op.cc (cfn_clz::fold_range): For
m_gimple_call_internal_p handle as a special case also second
argument
of -1 next to prec.
Diff:
---
gcc/gimple-range-op.cc | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index aec3f39ec0e..1b9a84708b9 100644
--- a/gcc/gimple-range-op.cc
+++ b/gcc/gimple-range-op.cc
@@ -941,8 +941,10 @@ cfn_clz::fold_range (irange , tree type, const irange
,
int maxi = prec - 1;
if (m_gimple_call_internal_p)
{
- // Only handle the single common value.
- if (rh.lower_bound () == prec)
+ // Handle only the two common values.
+ if (rh.lower_bound () == -1)
+ mini = -1;
+ else if (rh.lower_bound () == prec)
maxi = prec;
else
// Magic value to give up, unless we can prove arg is non-zero.
@@ -953,7 +955,7 @@ cfn_clz::fold_range (irange , tree type, const irange ,
if (wi::gt_p (lh.lower_bound (), 0, TYPE_SIGN (lh.type (
{
maxi = prec - 1 - wi::floor_log2 (lh.lower_bound ());
- if (mini == -2)
+ if (mini < 0)
mini = 0;
}
else if (!range_includes_zero_p (lh))
@@ -969,11 +971,11 @@ cfn_clz::fold_range (irange , tree type, const irange
,
if (max == 0)
{
// If CLZ_DEFINED_VALUE_AT_ZERO is 2 with VALUE of prec,
- // return [prec, prec], otherwise ignore the range.
- if (maxi == prec)
- mini = prec;
+ // return [prec, prec] or [-1, -1], otherwise ignore the range.
+ if (maxi == prec || mini == -1)
+ mini = maxi;
}
- else
+ else if (mini >= 0)
mini = newmini;
if (mini == -2)
[gcc r15-1013] fold-const: Handle CTZ like CLZ in tree_call_nonnegative_warnv_p [PR115337]
https://gcc.gnu.org/g:181861b072ff1ef650c1a9d0290a4a672b9e747c commit r15-1013-g181861b072ff1ef650c1a9d0290a4a672b9e747c Author: Jakub Jelinek Date: Tue Jun 4 15:52:09 2024 +0200 fold-const: Handle CTZ like CLZ in tree_call_nonnegative_warnv_p [PR115337] I think we can handle CTZ exactly like CLZ in tree_call_nonnegative_warnv_p. Like CLZ, if it is UB at zero, the result range is [0, prec-1] and if it is well defined at zero, the second argument provides the value at zero. 2024-06-04 Jakub Jelinek PR tree-optimization/115337 * fold-const.cc (tree_call_nonnegative_warnv_p): Handle CASE_CFN_CTZ like CASE_CFN_CLZ. Diff: --- gcc/fold-const.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 048c654c848..92b048c307e 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -15250,6 +15250,7 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1, return true; CASE_CFN_CLZ: +CASE_CFN_CTZ: if (arg1) return RECURSE (arg1); return true;
[gcc r15-1011] fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]
https://gcc.gnu.org/g:b82a816000791e7a286c7836b3a473ec0e2a577b
commit r15-1011-gb82a816000791e7a286c7836b3a473ec0e2a577b
Author: Jakub Jelinek
Date: Tue Jun 4 15:49:41 2024 +0200
fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]
The function currently incorrectly assumes all the __builtin_clz* and .CLZ
calls have non-negative result. That is the case of the former which is UB
on zero and has [0, prec-1] return value otherwise, and is the case of the
single argument .CLZ as well (again, UB on zero), but for two argument
.CLZ is the case only if the second argument is also nonnegative (or if we
know the argument can't be zero, but let's do that just in the ranger IMHO).
The following patch does that.
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* fold-const.cc (tree_call_nonnegative_warnv_p) :
If arg1 is non-NULL, RECURSE on it, otherwise return true.
* gcc.dg/bitint-106.c: New test.
Diff:
---
gcc/fold-const.cc | 6 +-
gcc/testsuite/gcc.dg/bitint-106.c | 29 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 117a816fec6..65ce03d572f 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15241,7 +15241,6 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn
fn, tree arg0, tree arg1,
CASE_CFN_FFS:
CASE_CFN_PARITY:
CASE_CFN_POPCOUNT:
-CASE_CFN_CLZ:
CASE_CFN_CLRSB:
case CFN_BUILT_IN_BSWAP16:
case CFN_BUILT_IN_BSWAP32:
@@ -15250,6 +15249,11 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn
fn, tree arg0, tree arg1,
/* Always true. */
return true;
+CASE_CFN_CLZ:
+ if (arg1)
+ return RECURSE (arg1);
+ return true;
+
CASE_CFN_SQRT:
CASE_CFN_SQRT_FN:
/* sqrt(-0.0) is -0.0. */
diff --git a/gcc/testsuite/gcc.dg/bitint-106.c
b/gcc/testsuite/gcc.dg/bitint-106.c
new file mode 100644
index 000..a36e8836690
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/bitint-106.c
@@ -0,0 +1,29 @@
+/* PR tree-optimization/115337 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-O2" } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+#define N 128
+#else
+#define N 63
+#endif
+
+_BitInt (N) g;
+int c;
+
+void
+foo (unsigned _BitInt (N + 1) z, _BitInt (N) *ret)
+{
+ c = __builtin_stdc_first_leading_one (z << N);
+ _BitInt (N) y = *(_BitInt (N) *) __builtin_memset (, c, 5);
+ *ret = y;
+}
+
+int
+main ()
+{
+ _BitInt (N) x;
+ foo (0, );
+ if (c || g || x)
+__builtin_abort ();
+}
[gcc r15-1012] fold-const, gimple-fold: Some formatting cleanups
https://gcc.gnu.org/g:7be37a9bd40862e6a4686105cacf22d393258848
commit r15-1012-g7be37a9bd40862e6a4686105cacf22d393258848
Author: Jakub Jelinek
Date: Tue Jun 4 15:51:31 2024 +0200
fold-const, gimple-fold: Some formatting cleanups
While looking into PR115337, I've spotted some badly formatted code,
which the following patch fixes.
2024-06-04 Jakub Jelinek
* fold-const.cc (tree_call_nonnegative_warnv_p): Formatting fixes.
(tree_invalid_nonnegative_warnv_p): Likewise.
* gimple-fold.cc (gimple_call_nonnegative_warnv_p): Likewise.
Diff:
---
gcc/fold-const.cc | 8
gcc/gimple-fold.cc | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 65ce03d572f..048c654c848 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15331,8 +15331,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn
fn, tree arg0, tree arg1,
non-negative if both operands are non-negative. In the presence
of qNaNs, we're non-negative if either operand is non-negative
and can't be a qNaN, or if both operands are non-negative. */
- if (tree_expr_maybe_signaling_nan_p (arg0) ||
- tree_expr_maybe_signaling_nan_p (arg1))
+ if (tree_expr_maybe_signaling_nan_p (arg0)
+ || tree_expr_maybe_signaling_nan_p (arg1))
return RECURSE (arg0) && RECURSE (arg1);
return RECURSE (arg0) ? (!tree_expr_maybe_nan_p (arg0)
|| RECURSE (arg1))
@@ -15431,8 +15431,8 @@ tree_invalid_nonnegative_warnv_p (tree t, bool
*strict_overflow_p, int depth)
case CALL_EXPR:
{
- tree arg0 = call_expr_nargs (t) > 0 ? CALL_EXPR_ARG (t, 0) : NULL_TREE;
- tree arg1 = call_expr_nargs (t) > 1 ? CALL_EXPR_ARG (t, 1) : NULL_TREE;
+ tree arg0 = call_expr_nargs (t) > 0 ? CALL_EXPR_ARG (t, 0) : NULL_TREE;
+ tree arg1 = call_expr_nargs (t) > 1 ? CALL_EXPR_ARG (t, 1) : NULL_TREE;
return tree_call_nonnegative_warnv_p (TREE_TYPE (t),
get_call_combined_fn (t),
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index c33583cf3ee..7c534d56bf1 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -9334,10 +9334,10 @@ static bool
gimple_call_nonnegative_warnv_p (gimple *stmt, bool *strict_overflow_p,
int depth)
{
- tree arg0 = gimple_call_num_args (stmt) > 0 ?
-gimple_call_arg (stmt, 0) : NULL_TREE;
- tree arg1 = gimple_call_num_args (stmt) > 1 ?
-gimple_call_arg (stmt, 1) : NULL_TREE;
+ tree arg0
+= gimple_call_num_args (stmt) > 0 ? gimple_call_arg (stmt, 0) : NULL_TREE;
+ tree arg1
+= gimple_call_num_args (stmt) > 1 ? gimple_call_arg (stmt, 1) : NULL_TREE;
tree lhs = gimple_call_lhs (stmt);
return (lhs
&& tree_call_nonnegative_warnv_p (TREE_TYPE (lhs),
[PATCH] fold-const: Handle CTZ like CLZ in tree_call_nonnegative_warnv_p [PR115337]
Hi! I think we can handle CTZ exactly like CLZ in tree_call_nonnegative_warnv_p. Like CLZ, if it is UB at zero, the result range is [0, prec-1] and if it is well defined at zero, the second argument provides the value at zero. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-06-04 Jakub Jelinek PR tree-optimization/115337 * fold-const.cc (tree_call_nonnegative_warnv_p): Handle CASE_CFN_CTZ like CASE_CFN_CLZ. --- gcc/fold-const.cc.jj2024-06-04 12:08:14.671262211 +0200 +++ gcc/fold-const.cc 2024-06-04 10:56:57.575425348 +0200 @@ -15250,6 +15250,7 @@ tree_call_nonnegative_warnv_p (tree type return true; CASE_CFN_CLZ: +CASE_CFN_CTZ: if (arg1) return RECURSE (arg1); return true; Jakub
[PATCH] ranger: Improve CLZ fold_range [PR115337]
Hi!
cfn_ctz::fold_range includes special cases for the case where .CTZ has
two arguments and so is well defined at zero, and the second argument is
equal to prec or -1, but cfn_clz::fold_range does that only for the prec
case. -1 is fairly common as well though, because the builtins
do use it now, so I think it is worth special casing that.
If we don't know anything about the argument, the difference for
.CLZ (arg, -1) is that previously the result was varying, now it will be
[-1, prec-1]. If we knew arg can't be zero, it used to be optimized before
as well into e.g. [0, prec-1] or similar.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* gimple-range-op.cc (cfn_clz::fold_range): For
m_gimple_call_internal_p handle as a special case also second argument
of -1 next to prec.
--- gcc/gimple-range-op.cc.jj 2024-05-21 10:19:34.736524824 +0200
+++ gcc/gimple-range-op.cc 2024-06-04 11:53:35.190005093 +0200
@@ -941,8 +941,10 @@ cfn_clz::fold_range (irange , tree typ
int maxi = prec - 1;
if (m_gimple_call_internal_p)
{
- // Only handle the single common value.
- if (rh.lower_bound () == prec)
+ // Handle only the two common values.
+ if (rh.lower_bound () == -1)
+ mini = -1;
+ else if (rh.lower_bound () == prec)
maxi = prec;
else
// Magic value to give up, unless we can prove arg is non-zero.
@@ -953,7 +955,7 @@ cfn_clz::fold_range (irange , tree typ
if (wi::gt_p (lh.lower_bound (), 0, TYPE_SIGN (lh.type (
{
maxi = prec - 1 - wi::floor_log2 (lh.lower_bound ());
- if (mini == -2)
+ if (mini < 0)
mini = 0;
}
else if (!range_includes_zero_p (lh))
@@ -969,11 +971,11 @@ cfn_clz::fold_range (irange , tree typ
if (max == 0)
{
// If CLZ_DEFINED_VALUE_AT_ZERO is 2 with VALUE of prec,
- // return [prec, prec], otherwise ignore the range.
- if (maxi == prec)
- mini = prec;
+ // return [prec, prec] or [-1, -1], otherwise ignore the range.
+ if (maxi == prec || mini == -1)
+ mini = maxi;
}
- else
+ else if (mini >= 0)
mini = newmini;
if (mini == -2)
Jakub
[PATCH] fold-const, gimple-fold: Some formatting cleanups
Hi!
While looking into PR115337, I've spotted some badly formatted code,
which the following patch fixes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-04 Jakub Jelinek
* fold-const.cc (tree_call_nonnegative_warnv_p): Formatting fixes.
(tree_invalid_nonnegative_warnv_p): Likewise.
* gimple-fold.cc (gimple_call_nonnegative_warnv_p): Likewise.
--- gcc/fold-const.cc.jj2024-04-04 10:47:46.363287718 +0200
+++ gcc/fold-const.cc 2024-06-04 10:56:57.575425348 +0200
@@ -15331,8 +15331,8 @@ tree_call_nonnegative_warnv_p (tree type
non-negative if both operands are non-negative. In the presence
of qNaNs, we're non-negative if either operand is non-negative
and can't be a qNaN, or if both operands are non-negative. */
- if (tree_expr_maybe_signaling_nan_p (arg0) ||
- tree_expr_maybe_signaling_nan_p (arg1))
+ if (tree_expr_maybe_signaling_nan_p (arg0)
+ || tree_expr_maybe_signaling_nan_p (arg1))
return RECURSE (arg0) && RECURSE (arg1);
return RECURSE (arg0) ? (!tree_expr_maybe_nan_p (arg0)
|| RECURSE (arg1))
@@ -15431,8 +15431,8 @@ tree_invalid_nonnegative_warnv_p (tree t
case CALL_EXPR:
{
- tree arg0 = call_expr_nargs (t) > 0 ? CALL_EXPR_ARG (t, 0) : NULL_TREE;
- tree arg1 = call_expr_nargs (t) > 1 ? CALL_EXPR_ARG (t, 1) : NULL_TREE;
+ tree arg0 = call_expr_nargs (t) > 0 ? CALL_EXPR_ARG (t, 0) : NULL_TREE;
+ tree arg1 = call_expr_nargs (t) > 1 ? CALL_EXPR_ARG (t, 1) : NULL_TREE;
return tree_call_nonnegative_warnv_p (TREE_TYPE (t),
get_call_combined_fn (t),
--- gcc/gimple-fold.cc.jj 2024-02-28 09:40:09.473563056 +0100
+++ gcc/gimple-fold.cc 2024-06-04 10:38:37.515145399 +0200
@@ -9334,10 +9334,10 @@ static bool
gimple_call_nonnegative_warnv_p (gimple *stmt, bool *strict_overflow_p,
int depth)
{
- tree arg0 = gimple_call_num_args (stmt) > 0 ?
-gimple_call_arg (stmt, 0) : NULL_TREE;
- tree arg1 = gimple_call_num_args (stmt) > 1 ?
-gimple_call_arg (stmt, 1) : NULL_TREE;
+ tree arg0
+= gimple_call_num_args (stmt) > 0 ? gimple_call_arg (stmt, 0) : NULL_TREE;
+ tree arg1
+= gimple_call_num_args (stmt) > 1 ? gimple_call_arg (stmt, 1) : NULL_TREE;
tree lhs = gimple_call_lhs (stmt);
return (lhs
&& tree_call_nonnegative_warnv_p (TREE_TYPE (lhs),
Jakub
[PATCH] fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337]
Hi!
The function currently incorrectly assumes all the __builtin_clz* and .CLZ
calls have non-negative result. That is the case of the former which is UB
on zero and has [0, prec-1] return value otherwise, and is the case of the
single argument .CLZ as well (again, UB on zero), but for two argument
.CLZ is the case only if the second argument is also nonnegative (or if we
know the argument can't be zero, but let's do that just in the ranger IMHO).
The following patch does that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 14?
For 13 and earlier, we can't use the testcase and the fold-const.cc change
would need to differentiate between __builtin_clz* vs. .CLZ and in the
latter case look at CLZ_DEFINED_VALUE_AT_ZERO.
2024-06-04 Jakub Jelinek
PR tree-optimization/115337
* fold-const.cc (tree_call_nonnegative_warnv_p) :
If arg1 is non-NULL, RECURSE on it, otherwise return true.
* gcc.dg/bitint-106.c: New test.
--- gcc/fold-const.cc.jj2024-04-04 10:47:46.363287718 +0200
+++ gcc/fold-const.cc 2024-06-04 10:56:57.575425348 +0200
@@ -15241,7 +15241,6 @@ tree_call_nonnegative_warnv_p (tree type
CASE_CFN_FFS:
CASE_CFN_PARITY:
CASE_CFN_POPCOUNT:
-CASE_CFN_CLZ:
CASE_CFN_CLRSB:
case CFN_BUILT_IN_BSWAP16:
case CFN_BUILT_IN_BSWAP32:
@@ -15250,6 +15249,11 @@ tree_call_nonnegative_warnv_p (tree type
/* Always true. */
return true;
+CASE_CFN_CLZ:
+ if (arg1)
+ return RECURSE (arg1);
+ return true;
+
CASE_CFN_SQRT:
CASE_CFN_SQRT_FN:
/* sqrt(-0.0) is -0.0. */
--- gcc/testsuite/gcc.dg/bitint-106.c.jj2024-06-04 12:00:59.017079094
+0200
+++ gcc/testsuite/gcc.dg/bitint-106.c 2024-06-04 12:00:41.975306632 +0200
@@ -0,0 +1,29 @@
+/* PR tree-optimization/115337 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-O2" } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+#define N 128
+#else
+#define N 63
+#endif
+
+_BitInt (N) g;
+int c;
+
+void
+foo (unsigned _BitInt (N + 1) z, _BitInt (N) *ret)
+{
+ c = __builtin_stdc_first_leading_one (z << N);
+ _BitInt (N) y = *(_BitInt (N) *) __builtin_memset (, c, 5);
+ *ret = y;
+}
+
+int
+main ()
+{
+ _BitInt (N) x;
+ foo (0, );
+ if (c || g || x)
+__builtin_abort ();
+}
Jakub
Re: [PATCH] Implement -fassume-sane-operator-new [PR110137]
On Wed, May 29, 2024 at 04:09:08AM +, user202...@protonmail.com wrote:
> This patch implements the flag -fassume-sane-operator-new as suggested in
> PR110137. When the flag is enabled, it is assumed that operator new does not
> modify global memory.
>
> While this patch is not powerful enough to handle the original issue in
> PR110035, it allows the optimizer to handle some simpler case (e.g. load from
> global memory with fixed address), as demonstrated in the test
> sane-operator-new-1.C.
>
> To handle the original issue in PR110035, some other improvement to the
> optimizer is needed, which will be sent as subsequent patches.
>
> Bootstrapped and regression tested on x86_64-pc-linux-gnu.
> From 14a8604907c89838577ff8560df9a3f9dc2d8afb Mon Sep 17 00:00:00 2001
> From: user202729
> Date: Fri, 24 May 2024 17:40:55 +0800
> Subject: [PATCH] Implement -fassume-sane-operator-new [PR110137]
>
> PR c++/110137
>
> gcc/c-family/ChangeLog:
>
> * c.opt: New option.
You need c.opt (fassume-sane-operator-new): New option.
> gcc/ChangeLog:
>
> * ira.cc (is_call_operator_new_p): New function.
> (may_modify_memory_p): Likewise.
> (validate_equiv_mem): Modify to use may_modify_memory_p.
The patch doesn't update doc/invoke.texi with the description of
what the option does, that is essential.
> +fassume-sane-operator-new
> +C++ Optimization Var(flag_assume_sane_operator_new)
> +Assume operator new does not have any side effect other than the allocation.
Is it just about operator new and not about operator delete as well in
clang?
Is it about all operator new or just the replaceable ones (standard ones in
global scope, those also have DECL_IS_REPLACEABLE_OPERATOR flag on them).
Depending on this, if the flag is about only replaceable ones, I think it is
a global property, so for LTO it should be merged as if there is a single TU
which uses this flag, it is set for the whole LTO compilation (or should it
be only for TUs with that flag which actually use such operator new calls?).
If it is all operators new, then it is a local property in each function (or
even better a property of the operators actually) and we should track
somewhere in cfun whether a function compiled with that flag calls operator
new and whether a function compiled without that flag calls operator new.
Then e.g. during inlining merge it, such that if both the functions invoke
operator new and they disagree on whether it is sane or not, the non-sane
case wins.
> --- a/gcc/ira.cc
> +++ b/gcc/ira.cc
This surely is much more important to handle in the alias oracle, not just
IRA.
> @@ -3080,6 +3080,27 @@ validate_equiv_mem_from_store (rtx dest, const_rtx set
> ATTRIBUTE_UNUSED,
>
> static bool equiv_init_varies_p (rtx x);
>
> +static bool is_call_operator_new_p (rtx_insn *insn)
Formatting, static bool on one line, is_call_... on another one.
And needs a function comment.
> +{
> + if (!CALL_P (insn))
> +return false;
> + tree fn = get_call_fndecl (insn);
> + if (fn == NULL_TREE)
> +return false;
> + return DECL_IS_OPERATOR_NEW_P (fn);
> +}
> +
> +/* Returns true if there is a possibility that INSN may modify memory.
> + If false is returned, the compiler proved INSN never modify memory. */
> +static bool may_modify_memory_p (rtx_insn *insn)
Again, missing newline instead of space after bool.
Not sure about the name of this function, even sane replaceable operator new
may modify memory (it actually has to), just shouldn't modify memory
the compiler cares about.
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/sane-operator-new-1.C
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
> +/* { dg-options "-O2 -fassume-sane-operator-new" } */
If the tests are x86 specific, they should go to g++.target/i386/ directory.
But as I said earlier, it would be better to handle optimizations like that
on GIMPLE too and then you can test that say on optimized dump on all
targets.
Jakub
[Bug c++/110137] implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #12 from Jakub Jelinek ---
Is the option supposed to be only about the standard global scope operator
new/delete (_Znam etc.) or also user operator new/delete class methods? If the
former, then I agree it is a global property (or at least a per shared
library/binary property, one can arrange stuff with symbol visibility etc.).
Otherwise it is a property of whatever operator new/delete you call.
I think DECL_IS_OPERATOR_{NEW,DELETE} is set on both of these, the standard
ones have
also DECL_IS_REPLACEABLE_OPERATOR flag on them.
Anyway, handling this just in IRA doesn't seem to be enough, surely it should
be also handled during alias analysis etc.
Re: RFC: Support for pragma clang loop interleave_count(N)
On Tue, Jun 04, 2024 at 11:58:43AM +0100, Andre Vieira (lists) wrote:
> case annot_expr_unroll_kind:
> + case annot_expr_interleaves_kind:
> {
> - pp_string (pp, ", unroll ");
> + pp_string (pp,
> +annot_expr_unroll_kind
I think annot_expr_unroll_kind is 1 and thus always non-zero.
You want to compare the value of the operand, or just use separate
cases, they aren't that large.
> +? ", unroll "
> +: ", interleaves ");
> pp_decimal_int (pp,
> (int) TREE_INT_CST_LOW (TREE_OPERAND (node, 2)));
> break;
Jakub
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Fixed for 15.1+ so far.
[gcc r15-1009] builtins: Force SAVE_EXPR for __builtin_{add, sub, mul}_overflow and __builtin{add, sub}c [PR108789]
https://gcc.gnu.org/g:b8e28381cb5c0cddfe5201faf799d8b27f5d7d6c
commit r15-1009-gb8e28381cb5c0cddfe5201faf799d8b27f5d7d6c
Author: Jakub Jelinek
Date: Tue Jun 4 12:28:01 2024 +0200
builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow and
__builtin{add,sub}c [PR108789]
The following testcase is miscompiled, because we use save_expr
on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first
two operands are not INTEGER_CSTs (in that case we just fold it right away)
but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually
create a SAVE_EXPR at all and so we lower it to
*arg2 = REALPART_EXPR (.ADD_OVERFLOW (arg0, arg1)), \
IMAGPART_EXPR (.ADD_OVERFLOW (arg0, arg1))
which evaluates the ifn twice and just hope it will be CSEd back.
As *arg2 aliases *arg0, that is not the case.
The builtins are really never const/pure as they store into what
the third arguments points to, so after handling the INTEGER_CST+INTEGER_CST
case, I think we should just always use SAVE_EXPR. Just building SAVE_EXPR
by hand and setting TREE_SIDE_EFFECTS on it doesn't work, because
c_fully_fold optimizes it away again, so the following patch marks the
ifn calls as TREE_SIDE_EFFECTS (but doesn't do it for the
__builtin_{add,sub,mul}_overflow_p case which were designed for use
especially in constant expressions and don't really evaluate the
realpart side, so we don't really need a SAVE_EXPR in that case).
2024-06-04 Jakub Jelinek
PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr.
(fold_builtin_addc_subc): Set TREE_SIDE_EFFECTS on call before
calling save_expr.
* gcc.c-torture/execute/pr108789.c: New test.
Diff:
---
gcc/builtins.cc| 22 ++-
gcc/testsuite/gcc.c-torture/execute/pr108789.c | 39 ++
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 00ee9eb2925..5b5307c67b8 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -10042,7 +10042,21 @@ fold_builtin_arith_overflow (location_t loc, enum
built_in_function fcode,
tree ctype = build_complex_type (type);
tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
arg0, arg1);
- tree tgt = save_expr (call);
+ tree tgt;
+ if (ovf_only)
+ {
+ tgt = call;
+ intres = NULL_TREE;
+ }
+ else
+ {
+ /* Force SAVE_EXPR even for calls which satisfy tree_invariant_p_1,
+as while the call itself is const, the REALPART_EXPR store is
+certainly not. And in any case, we want just one call,
+not multiple and trying to CSE them later. */
+ TREE_SIDE_EFFECTS (call) = 1;
+ tgt = save_expr (call);
+ }
intres = build1_loc (loc, REALPART_EXPR, type, tgt);
ovfres = build1_loc (loc, IMAGPART_EXPR, type, tgt);
ovfres = fold_convert_loc (loc, boolean_type_node, ovfres);
@@ -10354,11 +10368,17 @@ fold_builtin_addc_subc (location_t loc, enum
built_in_function fcode,
tree ctype = build_complex_type (type);
tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
args[0], args[1]);
+ /* Force SAVE_EXPR even for calls which satisfy tree_invariant_p_1,
+ as while the call itself is const, the REALPART_EXPR store is
+ certainly not. And in any case, we want just one call,
+ not multiple and trying to CSE them later. */
+ TREE_SIDE_EFFECTS (call) = 1;
tree tgt = save_expr (call);
tree intres = build1_loc (loc, REALPART_EXPR, type, tgt);
tree ovfres = build1_loc (loc, IMAGPART_EXPR, type, tgt);
call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
intres, args[2]);
+ TREE_SIDE_EFFECTS (call) = 1;
tgt = save_expr (call);
intres = build1_loc (loc, REALPART_EXPR, type, tgt);
tree ovfres2 = build1_loc (loc, IMAGPART_EXPR, type, tgt);
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr108789.c
b/gcc/testsuite/gcc.c-torture/execute/pr108789.c
new file mode 100644
index 000..32ee19be1c4
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr108789.c
@@ -0,0 +1,39 @@
+/* PR middle-end/108789 */
+
+int
+add (unsigned *r, const unsigned *a, const unsigned *b)
+{
+ return __builtin_add_overflow (*a, *b, r);
+}
+
+int
+mul (unsigned *r, const unsigned *a, const unsigned *b)
+{
+ return __builtin_mul_overflow (*a, *b, r);
+}
+
+int
+main ()
+{
+ unsigned x;
+
+ /* 1073741824U + 1073741824U should not overflow. */
+ x = (__INT_MAX__ + 1U) / 2;
+ if (add (, , ))
+__builtin_abort ();
+
+ /* 256U
[gcc r15-1008] invoke.texi: Clarify -march=lujiazui
https://gcc.gnu.org/g:09b4ab53155ea16e1fb12c2afcd9b6fe29a31c74
commit r15-1008-g09b4ab53155ea16e1fb12c2afcd9b6fe29a31c74
Author: Jakub Jelinek
Date: Tue Jun 4 12:20:13 2024 +0200
invoke.texi: Clarify -march=lujiazui
I was recently searching which exact CPUs are affected by the PR114576
wrong-code issue and went from the PTA_* bitmasks in GCC, so arrived
at the goldmont, goldmont-plus, tremont and lujiazui CPUs (as -march=
cases which do enable -maes and don't enable -mavx).
But when double-checking that against the invoke.texi documentation,
that was true for the first 3, but lujiazui said it supported AVX.
I was really confused by that, until I found the
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604407.html
explanation. So, seems the CPUs do have AVX and F16C but -march=lujiazui
doesn't enable those and even activelly attempts to filter those out from
the announced CPUID features, in glibc as well as e.g. in libgcc.
Thus, I think we should document what actually happens, otherwise
users could assume that
gcc -march=lujiazui predefines __AVX__ and __F16C__, which it doesn't.
2024-06-04 Jakub Jelinek
* doc/invoke.texi (lujiazui): Clarify that while the CPUs do support
AVX and F16C, -march=lujiazui actually doesn't enable those.
Diff:
---
gcc/doc/invoke.texi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 45115b5fbed..4e8967fd8ab 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -34808,8 +34808,10 @@ instruction set support.
@item lujiazui
ZHAOXIN lujiazui CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
-SSE4.2, AVX, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
-ABM, BMI, BMI2, F16C, FXSR, RDSEED instruction set support.
+SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
+ABM, BMI, BMI2, FXSR, RDSEED instruction set support. While the CPUs
+do support AVX and F16C, these aren't enabled by @code{-march=lujiazui}
+for performance reasons.
@item yongfeng
ZHAOXIN yongfeng CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #7 from Jakub Jelinek --- Created attachment 58342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58342=edit gcc15-pr115337-4.patch And finally, I think tree_call_expr_nonzero can handle CTZ the same as CLZ now.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #6 from Jakub Jelinek --- Created attachment 58341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58341=edit gcc15-pr115337-3.patch Improve ranger handling of .CLZ (x, -1). As the stdbit.h builtins now use that value, it is worth special casing it in the CLZ handling, so that we get e.g. [-1, 128] range rather than VARYING.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #5 from Jakub Jelinek --- Created attachment 58340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58340=edit gcc15-pr115337-2.patch Fixes for some formatting issues I found during the debugging.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #4 from Jakub Jelinek --- Created attachment 58339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58339=edit gcc15-pr115337-1.patch Untested fix.
[kdeconnect] [Bug 487707] After restart and login on root account
https://bugs.kde.org/show_bug.cgi?id=487707 --- Comment #1 from Jakub Masek --- Created attachment 170126 --> https://bugs.kde.org/attachment.cgi?id=170126=edit New crash information added by DrKonqi kdeconnectd (23.08.5) using Qt 5.15.9 After fresh install from workstation iso v9.4 this bug eccurs everytime when I login in to computer. -- Backtrace (Reduced): #4 0x7f56ad8e2036 in KdeConnectConfig::deviceId() () from /lib64/libkdeconnectcore.so.23 #5 0x7f56ad8e562d in KdeConnectConfig::deviceInfo() () from /lib64/libkdeconnectcore.so.23 #6 0x7f56ad8d20b5 in LanLinkProvider::broadcastToNetwork() () from /lib64/libkdeconnectcore.so.23 #7 0x7f56ac2dbc69 in QtPrivate::QSlotObjectBase::call (a=0x7ffc72c7d390, r=, this=0x55b7e98355b0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #8 doActivate (sender=0x55b7e9830740, signal_index=3, argv=0x7ffc72c7d390) at kernel/qobject.cpp:3923 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 487707] After restart and login on root account
https://bugs.kde.org/show_bug.cgi?id=487707 Jakub Masek changed: What|Removed |Added CC||j...@masoxik.cz -- You are receiving this mail because: You are watching all bug changes.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- cfn_clz::fold_range is actually correct (but given the use of -1 second argument perhaps could special case that case too). What is wrong is tree_call_nonnegative_warnv_p.
[PATCH] rs6000: Decrease code size of rs6000_init_generated_builtins [PR115324]
On Mon, Jun 03, 2024 at 03:40:38PM -0500, Segher Boessenkool wrote:
> > So, either we'd need to add some further GTY extensions, or the following
> > patch instead reworks it such that the fntype members which were the only
> > reason for PCH in those arrays are moved to separate arrays.
>
> And that just sidesteps the limitation in PCH?
Yes. But at the same size decreases the sizes of the data sections and
decreases size of the data written to/from PCH files, so I think it is a
win.
> > void
> > rs6000_init_generated_builtins ()
> > {
> > + bifdata *rs6000_builtin_info_p;
> > + tree *rs6000_builtin_info_fntype_p;
> > + ovlddata *rs6000_instance_info_p;
> > + tree *rs6000_instance_info_fntype_p;
> > + ovldrecord *rs6000_overload_info_p;
> > + __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
>
> Bah.
>
> It should not be called _p of course, it is not a predicate. And
> relying on the operand tie to not have to do a much more obvious
> assignment, please don't. Just *do* write assignments, and then use
> a simple "+r"?
>
> But you call this a hack anyway, you wouldn't propose to actually
> include this patch :-)
It was a quick hack just to see why the size grew that much.
Ideally some optimization would figure out we have a single function which
has
461 rs6000_overload_info
1257 rs6000_builtin_info_fntype
1768 rs6000_builtin_decls
2548 rs6000_instance_info_fntype
array references and that maybe it might be a good idea to just preload
the addresses of those arrays into some register if it decreases code size
and doesn't slow things down.
The function actually is called just once and is huge, so code size is even
more important than speed, which is dominated by all the GC allocations
anyway.
Until that is done, here is a slightly cleaner version of the hack, which
makes the function noipa (so that LTO doesn't undo it) for GCC 8.1+ and
passes the 4 arrays as arguments to the function from the caller.
This decreases the function size from 228668 bytes to 207572 bytes.
Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
2024-06-04 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Change
declaration of rs6000_init_generated_builtins from no arguments
to 4 pointer arguments.
(write_init_bif_table): Change rs6000_builtin_info_fntype to
builtin_info_fntype and rs6000_builtin_decls to builtin_decls.
(write_init_ovld_table): Change rs6000_instance_info_fntype to
instance_info_fntype, rs6000_builtin_decls to builtin_decls and
rs6000_overload_info to overload_info.
(write_init_file): Add __noipa__ attribute to
rs6000_init_generated_builtins for GCC 8.1+ and change the function
from no arguments to 4 pointer arguments. Change rs6000_builtin_decls
to builtin_decls.
* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Adjust
rs6000_init_generated_builtins caller.
--- gcc/config/rs6000/rs6000-gen-builtins.cc.jj 2024-06-03 23:11:02.662631144
+0200
+++ gcc/config/rs6000/rs6000-gen-builtins.cc2024-06-03 23:38:31.727620920
+0200
@@ -2376,7 +2376,10 @@ write_decls (void)
"rs6000_instance_info_fntype[RS6000_INST_MAX];\n");
fprintf (header_file, "extern ovldrecord rs6000_overload_info[];\n\n");
- fprintf (header_file, "extern void rs6000_init_generated_builtins ();\n\n");
+ fprintf (header_file,
+ "extern void rs6000_init_generated_builtins (tree *, tree *,\n");
+ fprintf (header_file,
+ "\t\t\t\t\tovldrecord *, tree *);\n\n");
fprintf (header_file,
"extern bool rs6000_builtin_is_supported (rs6000_gen_builtins);\n");
fprintf (header_file,
@@ -2651,7 +2654,7 @@ write_init_bif_table (void)
for (int i = 0; i <= curr_bif; i++)
{
fprintf (init_file,
- " rs6000_builtin_info_fntype[RS6000_BIF_%s]"
+ " builtin_info_fntype[RS6000_BIF_%s]"
"\n= %s;\n",
bifs[i].idname, bifs[i].fndecl);
@@ -2678,7 +2681,7 @@ write_init_bif_table (void)
}
fprintf (init_file,
- " rs6000_builtin_decls[(int)RS6000_BIF_%s] = t\n",
+ " builtin_decls[(int)RS6000_BIF_%s] = t\n",
bifs[i].idname);
fprintf (init_file,
"= add_builtin_function (\"%s\",\n",
@@ -2719,7 +2722,7 @@ write_init_bif_table (void)
fprintf (init_file, "}\n");
fprintf (init_file, " else\n");
fprintf (init_file, "{\n");
- fprintf (init_file, " rs6000_b
[PATCH] c: Fix up pointer types to may_alias structures [PR114493]
Hi!
The following testcase ICEs in ipa-free-lang, because the
fld_incomplete_type_of
gcc_assert (TYPE_CANONICAL (t2) != t2
&& TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t)));
assertion doesn't hold.
This is because t is a struct S * type which was created while struct S
was still incomplete and without the may_alias attribute (and TYPE_CANONICAL
of a pointer type is a type created with can_alias_all = false argument),
while later on on the struct definition may_alias attribute was used.
fld_incomplete_type_of then creates an incomplete distinct copy of the
structure (but with the original attributes) but pointers created for it
are because of the "may_alias" attribute TYPE_REF_CAN_ALIAS_ALL, including
their TYPE_CANONICAL, because while that is created with !can_alias_all
argument, we later set it because of the "may_alias" attribute on the
to_type.
This doesn't ICE with C++ since PR70512 fix because the C++ FE sets
TYPE_REF_CAN_ALIAS_ALL on all pointer types to the class type (and its
variants) when the may_alias is added.
The following patch does that in the C FE as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches?
2024-06-04 Jakub Jelinek
PR c/114493
* c-decl.cc (c_fixup_may_alias): New function.
(finish_struct): Call it if "may_alias" attribute is
specified.
* gcc.dg/pr114493-1.c: New test.
* gcc.dg/pr114493-2.c: New test.
--- gcc/c/c-decl.cc.jj 2024-05-07 08:47:35.974836903 +0200
+++ gcc/c/c-decl.cc 2024-06-03 19:55:53.819586291 +0200
@@ -9446,6 +9446,17 @@ verify_counted_by_attribute (tree struct
return;
}
+/* TYPE is a struct or union that we're applying may_alias to after the body is
+ parsed. Fixup any POINTER_TO types. */
+
+static void
+c_fixup_may_alias (tree type)
+{
+ for (tree t = TYPE_POINTER_TO (type); t; t = TYPE_NEXT_PTR_TO (t))
+for (tree v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
+ TYPE_REF_CAN_ALIAS_ALL (v) = true;
+}
+
/* Fill in the fields of a RECORD_TYPE or UNION_TYPE node, T.
LOC is the location of the RECORD_TYPE or UNION_TYPE's definition.
FIELDLIST is a chain of FIELD_DECL nodes for the fields.
@@ -9791,6 +9802,10 @@ finish_struct (location_t loc, tree t, t
C_TYPE_BEING_DEFINED (t) = 0;
+ if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (t)))
+for (x = TYPE_MAIN_VARIANT (t); x; x = TYPE_NEXT_VARIANT (x))
+ c_fixup_may_alias (x);
+
/* Set type canonical based on equivalence class. */
if (flag_isoc23 && !C_TYPE_VARIABLE_SIZE (t))
{
--- gcc/testsuite/gcc.dg/pr114493-1.c.jj2024-06-03 19:59:58.774336785
+0200
+++ gcc/testsuite/gcc.dg/pr114493-1.c 2024-06-03 19:59:12.931944923 +0200
@@ -0,0 +1,19 @@
+/* PR c/114493 */
+/* { dg-do compile { target lto } } */
+/* { dg-options "-O2 -flto" } */
+
+void foo (void);
+struct S;
+struct S bar (struct S **);
+struct S qux (const struct S **);
+
+struct __attribute__((__may_alias__)) S {
+ int s;
+};
+
+struct S
+baz (void)
+{
+ foo ();
+ return (struct S) {};
+}
--- gcc/testsuite/gcc.dg/pr114493-2.c.jj2024-06-03 19:59:58.774336785
+0200
+++ gcc/testsuite/gcc.dg/pr114493-2.c 2024-06-03 20:01:00.886512830 +0200
@@ -0,0 +1,26 @@
+/* PR c/114493 */
+/* { dg-do compile { target lto } } */
+/* { dg-options "-O2 -flto -std=c23" } */
+
+void foo (void);
+struct S;
+struct S bar (struct S **);
+struct S qux (const struct S **);
+
+void
+corge (void)
+{
+ struct S { int s; } s;
+ s.s = 0;
+}
+
+struct __attribute__((__may_alias__)) S {
+ int s;
+};
+
+struct S
+baz (void)
+{
+ foo ();
+ return (struct S) {};
+}
Jakub
[PATCH] builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow and __builtin{add,sub}c [PR108789]
Hi!
The following testcase is miscompiled, because we use save_expr
on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first
two operands are not INTEGER_CSTs (in that case we just fold it right away)
but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually
create a SAVE_EXPR at all and so we lower it to
*arg2 = REALPART_EXPR (.ADD_OVERFLOW (arg0, arg1)), \
IMAGPART_EXPR (.ADD_OVERFLOW (arg0, arg1))
which evaluates the ifn twice and just hope it will be CSEd back.
As *arg2 aliases *arg0, that is not the case.
The builtins are really never const/pure as they store into what
the third arguments points to, so after handling the INTEGER_CST+INTEGER_CST
case, I think we should just always use SAVE_EXPR. Just building SAVE_EXPR
by hand and setting TREE_SIDE_EFFECTS on it doesn't work, because
c_fully_fold optimizes it away again, so the following patch marks the
ifn calls as TREE_SIDE_EFFECTS (but doesn't do it for the
__builtin_{add,sub,mul}_overflow_p case which were designed for use
especially in constant expressions and don't really evaluate the
realpart side, so we don't really need a SAVE_EXPR in that case).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-06-04 Jakub Jelinek
PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr.
(fold_builtin_addc_subc): Set TREE_SIDE_EFFECTS on call before
calling save_expr.
* gcc.c-torture/execute/pr108789.c: New test.
--- gcc/builtins.cc.jj 2024-04-05 09:19:47.899050410 +0200
+++ gcc/builtins.cc 2024-06-03 17:27:11.071693074 +0200
@@ -10042,7 +10042,21 @@ fold_builtin_arith_overflow (location_t
tree ctype = build_complex_type (type);
tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
arg0, arg1);
- tree tgt = save_expr (call);
+ tree tgt;
+ if (ovf_only)
+ {
+ tgt = call;
+ intres = NULL_TREE;
+ }
+ else
+ {
+ /* Force SAVE_EXPR even for calls which satisfy tree_invariant_p_1,
+as while the call itself is const, the REALPART_EXPR store is
+certainly not. And in any case, we want just one call,
+not multiple and trying to CSE them later. */
+ TREE_SIDE_EFFECTS (call) = 1;
+ tgt = save_expr (call);
+ }
intres = build1_loc (loc, REALPART_EXPR, type, tgt);
ovfres = build1_loc (loc, IMAGPART_EXPR, type, tgt);
ovfres = fold_convert_loc (loc, boolean_type_node, ovfres);
@@ -10354,11 +10368,17 @@ fold_builtin_addc_subc (location_t loc,
tree ctype = build_complex_type (type);
tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
args[0], args[1]);
+ /* Force SAVE_EXPR even for calls which satisfy tree_invariant_p_1,
+ as while the call itself is const, the REALPART_EXPR store is
+ certainly not. And in any case, we want just one call,
+ not multiple and trying to CSE them later. */
+ TREE_SIDE_EFFECTS (call) = 1;
tree tgt = save_expr (call);
tree intres = build1_loc (loc, REALPART_EXPR, type, tgt);
tree ovfres = build1_loc (loc, IMAGPART_EXPR, type, tgt);
call = build_call_expr_internal_loc (loc, ifn, ctype, 2,
intres, args[2]);
+ TREE_SIDE_EFFECTS (call) = 1;
tgt = save_expr (call);
intres = build1_loc (loc, REALPART_EXPR, type, tgt);
tree ovfres2 = build1_loc (loc, IMAGPART_EXPR, type, tgt);
--- gcc/testsuite/gcc.c-torture/execute/pr108789.c.jj 2024-06-03
17:15:01.143366766 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr108789.c 2024-06-03
17:12:55.189036744 +0200
@@ -0,0 +1,39 @@
+/* PR middle-end/108789 */
+
+int
+add (unsigned *r, const unsigned *a, const unsigned *b)
+{
+ return __builtin_add_overflow (*a, *b, r);
+}
+
+int
+mul (unsigned *r, const unsigned *a, const unsigned *b)
+{
+ return __builtin_mul_overflow (*a, *b, r);
+}
+
+int
+main ()
+{
+ unsigned x;
+
+ /* 1073741824U + 1073741824U should not overflow. */
+ x = (__INT_MAX__ + 1U) / 2;
+ if (add (, , ))
+__builtin_abort ();
+
+ /* 256U * 256U should not overflow */
+ x = 1U << (sizeof (int) * __CHAR_BIT__ / 4);
+ if (mul (, , ))
+__builtin_abort ();
+
+ /* 2147483648U + 2147483648U should overflow */
+ x = __INT_MAX__ + 1U;
+ if (!add (, , ))
+__builtin_abort ();
+
+ /* 65536U * 65536U should overflow */
+ x = 1U << (sizeof (int) * __CHAR_BIT__ / 2);
+ if (!mul (, , ))
+__builtin_abort ();
+}
Jakub
Re: [ovs-dev] [PATCH net-next 1/2] selftests: openvswitch: fix action formatting
On Mon, 03 Jun 2024 15:00:03 -0400 Aaron Conole wrote: > I agree, this is an issue. BUT I think it might be better to just > filter by field type up front. See: > > https://github.com/apconole/linux-next-work/commit/7262107de7170d44b6dbf6c5ea6f7e6c0bb71d36#diff-3e72e7405c6bb4e9842bed5f63883ca930387086bb40d4034e92ed83a5decb4bR441 > > That version I think ends up being much easier to follow. If you want > to take it for your series, feel free. If you disagree, maybe there's > something I'm not considering about it. > > NOTE that version is just a bunch of independent changes that are > squashed together. I have a cleaner version. > > I can also bundle up the series I have so far and submit, but I didn't > want to do that until I got all the pmtu.sh support working. Maybe it > makes sense to send it now though. Simon, Jakub - wdyt? I'd say - hold onto the changes until pmtu.sh works, unless there's *any* reason for a particular patch to go in early, eg: - patch fixes existing bug - someone else needs a patch - ... - a patch which falls under some of the criteria above depends on the patch ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [PATCH net-next 1/2] selftests: openvswitch: fix action formatting
On Mon, 03 Jun 2024 15:00:03 -0400 Aaron Conole wrote: > I agree, this is an issue. BUT I think it might be better to just > filter by field type up front. See: > > https://github.com/apconole/linux-next-work/commit/7262107de7170d44b6dbf6c5ea6f7e6c0bb71d36#diff-3e72e7405c6bb4e9842bed5f63883ca930387086bb40d4034e92ed83a5decb4bR441 > > That version I think ends up being much easier to follow. If you want > to take it for your series, feel free. If you disagree, maybe there's > something I'm not considering about it. > > NOTE that version is just a bunch of independent changes that are > squashed together. I have a cleaner version. > > I can also bundle up the series I have so far and submit, but I didn't > want to do that until I got all the pmtu.sh support working. Maybe it > makes sense to send it now though. Simon, Jakub - wdyt? I'd say - hold onto the changes until pmtu.sh works, unless there's *any* reason for a particular patch to go in early, eg: - patch fixes existing bug - someone else needs a patch - ... - a patch which falls under some of the criteria above depends on the patch
Re: [PATCH] net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()
On Mon, 3 Jun 2024 11:33:28 +0200 Stefan Schmidt wrote:
> Hello.
>
> On 31.05.24 10:07, Yunshui Jiang wrote:
> > mac802154 devices update their dev->stats fields locklessly. Therefore
> > these counters should be updated atomically. Adopt SMP safe DEV_STATS_INC()
> > and DEV_STATS_ADD() to achieve this.
> >
> > Signed-off-by: Yunshui Jiang
> > ---
> > net/mac802154/tx.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
> > index 2a6f1ed763c9..6fbed5bb5c3e 100644
> > --- a/net/mac802154/tx.c
> > +++ b/net/mac802154/tx.c
> > @@ -34,8 +34,8 @@ void ieee802154_xmit_sync_worker(struct work_struct *work)
> > if (res)
> > goto err_tx;
> >
> > - dev->stats.tx_packets++;
> > - dev->stats.tx_bytes += skb->len;
> > + DEV_STATS_INC(dev, tx_packets);
> > + DEV_STATS_ADD(dev, tx_bytes, skb->len);
> >
> > ieee802154_xmit_complete(>hw, skb, false);
> >
> > @@ -90,8 +90,8 @@ ieee802154_tx(struct ieee802154_local *local, struct
> > sk_buff *skb)
> > if (ret)
> > goto err_wake_netif_queue;
> >
> > - dev->stats.tx_packets++;
> > - dev->stats.tx_bytes += len;
> > + DEV_STATS_INC(dev, tx_packets);
> > + DEV_STATS_ADD(dev, tx_bytes, len);
> > } else {
> > local->tx_skb = skb;
> > queue_work(local->workqueue, >sync_tx_work);
>
> This patch has been applied to the wpan tree and will be
> part of the next pull request to net. Thanks!
Hi! I haven't looked in detail, but FWIW
$ git grep LLTX net/mac802154/
$
and similar patch from this author has been rejected:
https://lore.kernel.org/all/cann89ilpyoojmxnjbvhy7gwpfbguxwrom9gzz-fwuuyfyjm...@mail.gmail.com/
[gcc r15-1001] rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
https://gcc.gnu.org/g:4cf2de9b5268224816a3d53fdd2c3d799ebfd9c8
commit r15-1001-g4cf2de9b5268224816a3d53fdd2c3d799ebfd9c8
Author: Jakub Jelinek
Date: Mon Jun 3 23:11:06 2024 +0200
rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or _instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them back
in full. While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.
So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.
Size-wise in .data sections it is (in bytes):
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.
Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.
When I applied
void
rs6000_init_generated_builtins ()
{
+ bifdata *rs6000_builtin_info_p;
+ tree *rs6000_builtin_info_fntype_p;
+ ovlddata *rs6000_instance_info_p;
+ tree *rs6000_instance_info_fntype_p;
+ ovldrecord *rs6000_overload_info_p;
+ __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+ __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+ __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+ __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+ __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+ #define rs6000_builtin_info rs6000_builtin_info_p
+ #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+ #define rs6000_instance_info rs6000_instance_info_p
+ #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+ #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
2024-06-03 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members. Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *. Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_in
[gcc r15-1000] c++: Fix parsing of abstract-declarator starting with ... followed by opening paren [PR115012]
https://gcc.gnu.org/g:48c3e5a4f935d6b8cd9ef7c51995e3b29ceb8be7
commit r15-1000-g48c3e5a4f935d6b8cd9ef7c51995e3b29ceb8be7
Author: Jakub Jelinek
Date: Mon Jun 3 23:07:08 2024 +0200
c++: Fix parsing of abstract-declarator starting with ... followed by
opening paren [PR115012]
The C++26 P2662R3 Pack indexing paper mentions that both GCC
and MSVC don't handle T...[10] parameter declaration when T
is a pack. And apparently neither T...(args).
While the former will change meaning in C++26, T...(args) is still
valid even in C++26.
The following patch handles just the T...(args) case in
cp_parser_direct_declarator.
2024-06-03 Jakub Jelinek
PR c++/115012
* parser.cc (cp_parser_direct_declarator): Handle
abstract declarator starting with ... followed by opening paren.
* g++.dg/cpp0x/variadic185.C: New test.
Diff:
---
gcc/cp/parser.cc | 15 +--
gcc/testsuite/g++.dg/cpp0x/variadic185.C | 43
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 779625144db..3b2ad25af9f 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -23991,7 +23991,12 @@ cp_parser_direct_declarator (cp_parser* parser,
{
/* Peek at the next token. */
token = cp_lexer_peek_token (parser->lexer);
- if (token->type == CPP_OPEN_PAREN)
+ if (token->type == CPP_OPEN_PAREN
+ || (first
+ && dcl_kind != CP_PARSER_DECLARATOR_NAMED
+ && token->type == CPP_ELLIPSIS
+ && cxx_dialect > cxx98
+ && cp_lexer_nth_token_is (parser->lexer, 2, CPP_OPEN_PAREN)))
{
/* This is either a parameter-declaration-clause, or a
parenthesized declarator. When we know we are parsing a
@@ -24030,6 +24035,11 @@ cp_parser_direct_declarator (cp_parser* parser,
Thus again, we try a parameter-declaration-clause, and if
that fails, we back out and return. */
+ bool pack_expansion_p = token->type == CPP_ELLIPSIS;
+
+ if (pack_expansion_p)
+ /* Consume the `...' */
+ cp_lexer_consume_token (parser->lexer);
if (!first || dcl_kind != CP_PARSER_DECLARATOR_NAMED)
{
@@ -24173,6 +24183,7 @@ cp_parser_direct_declarator (cp_parser* parser,
attrs,
parens_loc);
declarator->attributes = gnu_attrs;
+ declarator->parameter_pack_p |= pack_expansion_p;
/* Any subsequent parameter lists are to do with
return type, so are not those of the declared
function. */
@@ -24196,7 +24207,7 @@ cp_parser_direct_declarator (cp_parser* parser,
/* If this is the first, we can try a parenthesized
declarator. */
- if (first)
+ if (first && !pack_expansion_p)
{
bool saved_in_type_id_in_expr_p;
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic185.C
b/gcc/testsuite/g++.dg/cpp0x/variadic185.C
new file mode 100644
index 000..2c04afeda00
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic185.C
@@ -0,0 +1,43 @@
+// PR c++/115012
+// { dg-do compile { target { c++11 } } }
+// { dg-final { scan-assembler "_Z3fooIJidEEvDpFT_iE" } }
+// { dg-final { scan-assembler "_Z3barIiEvPFT_iE" } }
+// { dg-final { scan-assembler "_Z3bazIJidEEvDpFT_iE" } }
+
+template
+void
+foo (T... x (int))
+{
+}
+
+template
+void
+bar (T (int))
+{
+}
+
+template
+void
+baz (T... (int))
+{
+}
+
+int
+f1 (int)
+{
+ return 0;
+}
+
+double
+f2 (int)
+{
+ return 0;
+}
+
+void
+corge ()
+{
+ foo (f1, f2);
+ bar (f1);
+ baz (f1, f2);
+}
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #10 from Jakub Jelinek --- Created attachment 58337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58337=edit gcc15-pr114493.patch Untested fix.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #9 from Jakub Jelinek --- That was added for C++ in PR70512.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
This doesn't ICE in C++, because the C++ FE forcibly updates the corresponding
pointer types in:
#0 fixup_may_alias (klass=) at
../../gcc/cp/class.cc:2328
#1 0x00456835 in fixup_attribute_variants (t=) at ../../gcc/cp/class.cc:2354
#2 0x006f3024 in cp_parser_class_head (parser=0x7fffea2dea80,
nested_name_specifier_p=0x7fffd5ff) at ../../gcc/cp/parser.cc:27831
/* KLASS is a class that we're applying may_alias to after the body is
parsed. Fixup any POINTER_TO and REFERENCE_TO types. The
canonical type(s) will be implicitly updated. */
static void
fixup_may_alias (tree klass)
{
tree t, v;
for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_REF_CAN_ALIAS_ALL (v) = true;
for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_REF_CAN_ALIAS_ALL (v) = true;
}
Now, fixup_attribute_variants also does:
for (variants = TYPE_NEXT_VARIANT (t);
variants;
variants = TYPE_NEXT_VARIANT (variants))
{
/* These are the two fields that check_qualified_type looks at and
are affected by attributes. */
TYPE_ATTRIBUTES (variants) = attrs;
unsigned valign = align;
if (TYPE_USER_ALIGN (variants))
valign = MAX (valign, TYPE_ALIGN (variants));
else
TYPE_USER_ALIGN (variants) = user_align;
SET_TYPE_ALIGN (variants, valign);
TYPE_PACKED (variants) = packed;
if (may_alias)
fixup_may_alias (variants);
}
I think the TYPE_ATTRIBUTES update isn't needed, because
decl_attributes (, attributes, (int) ATTR_FLAG_TYPE_IN_PLACE);
should update the variants already:
984 TYPE_ATTRIBUTES (*anode) = r;
985 /* If this is the main variant, also push the
attributes
986 out to the other variants. */
987 if (*anode == TYPE_MAIN_VARIANT (*anode))
988 {
989 for (tree variant = *anode; variant;
990variant = TYPE_NEXT_VARIANT (variant))
991 {
992 if (TYPE_ATTRIBUTES (variant) == old_attrs)
993 TYPE_ATTRIBUTES (variant)
994 = TYPE_ATTRIBUTES (*anode);
995 else if (!find_same_attribute
996(attr, TYPE_ATTRIBUTES (variant)))
997 TYPE_ATTRIBUTES (variant) = tree_cons
998 (name, args, TYPE_ATTRIBUTES (variant));
999 }
1000}
Seems finish_struct doesn't actually call layout_type on the type variants,
wonder what does that, but I'd think that stuff like TYPE_USER_ALIGN,
TYPE_ALIGN would be finalized when layout_type is performed for those.
TYPE_PACKED is apparently done in
finish_record_layout even for the variants (called from layout_type).
Re: [PATCH v6 1/8] Improve must tail in RTL backend
On Mon, Jun 03, 2024 at 07:02:00PM +0200, Michael Matz wrote: > Hello, > > On Fri, 31 May 2024, Andi Kleen wrote: > > > > I think the ultimate knowledge if a call can or cannot be implemented as > > > tail-call lies within calls.cc/expand_call: It is inherently > > > target and ABI specific how arguments and returns are layed out, how the > > > stack frame is generated, if arguments are or aren't removed by callers > > > or callees and so on; all of that being knowledge that tree-tailcall > > > doesn't have and doesn't want to have. As such tree-tailcall should > > > not be regarded as ultimate truth, and failures of tree-tailcall to > > > recognize something as tail-callable shouldn't matter. > > > > It's not the ultimate truth, but some of the checks it does are not > > duplicated at expand time nor the backend. So it's one necessary pre > > condition with the current code base. > > > > Yes maybe the checks could be all moved, but that's a much larger > > project. > > Hmm. I count six tests in about 25 lines of code in > tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p. > > Are you perhaps worrying about the sibcall discovery itself (i.e. much of > find_tail_calls)? Why would that be needed for musttail? Is that > attribute sometimes applied to calls that aren't in fact sibcall-able? > > One thing I'm worried about is the need for a new sibcall pass at O0 just > for sibcall discovery. find_tail_calls isn't cheap, because it computes > live local variables for the whole function, potentially being quadratic. But the pass could be done only if there is at least one musttail call in a function (remembered in some cfun flag). If people use that attribute, guess they are willing to pay for it. Jakub
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Jakub Jelinek changed: What|Removed |Added CC||mr.bossman075 at gmail dot com --- Comment #13 from Jakub Jelinek --- *** Bug 115332 has been marked as a duplicate of this bug. ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 --- Comment #3 from Jakub Jelinek --- Oops. *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 44268 ***
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268 Jakub Jelinek changed: What|Removed |Added CC||mr.bossman075 at gmail dot com --- Comment #11 from Jakub Jelinek --- *** Bug 115332 has been marked as a duplicate of this bug. ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It behaves exactly as designed. There needs to be an edge in the control flow graph to the label, if there isn't, even when the label is referenced in some & computed value, it can't be validly called and thus the label becomes a "deleted label" and can move anywhere in the function.
Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)
On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote:
> On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote:
> > > @@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_parser *parser, tree
> > > attr_ns)
> > > /* Maybe we don't expect to see any arguments for this attribute.
> > > */
> > > const attribute_spec *as
> > > = lookup_attribute_spec (TREE_PURPOSE (attribute));
> > > -if (as && as->max_length == 0)
> > > +if ((as && as->max_length == 0) || is_attribute_p ("musttail",
> > > attr_id))
> >
> > This shouldn't be necessary with the attribute in the c-attribs table,
> > right? This patch is OK without this hunk and with the comment tweak above.
>
> Yes I will remove it. Also the hunk above can be simplified, we don't
> need the extra case anymore.
>
> But unfortunately there's another problem (sorry I missed that earlier
> but the Linaro bot pointed it out again):
>
> This hunk:
>
> @@ -21085,12 +21085,14 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
> complain, tree in_decl)
> bool op = CALL_EXPR_OPERATOR_SYNTAX (t);
> bool ord = CALL_EXPR_ORDERED_ARGS (t);
> bool rev = CALL_EXPR_REVERSE_ARGS (t);
> - if (op || ord || rev)
> + bool mtc = CALL_EXPR_MUST_TAIL_CALL (t);
> + if (op || ord || rev || mtc)
> if (tree call = extract_call_expr (ret))
> {
> CALL_EXPR_OPERATOR_SYNTAX (call) = op;
> CALL_EXPR_ORDERED_ARGS (call) = ord;
> CALL_EXPR_REVERSE_ARGS (call) = rev;
> + CALL_EXPR_MUST_TAIL_CALL (call) = mtc;
> }
The difference is that CALL_EXPR_MUST_TAIL_CALL is defined as:
#define CALL_EXPR_MUST_TAIL_CALL(NODE) \
(CALL_EXPR_CHECK (NODE)->base.static_flag)
while the others like:
#define CALL_EXPR_ORDERED_ARGS(NODE) \
TREE_LANG_FLAG_3 (CALL_OR_AGGR_INIT_CHECK (NODE))
where
#define CALL_OR_AGGR_INIT_CHECK(NODE) \
TREE_CHECK2 ((NODE), CALL_EXPR, AGGR_INIT_EXPR)
while
#define CALL_EXPR_CHECK(t) TREE_CHECK (t, CALL_EXPR)
(this one is defined in generated tree-check.h).
So, while the CALL_EXPR_REVERSE_ARGS etc. can be used on either
CALL_EXPR or AGGR_INIT_EXPR (the latter is a C++ specific tree code),
CALL_EXPR_MUST_TAIL_CALL is allowed only on CALL_EXPR.
AGGR_INIT_EXPR is used for C++ constructor calls, so I think
they really don't need such a flag, so you could do:
bool mtc = (TREE_CODE (t) == CALL_EXPR
? CALL_EXPR_MUST_TAIL_CALL (t) : false);
if (op || ord || rev || mtc)
...
if (mtc)
CALL_EXPR_MUST_TAIL_CALL (call) = 1;
or something similar.
Or you'd need to define a variant of the CALL_EXPR_MUST_TAIL_CALL
macro for the C++ FE (as CALL_OR_AGGR_INIT_CHECK is C++ FE too)
and use that in the FE and somehow assert it means the same thing
as the middle-end flag except that it can be also used on AGGR_INIT_EXPR.
Jakub
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 58336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58336=edit gcc15-pr108789.patch Untested fix.
[PATCH] rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
Hi!
PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or _instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them back
in full. While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.
So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.
Size-wise in .data sections it is (in bytes):
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.
Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.
When I applied
void
rs6000_init_generated_builtins ()
{
+ bifdata *rs6000_builtin_info_p;
+ tree *rs6000_builtin_info_fntype_p;
+ ovlddata *rs6000_instance_info_p;
+ tree *rs6000_instance_info_fntype_p;
+ ovldrecord *rs6000_overload_info_p;
+ __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+ __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+ __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+ __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+ __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+ #define rs6000_builtin_info rs6000_builtin_info_p
+ #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+ #define rs6000_instance_info rs6000_instance_info_p
+ #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+ #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
Bootstrapped/regtested on powerpc64le-linux and powerpc64-linux (-m32/-m64
testing there), ok for trunk and after a while for release branches?
2024-06-03 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members. Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *. Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_info_fntype and rs6000_instance_info_fntype arrays,
which have GTY markup.
(write_bif_static_init): Adjust for the above changes.
(write_ovld_static_init): Likewise.
(write_init_bif_table): Likewise.
(write_init_ovld_table): Likewise.
* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Likewise.
* config/rs6000/rs6000-c.cc (find_instance): Likewise. Make static.
(altivec_resolve_overloaded_builtin): Adjust for
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 --- Comment #4 from Jakub Jelinek --- Note, fold_builtin_arith_overflow just does tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2, arg0, arg1); tree tgt = save_expr (call); and then uses tgt twice, so it is save_expr decision whether it can be evaluated twice or needs to be done once. And save_expr adds SAVE_EXPR only to the second case when it sees non-const VAR_DECLs, in the first case the arguments are TREE_READONLY and so the ifn call is as well and so causes tree_invariant_p_1 to return true.
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 --- Comment #2 from Jakub Jelinek --- I think this is just invalid testcase. The compiler is told that *a is const, but it is changed through a different lvalue.
Re: [PATCH 17/52] gcn: Remove macros {FLOAT, DOUBLE, LONG_DOUBLE}_TYPE_SIZE
On Mon, Jun 03, 2024 at 05:41:11PM +0800, Kewen.Lin wrote: > > GCN does have some partially implemented support for HFmode ... do I need > > to do something new for that to work? > > For this hook, no, as it's mainly for float, double and long double types (C > language supported non decimal floating > point types). If you are referring to _Float16, I guess you may be > interested in another hook TARGET_FLOATN_MODE > which is for FloatN types. You don't need a new hook for that, the current _FloatNN discovery code is all that is needed. There should be just one mode for the IEEE compliant implementations for each size (there is the _Float16 vs. __bf16 but the latter isn't IEEE compliant, or just IEEE like), so tree.cc should figure everything out together with the current langhooks. Jakub
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324 --- Comment #2 from Jakub Jelinek --- Created attachment 58331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58331=edit gcc15-pr115324.patch Untested fix.
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |12.4
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
|PCH (and maybe GC) of |PCH of rs6000 builtins
|rs6000 builtins broken |broken
Ever confirmed|0 |1
Last reconfirmed||2024-06-03
--- Comment #1 from Jakub Jelinek ---
While for GC everything looks ok, in particular we have
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided so that they cover just the fntype fields in
rs6000_instance_info and rs6000_builtin_info, it causes problems for PCH,
because
PCH saves/restores the whole rs6000_instance_info/rs6000_builtin_info arrays,
which are huge and worse the contain quite a lot of pointers to .rodata/.data
sections besides the tree fntype members.
In struct bifdata it is
const char *GTY((skip(""))) bifname;
...
const char *GTY((skip(""))) attr_string;
and in struct ovlddata
const char *GTY((skip(""))) bifname;
...
ovlddata *GTY((skip(""))) next;
fields. bifname and attr_string members point to string literals, so .rodata
section,
and next is either NULL or _instance_info[RS6000_INST_XXX]
Now, the problem is when cc1/cc1plus etc. are PIEs, the saving is done when
.rodata/.data sections are loaded at one address, but the restoring can be done
when they are loaded at different address, so the pointers are garbage after
PCH restore.
We could extend GTY, to have a similar flag to callback where we'd somehow fix
up those pointers in global GTY roots.
Or I think we can just move the fntype members from those structures to
separate arrays, making the original arrays non-GTY and only GTY the new
*_fntype arrays.
I've implemented the latter, will attach it momentarily.
It seems to decrease the size of .data arrays.
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
On a cross from x86_64 -> powerpc64le it increases .text size in the
_Z30rs6000_init_generated_builtinsv function, but will need to find out if that
is also the case on powerpc64le native where section anchors are used, the
changes in the source are like:
rs6000_overload_info[RS6000_OVLD_VEC_VSUBFP - base].first_instance
-= _instance_info[RS6000_INST_VSUBFP_DEPR1];
+= RS6000_INST_VSUBFP_DEPR1;
- rs6000_instance_info[RS6000_INST_VSUBSBS_DEPR1].fntype
+ rs6000_instance_info_fntype[RS6000_INST_VSUBSBS_DEPR1]
= v16qi_ftype_v16qi_v16qi;
and
- rs6000_builtin_info[RS6000_BIF_CFSTRING].fntype
+ rs6000_builtin_info_fntype[RS6000_BIF_CFSTRING]
= v_ftype_v;
so there is IMO nothing inherently larger.
[Bug target/115324] New: [12/13/14/15 Regression] PCH (and maybe GC) of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
Bug ID: 115324
Summary: [12/13/14/15 Regression] PCH (and maybe GC) of rs6000
builtins broken
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: belegdol at gmail dot com, dan at danny dot cz
Depends on: 104323
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #104323 +++
The PR104323 fix doesn't seem to work with --enable-host-pie.
cat pr104323.h
#include
cat pr104323.c
/* { dg-require-effective-target powerpc_altivec_ok } */
/* { dg-options "-maltivec" } */
#include "pr104323.h"
__vector int a1 = { 100, 200, 300, 400 };
__vector int a2 = { 500, 600, 700, 800 };
__vector int r;
int
main ()
{
r = vec_add (a1, a2);
return 0;
}
./xgcc -B ./ -c pr104323.h -o pr104323.h.gch
./xgcc -B ./ -S pr104323.c
pr104323.c: In function ‘main’:
pr104323.c:13:3: internal compiler error: Segmentation fault
13 | r = vec_add (a1, a2);
| ^
0x5625e2834b83 crash_signal
../../gcc/toplev.cc:319
0x5625e228c56d altivec_resolve_overloaded_builtin(unsigned int, tree_node*,
void*)
../../gcc/config/rs6000/rs6000-c.cc:1997
0x5625e2190392 c_build_function_call_vec(unsigned int, vec const&, tree_node*, vec*,
vec*)
../../gcc/c/c-typeck.cc:3440
0x5625e21c4536 c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.cc:12682
0x5625e21a99a5 c_parser_postfix_expression
../../gcc/c/c-parser.cc:12234
0x5625e21ae60a c_parser_unary_expression
../../gcc/c/c-parser.cc:9894
0x5625e21b01df c_parser_cast_expression
../../gcc/c/c-parser.cc:9735
0x5625e21b04db c_parser_binary_expression
../../gcc/c/c-parser.cc:9503
0x5625e21b1a93 c_parser_conditional_expression
../../gcc/c/c-parser.cc:9198
0x5625e21b2324 c_parser_expr_no_commas
../../gcc/c/c-parser.cc:9111
0x5625e21b23ea c_parser_expr_no_commas
../../gcc/c/c-parser.cc:9154
0x5625e21b2773 c_parser_expression
../../gcc/c/c-parser.cc:12822
0x5625e21b2c57 c_parser_expression_conv
../../gcc/c/c-parser.cc:12862
0x5625e21d5b57 c_parser_statement_after_labels
../../gcc/c/c-parser.cc:7800
0x5625e21a942b c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:7287
0x5625e21d2136 c_parser_compound_statement
../../gcc/c/c-parser.cc:6564
0x5625e21d45af c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:3019
0x5625e21deb73 c_parser_external_declaration
../../gcc/c/c-parser.cc:2048
0x5625e21df5cb c_parser_translation_unit
../../gcc/c/c-parser.cc:1902
0x5625e21df5cb c_parse_file()
../../gcc/c/c-parser.cc:27269
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104323
[Bug 104323] [12 Regression] PCH (and maybe GC) of rs6000 builtins broken
Re: Trying to build libssh
Hi,
you seems to have some non-standard OpenSSL version installed. There
is a patch (already part of master) that detects the FIPS_mode() macro
and gracefully falls back if not found:
https://gitlab.com/libssh/libssh-mirror/-/commit/0d4658740b4a7f94cdbbfaa6d4d7dbc047660d4c
If it will work for you, I will backport it to th 0.10.x branch for a
next release.
Jakub
On Sun, Jun 2, 2024 at 9:11 AM Mikael Petterson
wrote:
>
> Hi,
>
> I am trying to build libssh 0.10.6 from source.
>
> I am using:
>
> git clone https://git.libssh.org/projects/libssh.git && cd libssh && git
> checkout tags/libssh-0.10.6 && \
>
> mkdir build && cd build && \
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE="Release"
> -DWITH_ZLIB=ON -DWITH_GSSAPI=OFF -DWITH_NACL=OFF -DWITH_PCAP=OFF
> -DWITH_SERVER=OFF -DOPENSSL_ROOT_DIR=/usr/local/openssl .. && \
>
> make -j2 && \
>
> make install
>
>
>
>
>
> I get this error:
>
>
> 12.90 -- Build files have been written to: /opt/dev/libssh/build
>
> 13.02 Scanning dependencies of target ssh
>
> 13.06 [ 1%] Building C object src/CMakeFiles/ssh.dir/agent.c.o
>
> 13.06 [ 2%] Building C object src/CMakeFiles/ssh.dir/auth.c.o
>
> 13.44 [ 3%] Building C object src/CMakeFiles/ssh.dir/base64.c.o
>
> 13.59 [ 4%] Building C object src/CMakeFiles/ssh.dir/bignum.c.o
>
> 13.64 [ 5%] Building C object src/CMakeFiles/ssh.dir/buffer.c.o
>
> 13.77 [ 6%] Building C object src/CMakeFiles/ssh.dir/callbacks.c.o
>
> 13.97 [ 7%] Building C object src/CMakeFiles/ssh.dir/channels.c.o
>
> 14.17 [ 8%] Building C object src/CMakeFiles/ssh.dir/client.c.o
>
> 14.49 [ 9%] Building C object src/CMakeFiles/ssh.dir/config.c.o
>
> 15.22 [ 10%] Building C object src/CMakeFiles/ssh.dir/connect.c.o
>
> 15.68 [ 11%] Building C object src/CMakeFiles/ssh.dir/connector.c.o
>
> 15.79 [ 12%] Building C object src/CMakeFiles/ssh.dir/crypto_common.c.o
>
> 15.98 [ 13%] Building C object src/CMakeFiles/ssh.dir/curve25519.c.o
>
> 16.01 [ 13%] Building C object src/CMakeFiles/ssh.dir/dh.c.o
>
> 16.32 [ 14%] Building C object src/CMakeFiles/ssh.dir/ecdh.c.o
>
> 16.41 [ 15%] Building C object src/CMakeFiles/ssh.dir/error.c.o
>
> 16.56 [ 16%] Building C object src/CMakeFiles/ssh.dir/getpass.c.o
>
> 16.65 [ 17%] Building C object src/CMakeFiles/ssh.dir/init.c.o
>
> 16.73 [ 18%] Building C object src/CMakeFiles/ssh.dir/kdf.c.o
>
> 16.83 [ 19%] Building C object src/CMakeFiles/ssh.dir/kex.c.o
>
> 16.96 In file included from /opt/dev/libssh/include/libssh/wrapper.h:28:0,
>
> 16.96 from /opt/dev/libssh/include/libssh/crypto.h:36,
>
> 16.96 from /opt/dev/libssh/include/libssh/dh.h:26,
>
> 16.96 from /opt/dev/libssh/src/kex.c:34:
>
> 16.96 /opt/dev/libssh/src/kex.c: In function 'ssh_client_select_hostkeys':
>
> 16.96 /opt/dev/libssh/include/libssh/libcrypto.h:107:26: error: implicit
> declaration of function 'FIPS_mode' [-Werror=implicit-function-declaration]
>
> 16.96 #define ssh_fips_mode() (FIPS_mode() != 0)
>
> 16.96 ^
>
> 16.96 /opt/dev/libssh/src/kex.c:680:13: note: in expansion of macro
> 'ssh_fips_mode'
>
> 16.96 if (ssh_fips_mode()) {
>
> 16.96 ^
>
> 16.98 [ 20%] Building C object src/CMakeFiles/ssh.dir/known_hosts.c.o
>
> 17.34 [ 21%] Building C object src/CMakeFiles/ssh.dir/knownhosts.c.o
>
> 17.35 cc1: some warnings being treated as errors
>
> 17.37 src/CMakeFiles/ssh.dir/build.make:518: recipe for target
> 'src/CMakeFiles/ssh.dir/kex.c.o' failed
>
> 17.37 make[2]: *** [src/CMakeFiles/ssh.dir/kex.c.o] Error 1
>
> 17.37 make[2]: *** Waiting for unfinished jobs
>
> 17.59 CMakeFiles/Makefile2:203: recipe for target
> 'src/CMakeFiles/ssh.dir/all' failed
>
> 17.60 Makefile:151: recipe for target 'all' failed
>
> 17.60 make[1]: *** [src/CMakeFiles/ssh.dir/all] Error 2
>
> 17.60 make: *** [all] Error 2
>
>
>
>
>
> Any ideas?
>
>
>
> //mike
Re: [PATCH V2] net: qrtr: ns: Ignore ENODEV failures in ns
On Thu, 30 May 2024 16:06:17 +0530 Sarannya S wrote: > -static int service_announce_del(struct sockaddr_qrtr *dest, > +static void service_announce_del(struct sockaddr_qrtr *dest, > struct qrtr_server *srv) nit: please realign the continuation line
Service monitoring in CommuniShift/OpenShift?
I am running a service in Fedora CommuniShift (planning to move it to Fedora production OpenShift instance in case it is relevant). Can anybody please help me understand how to configure some monitoring for it? Is it possible to configure nagios.fedoraproject.org for it? Or is there any other recommended approach? Basically, I would like to have some custom commands (checking if auth tokens are up-to-date, parsing a log file for specific errors, etc) and periodically run them on my deployed container. Or spawning a separate container in my project to run them. If they find any problem, I'd like to be notified via email. Thank you, Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH v2] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
On Sat, Jun 01, 2024 at 09:21:53AM +0100, Jonathan Wakely wrote: > On Fri, 31 May 2024 at 18:43, Alexandre Oliva wrote: > > > > On May 31, 2024, Alexandre Oliva wrote: > > > > >> So either don't change this line at all, or just do a simple > > >> s/__clang__/_GLIBCXX_CLANG/ > > > > > If c++config can be counted on, I'd be happy to do that, but I couldn't > > > tell that it could. > > > > Here's what I've retested on x86_64-linux-gnu and, slightly adjusted for > > gcc-13, on arm-vx7r2. Ok to install? > > OK > > If there's any chance of getting the vxworks system headers fixed to > work with GCC properly, that would be nice. Fixincludes? That seems like the standard way to workaround bugs in system headers on proprietary targets. Jakub
Re: [PATCH v2] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
On Sat, Jun 01, 2024 at 09:21:53AM +0100, Jonathan Wakely wrote: > On Fri, 31 May 2024 at 18:43, Alexandre Oliva wrote: > > > > On May 31, 2024, Alexandre Oliva wrote: > > > > >> So either don't change this line at all, or just do a simple > > >> s/__clang__/_GLIBCXX_CLANG/ > > > > > If c++config can be counted on, I'd be happy to do that, but I couldn't > > > tell that it could. > > > > Here's what I've retested on x86_64-linux-gnu and, slightly adjusted for > > gcc-13, on arm-vx7r2. Ok to install? > > OK > > If there's any chance of getting the vxworks system headers fixed to > work with GCC properly, that would be nice. Fixincludes? That seems like the standard way to workaround bugs in system headers on proprietary targets. Jakub
Bug#1072297: lastlog(8) man page: stray XML markup
Package: login Version: 1:4.13+dfsg1-1+b1 Severity: minor I stumbled upon this: $ man lastlog.8 | grep -w term Having high UIDs can create problems when handling the /var/log/lastlog with external tools. Although the I suppose this XML markup shouldn't be there. -- Jakub Wilk
[Pkg-shadow-devel] Bug#1072297: lastlog(8) man page: stray XML markup
Package: login Version: 1:4.13+dfsg1-1+b1 Severity: minor I stumbled upon this: $ man lastlog.8 | grep -w term Having high UIDs can create problems when handling the /var/log/lastlog with external tools. Although the I suppose this XML markup shouldn't be there. -- Jakub Wilk ___ Pkg-shadow-devel mailing list Pkg-shadow-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel
Re: [PATCH bpf-next 3/8] selftests/bpf: Use bpf_link attachments in test_sockmap
On Thu, May 30, 2024 at 04:45 PM -07, John Fastabend wrote: > Geliang Tang wrote: >> On Mon, 2024-05-27 at 21:36 +0200, Jakub Sitnicki wrote: >> > On Mon, May 27, 2024 at 10:12 AM -07, John Fastabend wrote: >> > > Geliang Tang wrote: [...] >> > > The one advantage of test_sockmap is we can have it run for longer >> > > runs by pushing different options through so might be worth keeping >> > > just for that. >> > > >> > > If you really want links here I'm OK with that I guess just asking. >> > >> > It was me who suggested the switch to bpf_link in reaction to a >> > series >> > of cleanups to prog_type and prog_attach_type submitted by Geliang. >> >> Yes, patches 3-5 address Jakub's suggestion: switching attachments to >> bpf_link. > > OK. Lets just take them the series lgtm. Jakub any other comments? Gave it a run - all looks well. Thanks for the patches. Geliang, is there some MPTCP+sockmap use-case you're working towards?
Re: [PATCH bpf-next 0/8] fixes for test_sockmap
On Thu, May 23, 2024 at 02:49 PM +08, Geliang Tang wrote: > From: Geliang Tang > > This patchset contains some fixes and improvements for test_sockmap. > > 3-5: switching attachments to bpf_link as Jakub suggested in [1]. > 1-2, 6-8: Small fixes. > > [1] > https://lore.kernel.org/bpf/87zfsiw3a3@cloudflare.com/ > > Geliang Tang (8): > selftests/bpf: Fix tx_prog_fd values in test_sockmap > selftests/bpf: Drop duplicate definition of i in test_sockmap > selftests/bpf: Use bpf_link attachments in test_sockmap > selftests/bpf: Replace tx_prog_fd with tx_prog in test_sockmap > selftests/bpf: Drop prog_fd array in test_sockmap > selftests/bpf: Fix size of map_fd in test_sockmap > selftests/bpf: Check length of recv in test_sockmap > selftests/bpf: Drop duplicate bpf_map_lookup_elem in test_sockmap > > .../selftests/bpf/progs/test_sockmap_kern.h | 3 - > tools/testing/selftests/bpf/test_sockmap.c| 101 +- > 2 files changed, 51 insertions(+), 53 deletions(-) Tested-by: Jakub Sitnicki
Re: [PATCH 01/11] OpenMP/PolyInt: Pass poly-int structures by address to OMP libs.
On Fri, May 31, 2024 at 08:45:54AM +0100, Richard Sandiford wrote:
> > When you say same way, do you mean the way SVE ABI defines the rules for
> > SVE types?
>
> No, sorry, I meant that if the choice isn't purely local to a source
> code function, the condition should be something like sizeless_type_p
> (suitably abstracted) rather than POLY_INT_CST_P. That way, the "ABI"
> stays the same regardless of -msve-vector-bits.
There is no ABI, it is how the caller and indirect callee communicate,
but both parts are compiled with the same compiler, so it can choose
differently based on different compiler version etc.
It is effectively simplified:
struct whatever { ... };
void callee (void *x) { struct whatever *w = *x; use *w; }
void caller (void) { struct whatever w; fill in w; ABI_call (callee, ); }
(plus in some cases the callee can also update values and propagate that
back to caller).
In any case, it is a similar "ABI" to e.g. tree-nested.cc communication
between caller and nested callee, how exactly are the variables laid out
in a struct depends on compiler version and whatever it decides, same
compiler then emits both sides.
Jakub
Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog
* Jun MO , 2024-05-31 01:05: And something "off topic". I find there is a char __glibc_reserved[20] variable in the struct utmp, which is commented as "Reserved for future use". Just a brainstorm, if this variable is not currently used, maybe it can be used to solve the Y2038 problem for wtmp? Or, more easily, you could treat the timestamp as unsigned int: https://sourceware.org/cgit/glibc/commit/?id=5361ad3910c257bc "Architectures which use a 32-bit seconds-since-epoch field in struct lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32, rv64, x86-64) switched from a signed to an unsigned type for that field. This allows these fields to store timestamps beyond the year 2038, until the year 2106. Please note that applications are still expected to migrate off the interfaces declared in and (except for login_tty) due to locking and session management problems." -- Jakub Wilk
Re: Y2038-safe replacements for utmp/wtmp and lastlog
* Jun MO , 2024-05-31 01:05: And something "off topic". I find there is a char __glibc_reserved[20] variable in the struct utmp, which is commented as "Reserved for future use". Just a brainstorm, if this variable is not currently used, maybe it can be used to solve the Y2038 problem for wtmp? Or, more easily, you could treat the timestamp as unsigned int: https://sourceware.org/cgit/glibc/commit/?id=5361ad3910c257bc "Architectures which use a 32-bit seconds-since-epoch field in struct lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32, rv64, x86-64) switched from a signed to an unsigned type for that field. This allows these fields to store timestamps beyond the year 2038, until the year 2106. Please note that applications are still expected to migrate off the interfaces declared in and (except for login_tty) due to locking and session management problems." -- Jakub Wilk
Re: Y2038-safe replacements for utmp/wtmp and lastlog
* Jun MO , 2024-05-31 01:05: And something "off topic". I find there is a char __glibc_reserved[20] variable in the struct utmp, which is commented as "Reserved for future use". Just a brainstorm, if this variable is not currently used, maybe it can be used to solve the Y2038 problem for wtmp? Or, more easily, you could treat the timestamp as unsigned int: https://sourceware.org/cgit/glibc/commit/?id=5361ad3910c257bc "Architectures which use a 32-bit seconds-since-epoch field in struct lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32, rv64, x86-64) switched from a signed to an unsigned type for that field. This allows these fields to store timestamps beyond the year 2038, until the year 2106. Please note that applications are still expected to migrate off the interfaces declared in and (except for login_tty) due to locking and session management problems." -- Jakub Wilk
[plasmashell] [Bug 481085] Battery widget in panel doesn't save "show percent" setting
https://bugs.kde.org/show_bug.cgi?id=481085 Jakub changed: What|Removed |Added CC||jjaruszew...@outlook.com --- Comment #10 from Jakub --- Can still reproduce on Plasma 6.0.5 on two different laptops. Now one has this setting permanently disabled (it was a relatively fresh plasma 6 install). And one has this setting permanently enabled (I enabled it back in Plasma 5). Either way changes to this setting does not save the changes to the config file :c -- You are receiving this mail because: You are watching all bug changes.
Re: [PATCH net-next v2] net: mana: Allow variable size indirection table
On Thu, 30 May 2024 17:37:02 +0300 Leon Romanovsky wrote: > Once you are ok with this patch, let me create shared branch for it. > It is -rc1 and Konstantin already submitted some changes to qp.c > https://lore.kernel.org/all/1716366242-558-1-git-send-email-kotara...@linux.microsoft.com/ > > This specific patch applies on top of Konstantin's changes cleanly. Yeah, once it's not buggy shared branch SG! Just to be sure, on top of -rc1, right?
Re: [PATCH net-next v2] net: mana: Allow variable size indirection table
On Tue, 28 May 2024 22:35:55 -0700 Shradha Gupta wrote:
> + save_table = kcalloc(apc->indir_table_sz, sizeof(u32), GFP_KERNEL);
> + if (!save_table)
> + return -ENOMEM;
> +
> if (rxfh->indir) {
> - for (i = 0; i < MANA_INDIRECT_TABLE_SIZE; i++)
> + for (i = 0; i < apc->indir_table_sz; i++)
> if (rxfh->indir[i] >= apc->num_queues)
> return -EINVAL;
leaks save_table
Re: PersistentManager and ClassNotFoundException
Hi Christopher, On Thu, May 30, 2024 at 1:40 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Jakub, > > On 5/30/24 05:25, Jakub Królikowski wrote: > >> Where is your configuration located? It *should* be inside > >> your located in META-INF/context.xml in your web application. > >> If it's in there, then everything it does should be in the context (and > >> ClassLoader) of your web application -- where your classes should be > >> locatable. > >> > >> If you have it anywhere else, it probably won't work the way you expect > >> it to work. > > > > Yes, you are right! Thank you for this hint! > > I have configured in /conf/server.xml. > > And indeed - interestingly, StandardManager, works correctly even there! > > PersistentManager, however, does not. > > After moving the configuration to /META-INF/context.xml, both > > managers work fine. > > It may be worth mentioning this in the documentation: > > > https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html#Persistence_Across_Restarts > > Would you like to provide a documentation patch/PR that works for you? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > I can write a paragraph about how to properly prepare the web service for serialisation and deserialisation, but I need some more time for that, because I see that the PersistentManager behaves differently from the StandardManager and I think it tries to serialise also session attributes, which are not instances of classes that implement java.io.Serializable. I need more time to experiment. Jakub
Re: PersistentManager and ClassNotFoundException
Hello Chris, On Tue, May 28, 2024 at 6:38 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Jakub, > > On 5/24/24 09:31, Jakub Królikowski wrote: > > On Fri, May 24, 2024 at 11:23 AM Mark Thomas wrote: > > > >> Can you provide the simplest web application (with source) that > >> replications the problem? > >> > >> Mark > >> > >> > >> On 23/05/2024 23:45, Jakub Królikowski wrote: > >>> Hi, > >>> > >>> I'm working with Tomcat 10.1. > >>> > >>> When a user starts using the store in my web application, I save the > >>> ShopCart object on the "cart" session attribute. > >>> I want the "cart" attributes to return to the session after restarting > >> the > >>> app. > >>> > >>> > >>> To enable session persistence I added > >>> > >>> > >>> > >>> to the Context. It loads the StandardManager. > >>> > >>> And this works fine - after reload / restart the object "ShopCart" is > >> back > >>> in the session. > >>> > >>> > >>> > >>> I want to experiment with PersistentManager. Tomcat docs says: " > >>> The persistence across restarts provided by the *StandardManager* is a > >>> simpler implementation than that provided by the *PersistentManager*. > If > >>> robust, production quality persistence across restarts is required then > >> the > >>> *PersistentManager* should be used with an appropriate configuration. > >>> > >>> " > >>> > >>> I hope for a Listener of deserialization of the session attributes. > >>> > >>> The new Manager configuration looks like this: > >>> > >>> >>> maxActiveSessions="2" saveOnRestart="true"> > >>> > >>> >>> "c:\tomcat10\sessionperm"/> > >>> > >>> > >>> > >>> But it doesn't work. After restart I get this exception: > >>> > >>> > >>> java.lang.ClassNotFoundException: ShopCart > >>> > >>> at > >>> > >> > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332) > >>> > >>> at > >>> > >> > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144) > >>> > >>> at java.base/java.lang.Class.forName0(Native Method) > >>> > >>> at java.base/java.lang.Class.forName(Class.java:534) > >>> > >>> at java.base/java.lang.Class.forName(Class.java:513) > >>> > >>> at > >>> > >> > org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158) > >>> > >>> at > >>> java.base/java.io > >> .ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061) > >>> > >>> at > >>> java.base/java.io > >> .ObjectInputStream.readClassDesc(ObjectInputStream.java:1927) > >>> > >>> at > >>> java.base/java.io > >> .ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252) > >>> > >>> at > >>> java.base/java.io > >> .ObjectInputStream.readObject0(ObjectInputStream.java:1762) > >>> > >>> at > >>> java.base/java.io > >> .ObjectInputStream.readObject(ObjectInputStream.java:540) > >>> > >>> at > >>> java.base/java.io > >> .ObjectInputStream.readObject(ObjectInputStream.java:498) > >>> > >>> at > >>> > >> > org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198) > >>> > >>> at > >>> > >> > org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831) > >>> > >>> at org.apache.catalina.session.FileStore.load(FileStore.java:203) > >>> > >>> at > >> org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138) > >>> > >>> at > >>> > >> > org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409) > >>> > >>> at > >>> > >> > org.apache.catalina.session.ManagerBase.backgroun
Re: [Intel-wired-lan] [PATCH iwl-next 11/12] idpf: convert header split mode to libeth + napi_build_skb()
On Tue, 28 May 2024 15:48:45 +0200 Alexander Lobakin wrote: > Currently, idpf uses the following model for the header buffers: > > * buffers are allocated via dma_alloc_coherent(); > * when receiving, napi_alloc_skb() is called and then the header is > copied to the newly allocated linear part. > > This is far from optimal as DMA coherent zone is slow on many systems > and memcpy() neutralizes the idea and benefits of the header split. Not > speaking of that XDP can't be run on DMA coherent buffers, but at the > same time the idea of allocating an skb to run XDP program is ill. > Instead, use libeth to create page_pools for the header buffers, allocate > them dynamically and then build an skb via napi_build_skb() around them > with no memory copy. With one exception... > When you enable header split, you except you'll always have a separate accept > header buffer, so that you could reserve headroom and tailroom only > there and then use full buffers for the data. For example, this is how > TCP zerocopy works -- you have to have the payload aligned to PAGE_SIZE. > The current hardware running idpf does *not* guarantee that you'll > always have headers placed separately. For example, on my setup, even > ICMP packets are written as one piece to the data buffers. You can't > build a valid skb around a data buffer in this case. > To not complicate things and not lose TCP zerocopy etc., when such thing > happens, use the empty header buffer and pull either full frame (if it's > short) or the Ethernet header there and build an skb around it. GRO > layer will pull more from the data buffer later. This W/A will hopefully > be removed one day. Hopefully soon, cause it will prevent you from mapping data buffers to user space or using DMABUF memory :(
Re: [Intel-wired-lan] [PATCH iwl-next 01/12] libeth: add cacheline / struct alignment helpers
On Tue, 28 May 2024 15:48:35 +0200 Alexander Lobakin wrote:
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 95a59ac78f82..d0cf9a2d82de 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1155,6 +1155,7 @@ sub dump_struct($$) {
> $members =~ s/\bstruct_group_attr\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
> $members =~ s/\bstruct_group_tagged\s*\(([^,]*),([^,]*),/struct $1
> $2; STRUCT_GROUP(/gos;
> $members =~ s/\b__struct_group\s*\(([^,]*,){3}/STRUCT_GROUP(/gos;
> +$members =~ s/\blibeth_cacheline_group\s*\(([^,]*,)/struct { } $1;
> STRUCT_GROUP(/gos;
> $members =~
> s/\bSTRUCT_GROUP(\(((?:(?>[^)(]+)|(?1))*)\))[^;]*;/$2/gos;
>
> my $args = qr{([^,)]+)};
Having per-driver grouping defines is a no-go.
Do you need the defines in the first place?
Are you sure the assert you're adding are not going to explode
on some weird arch? Honestly, patch 5 feels like a little too
much for a driver..
Re: [Development] Changing Qt's Binary Compatibility policy
Sorry for chiming in uninvited but isn't this how the Qt Online Installer thingy works? I know that with it I can install some prebuilt Qt distribution on my Linux - openSUSE Tumbleweed - and I kinda always assumed that the actual build host could be a different distro. I never really gave it much thought to be honest. Maybe there is some kind of matching mechanism somewhere in there during the download process. -- Best regards / Pozdrawiam serdecznie Narolewski Jakub Software Developer śr., 29 maj 2024 o 21:29 Thiago Macieira napisał(a): > On Wednesday 29 May 2024 00:30:12 GMT-3 Kevin Kofler via Development wrote: > > There is, however, one use case you are overlooking, and that is binaries > > compiled on one distribution and run on another. > > That's not supported at all and that has nothing to do with Qt. Unless the > two > distributions are coordinating and testing each other's binaries, it's not > guaranteed to work and is in fact a recipe for disaster. But if they are > coordinating, then the problem you're talking about doesn't exist. > > Some distributions have adopted the no-direct-external-access support and > others have not. In order to run against a Qt that was compiled with it, > you > must compile your software with it too, otherwise the loader will refuse > to > start your application. > > I don't understand why some distros explicitly disable that support. It > might > be because they wanted to retain compatibility with the negligible amount > of > Qt 6 software that existed before the option was introduced. But now > they're > locked into it for the duration of Qt 6.x. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Principal Engineer - Intel DCAI Fleet Engineering and Quality > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [VOTE] Release Apache Shiro 2.0.1
-1 (non binding) I can see a problem with Apache Karaf 4.4.6 because Karaf contains bouncycastle 1.77 and shiro needs the version 1.78+. Similar problem was reported here https://github.com/apache/shiro/issues/1400. best regards Jakub Jakub On Wed, May 29, 2024 at 8:40 AM Francois Papon wrote: > > +1 (binding) > > regards, > > François > > On 26/05/2024 03:02, le...@flowlogix.com wrote: > > This is a call to vote in favor of releasing Apache Shiro version 2.0.1 > > Maven Staging repo: > https://repository.apache.org/content/repositories/orgapacheshiro-1061 > https://repository.apache.org/content/repositories/orgapacheshiro-1061/org/apache/shiro/shiro-root/2.0.1/shiro-root-2.0.1-source-release.zip > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/shiro/2.0.1 > > Project website (just for informational purposes, not to be voted upon): > http://shiro.apache.org/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Release Notes: > https://github.com/apache/shiro/releases/tag/untagged-2a2fbc26921a12c6ed43 > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 (please include reasoning) >
[clang] [llvm] [AArch64] Add support for Qualcomm Oryon processor (PR #91022)
https://github.com/kuhar updated https://github.com/llvm/llvm-project/pull/91022
>From 8aebe46d7fdd15f02a9716718f53b03056ef0d19 Mon Sep 17 00:00:00 2001
From: Wei Zhao
Date: Fri, 3 May 2024 22:01:58 +
Subject: [PATCH 1/3] [AArch64] Add support for Qualcomm Oryon processor
---
clang/test/Driver/aarch64-oryon-1.c | 19 +
clang/test/Misc/target-invalid-cpu-note.c |4 +-
.../llvm/TargetParser/AArch64TargetParser.h |5 +
llvm/lib/Target/AArch64/AArch64.td|5 +
llvm/lib/Target/AArch64/AArch64Processors.td | 30 +
llvm/lib/Target/AArch64/AArch64SchedOryon.td | 1727 +
llvm/lib/Target/AArch64/AArch64Subtarget.cpp |7 +
llvm/lib/TargetParser/Host.cpp|1 +
llvm/unittests/TargetParser/Host.cpp |3 +
.../TargetParser/TargetParserTest.cpp | 16 +-
10 files changed, 1813 insertions(+), 4 deletions(-)
create mode 100644 clang/test/Driver/aarch64-oryon-1.c
create mode 100644 llvm/lib/Target/AArch64/AArch64SchedOryon.td
diff --git a/clang/test/Driver/aarch64-oryon-1.c
b/clang/test/Driver/aarch64-oryon-1.c
new file mode 100644
index 0..952ba5df74baf
--- /dev/null
+++ b/clang/test/Driver/aarch64-oryon-1.c
@@ -0,0 +1,19 @@
+// RUN: %clang -target aarch64 -mcpu=oryon-1 -### -c %s 2>&1 | FileCheck
-check-prefix=Phoenix %s
+// RUN: %clang -target aarch64 -mlittle-endian -mcpu=oryon-1 -### -c %s 2>&1 |
FileCheck -check-prefix=Phoenix %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mcpu=oryon-1 -### -c %s
2>&1 | FileCheck -check-prefix=Phoenix %s
+// RUN: %clang -target aarch64 -mtune=oryon-1 -### -c %s 2>&1 | FileCheck
-check-prefix=Phoenix-TUNE %s
+// RUN: %clang -target aarch64 -mlittle-endian -mtune=oryon-1 -### -c %s 2>&1
| FileCheck -check-prefix=Phoenix-TUNE %s
+// RUN: %clang -target aarch64_be -mlittle-endian -mtune=oryon-1 -### -c %s
2>&1 | FileCheck -check-prefix=Phoenix-TUNE %s
+// Phoenix: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu"
"oryon-1" "-target-feature" "+v8.6a"
+// Phoenix-TUNE: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu"
"generic"
+
+// RUN: %clang -target arm64 -mcpu=oryon-1 -### -c %s 2>&1 | FileCheck
-check-prefix=ARM64-Phoenix %s
+// RUN: %clang -target arm64 -mlittle-endian -mcpu=oryon-1 -### -c %s 2>&1 |
FileCheck -check-prefix=ARM64-Phoenix %s
+// RUN: %clang -target arm64 -mtune=oryon-1 -### -c %s 2>&1 | FileCheck
-check-prefix=ARM64-Phoenix-TUNE %s
+// RUN: %clang -target arm64 -mlittle-endian -mtune=oryon-1 -### -c %s 2>&1 |
FileCheck -check-prefix=ARM64-Phoenix-TUNE %s
+// ARM64-Phoenix: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "oryon-1"
"-target-feature" "+v8.6a"
+// ARM64-Phoenix-TUNE: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu"
"generic"
+
+// RUN: %clang -target aarch64 -mcpu=oryon-1 -mtune=cortex-a53 -### -c %s 2>&1
| FileCheck -check-prefix=MCPU-MTUNE-Phoenix %s
+// RUN: %clang -target aarch64 -mtune=cortex-a53 -mcpu=oryon-1 -### -c %s
2>&1 | FileCheck -check-prefix=MCPU-MTUNE-Phoenix %s
+// MCPU-MTUNE-Phoenix: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu"
"oryon-1"
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
index 768b243b04e3a..a71ebd6a023e7 100644
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ b/clang/test/Misc/target-invalid-cpu-note.c
@@ -5,11 +5,11 @@
// RUN: not %clang_cc1 -triple arm64--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix AARCH64
// AARCH64: error: unknown target CPU 'not-a-cpu'
-// AARCH64-NEXT: note: valid target CPU values are: cortex-a34, cortex-a35,
cortex-a53, cortex-a55, cortex-a510, cortex-a520, cortex-a520ae, cortex-a57,
cortex-a65, cortex-a65ae, cortex-a72, cortex-a73, cortex-a75, cortex-a76,
cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae, cortex-a78c, cortex-a710,
cortex-a715, cortex-a720, cortex-a720ae, cortex-r82, cortex-r82ae, cortex-x1,
cortex-x1c, cortex-x2, cortex-x3, cortex-x4, neoverse-e1, neoverse-n1,
neoverse-n2, neoverse-n3, neoverse-512tvb, neoverse-v1, neoverse-v2,
neoverse-v3, neoverse-v3ae, cyclone, apple-a7, apple-a8, apple-a9, apple-a10,
apple-a11, apple-a12, apple-a13, apple-a14, apple-a15, apple-a16, apple-a17,
apple-m1, apple-m2, apple-m3, apple-s4, apple-s5, exynos-m3, exynos-m4,
exynos-m5, falkor, saphira, kryo, thunderx2t99, thunderx3t110, thunderx,
thunderxt88, thunderxt81, thunderxt83, tsv110, a64fx, carmel, ampere1,
ampere1a, ampere1b, cobalt-100, grace{{$}}
+// AARCH64-NEXT: note: valid target CPU values are: cortex-a34, cortex-a35,
cortex-a53, cortex-a55, cortex-a510, cortex-a520, cortex-a520ae, cortex-a57,
cortex-a65, cortex-a65ae, cortex-a72, cortex-a73, cortex-a75, cortex-a76,
cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae, cortex-a78c, cortex-a710,
cortex-a715, cortex-a720, cortex-a720ae, cortex-r82, cortex-r82ae, cortex-x1,
cortex-x1c, cortex-x2, cortex-x3, cortex-x4, neoverse-e1, neoverse-n1,
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #18 from Jakub Jelinek --- (In reply to Natalie Perlin from comment #17) > Brief note on the errors is below. Does it need to be submitted as a > separate ticket/different bug? Yes. > I'd prepare a preprocessed file where the error occurs. Just try -freport-bug, if that works, upload what it prepares, otherwise follow https://gcc.gnu.org/bugs/
Re: [patch] libgomp: Enable USM for some nvptx devices
On Wed, May 29, 2024 at 08:20:01AM +0200, Tobias Burnus wrote:
> + if (num_devices > 0
> + && (omp_requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_MEMORY))
> +for (int dev = 0; dev < num_devices; dev++)
> + {
> + int pi;
> + CUresult r;
> + r = CUDA_CALL_NOCHECK (cuDeviceGetAttribute, ,
> + CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS,
> + dev);
Formatting nit, the CU_DEVICE_... should be below cuDeviceGetAttribute,
I think it fits like that (if it wouldn't one could use a temporary
variable).
Otherwise LGTM.
Jakub
Re: [patch] libgomp: Enable USM for AMD APUs and MI200 devices
On Wed, May 29, 2024 at 02:15:07PM +0200, Tobias Burnus wrote:
> + bool b;
> + hsa_status_t status;
> + status = hsa_fns.hsa_system_get_info_fn (
> + HSA_AMD_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT, );
> + if (status != HSA_STATUS_SUCCESS)
> + GOMP_PLUGIN_error (
> + "HSA_AMD_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT failed");
Formatting, the (s at the end of lines look terrible.
In the first case, perhaps using a temporary would help,
hsa_system_info_t arg = HSA_AMD_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT;
status = hsa_fns.hsa_system_get_info_fn (arg, );
(or use something else instead of arg, as long as its short), while in the
second
GOMP_PLUGIN_error ("HSA_AMD_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT "
"failed");
will do.
Other than that LGTM.
Jakub
