Any concrete plans after the GDB BoF?

[anix]

Dear：
thank you very mach for the program.
the following is description for bug.
# The source code convert between single-precision floating-point(32-bit) and half-precision floating-point (16-bit).
.section .data
m32fp:    .float 142,    580,    36832,  65504
half:    .short 0x5870, 0x6080, 0x787f, 0x7bff
h1:    .short 0, 0 ,0, 0
m1:    .float 0, 0, 0, 0
.section .text
.globl _start
_start:
    nop
    movaps m32fp, %xmm0
    vcvtps2ph $0, %xmm0, h1        #imm8=$0; h1 {m64}


    vcvtph2ps h1, %xmm1
    movups %xmm1, m1
   
next:    movl $1, %eax
    movl $0, %ebx
    int $0x80
# the source code end here.


# results under GNU Debugger (gdb)
(gdb) x/4fw &m32fp
0x804a000:    142    580    36832    65504
(gdb) x/4fw &m1
0x804a020:    142    580    36832    65504
(gdb) x/4fh &half
0x804a010:    22640    24704    30847    31743
(gdb) x/4fh &h1
0x804a018:    22640    24712    30847    31743
(gdb) x/4xw &m32fp
0x804a000:    0x430e0000    0x44110000    0x470fe000    0x477fe000
(gdb) x/4xw &m1
0x804a020:    0x430e0000    0x44110000    0x470fe000    0x477fe000
(gdb) x/4xh &half
0x804a010:    0x5870    0x6080    0x787f    0x7bff
(gdb) x/4xh &h1
0x804a018:    0x5870    0x6088    0x787f    0x7bff
# the results of half-precision data (half, h1) by gdb  are mistakes, or instruct me
# All above under IA-32 , OS is centos (32-bit), GNU as and gdb are  also 32-bit.
hope your return.
                        Niu Wensheng
                         2023.02.16

---Original---
From: "Joel Brobecker via Gdb"<gdb@sourceware.org>
Date: Thu, Feb 16, 2023 12:14 PM
To: "Andrew Burgess"<aburgess@redhat.com>;
Cc: "Joel Brobecker"<brobecker@adacore.com>;"Luis Machado"<luis.machado@arm.com>;"Mark Wielaard"<mark@klomp.org>;"Simon Marchi"<simark@simark.ca>;"Simon Marchi via Gdb"<gdb@sourceware.org>;
Subject: Re: Any concrete plans after the GDB BoF?


> > As long as the the tool is able to do the formatting of a given file
> > using only that one file, the git-hooks are ready. There is a
> > style_checker option which is currently calling a script that does
> > nothing. But if we have some tools that check things such as formatting,
> > copyright header format, etc, it's easy to insert them and reject
> > the commit.
> >
> > The problem is that this arrives too late in the process, IMO, because
> > by then, the review has already gone through. For a formatting issue,
> > one could argue that the change is trivial, and therefore automatically
> > re-approved, but this is not ideal.
> 
> Whether the commit should be reformatted and auto-approved is orthogonal
> I think to whether we should have an auto-format checked as part of the
> commit hook.
> 
> As long as folk are able to manually push to master then the process is
> open to (honest) user mistakes, and we should, as far as possible aim to
> have systems in place to guard against those mistakes.
> 
> So having git refuse to accept a commit that is incorrectly formatted
> would be a good thing; though I 100% agree with you that ideally we
> would ALSO have tools that could auto-check the formatting earlier in
> the process and bring that to the developers attention.

Agreed. If we want to ensure correct formatting, we need to check for it
before the commit gets pushed. The earlier, the better.

> > Good or bad, my concern is that the younger generation views emails
> > as antiquated and at the same time they have grown up learning about
> > collaboration using systems such as GitLab or GitHub.
> 
> I'd avoid the word 'antiquated' as it (too me) seems to have negative
> connotations.

I agree with that, and was only using this word in the context of
me putting myself in the shoes of those who shared this feedback
with me. Personally, I love email. But truly, some of the younger
generation I talked to simply do not understand our reluctance to
switch to what they believe to be superior technology. As far as
code collaboration goes, they truly see email as a thing of the past.

Having gone through a transition from email-based review to reviews
through a dedicated system, I have to say that it hurt at first,
but generally speaking, I think it was a huge boost overall.

> But I agree, many developers are familiar with a pull-request
> development model, and I think it has many advantages over our current
> way of doing things, I'd be very much in favour of switching to a PR
> style system.
> 
> That doesn't mean there aren't also advantages to how we do things
> today.

Agreed also.

-- 
Joel