Also pass -mno-sse to vect8-ret.c to disable XMM load/store when running
GCC tests with "-march=x86-64 -m32".
* gcc.target/i386/vect8-ret.c: Also pass -mno-sse.
---
gcc/testsuite/gcc.target/i386/vect8-ret.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/
* gcc.target/i386/pieces-memcpy-10.c: New test.
* gcc.target/i386/pieces-memcpy-11.c: Likewise.
* gcc.target/i386/pieces-memcpy-12.c: Likewise.
* gcc.target/i386/pieces-memcpy-13.c: Likewise.
* gcc.target/i386/pieces-memcpy-14.c: Likewise.
* gcc.targe
> On Jul 1, 2021, at 9:04 AM, Richard Biener wrote:
>
> On Thu, Jul 1, 2021 at 3:45 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
>>> wrote:
> On Jun 30, 2021
> On Jul 1, 2021, at 9:09 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
>>> wrote:
> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
On Thu, 1 Jul 2021, Jason Merrill wrote:
> On 6/30/21 5:27 PM, Patrick Palka wrote:
> > Here any_template_parm_r is failing to mark the template parameters
> > that're implicitly used by the unqualified use of 'd' inside the constraint,
> > because the code to do so assumes each level of a templat
Michael Matz writes:
> Hello,
>
> I haven't followed this thread too closely, in particular I haven't seen
> why the current form of the .DEFERRED_INIT call was chosen or suggested,
> but it triggered my "well, that's obviously wrong" gut feeling; so sorry
> for stating something which might be
On Thu, 2021-07-01 at 14:53 +0200, Richard Biener wrote:
> On Thu, Jul 1, 2021 at 12:16 PM Trevor Saunders <
> tbsau...@tbsaunde.org> wrote:
> >
> > On Wed, Jun 30, 2021 at 11:13:23AM -0400, David Malcolm wrote:
> > > On Wed, 2021-06-30 at 01:35 -0400, Trevor Saunders wrote:
> > > > This makes it
Hi, Michael,
> On Jul 1, 2021, at 9:40 AM, Michael Matz wrote:
>
> Hello,
>
> I haven't followed this thread too closely, in particular I haven't seen
> why the current form of the .DEFERRED_INIT call was chosen or suggested,
> but it triggered my "well, that's obviously wrong" gut feeling; s
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 16:14:30 +0200
>
> >> If I understand the notes correct, the '.' should be also hidden by e.g.
> >> Emacs.
> >
> > No, it doesn't. The actual text in the Info file is:
> >
> >
Hi,
This is a placeholder name ahead of any CTF implementation on
LLVM (which sets Darwin ABI). Ideally, we would get agreement
on this choice (or any replacement) before GCC12 is shipped.
tested on Darwin18,
pushed to master, thanks,
Iain
PR debug/101283 - Several tests fail on Darwin with -gc
On 7/1/21 5:44 PM, Eli Zaretskii wrote:
Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
From: Martin Liška
Date: Thu, 1 Jul 2021 16:14:30 +0200
If I understand the notes correct, the '.' should be also hidden by e.g. Emacs.
No, it doesn't. The actual text in the Info
On Thu, 2021-07-01 at 11:40 -0400, David Malcolm wrote:
> On Thu, 2021-07-01 at 14:53 +0200, Richard Biener wrote:
> > On Thu, Jul 1, 2021 at 12:16 PM Trevor Saunders <
> > tbsau...@tbsaunde.org> wrote:
> > >
> > > On Wed, Jun 30, 2021 at 11:13:23AM -0400, David Malcolm wrote:
> > > > On Wed, 2021
Hello,
On Thu, 1 Jul 2021, Richard Sandiford wrote:
> Well, it does feel like this is pressing the reset button on a thread
> whose message count is already in the high double figures. There's a
> risk that restarting the discussion now is going to repeat a lot of the
> same ground, probably at
We cannot fully support packed record layout in -fdump-ada-spec, as packing
in C and Ada does not behave the same, so we issue a warning. But some simple
cases are OK and can actually be handled without much work.
Tested on x86-64/Linux, applied on the mainline.
2021-07-01 Eric Botcazou
c
This extends the type name conflict detection mechanism to variables.
Tested on x86-64/Linux, applied on the mainline.
2021-07-01 Eric Botcazou
c-family/
* c-ada-spec.c (check_name): Rename into...
(check_type_name_conflict): ...this. Minor tweak.
(dump_ada_function_
This is a minor regression present on mainline and 11 branch, whereby the
value of the Enum_Rep attribute is always unsigned.
Tested on x86-64/Linux, applied on the mainline and 11 branch.
2021-07-01 Eric Botcazou
PR ada/101094
* exp_attr.adb (Get_Integer_Type): Return an in
Michael Matz writes:
> Hello,
>
> On Thu, 1 Jul 2021, Richard Sandiford wrote:
>
>> Well, it does feel like this is pressing the reset button on a thread
>> whose message count is already in the high double figures. There's a
>> risk that restarting the discussion now is going to repeat a lot of
> > I think this version addresses most of your concerns.
>
> Thanks, looking good. I'll fuss with it a bit and commit it soon.
Awesome!
Andrew
Hi, Richard,
> On Jul 1, 2021, at 11:23 AM, Richard Sandiford
> wrote:
>
> Michael Matz writes:
>> Hello,
>>
>> On Thu, 1 Jul 2021, Richard Sandiford wrote:
>>
>>> Well, it does feel like this is pressing the reset button on a thread
>>> whose message count is already in the high double figu
Hi,
a big difference between ELF and PE-COFF is that, with the latter, you can
build position-independent executables or DLLs without generating PIC; as a
matter of fact, flag_pic has historically been forced to 0 for 32-bit:
/* Don't allow flag_pic to propagate since gas may produce invalid co
> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> From: Martin Liška
> Date: Thu, 1 Jul 2021 18:04:24 +0200
>
> > Emacs doesn't hide the period. But there shouldn't be a period to
> > begin with, since it's the middle of a sentence. The correct way of
> > writing this i
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and what
to reject for which Fortran standard.
Now committed as 5c17042e880a5d1a3eb261f73e1b9da0c1aa2641
https://gcc.gnu.org/gcc-12/changes.html
Tobias
On 29.06.21 18:38, Julian Brown wrote:
On Tue, 29 Jun 2021 17:34:00 +0200
Tobias Burnus wrote:
This documents AMD GCN's new much-more complete TI-mode
(__int128_t) support, that was as v2
Add BTF_KIND_FLOAT, a new BTF type kind which has recently stabilized in
the linux kernel [1]. This kind is used for encoding floating point
types, and is of particular use when generating BTF for some s390
arch-specific kernel headers.
Also update some BTF tests which previously used floating poi
On July 1, 2021 4:40:11 PM GMT+02:00, Michael Matz wrote:
>Hello,
>
>I haven't followed this thread too closely, in particular I haven't
>seen
>why the current form of the .DEFERRED_INIT call was chosen or
>suggested,
>but it triggered my "well, that's obviously wrong" gut feeling; so
>sorry
>f
This attempst to improve the doxygen output to work around what seems to
be some bugs in doxygen (issues 8635 and 8638).
The @addtogroup command doesn't work for entities inside a nested
namespace (see 8635) so we need to close and reopen groups on entering
and leaving nested namespaces. This fixe
Hi!
On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
> The following patch adds support for them to GCC so that we stay in sync
> with LLVM.
This should be documented somewhere.
> + else if (fncode == VSX_BUILT
On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
>> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
>> The following patch adds support for them to GCC so that we stay in sync
>> with LLVM.
>
> This should be documen
This patch is updating soft-fp from glibc:
1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
2. Add __truncxfhf2 to truncate IEEE extended into IEEE half.
These are needed by x86 _Float16 support.
---
libgcc/soft-fp/extendhfxf2.c | 53
l
On 7/1/21 11:08 AM, Tobias Burnus wrote:
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and
On 6/30/21 4:55 PM, David Malcolm wrote:
On Tue, 2021-06-15 at 17:00 -0600, Martin Sebor wrote:
On 6/11/21 11:04 AM, David Malcolm wrote:
On Thu, 2021-06-10 at 17:26 -0600, Martin Sebor wrote:
This diff introduces the diagnostic infrastructure changes to
support
controlling warnings at any cal
On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
>> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
>> The following patch adds support for them to GCC so that we stay in sync
>> with LLVM.
>
> This should be documen
On 7/1/2021 1:28 PM, H.J. Lu via Gcc-patches wrote:
This patch is updating soft-fp from glibc:
1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
2. Add __truncxfhf2 to truncate IEEE extended into IEEE half.
These are needed by x86 _Float16 support.
Presumably these are
On 6/30/21 5:35 PM, David Malcolm wrote:
On Wed, 2021-06-30 at 13:45 -0600, Martin Sebor wrote:
On 6/30/21 9:39 AM, Martin Sebor wrote:
Ping. Attached is the same patch rebased on top the latest trunk.
Please see the attached patch instead. The previous one had typo
in it.
As discussed i
On Thu, Jul 1, 2021 at 1:12 PM Jeff Law wrote:
>
>
>
> On 7/1/2021 1:28 PM, H.J. Lu via Gcc-patches wrote:
> > This patch is updating soft-fp from glibc:
> >
> > 1. Add __extendhfxf2 to return an IEEE half converted to IEEE extended.
> > 2. Add __truncxfhf2 to truncate IEEE extended into IEEE half
Some general comments, following what I said on libc-alpha:
1. Can you confirm that the ABI being used for 64-bit, for _Float16 and
_Complex _Float16 argument passing and return, follows the current x86_64
ABI document?
2. Can you confirm that if you build with this instruction set extension
1. Pass _Float16 and _Complex _Float16 values on stack.
2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
---
low-level-sys-info.tex | 57 +-
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/low-level-sys-info.tex b/low
On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote:
> +/* Optimize for code like (_Float16) __builtin_sqrtf ((float) f16)
> + since it's not handled in frontend. */
If correct, it *should* be handled in front end (well, middle-end). See
what convert.c:convert_to_real_1 does, with a long comm
On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote:
> +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16)
> + since it's not handled in frontend. */
Much the same comments apply as for sqrt. But in this case, the
conversion code is in match.pd - right now, specific to pairs of
On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
> The main issue is complex _Float16 functions in libgcc. If _Float16 doesn't
> require -mavx512fp16, we need to compile complex _Float16 functions in
> libgcc without -mavx512fp16. Complex _Float16 performance is very
> important for our _Float
Hi!
On Thu, Jul 01, 2021 at 10:59:15PM +0930, Alan Modra wrote:
> * lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
Mike added this already, please make sure to not add it twice :-)
[...]
> gcc.target/powerpc/pr86731-fwrapv-longlong.c: Match power10 insns.
(It
On Thu, 1 Jul 2021, Richard Biener via Gcc-patches wrote:
> > C++ FE doesn't support _FLoat16, and the place float/double are
> > handled is in convert.c(which is GENERIC?), that's why I decided to do
> > it in the backend.
I think there ought to be a preliminary patch series adding whatever
_Fl
This moves some global state from input.c to a new file_cache class,
of which an instance is owned by global_dc. Various state is also
made private.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as b544c348e13ad33d55f0d954370ab1fb0f
On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
> 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
That restricts use of _Float16 to processors with SSE. Is that what we
want in the ABI, or should _Float16 be available with base 32-bit x86
architecture features only
On 6/28/2021 10:21 AM, Aldy Hernandez wrote:
This is is the main basic block path solver for use in the ranger-based
backwards threader. Given a path of BBs, the class can solve the final
conditional or any SSA name used in calculating the final conditional.
The main API is:
// This class i
On Thu, Jul 1, 2021 at 3:10 PM Joseph Myers wrote:
>
> On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
>
> > 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
>
> That restricts use of _Float16 to processors with SSE. Is that what we
> want in the ABI, or should _Float1
On Thu, 1 Jul 2021, H.J. Lu wrote:
> BTW, _Float16 software emulation may require more than just SSE
> since we need to do _Float16 load and store with XMM registers.
> There is no 16bit load/store for XMM registers without AVX512FP16.
You should be able to make the move go via general-purpose re
On Thu, Jul 1, 2021 at 3:40 PM Joseph Myers wrote:
>
> On Thu, 1 Jul 2021, H.J. Lu wrote:
>
> > BTW, _Float16 software emulation may require more than just SSE
> > since we need to do _Float16 load and store with XMM registers.
> > There is no 16bit load/store for XMM registers without AVX512FP16.
On Thu, Jul 1, 2021 at 4:02 PM H.J. Lu via llvm-dev
wrote:
> On Thu, Jul 1, 2021 at 3:40 PM Joseph Myers
> wrote:
> >
> > On Thu, 1 Jul 2021, H.J. Lu wrote:
> >
> > > BTW, _Float16 software emulation may require more than just SSE
> > > since we need to do _Float16 load and store with XMM regist
On Thu, Jul 1, 2021, 15:28 H.J. Lu via llvm-dev
wrote:
> On Thu, Jul 1, 2021 at 3:10 PM Joseph Myers
> wrote:
> >
> > On Thu, 1 Jul 2021, H.J. Lu via Gcc-patches wrote:
> >
> > > 2. Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1
> registers.
> >
> > That restricts use of _Float16 to
gen_autofdo_event.py was stumbling on models with stepping so
I updated the script to handle this case similar to the code in
https://github.com/andikleen/pmu-tools/blob/c6a5f63aede19def8886d6a8b74d7a55c38ca947/event_download.py
The second change was to tolerate cases when the CPU supports PEBS bu
On 7/1/2021 4:40 PM, Eugene Rozenfeld wrote:
gen_autofdo_event.py was stumbling on models with stepping so
I updated the script to handle this case similar to the code in
https://github.com/andikleen/pmu-tools/blob/c6a5f63aede19def8886d6a8b74d7a55c38ca947/event_download.py
The second change wa
On Thu, Jul 01, 2021 at 04:47:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 01, 2021 at 10:59:15PM +0930, Alan Modra wrote:
> > * lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
>
> Mike added this already, please make sure to not add it twice :-)
Yup, reb
On Thu, Jul 01, 2021 at 11:40:55AM -0400, David Malcolm via Gcc-patches wrote:
> On Thu, 2021-07-01 at 14:53 +0200, Richard Biener wrote:
> > On Thu, Jul 1, 2021 at 12:16 PM Trevor Saunders <
> > tbsau...@tbsaunde.org> wrote:
> > >
> > > On Wed, Jun 30, 2021 at 11:13:23AM -0400, David Malcolm wrot
On Thu, Jul 1, 2021 at 10:15 PM guojiufu via Gcc-patches
wrote:
>
> On 2021-07-01 20:35, Richard Biener wrote:
> > On Thu, 1 Jul 2021, Jiufu Guo wrote:
> >
> >> For code like:
> >> unsigned foo(unsigned val, unsigned start)
> >> {
> >> unsigned cnt = 0;
> >> for (unsigned i = start; i > val; +
-Wvla-parameter relies on operand_equal_p() with OEP_LEXICOGRAPHIC
set to compare VLA bounds for equality. But operand_equal_p()
doesn't consider decl names, and so nontrivial expressions that
refer to the same function parameter are considered unequal by
the function, leading to false positives.
On Thu, Jul 1, 2021 at 8:19 PM Richard Biener
wrote:
>
> On Mon, Jun 7, 2021 at 4:35 PM Richard Biener
> wrote:
> >
> > On Sun, Jun 6, 2021 at 12:01 PM Bin.Cheng wrote:
> > >
> > > On Wed, Jun 2, 2021 at 3:28 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Tue, Jun 1, 2021 at
Instead of copying some tests from gcc/testsuite/gcc.target/i386,
I created new tests. The i386 tests in question used rand() to
generate the input data and assembly to compute the rounded values.
Using rand() for testing seems wrong, and the assembly is obviously
not portable. I use static data,
2021-07-01 Paul A. Clarke
gcc/ChangeLog:
* config/rs6000/smmintrin.h (_mm_ceil_pd, _mm_ceil_ps,
_mm_ceil_sd, _mm_ceil_ss): New.
---
gcc/config/rs6000/smmintrin.h | 28
1 file changed, 28 insertions(+)
diff --git a/gcc/config/rs6000/smmintrin.h b/gc
Add the tests for _mm_ceil_pd, _mm_ceil_ps, _mm_ceil_sd, _mm_ceil_ss.
Copy a test for _mm_ceil_pd and _mm_ceil_ps from
gcc/testsuite/gcc.target/i386.
Define __VSX_SSE2__ to pick up some union definitons in
m128-check.h.
2021-07-01 Paul A. Clarke
gcc/testsuite/ChangeLog:
* gcc/testsui
Hi Vladimir,
on 2021/6/30 下午11:24, Vladimir Makarov wrote:
>
> On 2021-06-28 2:26 a.m., Kewen.Lin wrote:
>> Hi!
>>
>> on 2021/6/9 下午1:18, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR100328 has some details about this issue, I am trying to
>>> brief it here. In the hottest function LBM_per
Hi Richard,
on 2021/6/30 下午11:42, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> on 2021/6/28 下午3:20, Hongtao Liu wrote:
>>> On Mon, Jun 28, 2021 at 3:12 PM Hongtao Liu wrote:
On Mon, Jun 28, 2021 at 2:50 PM Kewen.Lin wrote:
>
> Hi!
>
> on 2021/6/9 下午1:18, Kewen.Lin
Hi,
With Hongtao's help (thanks), we got the SPEC2017 performance
evaluation result on x86_64 (see [1]), this new parameter
ira-consider-dup-in-all-alts has negative effects on i386.
Since we observed it can benefit ports aarch64 and rs6000, the
param is set as 1 by default, this patch is to disab
It was undocument before, but already used in linux kernel, so LLVM
community suggest we should document that, so that make it become
supported/documented/non-internal machine constraints.
gcc/ChangeLog:
PR target/101275
* doc/md.text (Machine Constraints): Document the 'S' constr
On 2021-07-02, Kito Cheng wrote:
It was undocument before, but already used in linux kernel, so LLVM
community suggest we should document that, so that make it become
supported/documented/non-internal machine constraints.
gcc/ChangeLog:
PR target/101275
* doc/md.text (Machine Co
Updated patch with minor change to move the variable declaration after comment.
Hongtao, could you help check-in the patch?
Hongyu Wang 于2021年7月1日周四 下午4:16写道：
>
> > Change some keylocker insn to Keylocker aesenc/aesdec in comments.
> > others LGTM.
>
> Changed.
>
> Forgot to mention bootstrapped
On 2021-07-02 08:51, Bin.Cheng wrote:
On Thu, Jul 1, 2021 at 10:15 PM guojiufu via Gcc-patches
wrote:
On 2021-07-01 20:35, Richard Biener wrote:
> On Thu, 1 Jul 2021, Jiufu Guo wrote:
>
>> For code like:
>> unsigned foo(unsigned val, unsigned start)
>> {
>> unsigned cnt = 0;
>> for (unsign
On Thu, 1 Jul 2021, Michael Matz wrote:
> Hello,
>
> On Thu, 1 Jul 2021, Richard Biener wrote:
>
> > diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
> > index 43045c5455e..43ef112a2d0 100644
> > --- a/gcc/gimple-loop-interchange.cc
> > +++ b/gcc/gimple-loop-interchan
On Thu, Jul 1, 2021 at 7:10 PM Uros Bizjak wrote:
>
> [Sorry for double post, gcc-patches address was wrong in original post]
>
> On Thu, Jul 1, 2021 at 7:48 AM liuhongt wrote:
> >
> > Hi:
> > AVX512FP16 is disclosed, refer to [1].
> > There're 100+ instructions for AVX512FP16, 67 gcc patches
On Fri, 2 Jul 2021, Richard Biener wrote:
> On Thu, 1 Jul 2021, Michael Matz wrote:
>
> > Hello,
> >
> > On Thu, 1 Jul 2021, Richard Biener wrote:
> >
> > > diff --git a/gcc/gimple-loop-interchange.cc
> > > b/gcc/gimple-loop-interchange.cc
> > > index 43045c5455e..43ef112a2d0 100644
> > > ---
On 7/1/21 10:14 PM, Martin Sebor wrote:
On 6/30/21 5:35 PM, David Malcolm wrote:
On Wed, 2021-06-30 at 13:45 -0600, Martin Sebor wrote:
On 6/30/21 9:39 AM, Martin Sebor wrote:
@@ -90,8 +90,8 @@ NOIPA void warn_g2 (struct A *p)
g2 (p);
}
-// { dg-message "inlined from 'g2'" "" { targ
101 - 171 of 171 matches
Mail list logo
