from:"Jakub"

On Tue, May 07, 2024 at 10:37:55AM +0800, HAO CHEN GUI wrote:
>   The former patch adds isfinite optab for __builtin_isfinite.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> 
>   Thus the builtin might not be folded at front end. The range op for
> isfinite is needed for value range analysis. This patch adds them.
> 
>   Compared to last version, this version fixes a typo.
> 
>   Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> Value Range: Add range op for builtin isfinite
> 
> The former patch adds optab for builtin isfinite. Thus builtin isfinite might
> not be folded at front end.  So the range op for isfinite is needed for value
> range analysis.  This patch adds range op for builtin isfinite.
> 
> gcc/
>   * gimple-range-op.cc (class cfn_isfinite): New.
>   (op_cfn_finite): New variables.
>   (gimple_range_op_handler::maybe_builtin_call): Handle
>   CFN_BUILT_IN_ISFINITE.
> 
> gcc/testsuite/
>   * gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c: New test.

BUILT_IN_ISFINITE is just one of many BUILT_IN_IS... builtins,
would be nice to handle the others as well.

E.g. isnormal/isnan/isinf, fpclassify etc.

Note, the man page says for e.g. isnormal that it returns nonzero or zero,
but in reality I think we implement it always inline and can check if
it always returns [0,1].
Some others like isinf return [-1,1] though I think and fpclassify
returns union of all the passed int values.

Jakub

[Bug 2063358] Re: Kodi from Debian (20.5) crashes when running addons due to Python 3.12

2024-05-14 Thread Jakub Klos

I did the same, although I have patched only the kodi.bin manually
The segfault is something that Kodi suffers from. I wouldn't be worried about 
it, not a Ubuntu issue I guess.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063358

Title:
  Kodi from Debian (20.5) crashes when running addons due to Python 3.12

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kodi/+bug/2063358/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH] [testsuite] Fix gcc.dg/pr115066.c fail on aarch64

On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
> 
> This happens because we expect to match:
> ...
> .byte   0xb # Define macro strx
> ...
> but instead we get:
> ...
> .byte   0xb // Define macro strx
> ...
> 
> Fix this by not explicitly matching the comment marker.
> 
> Tested on aarch64 and x86_64.
> 
> gcc/testsuite/ChangeLog:
> 
> 2024-05-14  Tom de Vries  
> 
> * gcc.dg/pr115066.c: Don't match comment marker.
> ---
>  gcc/testsuite/gcc.dg/pr115066.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/pr115066.c b/gcc/testsuite/gcc.dg/pr115066.c
> index 645757df209..a7e98500160 100644
> --- a/gcc/testsuite/gcc.dg/pr115066.c
> +++ b/gcc/testsuite/gcc.dg/pr115066.c
> @@ -2,7 +2,7 @@
>  /* { dg-skip-if "split DWARF unsupported" { hppa*-*-hpux* powerpc*-ibm-aix* 
> *-*-darwin* } } */
>  /* { dg-options "-gsplit-dwarf -g3 -dA -gdwarf-4" } */
>  /* { dg-final { scan-assembler-times {\.section\t"?\.debug_macro} 1 } } */
> -/* { dg-final { scan-assembler-not {\.byte\t0x5\t# Define macro strp} } } */
> -/* { dg-final { scan-assembler {\.byte\t0xb\t# Define macro strx} } } */
> +/* { dg-final { scan-assembler-not {\.byte\t0x5\t.* Define macro strp} } } */
> +/* { dg-final { scan-assembler {\.byte\t0xb\t.* Define macro strx} } } */

Actually, perhaps better use [^\n\r]* instead of .*
You don't want to match the comment on a different line.

Jakub

Re: [PATCH] [testsuite] Fix gcc.dg/pr115066.c fail on aarch64

On Tue, May 14, 2024 at 03:47:46PM +0200, Tom de Vries wrote:
> On aarch64, I get this failure:
> ...
> FAIL: gcc.dg/pr115066.c scan-assembler \\.byte\\t0xb\\t# Define macro strx
> ...
> 
> This happens because we expect to match:
> ...
> .byte   0xb # Define macro strx
> ...
> but instead we get:
> ...
> .byte   0xb // Define macro strx
> ...
> 
> Fix this by not explicitly matching the comment marker.
> 
> Tested on aarch64 and x86_64.
> 
> gcc/testsuite/ChangeLog:
> 
> 2024-05-14  Tom de Vries  
> 
> * gcc.dg/pr115066.c: Don't match comment marker.
> ---
>  gcc/testsuite/gcc.dg/pr115066.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Ok.

Jakub

Re: [PATCH net-next v10 2/3] net: gro: move L3 flush checks to tcp_gro_receive and udp_gro_receive_segment

2024-05-14 Thread Jakub Kicinski

