On Fri, Aug 6, 2021 at 12:59 PM Hongtao Liu wrote:
>
> On Fri, Aug 6, 2021 at 11:44 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Hi:
> > > ---
> > > OK, I think sth is amiss here upthread. insv/extv do look
On 05/08/2021 14:53, Martin Liška wrote:
On 7/23/21 11:39 AM, Sebastian Huber wrote:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda
info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101780
--- Comment #4 from KL ---
I get it but, as is, with no more contextual information, it is an annoying
warning.
Not enough information for the developer is the real problem here.
On Thu, Aug 5, 2021 at 5:20 AM Segher Boessenkool
wrote:
>
> On Wed, Aug 04, 2021 at 11:22:53AM +0100, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Wed, Aug 04, 2021 at 10:10:36AM +0100, Richard Sandiford wrote:
> > >> Richard Biener writes:
> > >> > Alternatively only
On Thu, Aug 5, 2021 at 5:20 AM Segher Boessenkool
wrote:
>
> On Wed, Aug 04, 2021 at 11:22:53AM +0100, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Wed, Aug 04, 2021 at 10:10:36AM +0100, Richard Sandiford wrote:
> > >> Richard Biener writes:
> > >> > Alternatively only
On Fri, Aug 6, 2021 at 11:44 AM Andrew Pinski via Gcc-patches
wrote:
>
> On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
> wrote:
> >
> > Hi:
> > ---
> > OK, I think sth is amiss here upthread. insv/extv do look like they
> > are designed
> > to work on integer modes (but docs do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64165
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61722
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
On Thu, Aug 5, 2021, at 8:30 AM, Michael Matz wrote:
> Hello,
>
> On Wed, 4 Aug 2021, John Ericson wrote:
>
> > On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote:
> > > ... the 'as' and 'ld' executables should be simply found within the
> > > version and target specific GCC libexecsubdir,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61463
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
wrote:
>
> Hi:
> ---
> OK, I think sth is amiss here upthread. insv/extv do look like they
> are designed
> to work on integer modes (but docs do not say anything about this here).
> In fact the caller of extract_bit_field_using_extv is
Hi:
---
OK, I think sth is amiss here upthread. insv/extv do look like they
are designed
to work on integer modes (but docs do not say anything about this here).
In fact the caller of extract_bit_field_using_extv is named
extract_integral_bit_field. Of course nothing seems to check what kind of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711
--- Comment #8 from bootmgr at 163 dot com ---
(In reply to ctice from comment #6)
> I applied the patch supplied in comment 5. I added
> --with-sysroot=/usr/local to my configure command (still not using
> --enable-threads=mcf or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52288
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101796
--- Comment #1 from Hongtao.liu ---
There's 2 issues.
1. simplify_rtx should be able to simplify it.
2. x86 backend use ix86_gen_scratch_sse_rtx (mode) which prevent simplication.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101796
Bug ID: 101796
Summary: Miss optimization to optimized (vashl op0, (op1:
const_duplicate_vector)) to (ashl op0 op1_inner)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816
--- Comment #5 from Andrew Pinski ---
The edge is also marked with EDGE_CROSSING. So maybe there is a way to try
communicate this to the register allocator.
[PATCH] Fix typo in fold-vec-load-builtin_vec_xl-* tests.
When I checked in the fix for running tests on power10 systems with
power10 code generation, I had a typo in the
fold-vec-load-builtin_vec_xl-* tests, swapping 'x' and 'v' in the p?lxv
pattern.
I checked this patch on a little endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783
--- Comment #1 from nick huang ---
The following snippet of code and error gives more clear the issue.
Considering:
template struct A{
typedef T& Type;
};
template
void f(const typename A::Type){}
struct B{};
template <>
void f(const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
On 7/30/21 9:06 AM, Jason Merrill wrote:
On 7/27/21 2:56 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
Are there any other suggestions or comments or is the latest revision
okay to commit?
OK.
I had to make a few more adjustments to fix up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101787
Hongtao.liu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744
H.J. Lu changed:
What|Removed |Added
CC||heinzisoft at web dot de
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
H.J. Lu changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #12 from H.J. Lu ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #11 from Filipe Brandenburger ---
BTW, I just checked and see that the commit is already pushed upstream:
https://github.com/gcc-mirror/gcc/commit/72264a639729a5dcc21dbee304717ce22b338bfd
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #10 from Filipe Brandenburger ---
(In reply to H.J. Lu from comment #9)
> Please try:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576603.html
>
> on GCC master branch. I can create a backport branch for GCC 11 if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57024
Andrew Pinski changed:
What|Removed |Added
Known to work||4.5.3, 4.9.0, 4.9.4, 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56406
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711
--- Comment #7 from ctice at gcc dot gnu.org ---
Also, I downloaded the sources for mcfgthread from the repo supplied in
comment5, but I can't seem to get that to build -- the GCC on my machine does
not recognize "-municode" as a valid flag. Is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711
--- Comment #6 from ctice at gcc dot gnu.org ---
I applied the patch supplied in comment 5. I added --with-sysroot=/usr/local
to my configure command (still not using --enable-threads=mcf or
--enable-vtable-verify). Now it configures, but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
On 8/4/21 3:46 AM, Richard Earnshaw wrote:
On 03/08/2021 18:44, Martin Sebor wrote:
On 8/3/21 4:11 AM, Prathamesh Kulkarni via Gcc wrote:
On Tue, 27 Jul 2021 at 13:49, Richard Biener
wrote:
On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc
wrote:
On Fri, 23 Jul 2021 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50214
--- Comment #1 from Andrew Pinski ---
The problem is you cann't use :P unless you have a templated pattern which
strmov/strset are.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
--- Comment #3 from Andrew Pinski ---
GCC, ICC, clang nor MSVC does this. Someone would need to look at the
instruction to see if it is valid to do for the C++11 memory model too. Does it
write to the memory location even without the add?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49869
--- Comment #1 from Andrew Pinski ---
On the trunk I only see one copy of the loop:
.L11:
movups (%rbx,%rax), %xmm7
movups 0(%rbp,%rax), %xmm0
movups (%r9,%rax), %xmm1
subps %xmm7, %xmm0
movups
rustspec.cc was based on the Go frontend gospec.cc. Remove special
handling of math and pthread libraries and profiling option. Handle
.rs files instead of .go files. Keep support for linking with (static)
librust which is currently commented out. Add generic static-librust
option to common.opt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47626
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711
--- Comment #5 from bootmgr at 163 dot com ---
(In reply to ctice from comment #4)
> Is there something special I need to download, set up, or build in order to
> do mingw32 cross-compiles?
>
> I'm getting configure/build failures even when I
On Thu, 2021-08-05 at 20:27 +0530, Ankur Saini wrote:
>
>
> > On 05-Aug-2021, at 4:56 AM, David Malcolm
> > wrote:
> >
> > On Wed, 2021-08-04 at 21:32 +0530, Ankur Saini wrote:
> >
> > [...snip...]
> > >
> > > - From observation, a typical vfunc call that isn't devirtualised
> > > by
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
Andrew Pinski changed:
What|Removed |Added
Known to work||8.1.0, 9.1.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
CC||gcc-bugs at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46551
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Snapshot gcc-9-20210805 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210805/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39843
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43225
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47895
--- Comment #4 from Andrew Pinski ---
This was fixed by r0-124016.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47895
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101795
Bug ID: 101795
Summary: (x > QNaNf) is not a constant expression
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
-Wmismatched-new-delete partly relies on valid_new_delete_pair_p()
to detect matching calls to operator new and delete. The function
returns a conservative result which, when indicating a mismatch,
the warning then works to make more accurate before it triggers.
As it turns out, the logic is
As I mentioned in the description of the access warning pass when
I submitted it in July(*), I planned to change the -Wstringop-xxx
code in the pass to run on the GIMPLE IL instead of on trees in
builtins.c (and elsewhere). The attached patch implements this
change along with moving more warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45090
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101794
Bug ID: 101794
Summary: std::lerp with NaN input does not result in NaN
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42646
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39843
Andrew Pinski changed:
What|Removed |Added
Target||ILP32
--- Comment #4 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39843
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
--- Comment #4 from Andrew Pinski ---
(In reply to thutt from comment #3)
> Thanks for the quick triage. If the optimizer is getting confused about
> control / data flow, is it possible that it's making bad decisions for
> codegen?
No, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31802
Andrew Pinski changed:
What|Removed |Added
Known to work||4.5.3, 4.7.1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
--- Comment #3 from thutt at vmware dot com ---
Thanks for the quick triage. If the optimizer is getting confused about
control / data flow, is it possible that it's making bad decisions for codegen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30492
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30685
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101792
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
--- Comment #1 from thutt at vmware dot com ---
Also using godbolt.org, this sample fails from 4.9.0 to trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
Bug ID: 101793
Summary: Incorrect production of ‘may be used uninitialized in
this function [-Werror=maybe-uninitialized]'
Product: gcc
Version: 9.3.0
Status:
On Thu, Aug 05, 2021 at 12:19:37PM -0600, Sandra Loosemore wrote:
> On 8/5/21 11:33 AM, Michael Meissner wrote:
> >At the moment, we only fully support C and C++ when changing the long double
> >format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is
> >invoked (and assuming
On Thu, Aug 05, 2021 at 06:49:21PM +0200, Martin Liška wrote:
> On 8/5/21 5:39 PM, Segher Boessenkool wrote:
> >>>If -mbork is the default, the coompiler whould behave the same if you
> >>>invoke it with -mbork as when you do not. And the optimize attribute
> >>>should work exactly the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101731
--- Comment #3 from Andrew Pinski ---
This is most likely caused by r7-2434.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101731
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101731
Andrew Pinski changed:
What|Removed |Added
Keywords||error-recovery,
|
Hi,
On Fri, Jul 30, 2021 at 03:03:13AM +0200, Mark Wielaard wrote:
> That variant is attached and can also be found here:
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-loc
> The original is also here:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101792
Bug ID: 101792
Summary: Compiling access to templated parent object fails with
unrelated message: invalid use of 'auto'
Product: gcc
Version: unknown
Status:
This Go patch extends the internal runtime/internal/atomic package to
match the externally visible sync/atomic package. This is the
gofrontend version of https://golang.org/cl/289152. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101505
--- Comment #8 from David Binderman ---
(In reply to Richard Biener from comment #7)
> This is a different bug though, probably caused by HJs changes, looks like
> the fixed PR101742, indeed updating and re-building my dev tree makes the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970
--- Comment #9 from Martin Uecker ---
The sizeof problem is that in c_expr_sizeof_expr the argument of sizeof is only
evaluated for VLAs but not for structs of variable size. The information about
the size is then lost. Changing this fixes some
On 8/5/21 11:33 AM, Michael Meissner wrote:
At the moment, we only fully support C and C++ when changing the long double
format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is
invoked (and assuming you are using GLIBC 2.32 or newer).
For Fortran and the other languages, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369
--- Comment #6 from Jakub Jelinek ---
Another possibility would be to detect it in cxx_eval_binary_expression before
calling fold_binary_loc and punt.
But, the constant evaluation actually doesn't track whether it is the same or
different
On 05/08/21 15:40 +0100, Jonathan Wakely wrote:
On 05/08/21 15:19 +0100, Jonathan Wakely wrote:
On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
This adds [[nodiscard]] throughout , as proposed by P2377R0
(with some minor corrections).
The attribute is added for all modes from C++11 up, using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101782
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c8b024fa4b76bfd914e96dd3cecfbb6ee8e91316
commit r12-2773-gc8b024fa4b76bfd914e96dd3cecfbb6ee8e91316
Author: Jonathan Wakely
On Wed, Aug 04, 2021 at 02:14:07PM -0600, Sandra Loosemore wrote:
> I was trying last week to run my not-yet-committed TS29113 testsuite
> on a powerpc64le-linux-gnu target and ran into some problems with
> the kind constants c_float128 and c_float128_complex from the
> ISO_C_BINDING module; per
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst[234][q] and vst1[q]_x[234] bfloat
Neon intrinsics in arm_neon.h.
It also adds new code generation tests to verify
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst2[q]_lane Neon intrinsics in
arm_neon.h.
It also adds new code generation tests to verify that superfluous move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79938
--- Comment #6 from postmaster at raasu dot org ---
I tried identical code using intrinsics with both clang and gcc:
clang:
movdqa xmm1,XMMWORD PTR [rip+0xd98]# 402050 <_IO_stdin_used+0x50>
pand xmm1,xmm0
movdqa xmm2,xmm0
pshufb
On 8/5/21 5:39 PM, Segher Boessenkool wrote:
On Thu, Aug 05, 2021 at 02:05:24PM +0200, Martin Liška wrote:
On 7/23/21 7:57 PM, Segher Boessenkool wrote:
Hi!
On Fri, Jul 23, 2021 at 07:47:54AM +0200, Martin Liška wrote:
On 7/12/21 7:20 PM, Segher Boessenkool wrote:
+static __attribute__
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst3[q]_lane Neon intrinsics in
arm_neon.h.
It also adds new code generation tests to verify that superfluous move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
--- Comment #7 from Matthew Malcomson ---
Hi there,
I didn't check all the new tests that Christophe mentioned, but all those I
checked had `dg-require-effective-target hwaddress_exec` in them.
The test that determines that effective target
The KIND argument of the INDEX intrinsic is a compile time constant
that is used at compile time only to resolve to a kind-specific library
method. It is otherwise completely ignored at runtime, and there is
no code generated for it as the library procedure has no kind argument.
This confuses
This reverts commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for
its testcase.
gcc/fortran/
* intrinsic.c (add_sym_4ind): Remove.
(add_functions): Use add_sym4 instead of add_sym4ind.
Don’t special case the index intrinsic.
* iresolve.c
Now that we can get information about an actual arg's associated
dummy using the associated_dummy attribute, the field missing_arg_type
contains redundant information.
This removes it.
gcc/fortran/
* gfortran.h (gfc_actual_arglist::missing_arg_type): Remove.
* interface.c
This adds two functions working with the wrapper class gfc_dummy_arg
and makes usage of them to simplify a bit the walking of elemental
procedure arguments for scalarization. As information about dummy arguments
can be obtained from the actual argument through the just-introduced
There was originally no way from an actual argument to get
to the corresponding dummy argument, even if the job of sorting
and matching actual with dummy arguments was done.
The closest was a field named actual in gfc_intrinsic_arg that was
used as scratch data when sorting arguments of one
Preliminary refactoring to make further changes more obvious.
No functional change.
gcc/fortran/
* intrinsic.c (sort_actual): initialise variable and use it earlier.
---
gcc/fortran/intrinsic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
Introduce a new wrapper class gfc_dummy_arg that provides a common
interface to both dummy arguments of user-defined procedures (which
have type gfc_formal_arglist) and dummy arguments of intrinsic procedures
(which have type gfc_intrinsic_arg).
gcc/fortran/
* gfortran.h
Hello,
This is the second submit of a patch series whose first version[1] was not
welcome because of its C++ usage.
After some thought I figured out that rewriting the series without C++
features would not be that impacting after all.
So here you go, the (not so) good old-fashioned way.
The
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst4[q]_lane Neon intrinsics in
arm_neon.h.
It also adds new code generation tests to verify that superfluous move
On Thu, Aug 05, 2021 at 08:47:54AM -0500, Bill Schmidt wrote:
> Hi Segher,
>
> On 8/4/21 5:29 PM, Segher Boessenkool wrote:
> >On Thu, Jul 29, 2021 at 08:30:48AM -0500, Bill Schmidt wrote:
> >+rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
> >>+ $(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101780
--- Comment #3 from Jonathan Wakely ---
(In reply to KL from comment #2)
> > How would P,Q,R be left uninitialized?
>
> Only if the analyzer has the info that, at this stage, there no default
> value for the field.
> It could be interesting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89085
--- Comment #2 from Jonathan Wakely ---
Accepted since r11-1571 and r10-8343:
c++: Refinements to "more constrained".
P2113 from the last C++ meeting clarified that we only compare constraints
on functions or function templates that have
1 - 100 of 285 matches
Mail list logo
