Hi!
I've searched for some uses of (HOST_WIDE_INT) constant or (unsigned
HOST_WIDE_INT) constant and turned them into uses of the appropriate
macros.
THere are quite a few cases in non-i386 backends but I've left that out
for now.
The only behavior change is in build_replicated_int_cst where the
Hi!
The following patch implements support for VIEW_CONVERT_EXPRs from/to
large/huge _BitInt to/from vector or complex types or anything else but
integral/pointer types which doesn't need to live in memory.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-24 Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Bug ID: 114085
Summary: Internal (cross) compiler error when building
libstdc++ for the H8/300 family
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #2 from Andrew Pinski ---
Here is another testcase, the only use of _BitInt is in the cast, everything
else is a bitfield:
```
struct a
{
unsigned t:(sizeof(int)*8-1);
};
typedef unsigned _BitInt(sizeof(int)*8-1) ub31;
struct a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Andreas Krebbel changed:
What|Removed |Added
CC||stefansf at linux dot ibm.com
---
ssion algorithms: zlib zstd
gcc version 14.0.1 20240223 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114054
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
From: Fangrui Song
Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
-mfdpic does not pass --fdpic to gas. This is an unnecessary
restriction. Just define the ASM_SPEC in bpabi.h.
Additionally, use armelf[b]_linux_fdpiceabi emulations for -mfdpic in
linux-eabi.h. This
This enables construction of V4SF CST like `{1.0f, 1.0f, 0.0f, 0.0f}`
(and other fp enabled CSTs) by using `fmov v0.2s, 1.0` as the instruction
is designed to zero out the other bits.
This is a small extension on top of the code that creates fmov for the case
where the all but the first element is
Aarch64 has a way to form some floating point CSTs via the fmov instructions,
these instructions also zero out the upper parts of the registers so they can
be used for vector CSTs that have have one non-zero constant that would be able
to formed via the fmov in the first element.
This implements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
Gaius Mulley changed:
What|Removed |Added
Attachment #57516|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103433
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Depends on||103433
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Summary|Type punning RISC-V vectors |Type punning RISC-V and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Andrew Pinski changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
--- Comment #4 from Gaius Mulley ---
Created attachment 57516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57516=edit
Proposed fix
Here is a proposed patch. The bug fix changes the FIO module to use the target
O_RDONLY, O_WRONLY,
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Bound testcase
Snapshot gcc-12-20240223 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20240223/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #4 from Maciej W. Rozycki ---
The flag enables the use of the conditional-move operations even with
hardware that has no support for such operations, hence unconditionally.
Such operations, where unavailable, are then synthesized as
+Martin who may have an opinion
(https://github.com/mstorsjo/llvm-mingw supports aarch64)
On Fri, Feb 23, 2024 at 6:15 AM Evgeny Karpov
wrote:
>
> Hi Andrew and Richard,
>
> Thank you for pointing out there's no need for a 64-bit ISA and the
> big-endian target.
> These changes will be
Hi Martin,
Thank you for the clarification regarding the vararg implementation.
It is correct. The work is still in progress and will be included in
a later patch series.
ARM64EC is a separate work, which is outside the scope of the current
contribution plan.
Regards,
Evgeny
-Original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:80d126ba99f4b9bc64d4861b3c4bae666497f2d4
commit r14-9160-g80d126ba99f4b9bc64d4861b3c4bae666497f2d4
Author: Steve Kargl
Date:
On Fri, Feb 23, 2024 at 10:15:17PM +0100, Harald Anlauf wrote:
> Hi Steve, all,
>
> here's an updated patch with an enhanced testcase that also
> checks MOLD= besides SOURCE=.
>
> Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
>
>From my viewpoint, yes.
Thanks for finding a better
Hi Richard,
Thank you for your review!
The MS_ABI definition is for the x86/x64 MS ABI, and it's clear that it
shouldn't be used on aarch64.
The AARCH64_CALLING_ABI_MS definition resolves the issue.
It just needs to be properly handled in mingw32.h.
The change below is sufficient to resolve
On 23 February 2024 22:15:17 CET, Harald Anlauf wrote:
>Hi Steve, all,
>
>here's an updated patch with an enhanced testcase that also
>checks MOLD= besides SOURCE=.
>
>Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
LGTM
cheers
>
>Cheers,
>Harald
Hi Steve, all,
here's an updated patch with an enhanced testcase that also
checks MOLD= besides SOURCE=.
Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
Cheers,
Harald
On 2/22/24 22:32, Harald Anlauf wrote:
On 2/22/24 22:01, Steve Kargl wrote:
BTW, my patch and I suspect your
On Thu, 22 Feb 2024 15:56:46 +
Evgeny Karpov wrote:
> A ChangeLog template using "Moved... ...here" has been generated by
> contrib/mklog.py.
> It seems that it needs modification.
>
> Regards,
> Evgeny
>
> -Original Message-
> Thursday, February 22, 2024 12:11 PM
> Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028
--- Comment #3 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:85c12ae8b80902ed46c97f33dbb61533e07f2905
commit r14-9159-g85c12ae8b80902ed46c97f33dbb61533e07f2905
Author: Robin Dapp
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Jonathan Wakely changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Comment
> +/* { dg-final { scan-assembler-times "vmv\.v\.i\tv\[0-9\],0" 0 } } */
>
> I think you should use "scan-assembler-not"
Thanks, going to commit with that change.
Regards
Robin
On Fri, 23 Feb 2024, Richard Sandiford wrote:
Are there two distinct ABIs for aarch64-*-mingw*? Or are these
distinctions ignored on aarch64 and just retained for compatibility?
On Windows on AArch64, the calling convention normally matches regular
AAPCS64 - so the ms_abi attribute normally
+CC Greg who might also have some bits in flight here.
On 2/23/24 01:23, Li, Pan2 wrote:
>
> > I would prefer to only keep zvl and scalable or zvl only, since I
>
> > don't see too much value in specifying a value which different from
>
> > zvl*b, that's a legacy option used before zvl*b option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #2 from Roland Illig ---
I don't understand why the word 'unconditionally' is necessary or useful here.
Isn't the option -mmovcc by itself already a condition? That would make the
word 'unconditionally' wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #1 from Andrew Pinski ---
This is not a play on words though. The flag enables the use of "conditional
moves" always (unconditionally).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
--- Comment #1 from Roland Illig ---
If you decide to keep the guidelines, here are a few ideas:
* Use the simplest English you can, while still being precise.
* Don't try to be funny. (See #114083 for a possible case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Bug ID: 114083
Summary: Possible word play on conditional/unconditional
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
--- Comment #5 from Andreas Schwab ---
If the unwinder crashes you have either incorrect unwind info or a corrupted
stack. Neither should be papered over.
On 2/22/24 2:08 PM, Jakub Jelinek wrote:
On Thu, Feb 22, 2024 at 12:59:18PM -0800, Greg McGary wrote:
The sign bit of a sign-extending load cannot be known until runtime,
so don't attempt to simplify it in the combiner.
2024-02-22 Greg McGary
PR rtl-optimization/113010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Bug ID: 114082
Summary: Guidelines for options are empty
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
On 2/23/24 06:23, Alexandre Oliva wrote:
I'm not so worried about bootstrap itself as I am about post-bootstrap
host tools. Those are unusual in that, after native bootstraps, they're
built using the just-built (last-stage) compiler and target libraries,
rather than the host compiler and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2
> -fno-vect-cost-model -O3.
`-O3 -fno-vect-cost-model -mavx2` is enough with my reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #2 from Andrew Pinski ---
Created attachment 57515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57515=edit
Reduced
On Fri, Feb 23, 2024 at 02:43:45PM +0100, Juergen Christ wrote:
> The emulation via word mode tries to perform integer arithmetic on floating
> point values instead of floating point arithmetic. This leads to
> mis-compilations.
>
> Failure occured on s390x on these existing test cases:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #14 from Tamar Christina ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646415.html
"Richard Earnshaw (lists)" writes:
> On 21/02/2024 17:47, Evgeny Karpov wrote:
>> Hello,
>>
>> We would like to take your attention to the review of changes for the
>> new GCC target, aarch64-w64-mingw32. The new target will be
>> supported, tested, added to CI, and maintained by Linaro. This
On Tue, Feb 20, 2024 at 06:35:34PM +0800, Kewen.Lin wrote:
> on 2024/2/8 03:58, Michael Meissner wrote:
> $ grep -r "define PROCESSOR_DEFAULT" gcc/config/rs6000/
> gcc/config/rs6000/aix71.h:#define PROCESSOR_DEFAULT PROCESSOR_POWER7
> gcc/config/rs6000/aix71.h:#define PROCESSOR_DEFAULT64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fdf9df9d55802e1d8ff0bd14585ea61b2bb9d798
commit r14-9158-gfdf9df9d55802e1d8ff0bd14585ea61b2bb9d798
Author: Jakub Jelinek
Date:
On Fri, Feb 23, 2024 at 9:51 AM Richard Sandiford
wrote:
>
> Evgeny Karpov writes:
> > The calling ABI enum definition has been done following a similar
> > convention in
> >
Hi All,
In certain cases we can have a situation where the merge block has a vUSE
virtual PHI and the exits do not. In this case for instance the exits lead
to an abort so they have no virtual PHIs. If we have a store before the first
exit and we move it to a later block during vectorization we
On 2/23/24 08:53, Christophe Lyon wrote:
On Fri, 23 Feb 2024 at 10:13, Christophe Lyon
wrote:
On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
Hi!
When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
constructor is supposed to return this pointer, but when we cp_fold
Evgeny Karpov writes:
> The calling ABI enum definition has been done following a similar convention
> in
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
>
> MS_ABI is used in gcc/config/i386/mingw32.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
--- Comment #4 from Sam James ---
I was just going off "incorrect debug info" in comment 0 given it's the only
thing I changed recently. If not, then I've got no idea.
If I were sure it were dwz, I'd file a bug there ;)
On Thu, 22 Feb 2024 20:29:37 PST (-0800), Kito Cheng wrote:
I guess Palmer is too busy, so committed to trunk :P
Thanks, I got distracted with some work stuff ;)
On Tue, Feb 13, 2024 at 11:55 PM Jeff Law wrote:
On 2/9/24 09:53, Palmer Dabbelt wrote:
> This builds for me, and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #5 from Andrew Pinski ---
This fixes patch causes the code to be rejected:
```
diff --git a/gcc/function.cc b/gcc/function.cc
index 5ffd438475e..7a0f7faa2d7 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -242,7 +242,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Sam James changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment #2
Evgeny Karpov writes:
> From 1ea6efa6f88d131884ecef21c4b5d2ecbab14ea7 Mon Sep 17 00:00:00 2001
> From: Zac Walker
> Date: Tue, 20 Feb 2024 18:06:36 +0100
> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for
> AArch64
>
> Define Cygwin and MinGW environment such as types,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #9 from Jakub Jelinek ---
Note, most not too old compilers handle small constant size memcpy as an
efficient way to load/store unaligned values and it is also portable. So,
instead of
*dstp = *srcp ^ *bufp;
if all those can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #2 from Andrew Pinski ---
Oh yes because I am building without `--enable-checking=release` .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #3 from Andrew Pinski ---
#5 0x0110cb3f in simplify_const_unary_operation (code=ZERO_EXTEND,
mode=E_DImode, op=0x776e0440, op_mode=E_SImode) at
../../gcc/simplify-rtx.cc:2131
2131 result = wide_int::from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #1 from Andrew Pinski ---
I get a different ICE:
t5.c: In function ‘foo’:
Evgeny Karpov writes:
> From 55fd2a63afa9abb3543d714b6f5925efd2682e08 Mon Sep 17 00:00:00 2001
> From: Zac Walker
> Date: Wed, 21 Feb 2024 12:20:46 +0100
> Subject: [PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF
>
> Define ASM specific for COFF format on AArch64.
>
> gcc/ChangeLog:
>
>
"Richard Earnshaw (lists)" writes:
> On 21/02/2024 18:30, Evgeny Karpov wrote:
>>
> +/* X18 reserved for the TEB on Windows. */
> +#ifdef TARGET_ARM64_MS_ABI
> +# define FIXED_X18 1
> +# define CALL_USED_X18 0
> +#else
> +# define FIXED_X18 0
> +# define CALL_USED_X18 1
> +#endif
>
> I'm not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
--- Comment #4 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html
Fix libatomic build to support --disable-gnu-indirect-function on AArch64.
Always build atomic_16.S and add aliases to the __atomic_* functions if
!HAVE_IFUNC.
Passes regress and bootstrap, OK for commit?
libatomic:
PR target/113986
* Makefile.in: Regenerated.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #8 from Chris Rapier ---
My apologies for misunderstanding and for coming across as aggressive in my
last response. This section of the code is about 15 years old so it hasn't,
obviously, been subject to a close enough review until
This fixes the cost model for BFI instructions which don't
use directly zero_extract on the LHS.
aarch64_bfi_rtx_p does the heavy lifting by matching of
the patterns.
Note this alone does not fix PR 107270, it is a step in the right
direction. There we get z zero_extend for the non-shifted part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #1 from Sam James ---
I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2
-fno-vect-cost-model -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Bug ID: 114081
Summary: [14 regression] ICE in verify_dominators when building
php-8.3.3 (error: dominator of 16 should be 111, not
3)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #7 from Andrew Pinski ---
(In reply to Chris Rapier from comment #5)
> So what you are saying is that behaviour *has* changed and what was a valid
> operation for 15 years is now invalid. I'm not mad about that. I just needed
> to
On 22.02.2024 18:45, Andrew Pinski wrote:
On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
wrote:
On 21/02/2024 18:30, Evgeny Karpov wrote:
+/* X18 reserved for the TEB on Windows. */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #5 from Chris Rapier ---
So what you are saying is that behaviour *has* changed and what was a valid
operation for 15 years is now invalid. I'm not mad about that. I just needed to
know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #27 from Sam James ---
Can someone sanity-check me on this by trying the instructions at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079#c0?
I think I can still hit the original crash, it's just flaky (it might pass
sometimes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #26 from Sam James ---
*** Bug 114079 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #4 from Jonathan Wakely ---
You could have checked this very easily using -fsanitize=undefined just like it
asks you to at https://gcc.gnu.org/bugs/ and at the top of the page when you
created this bug.
dst is 512-bit aligned
Hi Richard,
> This bit isn't. The correct fix here is to fix the pattern(s) concerned to
> add the missing predicate.
>
> Note that builtin-bswap.x explicitly mentions predicated mnemonics in the
> comments.
I fixed the patterns in v2. There are likely some more, plus we could likely
merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #3 from Jakub Jelinek ---
The testcase segfaults since r13-1607-gc3ed9e0d6e96d8697e4bab994f8acbc5506240ee
when the backend started using more aggressively vector instructions for
operations like the 128-bit logical ops, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #1 from Jakub Jelinek ---
That is undefined behavior, __int128/__int128_t/__uint128_t needs 16-byte
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Bug ID: 114080
Summary: Inconsistent handling of 128bit ints between GCC
versions
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
1 - 100 of 225 matches
Mail list logo