On Tue, 14 May 2024 14:13:21 +0200 Geert Uytterhoeven wrote:
> On Thu, May 9, 2024 at 9:09 PM Richard Gobert  
> wrote:
> > {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> > iph->id, ...) against all packets in a loop. These flush checks are used in
> > all merging UDP and TCP flows.
> >
> > These checks need to be done only once and only against the found p skb,
> > since they only affect flush and not same_flow.
> >
> > This patch leverages correct network header offsets from the cb for both
> > outer and inner network headers - allowing these checks to be done only
> > once, in tcp_gro_receive and udp_gro_receive_segment. As a result,
> > NAPI_GRO_CB(p)->flush is not used at all. In addition, flush_id checks are
> > more declarative and contained in inet_gro_flush, thus removing the need
> > for flush_id in napi_gro_cb.
> >
> > This results in less parsing code for non-loop flush tests for TCP and UDP
> > flows.
> >
> > To make sure results are not within noise range - I've made netfilter drop
> > all TCP packets, and measured CPU performance in GRO (in this case GRO is
> > responsible for about 50% of the CPU utilization).
> >
> > perf top while replaying 64 parallel IP/TCP streams merging in GRO:
> > (gro_receive_network_flush is compiled inline to tcp_gro_receive)
> > net-next:
> > 6.94% [kernel] [k] inet_gro_receive
> > 3.02% [kernel] [k] tcp_gro_receive
> >
> > patch applied:
> > 4.27% [kernel] [k] tcp_gro_receive
> > 4.22% [kernel] [k] inet_gro_receive
> >
> > perf top while replaying 64 parallel IP/IP/TCP streams merging in GRO (same
> > results for any encapsulation, in this case inet_gro_receive is top
> > offender in net-next)
> > net-next:
> > 10.09% [kernel] [k] inet_gro_receive
> > 2.08% [kernel] [k] tcp_gro_receive
> >
> > patch applied:
> > 6.97% [kernel] [k] inet_gro_receive
> > 3.68% [kernel] [k] tcp_gro_receive
> >
> > Signed-off-by: Richard Gobert   
> 
> Thanks for your patch, which is now commit 4b0ebbca3e167976 ("net: gro:
> move L3 flush checks to tcp_gro_receive and udp_gro_receive_segment")
> in net-next/main (next-20240514).
> 
> nore...@ellerman.id.au reports build failures on m68k, e.g.
> http://kisskb.ellerman.id.au/kisskb/buildresult/15168903/
> 
> net/core/gro.c: In function ‘dev_gro_receive’:
> ././include/linux/compiler_types.h:460:38: error: call to
> ‘__compiletime_assert_654’ declared with attribute error: BUILD_BUG_ON
> failed: !IS_ALIGNED(offsetof(struct napi_gro_cb, zeroed), sizeof(u32))

Hi Richard, any chance of getting this fixed within the next 2 hours?
I can't send the net-next PR if it doesn't build on one of the arches..

Re: [PATCH] [debug] Fix dwarf v4 .debug_macro.dwo

On Tue, May 14, 2024 at 01:35:30PM +0200, Tom de Vries wrote:
> Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and 
> -g3:
> ...
> $ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
> ...
> 
> In section .debug_macro.dwo, we have:
> ...
> .Ldebug_macro0:
> .value  0x4 # DWARF macro version number
> .byte   0x2 # Flags: 32-bit, lineptr present
> .long   .Lskeleton_debug_line0
> .byte   0x3 # Start new file
> .uleb128 0  # Included from line number 0
> .uleb128 0x1# file /data/vries/hello.c
> .byte   0x5 # Define macro strp
> .uleb128 0  # At line number 0
> .uleb128 0x1d0  # The macro: "__STDC__ 1"
> ...
> 
> Given that we use a DW_MACRO_define_strp, we'd expect 0x1d0 to be an
> offset into a .debug_str.dwo section.
> 
> But in fact, 0x1d0 is an index into the string offset table in
> .debug_str_offsets.dwo:
> ...
> .long   0x34f0  # indexed string 0x1d0: __STDC__ 1
> ...
> 
> Add asserts that catch this inconsistency, and fix this by using
> DW_MACRO_define_strx instead.
> 
> Tested on x86_64.
> 
> PR debug/115066

ChangeLog entry is missing.

Otherwise LGTM.

Jakub

Re: elog/ereport VS misleading backtrace_function function address

2024-05-14 Thread Jakub Wartak

Hi Peter!

On Sun, May 12, 2024 at 10:33 PM Peter Eisentraut  wrote:
>
> On 07.05.24 09:43, Jakub Wartak wrote:
> > NOTE: in case one will be testing this: one cannot ./configure with
> > --enable-debug as it prevents the compiler optimizations that actually
> > end up with the ".cold" branch optimizations that cause backtrace() to
> > return the wrong address.
>
> Is that configuration useful?  If you're interested in backtraces,
> wouldn't you also want debug symbols?

The use case here is that backtrace_functions is unreliable when we
ask customers on production builds to use it (so it's useful not just
for local tests)

> Don't production builds use debug
> symbols nowadays as well?

Reality is apparently mixed,at least from what I have checked :
- all RHEL 7.x/8.x (PGDG and our forks) do NOT come with
--enable-debug according to pg_config.
- on Debian 11/12 PGDG does come with --enable-debug

> >> I recall speculating about whether we could somehow invoke gdb
> >> to get a more comprehensive and accurate backtrace, but I don't
> >> really have a concrete idea how that could be made to work.
> > Oh no, I'm more about micro-fix rather than doing some bigger
> > revolution. The patch simply adds this one instruction in macro, so
> > that now backtrace_functions behaves better:
> >
> > 0x00773d28 <+105>:   call   0x79243f 
> > 0x00773d2d <+110>:   movzbl -0x12(%rbp),%eax  << this ends
> > up being added by the patch
> > 0x00773d31 <+114>:   call   0xdc1a0 
> >
> > I'll put that as for PG18 in CF, but maybe it could be backpatched too
> > - no hard opinion on that (I don't see how that ERROR/FATAL path could
> > cause any performance regressions)
>
> I'm missing a principled explanation of what this does.  I just see that
> it sprinkles some no-op code to make this particular thing work a bit
> differently, but this might just behave differently with the next
> compiler next year.  I'd like to see a bit more of an abstract
> explanation of what is happening here.

OK I'll try to explain using assembly, but I'm not an expert on this.
Let's go to the 1st post, assume we run with backtrace_function set:

get_collation_isdeterministic()  0x5c7680 to 0x5c76c1:
   might jump(!) to 0x14c686 
   note the two completely different address ranges (hot and separate cold)
   it's because of 913ec71d682 that added the cold branches
optimization via pg_attribute_cold to errstart_cold

Dump of assembler code for function get_collation_isdeterministic:
Address range 0x5c7680 to 0x5c76c1:
   0x005c7680 <+0>: push   %rbp
[..]
   0x005c7694 <+20>:call   0x5d63b0 
   0x005c7699 <+25>:test   %rax,%rax
   0x005c769c <+28>:je 0x14c686

[..]
   0x005c76b3 <+51>:call   0x5d6430 
   0x005c76b8 <+56>:mov%r12d,%eax
   0x005c76bb <+59>:mov-0x8(%rbp),%r12
   0x005c76bf <+63>:leave
   0x005c76c0 <+64>:ret
Address range 0x14c686 to 0x14c6bb:
// note here that the last
instruction is 0x14c6b6 not 0x14c6bb(!)
// note this cold path also has no
frame pointer setup
   0x0014c686 <-4698106>:   xor%esi,%esi
   0x0014c688 <-4698104>:   mov$0x15,%edi
   0x0014c68d <-4698099>:   call   0x14ec86 
   0x0014c692 <-4698094>:   mov%r12d,%esi
   0x0014c695 <-4698091>:   lea0x5028dc(%rip),%rdi
   # 0x64ef78
   0x0014c69c <-4698084>:   xor%eax,%eax
   0x0014c69e <-4698082>:   call   0x5df320 
   0x0014c6a3 <-4698077>:   lea0x6311a6(%rip),%rdx
   # 0x77d850 <__func__.34>
   0x0014c6aa <-4698070>:   mov$0x440,%esi
   0x0014c6af <-4698065>:   lea0x630c8a(%rip),%rdi
   # 0x77d340
   0x0014c6b6 <-4698058>:   call   0x5df100 
End of assembler dump.

so it's
get_collation_isdeterministic() ->
get_collation_isdeterministic.cold() [but not real function ->
no proper fp/stack?] ->
.. ->
errfinish() ->
set_backtrace() // just builds and appends string
using backtrace()/backtrace_functions()/backtrace_symbol_list().
prints/logs, finishes

It seems that the thing is that the limited GNU libc
backtrace_symbol_list() won't resolve the 0x14c6b6..0x14c6bb to the
"get_collation_isdeterministic[.cold]" symbol name and it will just
simply put 0x14c6bb in that the text asm. It's wrong and it is
confusing:

2024-03-27 14:39:13.065 CET [12899] postgres(a

Re: tutorial/example sftp in non blocking mode

2024-05-14 Thread Jakub Jelen

Hi.
The naming is hard. The sftp_async_read was mostly PoC API, but not to
support non-blocking operation, but asynchronous file transfer (that
means having several in-flight requests instead of busily waiting for
the first one to arrive). This was deprecated in favor of the
sftp_aio_* API as described in the tutorial, which should be available
in the next release due in coming months so if you have some feedback,
it would be hugely appreciated:

https://api.libssh.org/master/libssh_tutor_sftp_aio.html

As already mentioned, the nonblocking operation of SFTP is still not
supported. As far as I can see, it would need to rewrite all of the
sftp functions to support returning SSH_AGAIN instead of waiting,
possibly with some API changes as some of the functions do not return
status, but just the allocated objects.

Jakub

On Tue, May 14, 2024 at 12:50 AM  wrote:
>
> On Mon, 2024-05-13 at 18:15 -0400, reid.thomp...@crunchydata.com wrote:
> > On Mon, 2024-05-13 at 11:50 -0700, Norm Green wrote:
> > > sftp is broken in nonblocking mode. Only ssh works.
> > >
> > > See: https://gitlab.com/libssh/libssh-mirror/-/issues/58
> > >
> > > Norm Green
> > >
> > >
> > Thanks,
> >
> > so at this time, sftp is blocking only?
> >
> > And it looks like sftp_async_read* have been deprecated.
>
> So, I want to follow up on this, it appears that sftp_async_read* have been
> marked as deprecated, but the sftp tutorial still has a section describing
> non-blocking asynchronous reading via this mechanism.
> Is this method broken, or just deprecated in anticipation of a better
> implementation in the future?
>
> >
> > Looks like there may be work going on in master to support non-
> > blocking?
> >
> > Reid
>
>
>

Re: [PATCH net-next] net: mana: Enable MANA driver on ARM64 with 4K page size

On Mon, 13 May 2024 20:50:37 + Haiyang Zhang wrote:
> From the document, it can be:
> "ARM cores support both modes, but are most commonly used in, and typically 
> default to little-endian mode. Most Linux distributions for ARM tend to be 
> little-endian only." 
> https://developer.arm.com/documentation/den0042/a/Coding-for-Cortex-R-Processors/Endianness
> 
> MANA driver doesn't support big endian.

Alright, but please prioritize at least adding the 64k page support.
Linux drivers are supposed to be as platform independent as possible.
If you use the right APIs you shouldn't have to worry about the endian
or the page size.

Re: [PATCH net-next v9 00/14] Device Memory TCP

On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote:
> Device Memory TCP

Sorry Mina, this is too big to apply during the merge window :(
-- 
pw-bot: defer

Re: [PATCH net-next v9 00/14] Device Memory TCP

On Fri, 10 May 2024 16:21:11 -0700 Mina Almasry wrote:
> Device Memory TCP

Sorry Mina, this is too big to apply during the merge window :(
-- 
pw-bot: defer

Re: [PATCH net-next] net: mana: Enable MANA driver on ARM64 with 4K page size

On Mon, 13 May 2024 13:29:01 -0700 Haiyang Zhang wrote:
> - depends on PCI_MSI && X86_64
> + depends on PCI_MSI
> + depends on X86_64 || (ARM64 && !CPU_BIG_ENDIAN && ARM64_4K_PAGES)

Can ARM64 be big endian?

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

2024-05-13 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115073

--- Comment #3 from Jakub Jelinek  ---
Or another option is to use C23 , that is well defined for all
values.
But you need recent glibc (2.39 snapshots or 2.40) & gcc (14) for that.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

2024-05-13 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115073

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is misunderstanding of what C[LT]Z_DEFINED_VALUE_AT_ZERO is.
The builtin has always UB on zero.
If you want to define it for zero, use x ? __builtin_clz (x) : 32 (and the
like) or
__builtin_clzg (x, 32) in the source.
C[LT]Z_DEFINED_VALUE_AT_ZERO returning 2 then makes sure the compiler can fold
those conditionals or builtins into .CLZ internal calls with 2 arguments which
makes it well defined for all inputs.

[Bug 2063332] Re: Ubuntu 24.04 Wayland and Qt5 (regression - worked in Ubuntu 22.04)

2024-05-13 Thread Jakub Klos

I have tested it both on the real DE and also VM. Created a new account
in VM (no settings adjustments whatsoever) and still it does not catch
those shortcuts.

I wouldn't mind the decorations but the shortcuts issue is weird.
Especially, if it works for you.

Btw. your tester app has correct decorations compared to DC (Double
Commander) but I wouldn't be worried about it.

So far I am running the important apps with "xcb" and I am satisfied as all 
works. \
Thank you

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063332

Title:
  Ubuntu 24.04 Wayland and Qt5 (regression - worked in Ubuntu 22.04)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/2063332/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[gcc r13-8764] Manually add ChangeLog entries for various commits from 2024-05-09.

2024-05-13 Thread Jakub Jelinek via Gcc-cvs

https://gcc.gnu.org/g:2e353c687dbd343ce592c5ec089774b2c699798a

commit r13-8764-g2e353c687dbd343ce592c5ec089774b2c699798a
Author: Jakub Jelinek 
Date:   Mon May 13 15:09:04 2024 +0200

Manually add ChangeLog entries for various commits from 2024-05-09.

Diff:
---
 gcc/analyzer/ChangeLog  | 84 +
 gcc/jit/ChangeLog   |  8 +
 gcc/testsuite/ChangeLog | 79 ++
 3 files changed, 171 insertions(+)

diff --git a/gcc/analyzer/ChangeLog b/gcc/analyzer/ChangeLog
index 5f1171c0da89..d3a520c19848 100644
--- a/gcc/analyzer/ChangeLog
+++ b/gcc/analyzer/ChangeLog
@@ -7,6 +7,19 @@
(register_sanitizer_builtins): New.
(register_known_functions): Call register_sanitizer_builtins.
 
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2024-03-27  David Malcolm  
+
+   PR analyzer/114473
+   * call-summary.cc
+   (call_summary_replay::convert_svalue_from_summary): Assert that
+   the types match.
+   (call_summary_replay::convert_region_from_summary): Likewise.
+   (call_summary_replay::convert_region_from_summary_1): Add missing
+   cast for the deref of RK_SYMBOLIC case.
+
 2024-05-09  David Malcolm  
 
PR analyzer/109251
@@ -23,6 +36,19 @@
(kf_va_arg::impl_call_pre): Pass arg_sval to
va_arg_compatible_types_p.
 
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2024-01-31  David Malcolm  
+   PR analyzer/113253
+   * region-model.cc (region_model::on_stmt_pre): Add gcc_unreachable
+   for debug statements.
+   * state-purge.cc
+   (state_purge_per_ssa_name::state_purge_per_ssa_name): Skip any
+   debug stmts in the FOR_EACH_IMM_USE_FAST list.
+   * supergraph.cc (supergraph::supergraph): Don't add debug stmts
+   to the supernodes.
+
 2024-05-09  David Malcolm  
 
PR analyzer/112969
@@ -58,6 +84,64 @@
(concrete_binding::is_deleted): Likewise.
(concrete_binding::is_empty): Likewise.
 
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2023-08-03  David Malcolm  
+
+   PR analyzer/110882
+   * region.cc (int_size_in_bits): Fail on zero-sized types.
+
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2023-07-19  David Malcolm  
+
+   PR analyzer/110700
+   * region-model-manager.cc
+   (region_model_manager::get_or_create_int_cst): Assert that we have
+   an integral or pointer type.
+   * sm-taint.cc (taint_state_machine::check_for_tainted_divisor):
+   Don't check non-integral types.
+
+2024-05-09  Tim Lange  
+
+   Backported from master:
+   2023-06-09  Tim Lange  
+
+   PR analyzer/109577
+   * constraint-manager.cc (class sval_finder): Visitor to find
+   childs in svalue trees.
+   (constraint_manager::sval_constrained_p): Add new function to
+   check whether a sval might be part of an constraint.
+   * constraint-manager.h: Add sval_constrained_p function.
+   * region-model.cc (class size_visitor): Reverse behavior to not
+   emit a warning on not explicitly considered cases.
+   (region_model::check_region_size):
+   Adapt to size_visitor changes.
+
+2024-05-09  David Malcolm 
+
+   Backported from master:
+   2023-06-09  David Malcolm  
+
+   PR analyzer/110112
+   * region-model.cc (region_model::get_initial_value_for_global):
+   Move code to region::calc_initial_value_at_main.
+   * region.cc (region::get_initial_value_at_main): New function.
+   (region::calc_initial_value_at_main): New function, based on code
+   in region_model::get_initial_value_for_global.
+   (region::region): Initialize m_cached_init_sval_at_main.
+   (decl_region::get_svalue_for_constructor): Add a cache, splitting
+   out body to...
+   (decl_region::calc_svalue_for_constructor): ...this new function.
+   * region.h (region::get_initial_value_at_main): New decl.
+   (region::calc_initial_value_at_main): New decl.
+   (region::m_cached_init_sval_at_main): New field.
+   (decl_region::decl_region): Initialize m_ctor_svalue.
+   (decl_region::calc_svalue_for_constructor): New decl.
+   (decl_region::m_ctor_svalue): New field.
+
 2023-07-27  Release Manager
 
* GCC 13.2.0 released.
diff --git a/gcc/jit/ChangeLog b/gcc/jit/ChangeLog
index 986c831a2729..07708072688f 100644
--- a/gcc/jit/ChangeLog
+++ b/gcc/jit/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-09  Vibhav Pant  
+
+   Backported from master:
+   2023-10-25  Vibhav Pant  
+
+   * jit-recording.cc (recording::global::write_to_dump): Fix
+   dump of string literal initializers.
+
 2024-04-05  Iain Sandoe  
 
Backported from master:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 23a89209aeb7..878fb8f22549 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -9,6 +9,14

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

2024-05-13 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Tom de Vries from comment #1)
> Looking at the source code, I wonder if this would fix it:
> ...
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index eedb13bb069..045858bf638 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -29045,7 +29045,7 @@ output_macinfo_op (macinfo_entry *ref)
> && !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
> && (debug_str_section->common.flags & SECTION_MERGE) != 0)
>   {
> -   if (dwarf_split_debug_info && dwarf_version >= 5)
> +   if (dwarf_split_debug_info && (!dwarf_strict || dwarf_version >= 5))
>   ref->code = ref->code == DW_MACINFO_define
>   ? DW_MACRO_define_strx : DW_MACRO_undef_strx;
> else
> ...

Just make it if (dwarf_split_debug_info) then?
I mean, this whole code is guarded with
  if ((!dwarf_strict || dwarf_version >= 5)
  && ...)

Re: [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

2024-05-13 Thread Jakub Jelinek

On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote:
> > 2024-05-09  Jakub Jelinek  
> > Jason Merrill  
> > 
> > PR lto/113208
> > * cp-tree.h (maybe_optimize_cdtor): Remove.
> > * decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
> > for implicit instantiations of maybe in charge ctors/dtors
> > declared inline.
> > (import_export_decl): Don't call maybe_optimize_cdtor.
> > (c_parse_final_cleanups): Formatting fixes.
> > * optimize.cc (can_alias_cdtor): Adjust condition, for
> > HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even
> > if not DECL_INTERFACE_KNOWN.
> 
> > --- gcc/cp/optimize.cc.jj   2024-04-25 20:33:30.771858912 +0200
> > +++ gcc/cp/optimize.cc  2024-05-09 17:10:23.920478922 +0200
> > @@ -220,10 +220,8 @@ can_alias_cdtor (tree fn)
> > gcc_assert (DECL_MAYBE_IN_CHARGE_CDTOR_P (fn));
> > /* Don't use aliases for weak/linkonce definitions unless we can put 
> > both
> >symbols in the same COMDAT group.  */
> > -  return (DECL_INTERFACE_KNOWN (fn)
> > - && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
> > - && (!DECL_ONE_ONLY (fn)
> > - || (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
> > +  return (DECL_WEAK (fn) ? (HAVE_COMDAT_GROUP && DECL_ONE_ONLY (fn))
> > +: (DECL_INTERFACE_KNOWN (fn) && !DECL_ONE_ONLY (fn)));
> 
> Hmm, would
> 
> (DECL_ONE_ONLY (fn) ? HAVE_COMDAT_GROUP
>  : (DECL_INTERFACE_KNOWN (fn) && !DECL_WEAK (fn)))
> 
> make sense instead?  I don't think DECL_WEAK is necessary for COMDAT.

I think it isn't indeed necessary for COMDAT, although e.g. comdat_linkage
will not call make_decl_one_only if !flag_weak.

But I think it is absolutely required for the alias cdtor optimization
in question, because otherwise it would be an ABI change.
Consider older version of GCC or some other compiler emitting
_ZN6vectorI12QualityValueEC1ERKS1_
and
_ZN6vectorI12QualityValueEC2ERKS1_
symbols not as aliases, each in their own comdat groups, so
.text._ZN6vectorI12QualityValueEC1ERKS1_ in _ZN6vectorI12QualityValueEC1ERKS1_
comdat group and
.text._ZN6vectorI12QualityValueEC2ERKS1_ in _ZN6vectorI12QualityValueEC2ERKS1_
comdat group.  And then comes GCC with the above patch without the DECL_WEAK
check in there, and decides to use alias, so
_ZN6vectorI12QualityValueEC1ERKS1_ is an alias to
_ZN6vectorI12QualityValueEC2ERKS1_ and both live in
.text._ZN6vectorI12QualityValueEC2ERKS1_ section in
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group.  If you mix TUs with this,
the linker can keep one of the section sets from the 
_ZN6vectorI12QualityValueEC1ERKS1_
and _ZN6vectorI12QualityValueEC2ERKS1_ and _ZN6vectorI12QualityValueEC5ERKS1_
comdat groups.  If there is no .weak for the symbols, this will fail to
link, one can emit it either the old way or the new way but never both, it
is part of an ABI.
While with .weak, mixing it is possible, worst case one gets some unused
code in the linked binary or shared library.  Of course the desirable case
is that there is no mixing and there is no unused code, but if it happens,
no big deal.  Without .weak it is a big deal.

Jakub

[kwin] [Bug 482142] drag in drop files in Google Chrome renders Chrome unusable

2024-05-13 Thread Jakub

https://bugs.kde.org/show_bug.cgi?id=482142

Jakub  changed:

   What|Removed |Added

 CC||jjaruszew...@outlook.com

--- Comment #33 from Jakub  ---
As stated in Chromium issue:
> There seems to have been some recent change in Kwin which has caused it to no 
> longer send wl_data_source.{dnd_finished,cancelled} after 
> wl_data_source.dnd_drop_performed in these cases described in the repro 
> steps. My understanding is that it's a kwin bug, though Chromium should 
> minimally protect against this kind of compositor misbehavior and bugs 
> instead of the taking assumptions and stop responding to input events (due to 
> the dnd nested message loop to be kept running indefinitely).

So maybe this is the kwin bug? Reproducible for me

-- 
You are receiving this mail because:
You are watching all bug changes.

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

2024-05-13 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Jakub Jelinek  ---
Should be fixed now.

[gcc r15-427] tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern [PR113982]

2024-05-13 Thread Jakub Jelinek via Gcc-cvs

https://gcc.gnu.org/g:b621482296f6dec0abb22ed39cc4ce6811535d47

commit r15-427-gb621482296f6dec0abb22ed39cc4ce6811535d47
Author: Jakub Jelinek 
Date:   Mon May 13 11:15:27 2024 +0200

tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern 
[PR113982]

We pattern recognize already many different patterns, and closest to the
requested one also
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x > max)
where y/z has the same unsigned type and type is a wider unsigned type
and max is maximum value of the narrower unsigned type.
But apparently people are creative in writing this in diffent ways,
this requests
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x >> narrower_type_bits)

The following patch implements that.

2024-05-13  Jakub Jelinek  

PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith_overflow): Handle the RSHIFT_EXPR use case.

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

Diff:
---
 gcc/testsuite/gcc.dg/pr113982.c |  60 
 gcc/tree-ssa-math-opts.cc   | 121 ++--
 2 files changed, 177 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr113982.c b/gcc/testsuite/gcc.dg/pr113982.c
new file mode 100644
index ..4c5be6cc832e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113982.c
@@ -0,0 +1,60 @@
+/* PR middle-end/113982 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-widening_mul" } */
+
+#if __SIZEOF_INT128__
+typedef __uint128_t W;
+typedef unsigned long long T;
+#else
+typedef unsigned long long W;
+typedef unsigned int T;
+#endif
+#define B __CHAR_BIT__ * sizeof (T)
+
+struct S { int p; T r; };
+
+struct S
+foo (T x, T y)
+{
+  W z = (W) x + y;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+bar (T x)
+{
+  W z = (W) x + 132;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+baz (T x, unsigned short y)
+{
+  W z = (W) x + y;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+qux (unsigned short x, T y)
+{
+  W z = (W) x + y;
+  return (struct S) { z >> B, (T) z };
+}
+
+struct S
+corge (T x, T y)
+{
+  T w = x + y;
+  W z = (W) x + y;
+  return (struct S) { z >> B, w };
+}
+
+struct S
+garple (T x, T y)
+{
+  W z = (W) x + y;
+  T w = x + y;
+  return (struct S) { z >> B, w };
+}
+
+/* { dg-final { scan-tree-dump-times "ADD_OVERFLOW" 6 "widening_mul" { target 
{ i?86-*-* x86_64-*-* } } } } */
diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
index 705f4a4695ac..e8c804f09b7f 100644
--- a/gcc/tree-ssa-math-opts.cc
+++ b/gcc/tree-ssa-math-opts.cc
@@ -3947,6 +3947,66 @@ arith_overflow_check_p (gimple *stmt, gimple *cast_stmt, 
gimple *_stmt,
   else
 return 0;
 
+  if (maxval
+  && ccode == RSHIFT_EXPR
+  && crhs1 == lhs
+  && TREE_CODE (crhs2) == INTEGER_CST
+  && wi::to_widest (crhs2) == TYPE_PRECISION (TREE_TYPE (maxval)))
+{
+  tree shiftlhs = gimple_assign_lhs (use_stmt);
+  if (!shiftlhs)
+   return 0;
+  use_operand_p use;
+  if (!single_imm_use (shiftlhs, , _use_stmt))
+   return 0;
+  if (gimple_code (cur_use_stmt) == GIMPLE_COND)
+   {
+ ccode = gimple_cond_code (cur_use_stmt);
+ crhs1 = gimple_cond_lhs (cur_use_stmt);
+ crhs2 = gimple_cond_rhs (cur_use_stmt);
+   }
+  else if (is_gimple_assign (cur_use_stmt))
+   {
+ if (gimple_assign_rhs_class (cur_use_stmt) == GIMPLE_BINARY_RHS)
+   {
+ ccode = gimple_assign_rhs_code (cur_use_stmt);
+ crhs1 = gimple_assign_rhs1 (cur_use_stmt);
+ crhs2 = gimple_assign_rhs2 (cur_use_stmt);
+   }
+ else if (gimple_assign_rhs_code (cur_use_stmt) == COND_EXPR)
+   {
+ tree cond = gimple_assign_rhs1 (cur_use_stmt);
+ if (COMPARISON_CLASS_P (cond))
+   {
+ ccode = TREE_CODE (cond);
+ crhs1 = TREE_OPERAND (cond, 0);
+ crhs2 = TREE_OPERAND (cond, 1);
+   }
+ else
+   return 0;
+   }
+ else
+   {
+ enum tree_code sc = gimple_assign_rhs_code (cur_use_stmt);
+ tree castlhs = gimple_assign_lhs (cur_use_stmt);
+ if (!CONVERT_EXPR_CODE_P (sc)
+ || !castlhs
+ || !INTEGRAL_TYPE_P (TREE_TYPE (castlhs))
+ || (TYPE_PRECISION (TREE_TYPE (castlhs))
+ > TYPE_PRECISION (TREE_TYPE (maxval
+   return 0;
+ return 1;
+

[gcc r15-426] Manually add ChangeLog entry for r15-353-gd7bb8eaade3cd3aa70715c8567b4d7b08098e699

2024-05-13 Thread Jakub Jelinek via Gcc-cvs

https://gcc.gnu.org/g:f3f02a750c7b34b751fa809ab03d29b2ccf0785d

commit r15-426-gf3f02a750c7b34b751fa809ab03d29b2ccf0785d
Author: Jakub Jelinek 
Date:   Mon May 13 11:07:59 2024 +0200

Manually add ChangeLog entry for 
r15-353-gd7bb8eaade3cd3aa70715c8567b4d7b08098e699

Diff:
---
 gcc/ChangeLog | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 68c11340a9c6..5d57c861fb62 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -247,6 +247,32 @@
* config/riscv/bitmanip.md: Add splitter for shadd feeding another
add instruction.
 
+2024-05-10  Aldy Hernandez  
+
+   Revert:
+   2024-05-08  Aldy Hernandez  
+
+   * gimple-range-cache.cc (sbr_sparse_bitmap::sbr_sparse_bitmap):
+   Change irange to prange.
+   * gimple-range-fold.cc (fold_using_range::fold_stmt): Same.
+   (fold_using_range::range_of_address): Same.
+   * gimple-range-fold.h (range_of_address): Same.
+   * gimple-range-infer.cc (gimple_infer_range::add_nonzero): Same.
+   * gimple-range-op.cc (class cfn_strlen): Same.
+   * gimple-range-path.cc
+   (path_range_query::adjust_for_non_null_uses): Same.
+   * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Same.
+   * tree-ssa-structalias.cc (find_what_p_points_to): Same.
+   * range-op-ptr.cc (range_op_table::initialize_pointer_ops): Remove
+   hybrid entries in table.
+   * range-op.cc (range_op_table::range_op_table): Add pointer
+   entries for bitwise and/or and min/max.
+   * value-range.cc (irange::verify_range): Add assert.
+   * value-range.h (irange::varying_compatible_p): Remove check for
+   error_mark_node.
+   (irange::supports_p): Remove pointer support.
+   * ipa-cp.h (ipa_supports_p): Add prange support.
+
 2024-05-09  Roger Sayle  
 
* simplify-rtx.cc (simplify_const_binary_operation): Constant

Re: [pushed 00/21] Various backports to gcc 13 (analyzer, jit, diagnostics)

2024-05-13 Thread Jakub Jelinek

On Thu, May 09, 2024 at 01:42:15PM -0400, David Malcolm wrote:
> I've pushed the following changes to releases/gcc-13
> as r13-8741-g89feb3557a0188 through r13-8761-gb7a2697733d19a.

Unfortunately many of the commits contained git commit message wording
that update_git_version can't cope with.
Wording like
(cherry picked from commit r14-1664-gfe9771b59f576f)
is wrong,
(cherry picked from commit .)
is reserved solely for what one gets from git cherry-pick -x
(i.e. the full commit hash without anything extra).

I had to ignore the following commits in the ChangeLog generation
because of this:

89feb3557a018893cfe50c2e07f91559bd3cde2b
ccf8d3e3d26c6ba3d5e11fffeed8d64018e9c060
e0c52905f666e3d23881f82dbf39466a24f009f4
b38472ffc1e631bd357573b44d956ce16d94e666
a0b13d0860848dd5f2876897ada1e22e4e681e91
b8c772cae97b54386f7853edf0f9897012bfa90b
810d35a7e054bcbb5b66d2e5924428e445f5fba9
0df1ee083434ac00ecb19582b1e5b25e105981b2
2c688f6afce4cbb414f5baab1199cd525f309fca
60dcb710b6b4aa22ea96abc8df6dfe9067f3d7fe
44968a0e00f656e9bb3e504bb2fa1a8282002015

Can you please add the ChangeLog entries for these by hand
(commits which only touch ChangeLog files are allowed and shouldn't
contain ChangeLog style entry in the commit message)?

Thanks.

    Jakub

[PATCH] tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern [PR113982]

2024-05-13 Thread Jakub Jelinek

Hi!

We pattern recognize already many different patterns, and closest to the
requested one also
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x > max)
where y/z has the same unsigned type and type is a wider unsigned type
and max is maximum value of the narrower unsigned type.
But apparently people are creative in writing this in diffent ways,
this requests
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x >> narrower_type_bits)

The following patch implements that.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-05-13  Jakub Jelinek  

PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith_overflow): Handle the RSHIFT_EXPR use case.

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

--- gcc/tree-ssa-math-opts.cc.jj2024-04-11 09:26:36.318369218 +0200
+++ gcc/tree-ssa-math-opts.cc   2024-05-10 18:17:08.795744811 +0200
@@ -3947,6 +3947,66 @@ arith_overflow_check_p (gimple *stmt, gi
   else
 return 0;
 
+  if (maxval
+  && ccode == RSHIFT_EXPR
+  && crhs1 == lhs
+  && TREE_CODE (crhs2) == INTEGER_CST
+  && wi::to_widest (crhs2) == TYPE_PRECISION (TREE_TYPE (maxval)))
+{
+  tree shiftlhs = gimple_assign_lhs (use_stmt);
+  if (!shiftlhs)
+   return 0;
+  use_operand_p use;
+  if (!single_imm_use (shiftlhs, , _use_stmt))
+   return 0;
+  if (gimple_code (cur_use_stmt) == GIMPLE_COND)
+   {
+ ccode = gimple_cond_code (cur_use_stmt);
+ crhs1 = gimple_cond_lhs (cur_use_stmt);
+ crhs2 = gimple_cond_rhs (cur_use_stmt);
+   }
+  else if (is_gimple_assign (cur_use_stmt))
+   {
+ if (gimple_assign_rhs_class (cur_use_stmt) == GIMPLE_BINARY_RHS)
+   {
+ ccode = gimple_assign_rhs_code (cur_use_stmt);
+ crhs1 = gimple_assign_rhs1 (cur_use_stmt);
+ crhs2 = gimple_assign_rhs2 (cur_use_stmt);
+   }
+ else if (gimple_assign_rhs_code (cur_use_stmt) == COND_EXPR)
+   {
+ tree cond = gimple_assign_rhs1 (cur_use_stmt);
+ if (COMPARISON_CLASS_P (cond))
+   {
+ ccode = TREE_CODE (cond);
+ crhs1 = TREE_OPERAND (cond, 0);
+ crhs2 = TREE_OPERAND (cond, 1);
+   }
+ else
+   return 0;
+   }
+ else
+   {
+ enum tree_code sc = gimple_assign_rhs_code (cur_use_stmt);
+ tree castlhs = gimple_assign_lhs (cur_use_stmt);
+ if (!CONVERT_EXPR_CODE_P (sc)
+ || !castlhs
+ || !INTEGRAL_TYPE_P (TREE_TYPE (castlhs))
+ || (TYPE_PRECISION (TREE_TYPE (castlhs))
+ > TYPE_PRECISION (TREE_TYPE (maxval
+   return 0;
+ return 1;
+   }
+   }
+  else
+   return 0;
+  if ((ccode != EQ_EXPR && ccode != NE_EXPR)
+ || crhs1 != shiftlhs
+ || !integer_zerop (crhs2))
+   return 0;
+  return 1;
+}
+
   if (TREE_CODE_CLASS (ccode) != tcc_comparison)
 return 0;
 
@@ -4049,6 +4109,7 @@ arith_overflow_check_p (gimple *stmt, gi
_8 = IMAGPART_EXPR <_7>;
if (_8)
and replace (utype) x with _9.
+   Or with x >> popcount (max) instead of x > max.
 
Also recognize:
x = ~z;
@@ -4481,10 +4542,62 @@ match_arith_overflow (gimple_stmt_iterat
  gcc_checking_assert (is_gimple_assign (use_stmt));
  if (gimple_assign_rhs_class (use_stmt) == GIMPLE_BINARY_RHS)
{
- gimple_assign_set_rhs1 (use_stmt, ovf);
- gimple_assign_set_rhs2 (use_stmt, build_int_cst (type, 0));
- gimple_assign_set_rhs_code (use_stmt,
- ovf_use == 1 ? NE_EXPR : EQ_EXPR);
+ if (gimple_assign_rhs_code (use_stmt) == RSHIFT_EXPR)
+   {
+ g2 = gimple_build_assign (make_ssa_name (boolean_type_node),
+   ovf_use == 1 ? NE_EXPR : EQ_EXPR,
+   ovf, build_int_cst (type, 0));
+ gimple_stmt_iterator gsiu = gsi_for_stmt (use_stmt);
+ gsi_insert_before (, g2, GSI_SAME_STMT);
+ gimple_assign_set_rhs_with_ops (, NOP_EXPR,
+ gimple_assign_lhs (g2));
+ update_stmt (use_stmt);
+ use_operand_p use;
+ single_imm_use (gimple_assign_lhs (use_stmt), ,
+ _stmt);
+ if (gimple_code (use_stmt) == GIMPLE_COND)
+   {
+ gcond *cond_stmt = as_a  (u

[clang-tools-extra] [flang] [lld] [llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (PR #91864)

2024-05-12 Thread Jakub Kuderski via cfe-commits


https://github.com/kuhar approved this pull request.


https://github.com/llvm/llvm-project/pull/91864
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[Bug 2063332] Re: Ubuntu 24.04 Wayland and Qt5 (regression - worked in Ubuntu 22.04)

2024-05-12 Thread Jakub Klos

Thank you for spending the time on this, Dmitry.

I have tried your tester app and Ctrl+~ is not working for me in Ubuntu
24.04 (Gnome 46).

I have also realized I made a mistake (Alt+Shift+F7 works fine for me)
but what does not is Alt+Shift+?. I changed your code to use
QKeySequence(Qt::SHIFT | Qt::ALT | Qt::Key_Question) instead and then,
it also does not work. So your tester works only for Ctrl+. for me.

qgnomeplatform-qt5 is unmaintained a no longer developed, so not sure if
it's the right solution.

The app I am using is Double Commander built with qt5 support. It is not
a native app but works best for me as far as file commanders go. It can
be configured with your own shortuts and displays the shortcut you have
pressed. For Ctrl+. and Shift+Alt+? no shortcut is detected (almost like
you did not press any key). For Ctrl+~ is detects Ctrl+0 (with gt2 it
detects Ctrl+~). I know it is not a native Qt5 app and can be an issue
with some FPC/Lazarus qt unit though.

But still, even your tester does not work with those 2 shortcuts.

Thank you again

--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063332

Title:
Ubuntu 24.04 Wayland and Qt5 (regression - worked in Ubuntu 22.04)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/2063332/+subscriptions

--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH net-next v2] selftests: net: local_termination: annotate the expected failures

2024-05-10 Thread Jakub Kicinski

Vladimir said when adding this test:

  The bridge driver fares particularly badly [...] mainly because
  it does not implement IFF_UNICAST_FLT.

See commit 90b9566aa5cd ("selftests: forwarding: add a test for
local_termination.sh").

We don't want to hide the known gaps, but having a test which
always fails prevents us from catching regressions. Report
the cases we know may fail as XFAIL.

Reviewed-by: Vladimir Oltean 
Tested-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski 
---
CC: liuhang...@gmail.com
CC: sh...@kernel.org
CC: linux-kselftest@vger.kernel.org

v2:
 - remove duplicated log_test_xfail
v1: https://lore.kernel.org/all/20240509235553.5740-1-k...@kernel.org/
---
 .../net/forwarding/local_termination.sh   | 21 ++-
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/net/forwarding/local_termination.sh 
b/tools/testing/selftests/net/forwarding/local_termination.sh
index c5b0cbc85b3e..4bba9c78db3e 100755
--- a/tools/testing/selftests/net/forwarding/local_termination.sh
+++ b/tools/testing/selftests/net/forwarding/local_termination.sh
@@ -73,6 +73,10 @@ check_rcv()
local pattern=$3
local should_receive=$4
local should_fail=
+   local xfail_sw=$5
+
+   local kind=$(ip -j -d link show dev $if_name |
+jq -r '.[].linkinfo.info_kind')
 
[ $should_receive = true ] && should_fail=0 || should_fail=1
RET=0
@@ -81,7 +85,14 @@ check_rcv()
 
check_err_fail "$should_fail" "$?" "reception"
 
-   log_test "$if_name: $type"
+   # If not a SW interface, ignore the XFAIL allowance
+   [ "$kind" != veth ] && [ "$kind" != bridge ] && xfail_sw=
+
+   if [ $RET -ne 0 ] && [ "$xfail_sw" == true ]; then
+   log_test_xfail "$if_name: $type"
+   else
+   log_test "$if_name: $type"
+   fi
 }
 
 mc_route_prepare()
@@ -157,7 +168,7 @@ run_test()
 
check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
"$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address, promisc" \
"$smac > $UNKNOWN_UC_ADDR2, ethertype IPv4 (0x0800)" \
@@ -165,7 +176,7 @@ run_test()
 
check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address, allmulti" \
"$smac > $UNKNOWN_UC_ADDR3, ethertype IPv4 (0x0800)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Multicast IPv4 to joined group" \
"$smac > $JOINED_MACV4_MC_ADDR, ethertype IPv4 (0x0800)" \
@@ -173,7 +184,7 @@ run_test()
 
check_rcv $rcv_if_name "Multicast IPv4 to unknown group" \
"$smac > $UNKNOWN_MACV4_MC_ADDR1, ethertype IPv4 (0x0800)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Multicast IPv4 to unknown group, promisc" \
"$smac > $UNKNOWN_MACV4_MC_ADDR2, ethertype IPv4 (0x0800)" \
@@ -189,7 +200,7 @@ run_test()
 
check_rcv $rcv_if_name "Multicast IPv6 to unknown group" \
"$smac > $UNKNOWN_MACV6_MC_ADDR1, ethertype IPv6 (0x86dd)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Multicast IPv6 to unknown group, promisc" \
"$smac > $UNKNOWN_MACV6_MC_ADDR2, ethertype IPv6 (0x86dd)" \
-- 
2.45.0

Re: [PATCH net-next 1/2] selftests: net: fix timestamp not arriving in cmsg_time.sh

2024-05-10 Thread Jakub Kicinski

On Thu, 09 May 2024 22:49:50 -0400 Willem de Bruijn wrote:
> > struct sock_extended_err *see;
> > struct scm_timestamping *ts;
> > +   unsigned int ts_seen = 0;  
> 
> nit: mixing unsigned long and unsigned int

Fixed when applying, thanks!

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

2024-05-10 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982

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  ---
Created attachment 58179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58179=edit
gcc15-pr113982.patch

Untested fix.

Re: [PATCH net-next] selftests: net: use upstream mtools

2024-05-10 Thread Jakub Kicinski

On Fri, 10 May 2024 14:28:56 +0300 Vladimir Oltean wrote:
> Check that the deployed mtools version is 3.0 or above. Note that the
> version check breaks compatibility with my fork 

And Joachim's tree from before the tag, the PR was merged a while back
;)

> where I didn't bump the version, but I assume that won't be a problem.

Agreed, no point accumulating more bespoke checks.
I updated NIPA, next run should have tagged 3.0.

Speaking of requirement checks - I run the test on a fresh Fedora
install yesterday and it was failing with no indication of why.
Then I realized tcpdump wasn't installed :(

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

2024-05-10 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982

--- Comment #6 from Jakub Jelinek  ---
Note, since PR95853 we also recognize bool(r > ~0ULL) as the check rather than
bool(r >> 64).

[Bug target/114968] [14/15 Regression] missing `thiscall` attribute on builtin declaration of `cxa_thread_atexit()`

2024-05-10 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #26 from Jakub Jelinek  ---
Fixed then.

[gcc r14-10193] c++, mingw: Fix up types of dtor hooks to __cxa_{, thread_}atexit/__cxa_throw on mingw ia32 [PR114968

2024-05-10 Thread Jakub Jelinek via Gcc-cvs

https://gcc.gnu.org/g:a805de33f7be4f6886906ca5f4da493f3b743c76

commit r14-10193-ga805de33f7be4f6886906ca5f4da493f3b743c76
Author: Jakub Jelinek 
Date:   Fri May 10 09:21:38 2024 +0200

c++, mingw: Fix up types of dtor hooks to 
__cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

__cxa_atexit/__cxa_thread_atexit/__cxa_throw functions accept function
pointers to usually directly destructors rather than wrappers around
them.
Now, mingw ia32 uses implicitly __attribute__((thiscall)) calling
conventions for METHOD_TYPE (where the this pointer is passed in %ecx
register, the rest on the stack), so these functions use:
in config/os/mingw32/os_defines.h:
 #if defined (__i386__)
 #define _GLIBCXX_CDTOR_CALLABI __thiscall
 #endif
in libsupc++/cxxabi.h
__cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*) 
_GLIBCXX_NOTHROW;
__cxa_thread_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void *) 
_GLIBCXX_NOTHROW;
__cxa_throw(void*, std::type_info*, void (_GLIBCXX_CDTOR_CALLABI *) (void 
*))
__attribute__((__noreturn__));

Now, mingw for some weird reason uses
 #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true
so it never actually uses __cxa_atexit, but does use __cxa_thread_atexit
and __cxa_throw.  Recent changes for modules result in more detailed
__cxa_*atexit/__cxa_throw prototypes precreated by the compiler, and if
that happens and one also includes , the compiler complains about
mismatches in the prototypes.

One thing is the missing thiscall attribute on the FUNCTION_TYPE, the
other problem is that all of atexit/__cxa_atexit/__cxa_thread_atexit
get function pointer types created by a single function,
get_atexit_fn_ptr_type (), which creates it depending on if atexit
or __cxa_atexit will be used as either void(*)(void) or void(*)(void *),
but when using atexit and __cxa_thread_atexit it uses the wrong function
type for __cxa_thread_atexit.

The following patch adds a target hook to add the thiscall attribute to the
function pointers, and splits the get_atexit_fn_ptr_type () function into
get_atexit_fn_ptr_type () and get_cxa_atexit_fn_ptr_type (), the former 
always
creates shared void(*)(void) type, the latter creates either
void(*)(void*) (on most targets) or void(__attribute__((thiscall))*)(void*)
(on mingw ia32).  So that we don't waiste another GTY global tree for it,
because cleanup_type used for the same purpose for __cxa_throw should be
the same, the code changes it to use that type too.

In register_dtor_fn then based on the decision whether to use atexit,
__cxa_atexit or __cxa_thread_atexit it picks the right function pointer
type, and also if it decides to emit a __tcf_* wrapper for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.

2024-05-10  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add ob_parm argument, call
get_cxa_atexit_fn_ptr_type or get_atexit_fn_ptr_type depending
on it and create PARM_DECL also based on that argument.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
for use_dtor casts.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

(cherry picked from commit e5d8fd9ce05611093191d500ebc39f150d0ece2b)

Diff:
---
 gcc/config/i386/i386.cc | 16 ++
 gcc/cp/cp-tree.h|  7 +++---
 gcc/cp/decl.cc  | 59 +++--
 gcc/cp/except.cc|  6 +
 gcc/doc/tm.texi

[Bug target/114968] [14/15 Regression] missing `thiscall` attribute on builtin declaration of `cxa_thread_atexit()`

2024-05-10 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968

--- Comment #22 from Jakub Jelinek  ---
Does even the committed version work fine on mingw32?

[gcc r15-358] c++, mingw: Fix up types of dtor hooks to __cxa_{, thread_}atexit/__cxa_throw on mingw ia32 [PR114968

2024-05-10 Thread Jakub Jelinek via Gcc-cvs

https://gcc.gnu.org/g:e5d8fd9ce05611093191d500ebc39f150d0ece2b

commit r15-358-ge5d8fd9ce05611093191d500ebc39f150d0ece2b
Author: Jakub Jelinek 
Date:   Fri May 10 09:21:38 2024 +0200

c++, mingw: Fix up types of dtor hooks to 
__cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

__cxa_atexit/__cxa_thread_atexit/__cxa_throw functions accept function
pointers to usually directly destructors rather than wrappers around
them.
Now, mingw ia32 uses implicitly __attribute__((thiscall)) calling
conventions for METHOD_TYPE (where the this pointer is passed in %ecx
register, the rest on the stack), so these functions use:
in config/os/mingw32/os_defines.h:
 #if defined (__i386__)
 #define _GLIBCXX_CDTOR_CALLABI __thiscall
 #endif
in libsupc++/cxxabi.h
__cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*) 
_GLIBCXX_NOTHROW;
__cxa_thread_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void *) 
_GLIBCXX_NOTHROW;
__cxa_throw(void*, std::type_info*, void (_GLIBCXX_CDTOR_CALLABI *) (void 
*))
__attribute__((__noreturn__));

Now, mingw for some weird reason uses
 #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true
so it never actually uses __cxa_atexit, but does use __cxa_thread_atexit
and __cxa_throw.  Recent changes for modules result in more detailed
__cxa_*atexit/__cxa_throw prototypes precreated by the compiler, and if
that happens and one also includes , the compiler complains about
mismatches in the prototypes.

One thing is the missing thiscall attribute on the FUNCTION_TYPE, the
other problem is that all of atexit/__cxa_atexit/__cxa_thread_atexit
get function pointer types created by a single function,
get_atexit_fn_ptr_type (), which creates it depending on if atexit
or __cxa_atexit will be used as either void(*)(void) or void(*)(void *),
but when using atexit and __cxa_thread_atexit it uses the wrong function
type for __cxa_thread_atexit.

The following patch adds a target hook to add the thiscall attribute to the
function pointers, and splits the get_atexit_fn_ptr_type () function into
get_atexit_fn_ptr_type () and get_cxa_atexit_fn_ptr_type (), the former 
always
creates shared void(*)(void) type, the latter creates either
void(*)(void*) (on most targets) or void(__attribute__((thiscall))*)(void*)
(on mingw ia32).  So that we don't waiste another GTY global tree for it,
because cleanup_type used for the same purpose for __cxa_throw should be
the same, the code changes it to use that type too.

In register_dtor_fn then based on the decision whether to use atexit,
__cxa_atexit or __cxa_thread_atexit it picks the right function pointer
type, and also if it decides to emit a __tcf_* wrapper for the cleanup,
uses that type for that wrapper so that it agrees on calling convention.

2024-05-10  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add ob_parm argument, call
get_cxa_atexit_fn_ptr_type or get_atexit_fn_ptr_type depending
on it and create PARM_DECL also based on that argument.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
for use_dtor casts.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

Diff:
---
 gcc/config/i386/i386.cc | 16 ++
 gcc/cp/cp-tree.h|  7 +++---
 gcc/cp/decl.cc  | 59 +++--
 gcc/cp/except.cc|  6 +
 gcc/doc/tm.texi |  8 +++
 gcc/doc/tm.texi.in  |  2 ++
 gcc/target.def

Re: [PATCH net-next] selftests: net: local_termination: annotate the expected failures

On Fri, 10 May 2024 11:15:58 +0800 Hangbin Liu wrote:
> I may missed something, I saw there is already a log_test_xfail() in lib.sh
> 
> log_test_skip()
> {
> RET=$ksft_skip retmsg= log_test "$@"
> }
> 
> log_test_xfail()
> {
> RET=$ksft_xfail retmsg= log_test "$@"
> }
> 
> log_info()
> {
> ...
> }
> 
> Added by a923af1ceee7 ("selftests: forwarding: Convert log_test() to 
> recognize RET values")

Good catch, sorry. Must have had net checked out when I wrote it :(

[PATCH net-next 2/2] selftests: net: increase the delay for relative cmsg_time.sh test

Slow machines can delay scheduling of the packets for milliseconds.
Increase the delay to 8ms if KSFT_MACHINE_SLOW. Try to limit the
variability by moving setsockopts earlier (before we read time).

This fixes the "TXTIME rel" failures on debug kernels, like:

  Case ICMPv4  - TXTIME rel returned '', expected 'OK'

Signed-off-by: Jakub Kicinski 
---
CC: sh...@kernel.org
CC: linux-kselftest@vger.kernel.org
---
 tools/testing/selftests/net/cmsg_sender.c | 32 +--
 tools/testing/selftests/net/cmsg_time.sh  |  7 +++--
 2 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/tools/testing/selftests/net/cmsg_sender.c 
b/tools/testing/selftests/net/cmsg_sender.c
index f25268504937..b2df05ef71cb 100644
--- a/tools/testing/selftests/net/cmsg_sender.c
+++ b/tools/testing/selftests/net/cmsg_sender.c
@@ -260,15 +260,8 @@ cs_write_cmsg(int fd, struct msghdr *msg, char *cbuf, 
size_t cbuf_sz)
  SOL_IPV6, IPV6_HOPLIMIT, );
 
if (opt.txtime.ena) {
-   struct sock_txtime so_txtime = {
-   .clockid = CLOCK_MONOTONIC,
-   };
__u64 txtime;
 
-   if (setsockopt(fd, SOL_SOCKET, SO_TXTIME,
-  _txtime, sizeof(so_txtime)))
-   error(ERN_SOCKOPT, errno, "setsockopt TXTIME");
-
txtime = time_start_mono.tv_sec * (1000ULL * 1000 * 1000) +
 time_start_mono.tv_nsec +
 opt.txtime.delay * 1000;
@@ -284,13 +277,6 @@ cs_write_cmsg(int fd, struct msghdr *msg, char *cbuf, 
size_t cbuf_sz)
memcpy(CMSG_DATA(cmsg), , sizeof(txtime));
}
if (opt.ts.ena) {
-   __u32 val = SOF_TIMESTAMPING_SOFTWARE |
-   SOF_TIMESTAMPING_OPT_TSONLY;
-
-   if (setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING,
-  , sizeof(val)))
-   error(ERN_SOCKOPT, errno, "setsockopt TIMESTAMPING");
-
cmsg = (struct cmsghdr *)(cbuf + cmsg_len);
cmsg_len += CMSG_SPACE(sizeof(__u32));
if (cbuf_sz < cmsg_len)
@@ -426,6 +412,24 @@ static void ca_set_sockopts(int fd)
setsockopt(fd, SOL_SOCKET, SO_PRIORITY,
   , sizeof(opt.sockopt.priority)))
error(ERN_SOCKOPT, errno, "setsockopt SO_PRIORITY");
+
+   if (opt.txtime.ena) {
+   struct sock_txtime so_txtime = {
+   .clockid = CLOCK_MONOTONIC,
+   };
+
+   if (setsockopt(fd, SOL_SOCKET, SO_TXTIME,
+  _txtime, sizeof(so_txtime)))
+   error(ERN_SOCKOPT, errno, "setsockopt TXTIME");
+   }
+   if (opt.ts.ena) {
+   __u32 val = SOF_TIMESTAMPING_SOFTWARE |
+   SOF_TIMESTAMPING_OPT_TSONLY;
+
+   if (setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING,
+  , sizeof(val)))
+   error(ERN_SOCKOPT, errno, "setsockopt TIMESTAMPING");
+   }
 }
 
 int main(int argc, char *argv[])
diff --git a/tools/testing/selftests/net/cmsg_time.sh 
b/tools/testing/selftests/net/cmsg_time.sh
index af85267ad1e3..1d7e756644bc 100755
--- a/tools/testing/selftests/net/cmsg_time.sh
+++ b/tools/testing/selftests/net/cmsg_time.sh
@@ -66,10 +66,13 @@ for i in "-4 $TGT4" "-6 $TGT6"; do
 awk '/SND/ { if ($3 > 1000) print "OK"; }')
check_result $? "$ts" "OK" "$prot - TXTIME abs"
 
-   ts=$(ip netns exec $NS ./cmsg_sender -p $p $i 1234 -t -d 1000 |
+   [ "$KSFT_MACHINE_SLOW" = yes ] && delay=8000 || delay=1000
+
+   ts=$(ip netns exec $NS ./cmsg_sender -p $p $i 1234 -t -d $delay |
 awk '/SND/ {snd=$3}
  /SCHED/ {sch=$3}
- END { if (snd - sch > 500) print "OK"; }')
+ END { if (snd - sch > '$((delay/2))') print "OK";
+   else print snd, "-", sch, "<", '$((delay/2))'; }')
check_result $? "$ts" "OK" "$prot - TXTIME rel"
 done
 done
-- 
2.45.0

[PATCH net-next 1/2] selftests: net: fix timestamp not arriving in cmsg_time.sh

On slow machines the SND timestamp sometimes doesn't arrive before
we quit. The test only waits as long as the packet delay, so it's
easy for a race condition to happen.

Double the wait but do a bit of polling, once the SND timestamp
arrives there's no point to wait any longer.

This fixes the "TXTIME abs" failures on debug kernels, like:

   Case ICMPv4  - TXTIME abs returned '', expected 'OK'

Signed-off-by: Jakub Kicinski 
---
CC: sh...@kernel.org
CC: linux-kselftest@vger.kernel.org
---
 tools/testing/selftests/net/cmsg_sender.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/net/cmsg_sender.c 
b/tools/testing/selftests/net/cmsg_sender.c
index c79e65581dc3..f25268504937 100644
--- a/tools/testing/selftests/net/cmsg_sender.c
+++ b/tools/testing/selftests/net/cmsg_sender.c
@@ -333,16 +333,17 @@ static const char *cs_ts_info2str(unsigned int info)
return "unknown";
 }
 
-static void
+static unsigned long
 cs_read_cmsg(int fd, struct msghdr *msg, char *cbuf, size_t cbuf_sz)
 {
struct sock_extended_err *see;
struct scm_timestamping *ts;
+   unsigned int ts_seen = 0;
struct cmsghdr *cmsg;
int i, err;
 
if (!opt.ts.ena)
-   return;
+   return 0;
msg->msg_control = cbuf;
msg->msg_controllen = cbuf_sz;
 
@@ -396,8 +397,11 @@ cs_read_cmsg(int fd, struct msghdr *msg, char *cbuf, 
size_t cbuf_sz)
printf(" %5s ts%d %lluus\n",
   cs_ts_info2str(see->ee_info),
   i, rel_time);
+   ts_seen |= 1 << see->ee_info;
}
}
+
+   return ts_seen;
 }
 
 static void ca_set_sockopts(int fd)
@@ -509,10 +513,16 @@ int main(int argc, char *argv[])
err = ERN_SUCCESS;
 
if (opt.ts.ena) {
-   /* Make sure all timestamps have time to loop back */
-   usleep(opt.txtime.delay);
+   unsigned long seen;
+   int i;
 
-   cs_read_cmsg(fd, , cbuf, sizeof(cbuf));
+   /* Make sure all timestamps have time to loop back */
+   for (i = 0; i < 40; i++) {
+   seen = cs_read_cmsg(fd, , cbuf, sizeof(cbuf));
+   if (seen & (1 << SCM_TSTAMP_SND))
+   break;
+   usleep(opt.txtime.delay / 20);
+   }
}
 
 err_out:
-- 
2.45.0

[PATCH net-next] selftests: net: local_termination: annotate the expected failures

Vladimir said when adding this test:

  The bridge driver fares particularly badly [...] mainly because
  it does not implement IFF_UNICAST_FLT.

See commit 90b9566aa5cd ("selftests: forwarding: add a test for
local_termination.sh").

We don't want to hide the known gaps, but having a test which
always fails prevents us from catching regressions. Report
the cases we know may fail as XFAIL.

Signed-off-by: Jakub Kicinski 
---
CC: vladimir.olt...@nxp.com
CC: sh...@kernel.org
CC: pe...@nvidia.com
CC: liuhang...@gmail.com
CC: bpoir...@nvidia.com
CC: linux-kselftest@vger.kernel.org
---
 tools/testing/selftests/net/forwarding/lib.sh |  9 
 .../net/forwarding/local_termination.sh   | 21 ++-
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/net/forwarding/lib.sh 
b/tools/testing/selftests/net/forwarding/lib.sh
index 3353a1745946..4fe28ab5d8b9 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -605,6 +605,15 @@ log_test_xfail()
RET=$ksft_xfail retmsg= log_test "$@"
 }
 
+log_test_xfail()
+{
+   local test_name=$1
+   local opt_str=$2
+
+   printf "TEST: %-60s  [XFAIL]\n" "$test_name $opt_str"
+   return 0
+}
+
 log_info()
 {
local msg=$1
diff --git a/tools/testing/selftests/net/forwarding/local_termination.sh 
b/tools/testing/selftests/net/forwarding/local_termination.sh
index c5b0cbc85b3e..4bba9c78db3e 100755
--- a/tools/testing/selftests/net/forwarding/local_termination.sh
+++ b/tools/testing/selftests/net/forwarding/local_termination.sh
@@ -73,6 +73,10 @@ check_rcv()
local pattern=$3
local should_receive=$4
local should_fail=
+   local xfail_sw=$5
+
+   local kind=$(ip -j -d link show dev $if_name |
+jq -r '.[].linkinfo.info_kind')
 
[ $should_receive = true ] && should_fail=0 || should_fail=1
RET=0
@@ -81,7 +85,14 @@ check_rcv()
 
check_err_fail "$should_fail" "$?" "reception"
 
-   log_test "$if_name: $type"
+   # If not a SW interface, ignore the XFAIL allowance
+   [ "$kind" != veth ] && [ "$kind" != bridge ] && xfail_sw=
+
+   if [ $RET -ne 0 ] && [ "$xfail_sw" == true ]; then
+   log_test_xfail "$if_name: $type"
+   else
+   log_test "$if_name: $type"
+   fi
 }
 
 mc_route_prepare()
@@ -157,7 +168,7 @@ run_test()
 
check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
"$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address, promisc" \
"$smac > $UNKNOWN_UC_ADDR2, ethertype IPv4 (0x0800)" \
@@ -165,7 +176,7 @@ run_test()
 
check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address, allmulti" \
"$smac > $UNKNOWN_UC_ADDR3, ethertype IPv4 (0x0800)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Multicast IPv4 to joined group" \
"$smac > $JOINED_MACV4_MC_ADDR, ethertype IPv4 (0x0800)" \
@@ -173,7 +184,7 @@ run_test()
 
check_rcv $rcv_if_name "Multicast IPv4 to unknown group" \
"$smac > $UNKNOWN_MACV4_MC_ADDR1, ethertype IPv4 (0x0800)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Multicast IPv4 to unknown group, promisc" \
"$smac > $UNKNOWN_MACV4_MC_ADDR2, ethertype IPv4 (0x0800)" \
@@ -189,7 +200,7 @@ run_test()
 
check_rcv $rcv_if_name "Multicast IPv6 to unknown group" \
"$smac > $UNKNOWN_MACV6_MC_ADDR1, ethertype IPv6 (0x86dd)" \
-   false
+   false true
 
check_rcv $rcv_if_name "Multicast IPv6 to unknown group, promisc" \
"$smac > $UNKNOWN_MACV6_MC_ADDR2, ethertype IPv6 (0x86dd)" \
-- 
2.45.0

[Bug c++/113798] [C++26] P2662R3 - Pack indexing

2024-05-09 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113798

--- Comment #2 from Jakub Jelinek  ---
Ignore me, functions can't return arrays.

[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

2024-05-09 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Jakub Jelinek  ---
Fixed, thanks.

Re: [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

2024-05-09 Thread Jakub Jelinek

On Thu, May 09, 2024 at 02:58:52PM -0400, Marek Polacek wrote:
> On Thu, May 09, 2024 at 08:20:00PM +0200, Jakub Jelinek wrote:
> > --- gcc/cp/decl.cc.jj   2024-05-09 10:30:54.804505130 +0200
> > +++ gcc/cp/decl.cc  2024-05-09 17:07:08.400110018 +0200
> > @@ -19280,6 +19280,14 @@ cxx_comdat_group (tree decl)
> >   else
> > break;
> > }
> > +  /* If a ctor/dtor has already set the comdat group by
> > +maybe_clone_body, don't override it.  */
> > +  if (SUPPORTS_ONE_ONLY
> > + && TREE_CODE (decl) == FUNCTION_DECL
> > + && DECL_CLONED_FUNCTION_P (decl)
> > + && SUPPORTS_ONE_ONLY)
> > +   if (tree comdat = DECL_COMDAT_GROUP (decl))
> > + return comdat;
> 
> This checks SUPPORTS_ONE_ONLY twice.

Oops, you're right, fixed in my copy.

Jakub

[committed] testsuite: Fix up pr84508* tests [PR84508]

2024-05-09 Thread Jakub Jelinek

On Thu, May 09, 2024 at 12:45:42PM +0800, Hongtao Liu wrote:
> > PR target/84508
> > * gcc.target/i386/pr84508-1.c: New test.
> > * gcc.target/i386/pr84508-2.c: Ditto.

The tests FAIL on x86_64-linux with
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.target/i386/pr84508-1.c (test for excess errors)
Excess errors:
/usr/bin/ld: cannot find -lubsan

The problem is that only *.dg/ubsan/ubsan.exp calls ubsan_init
which adds the needed search paths to libubsan library.
So, link/run tests for -fsanitize=undefined need to go into
gcc.dg/ubsan/ or g++.dg/ubsan/, even when they are target specific.

Tested on x86_64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=pr84508* 
ubsan.exp=pr84508*'
and committed to trunk as obvious.

2024-05-09  Jakub Jelinek  

PR target/84508
* gcc.target/i386/pr84508-1.c: Move to ...
* gcc.dg/ubsan/pr84508-1.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.
* gcc.target/i386/pr84508-2.c: Move to ...
* gcc.dg/ubsan/pr84508-2.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.

diff --git a/gcc/testsuite/gcc.target/i386/pr84508-1.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
similarity index 74%
rename from gcc/testsuite/gcc.target/i386/pr84508-1.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
index bb3e28d017e..d781e01 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-1.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()
diff --git a/gcc/testsuite/gcc.target/i386/pr84508-2.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
similarity index 73%
rename from gcc/testsuite/gcc.target/i386/pr84508-2.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
index 32a8f20a536..cf9c7db1d15 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-2.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()

Jakub

[gcc r15-350] testsuite: Fix up pr84508* tests [PR84508]

2024-05-09 Thread Jakub Jelinek via Gcc-cvs

https://gcc.gnu.org/g:e02b5683e77c2b4317b23be72e43b6e6cc6c8e5b

commit r15-350-ge02b5683e77c2b4317b23be72e43b6e6cc6c8e5b
Author: Jakub Jelinek 
Date:   Thu May 9 20:59:05 2024 +0200

testsuite: Fix up pr84508* tests [PR84508]

The tests FAIL on x86_64-linux with
/usr/bin/ld: cannot find -lubsan
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.target/i386/pr84508-1.c (test for excess errors)
Excess errors:
/usr/bin/ld: cannot find -lubsan

The problem is that only *.dg/ubsan/ubsan.exp calls ubsan_init
which adds the needed search paths to libubsan library.
So, link/run tests for -fsanitize=undefined need to go into
gcc.dg/ubsan/ or g++.dg/ubsan/, even when they are target specific.

2024-05-09  Jakub Jelinek  

PR target/84508
* gcc.target/i386/pr84508-1.c: Move to ...
* gcc.dg/ubsan/pr84508-1.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.
* gcc.target/i386/pr84508-2.c: Move to ...
* gcc.dg/ubsan/pr84508-2.c: ... here.  Restrict to i?86/x86_64
non-ia32 targets.

Diff:
---
 gcc/testsuite/{gcc.target/i386 => gcc.dg/ubsan}/pr84508-1.c | 3 ++-
 gcc/testsuite/{gcc.target/i386 => gcc.dg/ubsan}/pr84508-2.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr84508-1.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
similarity index 74%
rename from gcc/testsuite/gcc.target/i386/pr84508-1.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
index bb3e28d017e9..d781e01c 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-1.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-1.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()
diff --git a/gcc/testsuite/gcc.target/i386/pr84508-2.c 
b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
similarity index 73%
rename from gcc/testsuite/gcc.target/i386/pr84508-2.c
rename to gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
index 32a8f20a5364..cf9c7db1d159 100644
--- a/gcc/testsuite/gcc.target/i386/pr84508-2.c
+++ b/gcc/testsuite/gcc.dg/ubsan/pr84508-2.c
@@ -1,5 +1,6 @@
-/* { dg-do run { target { ! ia32 } } } */
+/* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */
 /* { dg-options "-fsanitize=undefined" } */
+
 #include 
 
 int main()

[PATCH] c++, mingw, v2: Fix up types of dtor hooks to __cxa_{,thread_}atexit/__cxa_throw on mingw ia32 [PR114968]

2024-05-09 Thread Jakub Jelinek

On Thu, May 09, 2024 at 01:05:59PM -0400, Jason Merrill wrote:
> I think I'd rather pass ob_parm to start_cleanup_fn, where it can also
> replace the flag_use_cxa_atexit check in that function.

Good idea, changed in the following patch.

> > @@ -9998,7 +10004,8 @@ register_dtor_fn (tree decl)
> >   {
> > /* We must convert CLEANUP to the type that "__cxa_atexit"
> >  expects.  */
> > -  cleanup = build_nop (get_atexit_fn_ptr_type (), cleanup);
> > +  cleanup = build_nop (ob_parm ? get_cxa_atexit_fn_ptr_type ()
> > +  : get_atexit_fn_ptr_type (), cleanup);
> 
> If we're (now) using the correct type to build the cleanup fn, this
> conversion should be unnecessary.

This is the use_dtor case, where cleanup will have METHOD_TYPE, so
I think we need to cast.  But, we can cast always to
get_cxa_atexit_fn_ptr_type () type, because this is in use_dtor guarded code
and use_dtor is ob_parm && CLASS_TYPE_P (type), so when use_dtor is true,
ob_parm is also true.

Ok for trunk if it passes another bootstrap/regtest?

2024-05-09  Jakub Jelinek  

PR target/114968
gcc/
* target.def (use_atexit_for_cxa_atexit): Remove spurious space
from comment.
(adjust_cdtor_callabi_fntype): New cxx target hook.
* targhooks.h (default_cxx_adjust_cdtor_callabi_fntype): Declare.
* targhooks.cc (default_cxx_adjust_cdtor_callabi_fntype): New
function.
* doc/tm.texi.in (TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Add.
* doc/tm.texi: Regenerate.
* config/i386/i386.cc (ix86_cxx_adjust_cdtor_callabi_fntype): New
function.
(TARGET_CXX_ADJUST_CDTOR_CALLABI_FNTYPE): Redefine.
gcc/cp/
* cp-tree.h (atexit_fn_ptr_type_node, cleanup_type): Adjust macro
comments.
(get_cxa_atexit_fn_ptr_type): Declare.
* decl.cc (get_atexit_fn_ptr_type): Adjust function comment, only
build type for atexit argument.
(get_cxa_atexit_fn_ptr_type): New function.
(get_atexit_node): Call get_cxa_atexit_fn_ptr_type rather than
get_atexit_fn_ptr_type when using __cxa_atexit.
(get_thread_atexit_node): Call get_cxa_atexit_fn_ptr_type
rather than get_atexit_fn_ptr_type.
(start_cleanup_fn): Add ob_parm argument, call
get_cxa_atexit_fn_ptr_type or get_atexit_fn_ptr_type depending
on it and create PARM_DECL also based on that argument.
(register_dtor_fn): Adjust start_cleanup_fn caller, use
get_cxa_atexit_fn_ptr_type rather than get_atexit_fn_ptr_type
for use_dtor casts.
* except.cc (build_throw): Use get_cxa_atexit_fn_ptr_type ().

--- gcc/target.def.jj   2024-05-09 10:30:54.926503473 +0200
+++ gcc/target.def  2024-05-09 20:27:16.294780780 +0200
@@ -6498,7 +6498,7 @@ is in effect.  The default is to return
  hook_bool_void_false)

 /* Returns true if target may use atexit in the same manner as
-   __cxa_atexit  to register static destructors.  */
+   __cxa_atexit to register static destructors.  */
 DEFHOOK
 (use_atexit_for_cxa_atexit,
  "This hook returns true if the target @code{atexit} function can be used\n\
@@ -6509,6 +6509,17 @@ unloaded. The default is to return false
  bool, (void),
  hook_bool_void_false)

+/* Returns modified FUNCTION_TYPE for cdtor callabi.  */
+DEFHOOK
+(adjust_cdtor_callabi_fntype,
+ "This hook returns a possibly modified @code{FUNCTION_TYPE} for arguments\n\
+to @code{__cxa_atexit}, @code{__cxa_thread_atexit} or @code{__cxa_throw}\n\
+function pointers.  ABIs like mingw32 require special attributes to be added\n\
+to function types pointed to by arguments of these functions.\n\
+The default is to return the passed argument unmodified.",
+ tree, (tree fntype),
+ default_cxx_adjust_cdtor_callabi_fntype)
+
 DEFHOOK
 (adjust_class_at_definition,
 "@var{type} is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just\n\
--- gcc/targhooks.h.jj  2024-05-09 10:30:54.941503269 +0200
+++ gcc/targhooks.h 2024-05-09 20:27:16.315780505 +0200
@@ -65,6 +65,7 @@ extern machine_mode default_mode_for_suf

 extern tree default_cxx_guard_type (void);
 extern tree default_cxx_get_cookie_size (tree);
+extern tree default_cxx_adjust_cdtor_callabi_fntype (tree);

 extern bool hook_pass_by_reference_must_pass_in_stack
   (cumulative_args_t, const function_arg_info &);
--- gcc/targhooks.cc.jj 2024-05-09 10:30:54.927503459 +0200
+++ gcc/targhooks.cc2024-05-09 20:27:16.338780204 +0200
@@ -329,6 +329,14 @@ default_cxx_get_cookie_size (tree type)
   return cookie_size;
 }

+/* Returns modified FUNCTION_TYPE for cdtor callabi.  */
+
+tree
+default_cxx_adjust_cdtor_callabi_fntype (tree fntype)
+{
+  return fntype;
+}
+
 /* Return true if a parameter must be passed by reference.  This version
of the TARGET_PASS_BY_REFERENCE hook uses just MUST_PASS_IN_STACK.  */

--- gcc/d

Re: [PATCH net] selftests: net: move amt to socat for better compatibility

On Thu, 09 May 2024 19:39:36 +0200 Paolo Abeni wrote:
> Acked-by: Paolo Abeni

Thanks!

> As a minor note, shell variable expansion should already trim all the
> trailing/leading spaces from the socat command output, so it should not
> be necessary replace the string comparison with the grep command:
> 
>   RESULT6=$(ip netns exec "${LISTENER}" timeout 15 socat - 
> UDP6-LISTEN:6000,readbytes=128 || true)
>   if [ "$RESULT6" == "2001:db8:3::2" ]; then

99% sure I tried that exact thing, but it wasn't enough.

$ msg=$(socat - UDP4-LISTEN:1234,readbytes=128)
$ echo ">$msg<"
>127.0.0.1  
> <
$ msg=$msg
$ echo ">$msg<"
>127.0.0.1  
> <
$ msg=$(echo $msg)
$ echo ">$msg<"
>127.0.0.1<


IOW we'd need to feed it thru an echo or some such.
Possibly something like: [ $(echo $msg) == "127.0.0.1" ]
But I personally find that a touch too magical.
The grep works 路️

Re: [PATCH] selftests: Add _GNU_SOURCE definition when including kselftest_harness.h