https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
Andrew Pinski changed:
What|Removed |Added
CC||qiyao at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83010
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47590
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-debug
Component|debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70419
--- Comment #3 from Andrew Pinski ---
(In reply to Balint Reczey from comment #1)
> Also please fix the error message emitted when trying to link a non-PIE
> non-PIC static library to a position independent executable:
The error message comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64499
--- Comment #1 from Andrew Pinski ---
The problem is in ASM_FINAL_SPEC in gcc.c:
#ifndef ASM_FINAL_SPEC
#define ASM_FINAL_SPEC \
"%{gsplit-dwarf: \n\
objcopy --extract-dwo \
%{c:%{o*:%*}%{!o*:%w%b%O}}%{!c:%U%O} \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90443
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90902
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91244
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-01
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99783
--- Comment #9 from shorne at gmail dot com ---
I was able to debug this.
Basically, the code to avoid overflow by masking the relocation value with
0x fails if the relocation value has the 16-bit sign bit set. I.e. 0x90e4
has 0x8000 set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103884
Andrew Pinski changed:
What|Removed |Added
Keywords||assemble-failure,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103878
--- Comment #3 from Fedor Chelnokov ---
Bugreport for Clang/LLVM: https://github.com/llvm/llvm-project/issues/52942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103884
Bug ID: 103884
Summary: ICE when calling static and non-static member function
templates with the same parameter types and requires
clause
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86143
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103878
--- Comment #2 from Andrew Pinski ---
Since it was reported that clang/LLVM have the same issue, is there a bug
report about that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98364
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
Summary|[modules] global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7918d8270a43e42b0cba902ec17ce87b6a3c74a9
commit r12-6163-g7918d8270a43e42b0cba902ec17ce87b6a3c74a9
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103639
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:222dbebefbbc07f78e51d82ba605988ef57e5fc9
commit r12-6162-g222dbebefbbc07f78e51d82ba605988ef57e5fc9
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 99051, which changed state.
Bug 99051 Summary: [modules] ICE/SIGSEGV in get_location_from_adhoc_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99051
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99915
Andrew Pinski changed:
What|Removed |Added
CC||boris at kolpackov dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99051
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 101184, which changed state.
Bug 101184 Summary: [modules] ICE and unexpected behavior when using precisely
5 stl-memory includes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101184
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99915
Andrew Pinski changed:
What|Removed |Added
CC||1lumin at protonmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101184
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
--- Comment #3 from Andrew Pinski ---
Sorry PR 100052.
*** This bug has been marked as a duplicate of bug 100052 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99861
Bug 99861 depends on bug 12, which changed state.
Bug 12 Summary: internal compiler error: in hashtab_chk_error, at
hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103769
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99915
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479
--- Comment #19 from Andrew Pinski ---
Created attachment 52106
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52106=edit
reduced testcase
Not even though it says PR 100129, this is the reduced testcase.
just execute t.sh which does:
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #6 from Andrew Pinski ---
I doubt many people use gsplit-dwarf really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
Aurelien Jarno changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment
Hi,
This patch adds nansq() to libquadmath, a function that returns a signalling
NaN. It is a need for full libgfortran support of signalling NaNs, because not
all targets that have _Float128 define a __builtin_nanq() function.
Bootstrapped and tested on x86_64-pc-gnu-linux and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93239
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879
Luiz Henrique Laurini changed:
What|Removed |Added
CC||lhlaurini at hotmail dot com
Snapshot gcc-10-20211231 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20211231/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Attached patch pushed as cb48166e52c0f159eb80a0666c4847825e294ec0
Confirmed by Dave to make the testcase pass on hppa-unknown-linux-gnu
FX
0001-Fortran-Fix-test-on-targets-without-REAL128.patch
Description: Binary data
On Fri, Dec 31, 2021 at 2:19 PM Noah Goldstein wrote:
>
> On Fri, Dec 31, 2021 at 4:14 PM Noah Goldstein
> wrote:
> >
> > On Fri, Dec 31, 2021 at 2:36 PM H.J. Lu wrote:
> > >
> > > On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein
> > > wrote:
> > > >
> > > > On Fri, Dec 31, 2021 at 12:20 PM
On Fri, Dec 31, 2021 at 4:14 PM Noah Goldstein wrote:
>
> On Fri, Dec 31, 2021 at 2:36 PM H.J. Lu wrote:
> >
> > On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein
> > wrote:
> > >
> > > On Fri, Dec 31, 2021 at 12:20 PM H.J. Lu wrote:
> > > >
> > > > Update MEMSET_VDUP_TO_VEC0_AND_SET_RETURN to
On Fri, Dec 31, 2021 at 2:36 PM H.J. Lu wrote:
>
> On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein
> wrote:
> >
> > On Fri, Dec 31, 2021 at 12:20 PM H.J. Lu wrote:
> > >
> > > Update MEMSET_VDUP_TO_VEC0_AND_SET_RETURN to use PXOR, which has lower
> > > lantency and higher throughput than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879
--- Comment #2 from Andrew Pinski ---
MSVC also rejects it:
example.cpp
(14): error C2131: expression did not evaluate to a constant
(10): note: failure was caused by call of undefined function or one not
declared 'constexpr'
(10): note: see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879
--- Comment #1 from Andrew Pinski ---
clang rejects it also (with their libc++):
:10:5: error: variable of non-literal type 'S' cannot be defined in a
constexpr function
S s{"str"};
^
:6:29: note: 'S' is not literal because it has data
* Noah Goldstein:
>> >> bzero does not have the interface ambiguity that bcmp has. So the
>> >> only reason for not using it would be namespace cleanliness.
>> >
>> > bzero isn't a standard C function and it isn't optimized like memset
>> > in glibc.
>
> It could be an issue if the
On Fri, Dec 31, 2021 at 3:02 PM Florian Weimer wrote:
>
> * H. J. Lu:
>
> > On Fri, Dec 31, 2021 at 12:43 PM Florian Weimer wrote:
> >>
> >> * H. J. Lu via Libc-alpha:
> >>
> >> > bzero is an alias of SSE2 memset in glibc. Should we add __memsetzero
> >> > like __memcmpeq? It should be almost
* H. J. Lu:
> On Fri, Dec 31, 2021 at 12:43 PM Florian Weimer wrote:
>>
>> * H. J. Lu via Libc-alpha:
>>
>> > bzero is an alias of SSE2 memset in glibc. Should we add __memsetzero
>> > like __memcmpeq? It should be almost free in glibc. GCC can use
>> > __memsetzero if it is available.
>>
>>
On Fri, Dec 31, 2021 at 12:43 PM Florian Weimer wrote:
>
> * H. J. Lu via Libc-alpha:
>
> > bzero is an alias of SSE2 memset in glibc. Should we add __memsetzero
> > like __memcmpeq? It should be almost free in glibc. GCC can use
> > __memsetzero if it is available.
>
> bzero does not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
--- Comment #4 from Andrew Pinski ---
noipa might help also. Though I can't remember if the IPA RA checks that (it
should).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Jose Silva changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
* H. J. Lu via Libc-alpha:
> bzero is an alias of SSE2 memset in glibc. Should we add __memsetzero
> like __memcmpeq? It should be almost free in glibc. GCC can use
> __memsetzero if it is available.
bzero does not have the interface ambiguity that bcmp has. So the
only reason for not using
On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein wrote:
>
> On Fri, Dec 31, 2021 at 12:20 PM H.J. Lu wrote:
> >
> > Update MEMSET_VDUP_TO_VEC0_AND_SET_RETURN to use PXOR, which has lower
> > lantency and higher throughput than VPBROADCAST, for zero constant.
> > Since the most common usage of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639
--- Comment #12 from dave.anglin at bell dot net ---
On 2021-12-29 12:26 p.m., fxcoudert at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639
>
> --- Comment #10 from Francois-Xavier Coudert
> ---
> Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103876
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Hi Joseph,
> 1. You should use -fsignaling-nans if you want signaling NaNs to work
> correctly.
Thanks, we’ll compile the libgfortran parts that are IEEE-related with that
from now on. Sounds like a good idea, anyway.
> 3. There is probably a reasonable case for interpreting such conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103866
--- Comment #10 from Jonathan Wakely ---
Created attachment 52104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52104=edit
libstdc++: Fix freestanding build using --without-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877
Jonathan Wakely changed:
What|Removed |Added
Keywords||documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103866
--- Comment #9 from Jonathan Wakely ---
GCC_HEADER_STDINT is unusable for freestanding, because it uses autoconf's
AC_CHECK_SIZEOF with the default includes, which does #include
unconditionally.
But we only use GCC_HEADER_STDINT to create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103880
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103878
--- Comment #1 from Jonathan Wakely ---
Isn't this simply the documented limitation of tsan?
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.races
On Fri, Dec 31, 2021 at 1:32 AM Jakub Jelinek wrote:
>
> The following patch adjusts the testcase for the above change.
> Tested on x86_64-linux, ok for trunk?
>
> 2021-12-31 Jakub Jelinek
>
> * gcc.misc-tests/godump-1.c: Adjust for renaming of last
> field from _align suffix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
Francois-Xavier Coudert changed:
What|Removed |Added
Attachment #52101|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103883
Bug ID: 103883
Summary: Signaling NaN is not handled correctly on typedef'd
floating-point type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881
--- Comment #2 from Jakub Jelinek ---
See C99 6.3.1.1/2 and 6.3.1.8, yes, in all cases of |=, &=, |, & the uint8_t
operands are promoted to int.
And the reason why we don't warn for the simple binary operations is that those
common cases have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881
--- Comment #1 from thomas at habets dot se ---
I just reproduced this from git HEAD, as seen on github (commit
e3cbb8c66c930ba738674b0fcf29848dc3ecfef2), with latest commit today,
2021-12-31.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
thomas at habets dot se changed:
What|Removed |Added
CC||thomas at habets dot se
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Bug ID: 103882
Summary: Register corruption in ASM only functions when
optization is -O2/-Os/-O3
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity:
On Fri, 31 Dec 2021, FX via Gcc wrote:
> The reason I ended up in this rabbit hole is that I am implementing some
> handling of signalling NaNs in libgfortran. Could someone either confirm
> that the behavior observed above is a bug, or if not, kindly explain to
> me why it happens?
1. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #14 from Francois-Xavier Coudert ---
Created attachment 52101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52101=edit
First attempt at a patch
This is a first version of a patch for support of signalling NaNs. What it
does:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881
Bug ID: 103881
Summary: Wconversion false positive when using |= and &= with
two rvalues in binary op
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103880
--- Comment #1 from Jose Silva ---
pressed enter, and accidentally submitted :|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103880
Bug ID: 103880
Summary: GCC
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #4 from Aurelien Jarno ---
This is a better backtrace after building a riscv64 cross compiler from the
releases/gcc-11 branch:
/tmp/onnxifi_loader.c.i:6:1: internal compiler error: Segmentation fault
6 | }
| ^
0xadad0f
Hi,
I think I’ve found a bug in the handling of __builtin_nans() in GCC, but I am
aware that this is a tricky area, so before claiming so I would like to check
with the experts. Consider the following code:
$ cat v.c
#include
#include
#if 1
typedef double GFC_REAL_8;
#else
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329
--- Comment #4 from Jakub Jelinek ---
But, if we avoid that
/* Mark enumeration types as used. */
if (TREE_CODE (decl) == CONST_DECL)
used_types_insert (DECL_CONTEXT (decl));
during error.c instantiations, will it be actually marked if
Hi Jakub,
Actually playing with that (e.g. for matmul) revealed a brown paper bag
bug in the previous patch, fixed thusly:
OK.
Thanks a lot!
Best regards
Thomas
Hi Jakub,
Ok for power-ieee128 branch?
OK. Thanks for stepping up! I am a little distracted right now, but
I think I will also continue working on this for a bit.
Best regards
Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879
Bug ID: 103879
Summary: error: accessing value of variant::_Copy_ctor_base
through a 'const variant' glvalue in a
constant expression
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103878
Bug ID: 103878
Summary: ThreadSanitizer: false report about data race
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103873
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #3 from Aurelien Jarno ---
I have been able to reduce the reproducer code to almost nothing, so I guess
the issue is mostly related to the options and not to the source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
Aurelien Jarno changed:
What|Removed |Added
Attachment #52099|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
Eric Estievenart changed:
What|Removed |Added
CC||steve+gcc at tecwec dot eu
---
On Fri, Dec 31, 2021 at 03:16:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Haven't played enough with it to see if the various *_r17 or *_c17
> API entrypoints are called (but verified abi_kind is right in the
> debugger), in all my attempts so far everything was emitted inline.
Actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877
Bug ID: 103877
Summary: libstdc++ docs give a bad recommendation for printing
C++ defines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Hi!
The following patch detects the powerpc64le-linux kind == 16 cases
and for the -mabi=ieeelongdouble case (no matter whether it is the
configured in default or just option used on the command line) uses
_r17 or _c17 instead of _r16 or _c17 in the library API names.
>From what I can see, e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103875
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103876
Bug ID: 103876
Summary: Parameter pack not expanded in lambda within
static_assert in a fold-expression of a lambda
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Hi!
The following patch quiets
../../../libgfortran/generated/in_pack_r17.c:35:1: warning: no previous
prototype for ‘internal_pack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_pack_c17.c:35:1: warning: no previous
prototype for ‘internal_pack_c17’ [-Wmissing-prototypes]
Although we build the library with GCC which is known to support
_Static_assert this might be done on a system without the macro
mapping static_assert to the compiler keyword.
The use of static_assert introduced with r12-6126-g3430132f3e82
causes bootstrap to fail on such targets, fixed by using
... for targets that support vectorization of 2-byte char stores
with unaligned address at plain O2.
2021-12-31 Uroš Bizjak
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_vect_slp_store_usage):
Handle TEST_V2QI_2.
(check_effective_target_vect_slp_v2qi_store_unalign):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103875
Bug ID: 103875
Summary: Dead writes are not optimized out
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pending
1 - 100 of 113 matches
Mail list logo
