This avoids inline expansion to preserve the warning by making
the memcpy size a non-power-of-two as suggested by Martin Sebor.
Tested on x86_64-unknown-linux-gnu, pushed.
2021-09-29 Richard Biener
* gcc.dg/out-of-bounds-1.c: Make memcpied size not power-of-two.
---
gcc/testsuite/gcc
Hi David.
> The BPF CO-RE support (commit 8bdabb37549f12ce727800a1c8aa182c0b1dd42a)
> mistakenly overwrote bpf-*-* extra_headers in config.gcc, causing
> bpf-helpers.h to not be installed. The redefinition with coreout.h is
> unneeded, so delete it.
This is OK.
Thanks.
>
> gcc/ChangeLog:
>
>
Hi Bill,
Thanks for your prompt comments!
on 2021/9/29 上午3:24, Bill Schmidt wrote:
> Hi Kewen,
>
> Although I agree that what we do now is tragically bad (and will be fixed in
> the builtin rewrite), this seems a little too cavalier to remove all checking
> during initialization without adding
On Linux/x86_64,
e12f66d96fe41c8ef8a0d01b6a8394cd6bce3978 is the first bad commit
commit e12f66d96fe41c8ef8a0d01b6a8394cd6bce3978
Author: Andrew Pinski
Date: Fri Sep 17 04:59:03 2021 +
c: [PR32122] Require pointer types for computed gotos
caused
FAIL: gcc.c-torture/compile/920826-1.c
On 9/28/21 2:24 PM, Bill Schmidt via Gcc-patches wrote:
> Unless you are planning to do a backport, I think the proper way forward
> here is to just wait for the new builtin support to land. In the new code,
> we initialize all built-ins up front, and check properly at expansion time
> whether the
From: Geng Qi
No known code changes, just fixes an inconsistency that was noticed.
Committed.
Jim
gcc/
* config/riscv/riscv.md (mulv4): Call gen_smul3_highpart.
(mulditi3): Call muldi3_highpart.
(muldi3_highpart): Rename to muldi3_highpart.
(mulsidi3): C
On Mon, Sep 27, 2021 at 4:38 AM Geng Qi via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> gcc/ChangeLog:
> * config/riscv/riscv.md
> (muldi3_highpart): Rename to muldi3_highpart.
> (mulditi3): Emit muldi3_highpart.
> (mulsi3_highpart): Rename to mulsi3_highpart.
>
On Tue, Sep 28, 2021 at 3:05 PM Christoph Muellner <
cmuell...@ventanamicro.com> wrote:
> We talked about this in the T&R meeting on Monday.
> Philipp Tomsich mentioned, that he has a patchset from earlier this
> year, which adds support for Zbs.
> He proposed to rebase it and send it to the list
On Wed, Sep 29, 2021 at 12:01 AM Jim Wilson wrote:
>
> On Thu, Sep 23, 2021 at 12:57 AM Kito Cheng wrote:
>>
>> Bit manipulation extension[1] is finishing the public review and waiting for
>> the rest of the ratification process, I believe that will become a ratified
>> extension soon, so I think
On Mon, Sep 27, 2021 at 4:20 AM Christoph Muellner <
cmuell...@ventanamicro.com> wrote:
> In case somebody wants to test this patchset, a patchset for Binutils
> is required as well.
> AFAIK here would be the Binutils branch with the required changes:
>
> https://github.com/riscv-collab/riscv-binu
On Thu, Sep 23, 2021 at 12:57 AM Kito Cheng wrote:
> Bit manipulation extension[1] is finishing the public review and waiting
> for
> the rest of the ratification process, I believe that will become a ratified
> extension soon, so I think it's time to submit to upstream for review now
> :)
>
We
On Tue, 28 Sep 2021, Roger Sayle wrote:
> Next, I'd like to state that your "five restrictions" ontology is an
> excellent starting point, but I'd like to argue that your proposed list
> of 5 is the wrong shape (insufficiently refined). Instead, I'd like to
> counter-propose that an improvement
Hi Harald,
Gerhard's testcase triggers a NULL pointer dereference during the
attempt to expand an invalid constructor. The simple and obvious
solution is to catch that case.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
OK.
Thanks for the patch!
Best regards
Tho
On Tue, 28 Sep 2021, Hongtao Liu via Gcc-patches wrote:
> Yes, that's why I didn't follow the existing pattern, i think we can
> add optimize back to the condition, but not canonicalize_math_p ()
> since there's no math function for _Float16.
At some point we should add _Float16 functions to glib
Dear Fortranners,
Gerhard's testcase triggers a NULL pointer dereference during the
attempt to expand an invalid constructor. The simple and obvious
solution is to catch that case.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
Thanks,
Harald
Fortran: fix error recovery for i
On 9/28/21 7:50 AM, Richard Biener wrote:
On Wed, Sep 15, 2021 at 10:46 AM Martin Liška wrote:
/* Unswitch single LOOP. NUM is number of unswitchings done; we do not allow
@@ -269,6 +311,7 @@ tree_unswitch_single_loop (class loop *loop, int num)
class loop *nloop;
unsigned i, foun
On Tue, Sep 28, 2021 at 08:31:13PM +, Qing Zhao wrote:
> Hi,
>
> This is the patch for the gcc12 changes per your request.
>
> Kees provided most of the wording.
>
> Please take a look and let’s know whether it’s good for commit?
>
> thanks.
>
> Qing
>
> ===
On Tue, Sep 28, 2021 at 03:33:35PM -0400, Jason Merrill wrote:
> > > According to the function comment for defaulted_late_check, won't
> > > COMPLETE_TYPE_P (ctx) always be false here?
>
> Not for a function defaulted outside the class.
>
> > If so, I wonder if we could get away with moving this
Hi,
This is the patch for the gcc12 changes per your request.
Kees provided most of the wording.
Please take a look and let’s know whether it’s good for commit?
thanks.
Qing
From: qing zhao
Date: Tue, 28 Sep 2021 12:01:42 -0700
Subject: [
On Tue, 28 Sept 2021 at 21:21, François Dumont via Libstdc++
wrote:
>
> On 27/09/21 11:06 pm, Jonathan Wakely wrote:
> > On Mon, 27 Sept 2021 at 21:26, François Dumont via Libstdc++
> > wrote:
> >> Here is a small patch to fix a test which fails in
> >> _GLIBCXX_VERSION_NAMESPACE mode.
> >>
> >>
On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote:
> On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote:
> > +void
> > +handle_ignored_attributes_option (vec *v)
> > +{
> > + if (v == nullptr)
> > +return;
> > +
> > + for (auto opt : v)
> > +{
> > + if (strcmp (opt, "c
On 27/09/21 11:06 pm, Jonathan Wakely wrote:
On Mon, 27 Sept 2021 at 21:26, François Dumont via Libstdc++
wrote:
Here is a small patch to fix a test which fails in
_GLIBCXX_VERSION_NAMESPACE mode.
IMHO it would be better to avoid putting content in
versioned namespace, no ?
No opinion on th
On 9/26/21 21:31, nick huang via Gcc-patches wrote:
Hi Jason,
1. Thank you very much for your detailed comments for my patch and I really
appreciate it! Here is my revised patch:
The root cause of this bug is that it considers reference with
cv-qualifiers as an error by generating value for va
Hi!
On Thu, Aug 26, 2021 at 11:53:24AM -0300, Raphael Moreira Zinsly wrote:
> Without dwarf2 unwind tables available _Unwind_Backtrace() is not
> able to return the full backtrace.
> This patch adds a fallback function on powerpc to get the backtrace
> by doing a backchain, this code was originall
On 9/28/21 15:15, Patrick Palka wrote:
Here, when unifying TT with S, processing_template_decl is unset, and
this foils the dependence checks in do_auto_deduction for avoiding
checking constraints on an auto when the initializer is dependent.
This patch fixes this issue by making sure processing
There is no benefit to using _SizeT instead of size_t, and IterT tells
you less about the type than const _CharT*. This removes some unhelpful
typedefs.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/regex_automaton.h (_NFA_base::_SizeT): Remove.
* include
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/regex_compiler.tcc: Add line break in empty while
statement.
* include/bits/regex_executor.tcc: Avoid unused parameter
warning.
Tested x86_64-linux. Committed to trunk.
commit b5f276b8c76d892f
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/regex.h (basic_regex, swap): Add noexcept to
non-throwing functions.
* include/bits/regex_automaton.h (_State_base, _State)
(_NFA_base): Likewise.
* include/bits/regex_compiler.h (_Compi
This fixes a logic error in the futex-based timed wait.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__platform_wait_until_impl):
Return false for ETIMEDOUT and true otherwise.
Tested x86_64-linux.
I'm not seeing any tests fail as
On 9/28/21 09:53, Patrick Palka wrote:
On Tue, 28 Sep 2021, Patrick Palka wrote:
On Tue, 28 Sep 2021, Jakub Jelinek via Gcc-patches wrote:
Hi!
The testcases in the patch are either miscompiled or ICE with checking,
because the defaulted operator== is synthetized too early (but only if
conste
On Thu, 2 Sept 2021 at 22:25, Jonathan Wakely wrote:
>
> On Thu, 2 Sept 2021 at 19:00, Jonathan Wakely wrote:
> >
> > * include/bits/atomic_wait.h (_GLIBCXX_HAVE_PLATFORM_WAIT):
> > Define before first attempt to check it.
> >
> > Tested x86_64-linux and powerpc64-linux, not committ
Hi,
Recognise .d for D source files on the command line. This will
trigger an invocation of dsymutil when a D source is present.
tested along with D patches on i686, powerpc and x86_64 darwin,
pushed to master, thanks,
Iain
gcc/ChangeLog:
* config/darwin.h (DSYMUTIL_SPEC): Recognize D
As an extension, our container adaptors SFINAE away the default
constructor if the adapted sequence container is not default
constructible. When _GLIBCXX_CONCEPT_CHECKS is defined we enforce that
the sequence is default constructible, so the tests for the extension
fail. This disables the relevant
The extension that allows implicitly rebinding a container's allocator
is not allowed when _GLIBCXX_CONCEPT_CHECKS is defined, so skip the
tests for that extension.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
*
testsuite/23_containers/deque/requirements/explicit_instantiatio
This adds some additional checks the the C++98-style concept checks for
iterators, and removes some bogus checks for mutable iterators. Instead
of requiring that the result of dereferencing a mutable iterator is
assignable (which is a property of the value type, not required for the
iterator) check
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/copy/34595.cc: Add missing operation
for type used as an iterator.
* testsuite/25_algorithms/unique_copy/check_type.cc: Likewise.
Tested x86_64-linux. Committed to trunk.
commit 5f1db7627f6
Types used in ordered containers need to be comparable, or the container
needs to use a custom comparison function. These tests fail when
_GLIBCXX_CONCEPT_CHECKS is defined, because the element types aren't
comparable.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/2
The _OutputIteratorConcept should be checked using the correct value
category. The std::move_backward and std::copy_backward algorithms
should use _OutputIteratorConcept instead of _ConvertibleConcept.
In order to use the correct value category, the concept should use a
function that returns _Valu
This allows std::__to_address to be used with __normal_iterator in
C++11/14/17 modes. Without the partial specialization the deduced
pointer_traits::element_type is incorrect, and so the return type of
__to_address is wrong.
A similar partial specialization is probably needed for
__gnu_debug::_Saf
Hi Kewen,
Although I agree that what we do now is tragically bad (and will be fixed in
the builtin rewrite), this seems a little too cavalier to remove all checking
during initialization without adding any checking somewhere else. :-) We still
need to check for invalid usage when the builtin i
Hi,
We have a somewhat unusual situation in that for PPC64, R13 is
both reserved for future use by the ABI document and callee-saved.
In fact, it is already used internally by the pthreads
implementation to contain pthread_self.
So add R13 to the fixed regs, but also keep it in the callee-
saved
Here, when unifying TT with S, processing_template_decl is unset, and
this foils the dependence checks in do_auto_deduction for avoiding
checking constraints on an auto when the initializer is dependent.
This patch fixes this issue by making sure processing_template_decl is
set during the call to
Hi Tobias,
let me first reach for my brown bag...
> Otherwise, the quote from F2018 of my previous email applies:
>
> F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim'
> argument the following. The case without 'dim' just iterates
> through case (i) for each dim. Thus:
>
> "If DIM is pre
Hi,
These two symbols have been emitted since 4.8, but were not added
to the Darwin exports, so we have been using the ones from libgcc.a.
Added to libgcc_s now.
tested on i686 and x86_64-darwin, pushed to master,
thanks
Iain
Signed-off-by: Iain Sandoe
libgcc/ChangeLog:
* config/i386
CTF is supported for C only. Currently, a warning is emitted if the -gctf
command line option is specified for a non-C frontend. This warning is also
used by the GCC testsuite framework - it skips adding -gctf to the list of
debug flags for automated testing, if CTF is not supported for the front
Fix the free'up of btf_var_ids hash_map in btf_finalize ().
Testing notes:
- Bootstrapped GCC with -gbtf as an experiment.
- Usual bootstrap and regression testing on x86_64.
- BPF backend testing - make all-gcc, reg tested bpf.exp, btf.exp and ctf.exp.
(tested using David Faust's config.gcc pa
On Tue, Sep 28, 2021 at 01:25:13PM -0400, Patrick Palka via Gcc-patches wrote:
> On Tue, 28 Sep 2021, Jakub Jelinek wrote:
>
> > On Tue, Sep 28, 2021 at 06:49:38PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> > > > Ah yeah,
The BPF CO-RE support (commit 8bdabb37549f12ce727800a1c8aa182c0b1dd42a)
mistakenly overwrote bpf-*-* extra_headers in config.gcc, causing
bpf-helpers.h to not be installed. The redefinition with coreout.h is
unneeded, so delete it.
gcc/ChangeLog:
* config.gcc (bpf-*-*): Do not overwrite e
On 9/27/21 15:38, Iain Sandoe wrote:
For coroutines, we make copies of the original function arguments into
the coroutine frame. Normally, these are destroyed on the proper exit
from the coroutine when the frame is destroyed.
However, if an exception is thrown before the first suspend point is
On Tue, 28 Sep 2021, Jakub Jelinek wrote:
> On Tue, Sep 28, 2021 at 06:49:38PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> > > Ah yeah, sorry for the noise, I misunderstood the function comment.
> > >
> > > On a related note I t
The previous message told you something was wrong, but not why it
happened or why it's bad. This changes it to explain that the function
is being misused.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward(remove_reference_t&&)):
Improve text o
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/102499
* include/bits/fs_path.h (path::begin, path::end): Add noexcept
to declarations, to match definitions.
Tested x86_64-linux. Committed to trunk.
commit f2b7f56a15d9cbbd2f0db22e0e39c4dd161bab69
Aut
On Tue, Sep 28, 2021 at 06:49:38PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> > Ah yeah, sorry for the noise, I misunderstood the function comment.
> >
> > On a related note I think 'ctx' can also be a NAMESPACE_DECL here in
> > t
On Tue, Sep 28, 2021 at 12:44:58PM -0400, Patrick Palka wrote:
> Ah yeah, sorry for the noise, I misunderstood the function comment.
>
> On a related note I think 'ctx' can also be a NAMESPACE_DECL here in
> the case of a defaulted non-member operator<=> (as in the below), for
> which I'd expect t
On Tue, 28 Sep 2021, Jakub Jelinek wrote:
> On Tue, Sep 28, 2021 at 09:49:11AM -0400, Patrick Palka via Gcc-patches wrote:
> > > --- gcc/cp/method.c.jj2021-09-15 08:55:37.563497558 +0200
> > > +++ gcc/cp/method.c 2021-09-27 13:48:12.139271830 +0200
> > > @@ -3160,8 +3160,11 @@ defaulted_
On 9/28/2021 10:09 AM, Aldy Hernandez wrote:
I really don't know what to do here. This is a bit of whack-o-mole.
The IL is sufficiently different for various architectures that any
tweak can cause the number of jump threads to vary.
For the pr7745-2.c testcase, we have less threading candida
Found when looking at Sandra's c535b-1.f90 and playing around.
When fixing same_type_as, I spotted by code reading another issue,
related to not catering for derived types. (Untested whether it
failed indeed.)
I added now a bunch of testcases.
OK for mainline?
Tobias
-
Siemens
On 9/28/21 6:05 PM, Richard Biener wrote:
On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abu
I really don't know what to do here. This is a bit of whack-o-mole.
The IL is sufficiently different for various architectures that any
tweak can cause the number of jump threads to vary.
For the pr7745-2.c testcase, we have less threading candidates because 2
of them now cross loop boundaries.
On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
>
>
>On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
>>
>>
>> On 9/28/21 3:47 PM, Jeff Law wrote:
>>>
>>>
>>> On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches
wrote:
>
>
>On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
>>
>>
>> On 9/28/21 3:47 PM, Jeff Law wrote:
>>>
>>>
>>> On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightm
On 9/28/21 1:20 AM, Richard Biener wrote:
On Mon, 27 Sep 2021, sunil.k.pandey wrote:
On Linux/x86_64,
d06dc8a2c73735e9496f434787ba4c93ceee5eea is the first bad commit
commit d06dc8a2c73735e9496f434787ba4c93ceee5eea
Author: Richard Biener
Date: Mon Sep 27 13:36:12 2021 +0200
middle-end
Hi all,
This patch adds support for -march=armv8.7-a in GCC.
It adds the +ls64 extension that's included in this architecture revision.
Currently this is just the command-line option and +ls64 allows the relevant
instructions
to be used in inline assembly. The ACLE defines some intrinsics for the
Ping…
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: [PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests.
Date: September 21, 2021 at 2:20:58 PM CDT
To: gcc-patches Nick Alcock via
mailto:gcc-patches@gcc.gnu.org>>
Reply
On Tue, Sep 28, 2021 at 09:49:11AM -0400, Patrick Palka via Gcc-patches wrote:
> > --- gcc/cp/method.c.jj 2021-09-15 08:55:37.563497558 +0200
> > +++ gcc/cp/method.c 2021-09-27 13:48:12.139271830 +0200
> > @@ -3160,8 +3160,11 @@ defaulted_late_check (tree fn)
> >if (kind == sfk_comparison)
On 9/25/21 15:15, nick huang wrote:
Why doesn't the PR92010 fix address these testcases as well?
3. PR92010 creates new functions of "rebuild_function_or_method_type" and by
using gdb to trace PR101402 code as following:
template struct A {
typedef T arr[3];
};
template void f(const typ
On 9/28/2021 7:53 AM, Aldy Hernandez wrote:
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightm
On 9/28/21 3:47 PM, Jeff Law wrote:
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightmare if you're not intimately
familiar with the
On Tue, 28 Sep 2021, Patrick Palka wrote:
> On Tue, 28 Sep 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > Hi!
> >
> > The testcases in the patch are either miscompiled or ICE with checking,
> > because the defaulted operator== is synthetized too early (but only if
> > constexpr), when the corr
On Tue, 28 Sep 2021, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The testcases in the patch are either miscompiled or ICE with checking,
> because the defaulted operator== is synthetized too early (but only if
> constexpr), when the corresponding class type is still incomplete type.
> The prob
On 9/28/2021 3:45 AM, Aldy Hernandez wrote:
In analyzing PR102511, it has become abundantly clear that we need
better debugging aids for the jump threader solver. Currently
debugging these issues is a nightmare if you're not intimately
familiar with the code. This patch attempts to improve t
On 28/09/2021 13:18, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Gcc-patches On Behalf Of Christophe
LYON via Gcc-patches
Sent: 08 September 2021 08:49
To: Richard Earnshaw ; gcc-
patc...@gcc.gnu.org
Subject: Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS regclass
On 28/09/2021 13:14, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 03/13] arm: Add test for PR target/101325
This test is derived from the one provided
On 28/09/2021 13:12, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 02/13] arm: Add tests for PR target/100757
These tests currently trigger an ICE whic
> On Sep 28, 2021, at 2:14 AM, Richard Biener via Gcc-patches
> wrote:
>
> On Tue, Sep 21, 2021 at 4:26 PM Richard Biener via Gcc-patches
> wrote:
>>
>> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
>> is not specified by the target and errors out if DWARF DWARF is n
Hi,
this patch implements the latest of my attempts to avoid some of the
unnecessary temporaries noce_convert_multiple currently emits. I named
it 8/7 because it actually applies on top of the last series that is not
yet approved while being a rather minor change.
The idea is to go over the
On Tue, Sep 28, 2021 at 03:00:56PM +0200, Tobias Burnus wrote:
> The depend type is a struct with two pointer members for C/C++ - but for
> Fortran OpenMP requires an integer type with kind = omp_depend_kind. Thus,
> libgomp's configure checks that an integer type/kind with size 2*sizeof(void*)
> i
Found this one lurking around in one of my trees.
It does not solve the actual issue of John that hppa64-hp-hpux11.11 does
not have an __int128 alias integer(kind=16) type. The latter is required for
OpenMP's omp_depend_kind as per implementation choice is has to be large
enough to store two poin
On Tue, 28 Sep 2021, Ilya Leoshkevich wrote:
> On Tue, 2021-09-28 at 13:28 +0200, Richard Biener wrote:
> > On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> >
> > > Add both positive and negative tests.
> >
> > The tests will likely be quite fragile with respect to what is
> > actually vectorized
Hi!
On 2021-09-27T14:07:53+0200, Tobias Burnus wrote:
> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
> Conclusion: Reviews are very helpful :-)
Ha! :-) (... and I wasn't even involed here!) ;-P
As testing showed here:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/a
Hi!
On 2021-09-27T14:38:56+0200, Tobias Burnus wrote:
> On 27.09.21 14:07, Tobias Burnus wrote:
>> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
>
> I accidentally changed dg-note to dg-message when updating the expected
> output, as the dump has changed. (Copying seemingly the
On Tue, Sep 28, 2021 at 1:34 PM Roger Sayle wrote:
>
>
> Hi Joseph,
> Firstly very many thanks for taking the time to respond, and especially for
> mentioning
> the discussion in PR 54192 (and Marc Glisse's -ffenv-access patches, but
> they are a
> little less relevant). Indeed the starting point
On Fri, Sep 24, 2021 at 8:29 AM Xionghu Luo wrote:
>
> Update the patch to v3, not sure whether you prefer the paste style
> and continue to link the previous thread as Segher dislikes this...
>
>
> [PATCH v3] Don't move cold code out of loop by checking bb count
>
>
> Changes:
> 1. Handle max_loo
On Wed, Sep 15, 2021 at 10:46 AM Martin Liška wrote:
>
> Hello.
>
> The patch extends the loop unswitching pass so that gswitch
> statements are supported. The pass now uses ranger which marks
> switch edges that are known to be unreachable in a versioned loop.
>
> Patch can bootstrap on x86_64-li
On Tue, 2021-09-28 at 13:28 +0200, Richard Biener wrote:
> On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
>
> > Add both positive and negative tests.
>
> The tests will likely be quite fragile with respect to what is
> actually vectorized on which target. If you move the tests
> to gcc.dg/vect/ yo
Hi Joseph,
Firstly very many thanks for taking the time to respond, and especially for
mentioning
the discussion in PR 54192 (and Marc Glisse's -ffenv-access patches, but
they are a
little less relevant). Indeed the starting point for this patch is Richard
Beiner's proposal
in comment #9 for tha
On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> Add both positive and negative tests.
The tests will likely be quite fragile with respect to what is
actually vectorized on which target. If you move the tests
to gcc.dg/vect/ you could at least do
/* { dg-require-effective-target vect_int } */
do
On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> PR tree-optimization/49749 introduced code that shortens dependency
> chains containing loop accumulators by placing them last on operand
> lists of associative operations.
>
> 456.hmmer benchmark on s390 could benefit from this, however, the code
>
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:17
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 06/13] arm: Fix mve_vmvnq_n_ argument
> mode
>
> The vmvnq_n* intrinsics a
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:17
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 05/13] arm: Add support for VPR_REG in
> arm_class_likely_spilled_p
>
> VP
On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
> Biasing loop-carried PHIs during the 1st reassociation pass interferes
> with reduction chains and does not bring measurable benefits, so do it
> only during the 2nd reassociation pass.
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * passe
Hi Christophe,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> LYON via Gcc-patches
> Sent: 08 September 2021 08:49
> To: Richard Earnshaw ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS
On Sun, 26 Sep 2021, liuhongt wrote:
> Hi:
> > Please don't add the -fno- option to the warning tests. As I said,
> > I would prefer to either suppress the vectorization for the failing
> > cases by tweaking the test code or xfail them. That way future
> > regressions won't be masked by the opti
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 03/13] arm: Add test for PR target/101325
>
> This test is derived from th
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 02/13] arm: Add tests for PR target/100757
>
> These tests currently trigg
Hi Christophe,
Sorry for the delay.
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: 07 September 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 01/13] arm: Add new tests for comparison
On Tue, Sep 28, 2021 at 11:42 AM Aldy Hernandez wrote:
>
>
>
> On 9/28/21 9:41 AM, Richard Biener wrote:
> > On Tue, Sep 28, 2021 at 8:29 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 9/28/2021 12:17 AM, Aldy Hernandez wrote:
> >>> On Tue, Sep 28, 2021 at 3:46 AM Jeff Law wrote:
This adds a testcase for the PR which was fixed with the fix for
PR100112.
Tested on x86_64-unknown-linux-gnu, pushed.
2021-09-28 Richard Biener
PR tree-optimization/99793
* gcc.dg/tree-ssa/pr99793.c: New testcase.
---
gcc/testsuite/gcc.dg/tree-ssa/pr99793.c | 14
On Tue, Sep 28, 2021 at 11:33 AM Jakub Jelinek wrote:
>
> Hi!
>
> i387 has instructions to store some transcedental numbers into the top of
> stack. The problem is that what exact bit in the last place one gets for
> those depends on the current rounding mode, the CPU knows the number with
> slig
1 - 100 of 123 matches
Mail list logo
