that we were trying to escape?
The proposal is as an ABI only (compilers would generate calls to
__memcmpeq from boolean uses of memcmp, users wouldn't write calls to
__memcmpeq directly, __memcmpeq wouldn't be declared in installed libc
headers). If such dependence arises, that would suggest a
function will return zero. Otherwise the function will return a
>> > non-zero value.
>> >
>> > Equality between the byte sequences starting at 's1' and 's2' is
>> > defined as follows:
>> >
>> > 1. If 'n' is zero the two sequences are zero.
>>
> 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
> >offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
> >
> > For a simple C implementation of '__memcmpeq()' could be as follows:
> >
> >
> > int __memcmpeq(const void* s1, const void* s2, size_t n)
size_t i;
> const char *s1c, *s2c;
> s1c = (const char*)s1;
> s2c = (const char*)s2;
> for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
> ret = s1c[i] - s2c[i]
> }
> return ret;
> }
>
>
> Notes
>
> This int
n ret;
}
Notes
This interface is essentially old 'bcmp()' and 'memcmp()' will always
be a valid implementation of '__memcmpeq()'.
ABI vs API
This proposal is for '__memcmpeq()' as a new ABI. As an ABI
'__memcmpeq()' will have value, as using the return value of
'memcmp()' is quit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85915
--- Comment #16 from Luke Dashjr ---
GCC only supports defaults now?
|--- |WONTFIX
--- Comment #15 from Andrew Pinski ---
Right and mfunction-return=thunk was never the default in any GCC release,
there was no ABI change techincally. It is only an ABI change because gentoo
decided to turn it the default for glibc.
On Thu, Sep 9, 2021 at 11:31 PM H.J. Lu wrote:
>
> On Wed, Jul 21, 2021 at 12:44 AM liuhongt wrote:
> >
> > From: "H.J. Lu"
> >
> > Copied from regular XMM ABI tests. Only run AVX512FP16 ABI tests for ELF
> > targets.
> >
> > gcc/te
On Wed, Jul 21, 2021 at 12:44 AM liuhongt wrote:
>
> From: "H.J. Lu"
>
> Copied from regular XMM ABI tests. Only run AVX512FP16 ABI tests for ELF
> targets.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/x86_64/abi/avx512fp16/abi-avx512fp16-xmm.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102197
Bug ID: 102197
Summary: ABI to pass and return 32-bit FP vectors
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53665
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On 9/2/21 4:49 AM, Jakub Jelinek wrote:
On Thu, Sep 02, 2021 at 12:19:03AM +0200, Jakub Jelinek via Gcc-patches wrote:
Ah, thanks for the archeology. So it indeed seems like in theory an ABI change
between GCC 3.4 and 4.0 for C then on some of the targets like x86_64 which
already existed
On Thu, Sep 02, 2021 at 12:19:03AM +0200, Jakub Jelinek via Gcc-patches wrote:
> Ah, thanks for the archeology. So it indeed seems like in theory an ABI
> change
> between GCC 3.4 and 4.0 for C then on some of the targets like x86_64 which
> already existed in 3.2-ish era. I actua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
--- Comment #6 from H.J. Lu ---
I think psABIs should specify how to pass and return 8-bit, 16-bit and 32-bit
vectors. We can treat them as
struct vectorN
{
intN
};
and vectorize V2SFmode PLUS,
MINUS, MULT, MIN and MAX operations using XMM registers.
Add ABI warnings for 64-bit integer vectors without MMX and 64-bit float
vector without 3DNOW.
gcc/
PR target/102027
PR target/102105
* config/i386/i386.c (m64_mode): New function
On Mon, Aug 30, 2021 at 6:49 AM Jakub Jelinek wrote:
>
> On Sun, Aug 29, 2021 at 12:11:23PM -0700, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -1840,6 +1840,54 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /*
> > Argument info to initialize */
> >
e C++ FE these fields are meaningful for
> > > > layout purposes but they are only supposed to influence layout
> > > > but not ABI (but why does the C++ FE say that?)
>
> The code to remove zero-length bit-fields was copied from the C front end
> when G++ was fir
On 8/31/21 5:15 AM, Richard Biener wrote:
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
Just to clarify - in the C++ FE these fields are meaningful for
layout purposes but they are only supposed to influence layout
but not ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
--- Comment #5 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> gcc has also some problems in this area. With -mregparm=3, one would expect
> arguments obeying integer ABI to be passed in registers, but regparm flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
--- Comment #4 from Jakub Jelinek ---
Well, we already have the ABI ISA dependent,
typedef int __v8si __attribute__((__vector_size__ (32)));
__v8si
foo (__v8si x, __v8si y)
{
return x + y;
}
has different ABI based on -mavx or -mno-avx, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
--- Comment #3 from Uroš Bizjak ---
gcc has also some problems in this area. With -mregparm=3, one would expect
arguments obeying integer ABI to be passed in registers, but regparm flag has
no effect and the same code is produced:
foo
clang creates:
foo:
movzwl 16(%esp), %edx
movzwl 12(%esp), %eax
addw4(%esp), %ax
addw8(%esp), %dx
retl
So, it is incompatible with itself for -msse/-mno-sse differences. The ABI
should be ISA agnostic, so using integer ABI as implemented by gcc is IMO t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015
--- Comment #4 from Jonathan Wakely ---
In https://gcc.gnu.org/pipermail/libstdc++/2021-August/053108.html I proposed
dropping C++98 support for the gnu-versioned-namespace, which would allow us to
fix this by using [[__no_unique_address__]].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> > Just to clarify - in the C++ FE these fields are meaningful for
> > layout purposes but they are only supposed to influence layout
> > but not ABI (but wh
On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> Just to clarify - in the C++ FE these fields are meaningful for
> layout purposes but they are only supposed to influence layout
> but not ABI (but why does the C++ FE say that?) and thus the
> 'DECL_FIELD_ABI_IGNORE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143
Bug ID: 102143
Summary: ABI incompatibility with clang when passing 32bit
vectors on 32bit i686
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
Hi!
This is an incremental patch to
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578447.html
for x86_64 ABI.
For zero-width bitfields current GCC classify_argument does:
if (DECL_BIT_FIELD (field))
{
for (i = (int_bit_position
mpatible helper intrinsics patch, so that the FE can actually
> > determine what is and isn't layout-compatible according to the spec)
> > unfortunately changed the ABI on various platforms.
> > The C FE has been keeping zero-width bitfields in the types, while
> > the C++ FE
s and isn't layout-compatible according to the spec)
> unfortunately changed the ABI on various platforms.
> The C FE has been keeping zero-width bitfields in the types, while
> the C++ FE has been removing them after structure layout, so in various
> cases when passing such structures in
the ABI on various platforms.
The C FE has been keeping zero-width bitfields in the types, while
the C++ FE has been removing them after structure layout, so in various
cases when passing such structures in registers we had different ABI
between C and C++.
The following patch doesn't change anything
On Sun, Aug 29, 2021 at 12:11:23PM -0700, H.J. Lu wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -1840,6 +1840,54 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /*
> Argument info to initialize */
>cfun->machine->arg_reg_available = (cum->nregs > 0);
> }
>
> +/*
On 8/28/2021 1:17 AM, Xi Ruoyao wrote:
On Fri, 2021-08-27 at 15:38 -0600, Jeff Law wrote:
On 8/26/2021 10:20 PM, Xi Ruoyao via Gcc-patches wrote:
On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
gcc/ChangeLog:
PR target/102089
* config.gcc: MIPS: use N64 ABI
and vectorize V2SFmode PLUS,
MINUS, MULT, MIN and MAX operations using XMM registers.
Add ABI warnings for 64-bit integer vectors without MMX and 64-bit float
vector without 3DNOW.
gcc/
PR target/102027
PR target/102105
* config/i386/i386.c (single_m64_base_type): New
On Sun, Aug 29, 2021 at 09:17:10AM -0700, H.J. Lu wrote:
> How does it work?
Depends on the terminal. E.g. in recent, at most a few years old
gnome-terminal, that GCC 11.1 is dotted underlined and hovering with mouse
on it shows it normal underlined and prints the URL, right click shows a
menu
. We can use SSE2 to support MMX register modes.
GCC 10.4 is changed to diagnose this ABI change with -Wpsabi.
GCC 11.1 enabled 64-bit float vector without 3DNOW by:
commit 7c355156aa20eaec7401d7c66f6a6cfbe597abc2
Author: Uros Bizjak
Date: Mon May 11 11:16:31 2020 +0200
i386: Vectorize
;
> > + if (!warnedm64_ret)
> > + {
> > + if (warning (OPT_Wpsabi,
> > +"the ABI of returning structure with a "
> > +"64-bit vector has changed in GCC %d.1",
>
if (warning (OPT_Wpsabi,
> + "the ABI of returning structure with a "
> +"64-bit vector has changed in GCC %d.1",
> +gcc_version))
> + warnedm64_ret = true;
> + }
>
and vectorize V2SFmode PLUS,
MINUS, MULT, MIN and MAX operations using XMM registers.
Add ABI warnings for 64-bit integer vectors without MMX and 64-bit float
vector without 3DNOW.
gcc/
PR target/102027
PR target/102105
* config/i386/i386.c (single_m64_base_type): New
On Fri, 2021-08-27 at 15:38 -0600, Jeff Law wrote:
>
>
> On 8/26/2021 10:20 PM, Xi Ruoyao via Gcc-patches wrote:
> > On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
> > > gcc/ChangeLog:
> > >
> > > PR target/102089
> > >
Aug 26 23:56:58 2021 -0400
MIPS: use N64 ABI by default if the triple end with -gnuabi64
gcc/ChangeLog:
PR target/102089
* config.gcc: MIPS: use N64 ABI by default if the triple end
with -gnuabi64, which is used by Debian since 2013.
Regression] |x86_64: ABI break with
|x86_64: ABI break with |vector in union and
|vector in union and |-mno-mmx -mavx
|-mno-mmx -mavx |
--- Comment #2 from H.J. Lu ---
I consider this is a GCC 9 bug:
[hjl@gnu-cfl-2
On 8/26/2021 10:20 PM, Xi Ruoyao via Gcc-patches wrote:
On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
gcc/ChangeLog:
PR target/102089
* config.gcc: MIPS: use N64 ABI by default if the triple end
with -gnuabi64, which is used by Debian since 2013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102105
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102108
Bug ID: 102108
Summary: [meta] ABI change due to SSE emulation of MMX
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102105
--- Comment #1 from Marek Polacek ---
diff between r271212 and r271213:
$ diff -up ~/y12.s ~/y13.s
--- /home/mpolacek/y12.s2021-08-27 16:25:46.0 -0400
+++ /home/mpolacek/y13.s2021-08-27 16:25:53.0 -0400
@@ -87,8
||ABI
Summary|x86_64: ABI break with |[10/11/12 Regression]
|vector in union and |x86_64: ABI break with
|-mno-mmx -mavx |vector in union and
||-mno-mmx -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102105
Bug ID: 102105
Summary: x86_64: ABI break with vector in union and -mno-mmx
-mavx
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
> gcc/ChangeLog:
>
> PR target/102089
> * config.gcc: MIPS: use N64 ABI by default if the triple end
> with -gnuabi64, which is used by Debian since 2013.
> ---
> gcc/config.gcc | 14 +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
--- Comment #3 from YunQiang Su ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578240.html
Patch has been sent to gcc-patches.
gcc/ChangeLog:
PR target/102089
* config.gcc: MIPS: use N64 ABI by default if the triple end
with -gnuabi64, which is used by Debian since 2013.
---
gcc/config.gcc | 14 ++
1 file changed, 14 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
--- Comment #2 from YunQiang Su ---
(In reply to Andrew Pinski from comment #1)
> Patches should be sent to gcc-patches@ after reading
> https://gcc.gnu.org/contribute.html
Yes. the patch will be send just now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
Andrew Pinski changed:
What|Removed |Added
Target||mips*-*-linux-gnuabi64
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
Bug ID: 102089
Summary: MIPS: use N64 ABI by default if the triple end with
-gnuabi64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81237
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
> Yes, it would be nice to transition away from relying on TYPE_MODE for
> argument passing. Does the psABI say anything about this case or is it in
> the area of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #6 from Andrew Pinski ---
(In reply to H.J. Lu from comment #5)
> (In reply to Andrew Pinski from comment #3)
> > There are calls to vector_mode_supported_p in stor-layout which changes the
>
> It sounds odd to me since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #5 from H.J. Lu ---
(In reply to Andrew Pinski from comment #3)
> There are calls to vector_mode_supported_p in stor-layout which changes the
It sounds odd to me since vector_mode_supported_p can change overtime.
> TYPE_MODE of
> true or not and classify_argument depends on TYPE_MODE in some cases
We need to issue a ABI change warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #2 from Uroš Bizjak ---
gcc-11 does:
:
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
--- Comment #1 from Uroš Bizjak ---
(In reply to Marek Polacek from comment #0)
> We have an ABI break. Discovered by
> Running
> /root/rpmbuild/BUILD/gcc-11.2.1-20210728/gcc/testsuite/gcc.dg/compat/struct-
> layout-1.exp ...
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
Marek Polacek changed:
What|Removed |Added
Keywords||ABI
Summary|ABI break when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027
Bug ID: 102027
Summary: ABI break when using vector type in function
arg/return value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015
--- Comment #2 from Kamil Kaznowski ---
(In reply to Andrew Pinski from comment #1)
> https://stackoverflow.com/questions/66573773/is-there-a-reason-for-8-bytes-
> of-size-overhead-in-libstdc-stdmultiset-map
This is my post, I forgot to post a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015
--- Comment #1 from Andrew Pinski ---
https://stackoverflow.com/questions/66573773/is-there-a-reason-for-8-bytes-of-size-overhead-in-libstdc-stdmultiset-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015
Bug ID: 102015
Summary: [missed optimization] Small memory overhead in
_Rb_tree_impl (fix would require ABI break)
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82668
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Hi,
This patch from Matt, adjusts the default exception model for
all targets that might use NeXT ABI 2 (currently, Darwin had
handled this locally).
tested on x86_64-darwin, i686-darwin, x86_64-linux,
pushed to master, thanks,
Iain
=
Signed-off-by: Matt Jacobson
gcc/c-family/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58429
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
2021 at 11:36 PM Matt Jacobson via Gcc-patches
>>> wrote:
>>>>
>>>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2
>>>> crashes,
>>>> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions
>>>> (which
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39258
--- Comment #4 from Andrew Pinski ---
union sse2 does not pass via a register for me on x86_64
> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches
> wrote:
>
>> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote:
>>
>> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>> wrote:
>>>
>>> As is, an invocation of GCC wi
> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote:
>
> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
> wrote:
>>
>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes,
>> unless target-specific code adds an implicit -f
On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
wrote:
>
> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes,
> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions (which
> Darwin does).
>
> This patch makes the gene
As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes,
unless target-specific code adds an implicit -fno-objc-sjlj-exceptions (which
Darwin does).
This patch makes the general case not crash.
I don't have commit access, so if this patch is suitable, I'd need someone else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616
Andreas Schwab changed:
What|Removed |Added
Resolution|WORKSFORME |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616
tong__hui at 163 dot com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/avx512fp16/m512h/abi-avx512fp16-zmm.exp:
New file.
* gcc.target/x86_64/abi/avx512fp16/m512h/args.h: Likewise.
* gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise.
* gcc.target/x86_64/abi
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/avx512fp16/m256h/abi-avx512fp16-ymm.exp:
New exp file.
* gcc.target/x86_64/abi/avx512fp16/m256h/args.h: New header.
* gcc.target/x86_64/abi/avx512fp16/m256h/avx512fp16-ymm-check.h:
Likewise
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/avx512fp16/m512h/abi-avx512fp16-zmm.exp:
New file.
* gcc.target/x86_64/abi/avx512fp16/m512h/args.h: Likewise.
* gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise.
* gcc.target/x86_64/abi
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/avx512fp16/m256h/abi-avx512fp16-ymm.exp:
New exp file.
* gcc.target/x86_64/abi/avx512fp16/m256h/args.h: New header.
* gcc.target/x86_64/abi/avx512fp16/m256h/avx512fp16-ymm-check.h:
Likewise
> which leads to incorrect optimization in pass_reload. In order to
> > solve this problem, this patch refine instructions as call_insns in
> > which the call has a special vzeroupper ABI.
> >
> > gcc/ChangeLog:
> >
> > PR target/82735
>
lem, this patch refine instructions as call_insns in
> which the call has a special vzeroupper ABI.
>
> gcc/ChangeLog:
>
> PR target/82735
> * config/i386/i386-expand.c (ix86_expand_builtin): Remove
> assignment of cfun->machine->has_explicit_vzerouppe
not carry any CLOBBERS or SETs before LRA,
> which leads to incorrect optimization in pass_reload. In order to
> solve this problem, this patch refine instructions as call_insns in
> which the call has a special vzeroupper ABI.
>
> gcc/ChangeLog:
>
> PR target/8273
On 6/1/21 7:44 PM, Segher Boessenkool wrote:
It would be nice if we had a selector for when we can use -mrop-protect,
instead of assuming it is only for ELFv2.
Agreed -- I'll take a note and try to get to this sometime.
a special vzeroupper ABI.
gcc/ChangeLog:
PR target/82735
* config/i386/i386-expand.c (ix86_expand_builtin): Remove
assignment of cfun->machine->has_explicit_vzeroupper.
* config/i386/i386-features.c
(ix86_add_reg_usage_to_vzerouppers):
On Tue, Jun 01, 2021 at 11:18:05AM -0500, Bill Schmidt wrote:
> Hi! PR100750 reports a failure on my part to require the ELFv2 ABI for
> one of the ROP tests. This fixes that.
It would be nice if we had a selector for when we can use -mrop-protect,
instead of assuming it is only for
Hi! PR100750 reports a failure on my part to require the ELFv2 ABI for
one of the ROP tests. This fixes that.
Tested on powerpc64-linux-gnu, committed as obvious.
Thanks!
Bill
PR100750: Require ELFv2 ABI for ROP test
2021-06-01 Bill Schmidt
gcc/testsuite/
PR testsuite/100750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
Richard Biener changed:
What|Removed |Added
Target Milestone|9.4 |9.5
--- Comment #30 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91710
Richard Biener changed:
What|Removed |Added
Target Milestone|9.4 |9.5
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98734
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.5 |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.5 |9.4
--- Comment #29 from Jakub Jelinek
t; > it is no longer needed since option parsing has been improved:
> > -mfloat-abi is handled via arm.opt and updates the var_float_abi
> > variable. So, the last instance of -mfloat-abi= on the command line
> > wins.
> >
>
> Yeah, at the time it was added, the
On 22/04/2021 08:01, Christophe Lyon via Gcc-patches wrote:
arm.h has had this error message since 1997, and was never updated to
take softfp into account. Anyway, it seems it was useful long ago, but
it is no longer needed since option parsing has been improved:
-mfloat-abi is handled via
901 - 1000 of 5007 matches
Mail list logo
