Re: [PATCH] Replace IgnoreSize/DefaultSize with MnemonicSize

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Mar 4, 2020 at 8:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 03.03.2020 20:31, H.J. Lu wrote:
> > On Tue, Mar 3, 2020 at 9:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 03.03.2020 18:15, H.J. Lu wrote:
> >>> On Tue, Mar 3, 2020 at 6:50 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 03.03.2020 15:09, H.J. Lu wrote:
> >>>>> I am testing this patch with GCC 8.  I will check it in if it fixes
> >>>>> regressions in GCC 8 testsuits:
> >>>>>
> >>>>> https://gcc.gnu.org/ml/gcc-regression/2020-03/msg00008.html
> >>>>>
> >>>>> H.J.
> >>>>> ---
> >>>>> According to gas manual, suffix in instruction mnemonics isn't always
> >>>>> required:
> >>>>>
> >>>>> When there is no sizing suffix and no (suitable) register operands to
> >>>>> deduce the size of memory operands, with a few exceptions and where long
> >>>>> operand size is possible in the first place, operand size will default
> >>>>> to long in 32- and 64-bit modes.
> >>>>
> >>>> Nothing there says that this defaulting is to happen silently. Yet
> >>>> _that's_ what my earlier changes altered. The defaulting is still
> >>>> the same. And no - SUCH CASES SHOULD NOT GO SILENTLY, neither here
> >>>> nor in the MOVSX/MOVZX case. Ambiguities should _always_ be
> >>>> pointed out by the assembler. (There may be [and there is] a mode
> >>>> in which this goes silently, to be enabled at the programmer's
> >>>> risk.)
> >>>
> >>> It is not going to happen in AT&T syntax.   Gas has to support older GCC
> >>> without any warnings.
> >>
> >> Why? What's wrong with pointing out issues even with compiler
> >> generated code? In fact iirc gcc used to be buggy in regard of
> >> these conversion instructions, and the assembler change helped
> >> spot this.
> >
> > I appreciate your intention.  But the primary goal of gas is to serve GCC.
> > In this case, there are ino issues with integer conversion in GCC 8 and we
> > have to support existing GCC 8.  Issue a warning in AT&T syntax is not
> > really an option here.
>
> The initial release of gcc 8 was still buggy, and you can then
> extrapolate this to older versions. If code is to be compiled
> warning-free with older releases, gcc should get respective
> backports. Hiding actual bugs (because of gcc shortcomings) is
> not really an option here (to use your wording).

I am testing GCC 8.4 release and there are no integer conversion
bugs.

> Furthermore - if you were to discover more problems with even
> older gcc versions, would you then "declare" all those insns
> as exceptions too? Such an approach doesn't make any sense to
> me.
>

If you find a GCC codegen bug, please open a GCC bug and I will
fix it.

-- 
H.J.