On 25.06.2023 08:41, Hongtao Liu wrote:
> On Sun, Jun 25, 2023 at 2:35 PM Hongtao Liu wrote:
>>
>> On Sun, Jun 25, 2023 at 2:25 PM Jan Beulich wrote:
>>>
>>> On 25.06.2023 07:12, Hongtao Liu wrote:
>>>> On Wed, Jun 21, 2023 at 2:
On 06.11.2023 23:29, David Malcolm wrote:
> Here's a patch for gas in binutils that makes it use libdiagnostics
> (with some nasty hardcoded paths to specific places on my hard drive
> to make it easier to develop the API).
>
> For now this hardcodes adding two sinks: a text sink on stderr, and
>
On 07.11.2023 15:32, David Malcolm wrote:
> On Tue, 2023-11-07 at 11:03 +0100, Jan Beulich wrote:
>> On 06.11.2023 23:29, David Malcolm wrote:
>>> All of the locations are just lines; does gas do column numbers at
>>> all?
>>> (or ranges?)
>>
>> It
On 21.11.2023 23:20, David Malcolm wrote:
> @@ -101,6 +109,29 @@ had_warnings (void)
>return warning_count;
> }
>
> +#if USE_LIBDIAGNOSTICS
> +static diagnostic_manager *diag_mgr;
> +#endif
> +
> +void messages_init (void)
> +{
> +#if USE_LIBDIAGNOSTICS
> + diag_mgr = diagnostic_manager_new
Much like AT_HWCAP is already provided in case the platform headers
don't have the value (yet).
libgcc/
* config/aarch64/cpuinfo.c: Provide AT_HWCAP2.
---
Observed as build failure with 14.1.0, so may want backporting there.
--- a/libgcc/config/aarch64/cpuinfo.c
+++ b/libgcc/config/aarch
For one setting ld_ver in a conditional (no in-tree ld) when it's used,
for x86 at least, in unconditional ways can't be quite right. And then
prefixing relative paths to binaries with ${objdir}/, when ${objdir}
nowadays resolves to just .libs, can at best be a leftover that wasn't
properly cleaned
Present wording has misled people to believe the ?: operator would be
evaluating all three of the involved expressions.
gcc/
* doc/extend.texi: Clarify __builtin_choose_expr() similarity to
the ?: operator.
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14962,9 +14962,9
Quite a while ago configure.in go renamed to configure.ac in all of
binutils' subtrees - allow for both when checking for that case while
configuring.
gcc/
2015-07-15 Jan Beulich
* acinclude.m4: Replace configure.in by configure.[ai][cn].
* configure.ac: Lik
>>> On 15.07.15 at 18:07, wrote:
> On Wed, Jul 15, 2015 at 1:03 AM, Jan Beulich wrote:
>> --- a/gcc/acinclude.m4
>> +++ b/gcc/acinclude.m4
>> @@ -390,7 +390,7 @@ AC_DEFUN([_gcc_COMPUTE_GAS_VERSION],
>> [gcc_cv_as_bfd_srcdir=`echo $srcdir |
Make up to 3.80 (documented as minimal permitted version) doesn't
support "else if...".
2015-07-16 Jan Beulich
* config/t-softfp: Split up "else ifneq".
--- a/libgcc/config/t-softfp
+++ b/libgcc/config/t-softfp
@@ -103,7 +103,8 @@ ifeq ($(enable_share
>>> On 17.07.15 at 06:26, wrote:
> Which imported packages use configure.in? I'm happy to submit patches
> for those, too.
The answer to this may not even matter - consuming components
(like gcc is in respect to binutils) shouldn't assume only the newer
name is used: It should remain to be possi
12-10 Jan Beulich
* varasm.c (get_variable_section): Validate initializer in
named .bss-like sections.
gcc/testsuite/
2015-12-10 Jan Beulich
* gcc.dg/bss.c: New.
--- 2015-12-09/gcc/testsuite/gcc.dg/bss.c
+++ 2015-12-09/gcc/testsuite/gcc.dg/bss.c
@@ -0,0 +1,8 @@
+/
cking bad behavior started with 4.6.x (4.5.3 was
still okay), but generated code got quite a bit worse as of 4.9.0.
[v3: Re-base to current trunk.]
[v2: Drop inclusion of hard register variables, as requested by
Jakub and Richard.]
gcc/
2015-12-10 Jan Beulich
* cfgexp
>>> On 10.12.15 at 14:53, wrote:
> On 12/10/2015 01:38 PM, Jan Beulich wrote:
>> --- 2015-12-09/gcc/cfgexpand.c
>> +++ 2015-12-09/gcc/cfgexpand.c
>> @@ -1544,12 +1544,15 @@ static HOST_WIDE_INT
>> expand_one_var (tree var, bool toplevel, bool really_expa
gcc/c/
2015-12-10 Jan Beulich
* c-fold.c (c_fully_fold_internal): Also emit shift count
warnings for vector types.
* c-typeck.c (build_binary_op): Likewise.
--- 2015-12-09/gcc/c/c-fold.c
+++ 2015-12-09/gcc/c/c-fold.c
@@ -320,8 +320,6 @@ c_fully_fold_internal (tree expr
>>> On 02.12.17 at 01:13, wrote:
> On Fri, Dec 01, 2017 at 02:54:28PM +0100, Jakub Jelinek wrote:
>> Will try this:
>
> That failed to bootstrap, but here is an updated version that passed
> bootstrap/regtest on x86_64-linux and i686-linux, ok for trunk?
Thanks for the quick fix. A related quest
Simply mirror the MODE_XI logic of handling unaligned operands in
mov_internal into MODE_TI / MODE_OI handling.
gcc/
2017-12-13 Jan Beulich
* sse.md (mov_internal): Tighten condition for when to use
vmovdqu for TI and OI modes.
gcc/testsuite/
2017-12-13 Jan Beulich
>>> On 13.12.17 at 10:33, wrote:
> Simply mirror the MODE_XI logic of handling unaligned operands in
> mov_internal into MODE_TI / MODE_OI handling.
>
> gcc/
> 2017-12-13 Jan Beulich
>
> * sse.md (mov_internal): Tighten condition for when to use
>
>>> On 02.01.18 at 11:05, wrote:
>> >>> On 13.12.17 at 10:33, wrote:
>> > Simply mirror the MODE_XI logic of handling unaligned operands in
>> > mov_internal into MODE_TI / MODE_OI handling.
>> >
>> > gcc/
>> > 2017-12-13 J
>>> "H.J. Lu" 04/09/18 9:09 PM >>>
>On Mon, Apr 9, 2018 at 11:37 AM, Jakub Jelinek wrote:
>> BTW, -masm=intel seems to be in quite bad shape even in the assembler, in
>> various testcases I'm getting errors like on the following reduced one:
>> int k1, xmm0;
>> int foo (void) { return k1; }
>> in
>>> On 10.04.18 at 08:42, wrote:
> On Mon, Apr 09, 2018 at 11:50:14PM -0600, Jan Beulich wrote:
>> >> As ICC generates the same assembly on the instructions:
>> >> mov eax, DWORD PTR k1[rip]
>> >> ...
>> >> mov ea
cking bad behavior started with 4.6.x (4.5.3 was
still okay), but generated code got quite a bit worse as of 4.9.0.
gcc/
2014-10-23 Jan Beulich
* cfgexpand.c (expand_one_var): Exclude static, external, and
hard register variables when adjusting stack alignment related
>>> On 23.10.14 at 08:50, wrote:
> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
>> Function (or more narrow) scope static variables (as well as others not
>> placed on the stack) should also not have any effect on the stack
>> alignment. I noticed
>>> On 23.10.14 at 20:13, wrote:
> On 10/23/14 01:09, Jan Beulich wrote:
>>>>> On 23.10.14 at 08:50, wrote:
>>> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
>>>> Function (or more narrow) scope static variables (as well as others no
>>> On 24.10.14 at 11:10, wrote:
> On Fri, Oct 24, 2014 at 11:01 AM, Jan Beulich wrote:
>>>>> On 23.10.14 at 20:13, wrote:
>>> On 10/23/14 01:09, Jan Beulich wrote:
>>>>>>> On 23.10.14 at 08:50, wrote:
>>>>> On Thu, Oct 2
>>> On 24.10.14 at 11:52, wrote:
> On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek wrote:
>> On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
>>> >> For something in static storage, this seems OK. However, I think a hard
>>> >> register variable ought to be left alone -- even if w
cking bad behavior started with 4.6.x (4.5.3 was
still okay), but generated code got quite a bit worse as of 4.9.0.
[v2: Drop inclusion of hard register variables, as requested by
Jakub and Richard.]
gcc/
2014-10-24 Jan Beulich
* cfgexpand.c (expand_one_var): Exclude stati
gcc/testsuite:
2014-10-30 Jan Beulich
* gcc.target/i386/i386.exp: Extend option set to test
vect-args.c with to include -mavx, -mavx2, and -mavx512f.
* gcc.target/i386/vect-args.c: Add AVX* modes and tests.
--- a/gcc/testsuite/gcc.target/i386/i386.exp
+++ b/gcc
no
explicit clobbers can again be made subject to CSE.
gcc:
2014-10-31 Jan Beulich
* config/i386/i386.c (ix86_target_string): Add
-mno-default-asm-clobbers.
(ix86_valid_target_attribute_inner_p): Handle
-m{,no-}default-asm-clobbers.
(ix86_md_asm_c
>>> On 31.10.14 at 20:02, wrote:
> On 10/31/14 02:07, Jan Beulich wrote:
>> While it always seemed wrong to me that there's no way to avoid the
>> default "flags" and "fpsr" clobbers, the regression the fix for
>> PR/60663 introduced (see P
effect of the tests, but these are ones helping make sure the assembler
actually still assembles correctly the output after the changes here.
gcc/
2018-12-21 Jan Beulich
* config/i386/i386.md (rex64suffix): Add L suffix for SI.
* config/i386/sse.md (sse_cvtss2si,
sse
ermit {%k0} - where they get touched here anyway this
gets fixed at the same time.
gcc/
2018-12-21 Jan Beulich
* config/i386/sse.md
(_cmp3,
_cmp3,
_ucmp3,
_ucmp3,
avx512f_vmcmp3,
avx512f_vmcmp3_mask,
avx512f_maskcmp3,
They are no different from their VAESENC{,LAST} counterparts in this
regard.
gcc/
2018-12-21 Jan Beulich
* config/i386/sse.md (vaesdec_, vaesdeclast_): Allow
memory input.
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -21659,7 +21659,7 @@
[(set
>>> On 21.12.18 at 14:55, wrote:
> On Fri, Dec 21, 2018 at 9:08 AM Jan Beulich wrote:
>>
>> For 64-bit these should not be emitted without suffix in AT&T mode (as
>> being ambiguous that way); the suffixes are benign for 32-bit. For
>> consistency al
- the affine transformations are not commutative (the two source
operands have entirely different meaning)
- there's no need for three alternatives
- the nonimmediate_operand/Bm combination can better be vector_operand/m
gcc/
2019-06-27 Jan Beulich
* config/i386/s
SSE2 is the required prereq of the builtins; as x86-64 has SSE2 enabled
anyway, the test failure was noticable on 32-bit builds only.
gcc/testsuite/
2019-06-27 Jan Beulich
* gcc.target/i386/gfni-4.c: Pass -msse2.
--- a/gcc/testsuite/gcc.target/i386/gfni-4.c
+++ b/gcc/testsuite
immediate is only one of many possible ones; I was
trying to make the insn here distinguishable from the pre-existing uses
of vpternlog.
gcc/
2019-06-27 Jan Beulich
* config/i386/sse.md (_cvtmask2):
Require only AVX512F.
(*_cvtmask2): Likewise. Add
alternative
NOT on vectors of integers does not require loading a constant vector of
all ones into a register - VPTERNLOG can be used here (and could/should
be further used to carry out other binary and ternary logical operations
which don't have a special purpose instruction).
gcc/
2019-06-27 Jan Be
e just m on the
first and replace nonimmediate_operand by vector_operand.
gcc/
2019-06-27 Jan Beulich
* config/i386/sse.md (sse2_cvtpd2pi, sse2_cvttpd2pi): Use
vector_operand plus "m" constraint.
gcc/testsuite/
2019-06-27 Jan Beulich
* gcc.target/i386/
Without these constraints asm() can't make use of mask registers.
gcc/
2019-06-27 Jan Beulich
* config/i386/constraints.md: Remove @internal from "k" and
"Yk".
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -79,10 +79,10
>>> On 27.06.19 at 12:11, wrote:
> Without these constraints asm() can't make use of mask registers.
Similarly it is entirely unclear to me how to use e.g. v4fmaddps or
vp2intersectd in asm(): For the former the respective "Yh"
constraint was dropped (oddly enough leaving its comment line in
plac
>>> On 27.06.19 at 12:20, wrote:
> On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
>>
>> - the affine transformations are not commutative (the two source
>> operands have entirely different meaning)
>> - there's no need for three alternatives
>
>>> On 27.06.19 at 12:58, wrote:
> On Thu, Jun 27, 2019 at 12:49 PM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 12:20, wrote:
>> > On Thu, Jun 27, 2019 at 10:57 AM Jan Beulich wrote:
>> >>
>> >> - the affine transformations
>>> On 27.06.19 at 13:09, wrote:
> On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
>>
>> Without these constraints asm() can't make use of mask registers.
>
> asm should be deprecated. We have intrinsics for this purpose.
While maybe not explicitly app
>>> On 27.06.19 at 14:00, wrote:
> On Thu, Jun 27, 2019 at 1:46 PM Jan Beulich wrote:
>>
>> >>> On 27.06.19 at 13:09, wrote:
>> > On Thu, Jun 27, 2019 at 12:11 PM Jan Beulich wrote:
>> >>
>> >> Without these constraints asm() ca
The affine transformations are not commutative (the two source operands
have entirely different meaning).
Also the nonimmediate_operand predicate can better be vector_operand.
gcc/
2019-06-28 Jan Beulich
* config/i386/sse.md (vgf2p8affineinvqb_,
vgf2p8affineqb_): Drop
There's no need for three alternatives: "v" without TARGET_AVX512F is
the same as "x".
gcc/
2019-06-28 Jan Beulich
* config/i386/sse.md (vgf2p8affineinvqb_,
vgf2p8affineqb_): Eliminate redundant
alternative.
---
v2: New, split off from prev
7;t have a special purpose instruction).
>
> gcc/
> 2019-06-27 Jan Beulich
>
> * config/i386/sse.md (ternlogsuffix): New.
> (one_cmpl2): Don't force CONSTM1_RTX into a register when
> AVX512F is in use.
> (one_cmpl2): New.
>
> --- a/gcc/
Q} are available only with AVX512DQ).
>
> Note that the chosen immediate is only one of many possible ones; I was
> trying to make the insn here distinguishable from the pre-existing uses
> of vpternlog.
>
> gcc/
> 2019-06-27 Jan Beulich
>
> * config/i386/
lping make sure the assembler
actually still assembles correctly the output after the changes here.
---
v2: Don't drop (redundant) suffixes from *2SI conversions. Adjust
changes to testsuite accordingly.
gcc/
2019-01-10 Jan Beulich
* config/i386/i386.md (rex64suffix): Add L su
While either of the last two operands can be in memory, they can't be
swapped.
gcc/
2017-04-28 Jan Beulich
* config/i386/sse.md (xop_vpermil23): Use alternatives.
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17092,12 +17092,12 @@
(set_attr "
>>> On 01.05.17 at 11:09, wrote:
> On Fri, Apr 28, 2017 at 4:51 PM, Jan Beulich wrote:
>> While either of the last two operands can be in memory, they can't be
>> swapped.
>>
>> gcc/
>> 2017-04-28 Jan Beulich
>>
>> * config
I cannot see how without allowing the compiler to use SSE2 instructions
(as is done by all other tests for this PR scanning for particular
instructions) this test could ever have succeeded anywhere.
gcc/testsuite/
2016-07-01 Jan Beulich
* gcc.target/i386/pr65105-2.c: Add -msse2
Just like gas, which has recently learned to reject such initializers,
gcc shouldn't accept such either.
---
v2: Use dg-require-named-sections.
gcc/
2016-07-01 Jan Beulich
* varasm.c (get_variable_section): Validate initializer in
named .bss-like sections.
gcc/testsuite/
Irrespective of the use of -o this so far resulted in "error: output
filename specified twice", since cc1_options already produces a -o
option when -S was specified.
gcc/
2016-07-01 Jan Beulich
* varasm.c (get_variable_section): Validate initializer in
named .bss-lik
Hello,
is there a reason why in output constraints such gets accepted silently
(by parse_output_constraint()) while parse_input_constraint() issues
an error if it encounters any? The latter behavior seems more forward
compatible to me (such that if any such characters acquire meaning,
one can prob
>>> On 01.07.16 at 15:36, wrote:
> On 07/01/2016 10:21 AM, Jan Beulich wrote:
>> Just like gas, which has recently learned to reject such initializers,
>> gcc shouldn't accept such either.
>> ---
>> v2: Use dg-require-named-sections.
>>
>> gc
>>> On 01.07.16 at 15:44, wrote:
> On 07/01/2016 03:42 PM, Jan Beulich wrote:
>>>>> On 01.07.16 at 15:36, wrote:
>
>>> Looks ok, except why the empty dg-options string in the testcase?
>>
>> Because I've seen in it that way in various ot
gcc/c/
2016-07-01 Jan Beulich
* c-fold.c (c_fully_fold_internal): Also emit shift count
warnings for vector types.
* c-typeck.c (build_binary_op): Likewise.
gcc/testsuite/
2016-07-01 Jan Beulich
* gcc.dg/vshift-6.c, gcc.dg/vshift-7.c: New.
--- 2016-06-30
>>> On 01.07.16 at 17:17, wrote:
> On 07/01/2016 10:22 AM, Jan Beulich wrote:
>> Irrespective of the use of -o this so far resulted in "error: output
>> filename specified twice", since cc1_options already produces a -o
>> option when -S was specifie
d be better.
I didn't really understand what was meant here, i.e. how the
proposed alternative was supposed to look like in an actual
asm().
gcc/
2016-07-06 Jan Beulich
* cfgexpand.c (expand_asm_stmt): Cope with negative register
numbers.
* config/i386/i386
chard.]
gcc/
2015-12-11 Jan Beulich
* cfgexpand.c (expand_one_var): Exit early for static and
external variables when adjusting stack alignment related.
gcc/testsuite/
2015-12-11 Jan Beulich
* gcc.c-torture/execute/stkalign.c: New.
--- 2015-12-09/gcc/cfgexpand.c
+++ 20
>>> On 11.12.15 at 21:40, wrote:
> On 12/11/2015 12:28 AM, Jan Beulich wrote:
>> gcc/c/
>> 2015-12-10 Jan Beulich
>>
>> * c-fold.c (c_fully_fold_internal): Also emit shift count
>> warnings for vector types.
>> * c-typeck.c (build
>>> On 14.12.15 at 09:35, wrote:
> On Fri, Dec 11, 2015 at 2:54 PM, Bernd Schmidt wrote:
>> On 12/11/2015 02:48 PM, Jan Beulich wrote:
>>>
>>> Function (or more narrow) scope static variables (as well as others not
>>> placed on the stack)
>>> On 14.12.15 at 10:07, wrote:
> Note that we also record alignment to make sure we can spill to properly
> aligned stack slots.
>
> I don't see why we don't need to do that for used statics/externs. That is
> are you sure we never need to spill a var of their type?
No, I'm not, but note that
able to figure out possible valid
> qualifiers to use here.
>
> gcc/
> 2015-12-10 Jan Beulich
>
> * varasm.c (get_variable_section): Validate initializer in
> named .bss-like sections.
>
> gcc/testsuite/
> 2015-12-10 Jan Beulich
>
>
This is so that use of symbols referenced in these asm()-s can be
properly tracked by the compiler, just like is the case for all other
asm()-s. I'm particularly looking forward to use this in the Linux
kernel. It is certainly not very useful in PIC code, at least not with
some extra care.
Changes
Split out LTO's writing of top level asm nodes in preparation of extending
what needs to be written out when top level asm-s get enhanced to accept a
limited set of input operands.
gcc/
2011-09-30 Jan Beulich
* lto-cgraph.c (output_cgraph): Remove processing of 'cgraph
gcc/
2011-09-30 Jan Beulich
* c-parser.c (c_parser_simple_asm_expr): Add new second parameter
'inputsp'. Process inputs if caller indicates they are allowed. Adjust
calls to c_parser_asm_operands().
(c_parser_asm_operands): Change type of second param
>>> On 30.09.11 at 14:47, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I&
>>> On 30.09.11 at 14:42, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I
>>> On 30.09.11 at 14:34, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
>> Split out LTO's writing of top level asm nodes in preparation of extending
>> what needs to be written out when top level asm-s get enhanced to accept a
>
>>> On 05.10.11 at 10:54, Jan Hubicka wrote:
>>> we have, like specifying the set of symbols _defined_ by a toplevel
>>> asm, right? I might misremember but sth like
>>>
>>> extern void foo (void);
>>> asm("" "foo");
>>>
>>> was supposed to do the trick. Or should we treat those as outputs
On 19.06.2024 16:01, Jan Beulich wrote:
> Present wording has misled people to believe the ?: operator would be
> evaluating all three of the involved expressions.
>
> gcc/
>
> * doc/extend.texi: Clarify __builtin_choose_expr() similarity to
> the ?: operator.
On 08.10.2024 17:38, Sandra Loosemore wrote:
> On 10/8/24 09:35, Jan Beulich wrote:
>> On 08.10.2024 17:30, Sandra Loosemore wrote:
>>> [snip]
>>>
>>> Hmmm, looking at the complete documentation for this built-in, and the
>>> code, I think I&
Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly
said "..., but we need to emit {evex} prefix in the assembly if AES ISA
is not enabled". Yet it did so only for the TARGET_AES insns. Going from
the alternative chosen in the TARGET_VAES insns isn't quite right: If
AES is (als
On 08.10.2024 17:30, Sandra Loosemore wrote:
> On 10/8/24 08:12, Jan Beulich wrote:
>> On 19.06.2024 16:01, Jan Beulich wrote:
>>> Present wording has misled people to believe the ?: operator would be
>>> evaluating all three of the involved expressions.
>>>
&g
On 08.10.2024 08:54, Hongtao Liu wrote:
> On Mon, Sep 30, 2024 at 3:33 PM Jan Beulich wrote:
>>
>> Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly
>> said "..., but we need to emit {evex} prefix in the assembly if AES ISA
>> i
On 25.09.2024 10:52, Hongtao Liu wrote:
> On Wed, Sep 25, 2024 at 3:55 PM Jan Beulich wrote:
>>
>> On 25.09.2024 09:38, Hongtao Liu wrote:
>>> On Wed, Sep 25, 2024 at 2:56 PM Jan Beulich wrote:
>>>>
>>>> Commit a79d13a01f8c ("i386: Fix aes/vae
On 25.09.2024 09:38, Hongtao Liu wrote:
> On Wed, Sep 25, 2024 at 2:56 PM Jan Beulich wrote:
>>
>> Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly
>> said "..., but we need to emit {evex} prefix in the assembly if AES ISA
>> i
Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly
said "..., but we need to emit {evex} prefix in the assembly if AES ISA
is not enabled". Yet it did so only for the TARGET_AES insns. Going from
the alternative chosen in the TARGET_VAES insns is wrong for two
reasons:
- if, w
Documentation is pretty clear here: "Require a constant operand and
print the constant expression with no punctuation." See the patches for
further details.
1: fix asm() operand 'c' modifier handling
2: x86: fix asm() operand 'c' modifier handling
Technically for x86 the 2nd patch alone ought to
Documentation is pretty clear here: "Require a constant operand and
print the constant expression with no punctuation." IOW any integer
value of whatever magnitude or sign ought to be acceptable.
---
RFC: If this (doing the change in generic code) is the way to go, in a
few cases arch-specific
Documentation is pretty clear here: "Require a constant operand and
print the constant expression with no punctuation"; the internal use for
condition codes is entirely undocumented. IOW any constant value of
whatever kind, magnitude, or sign ought to be acceptable as long as it's
expressable. Wire
On 21.11.2024 13:03, Jan Beulich wrote:
> Documentation is pretty clear here: "Require a constant operand and
> print the constant expression with no punctuation." See the patches for
> further details.
>
> 1: fix asm() operand 'c' modifier handling
>
On 06.06.2025 17:28, Sandra Loosemore wrote:
> On 6/6/25 00:44, Jan Beulich wrote:
>> As per documentation, even 4.7 ought to suffice. At least 4.13 objects
>> to there being nothing ahead of the first comma in @xref{}.
>> ---
>> The text inserted it merely a guess; I&#
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being a blank between @anchor and the opening curly brace.
---
Noticed with gcc15, so may want backporting.
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -1077,7 +1077,7 @@ condition 1 not covered (true)
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being nothing ahead of the first comma in @xref{}.
---
The text inserted it merely a guess; I'm open to better suggestions.
Noticed with gcc15, so may want backporting.
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.t
On 21.11.2024 13:03, Jan Beulich wrote:
> Documentation is pretty clear here: "Require a constant operand and
> print the constant expression with no punctuation." See the patches for
> further details.
>
> 1: fix asm() operand 'c' modifier handling
>
On 13.06.2023 05:28, Fangrui Song wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/large-data.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-options "-O2 -mcmodel=large -mlarge-data-threshold=4" } */
> +/* { dg-final { scan-assem
Like is already the case for the AVX/AVX2 form, VMOVDDUP - acting on
double precision floating values - is more appropriate to use here, and
it can also result in shorter insn encodings when source is memory or
%xmm0...%xmm7, and no masking is applied (in allowing a 2-byte VEX
prefix then instead o
gcc/
* config/i386/constraints.md: Mention k and r for B.
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -162,7 +162,9 @@
;; g GOT memory operand.
;; m Vector memory operand
;; c Constant memory operand
+;; k TLS address that allows insn using non-
... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
never longer (yet sometimes shorter) than the corresponding VSHUFPS /
VPSHUFD, due to the immediate operand of the shuffle insns balancing the
need for VEX3 in the broadcast ones. When EVEX encoding is required the
broadcast insn
There's no reason to constrain this to AVX512VL, as the wider operation
is not usable for more narrow operands only when the possible memory
source is a non-broadcast one. This way even the scalar copysign3
can benefit from the operation being a single-insn one (leaving aside
moves which the compil
On 14.06.2023 09:41, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
>> never longer (yet sometimes shorter) than the corresponding VSHUFPS /
>>
On 14.06.2023 10:10, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> There's no reason to constrain this to AVX512VL, as the wider operation
>> is not usable for more narrow operands only when the possible memor
The input constraint for the %vmovddup alternative was wrong, as the
upper 16 XMM registers require AVX512VL to be used with this insn. To
compensate, introduce a new alternative permitting all 32 registers, by
broadcasting to the full 512 bits in that case if AVX512VL is not
available.
gcc/
On 15.06.2023 07:23, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
>>
>> On 14.06.2023 09:41, Hongtao Liu wrote:
>>> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
>>> wrote:
>>>>
>>>> ... in vec_d
On 15.06.2023 09:45, Hongtao Liu wrote:
> On Thu, Jun 15, 2023 at 3:07 PM Uros Bizjak via Gcc-patches
> wrote:
>> On Thu, Jun 15, 2023 at 8:03 AM Jan Beulich via Gcc-patches
>> wrote:
>>> +case 3:
>>> + return "%vmovddup\t{%1, %0|%0, %1}";
&
The input constraint for the %vmovddup alternative was wrong, as the
upper 16 XMM registers require AVX512VL to be used with this insn. To
compensate, introduce a new alternative permitting all 32 registers, by
broadcasting to the full 512 bits in that case if AVX512VL is not
available.
gcc/
1 - 100 of 177 matches
Mail list logo
