From: Thomas Rodgers
This patch supercedes both the Add C++2a synchronization support patch
being replied to *and* the patch adding wait/notify_* to atomic_flag.
Add support for -
* atomic_flag::wait/notify_one/notify_all
* atomic::wait/notify_one/notify_all
* counting_semaphore
* binary
Qing Zhao writes:
>> On Sep 11, 2020, at 4:44 PM, Richard Sandiford
>> wrote:
>>
>> Qing Zhao writes:
On Sep 11, 2020, at 12:32 PM, Richard Sandiford
>> If we go for (2), then I think it would be
better to do
it at the start of pass_late_compilation instead. (Some targ
> On Sep 11, 2020, at 4:51 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 11, 2020 at 04:29:16PM -0500, Qing Zhao wrote:
>>> On Sep 11, 2020, at 4:03 PM, Segher Boessenkool
>>> wrote:
The parameters that are passed to sys call will be destroyed, therefore,
the attack will likely
From: Sergei Trofimovich
Before the change 'man gcc' rendered "SOURCE_DATE_EPOCH" section as:
... the output of @command{date +%s} on GNU/Linux ...
After the change it renders as:
... the output of "date +%s" on GNU/Linux ...
gcc/ChangeLog:
* doc/cppenv.texi: Use @code{} instead
Hi Pat,
On Fri, Sep 11, 2020 at 05:04:29PM -0500, Pat Haugen wrote:
> The following is mostly a mechanical change to rename the mffgpr/mftgpr
> insn types to mtvsr/mfvsr to be more clear. It also removes Power6
> references to those insn types since we no longer generate those
> instructions.
>
> On Sep 11, 2020, at 4:44 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> On Sep 11, 2020, at 12:32 PM, Richard Sandiford
>>> >> If we go for (2), then I think it would be better to do
>>> it at the start of pass_late_compilation instead. (Some targets wouldn't
>>> cope with do
Here is the patch that I applied:
>From 1a2e0742e3e3c45f75d0ce31c45a7778c8d1f45e Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Fri, 11 Sep 2020 16:57:13 -0400
Subject: [PATCH] PowerPC: rename some functions.
gcc/
2020-09-11 Michael Meissner
* config/rs6000/rs6000.c (rs6000_ma
The following is mostly a mechanical change to rename the mffgpr/mftgpr
insn types to mtvsr/mfvsr to be more clear. It also removes Power6
references to those insn types since we no longer generate those
instructions.
Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?
-Pat
From: Sergei Trofimovich
gcc/ChangeLog:
* doc/invoke.texi: fix '-fprofile-reproducibility' option
spelling in maunal.
---
gcc/doc/invoke.texi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bca8c856dc8.
From: Sergei Trofimovich
Before the change option handling did not accept an argument:
xgcc: error: unknown profile reproducibility method '=serial'
xgcc: note: valid arguments to '-fprofile-reproducible' are: multithreaded
parallel-runs serial; did you mean 'serial'?
The change also includ
On Fri, Sep 11, 2020 at 04:29:16PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 4:03 PM, Segher Boessenkool
> > wrote:
> >> The parameters that are passed to sys call will be destroyed, therefore,
> >> the attack will likely failed.
> >
> > But you do not need more than one non-zero argument
Qing Zhao writes:
>> On Sep 11, 2020, at 12:32 PM, Richard Sandiford
>> >> If we go for (2), then I think it would be better to do
>> it at the start of pass_late_compilation instead. (Some targets wouldn't
>> cope with doing it later.) The reason for doing it so late is that the
>> set of us
> On Sep 11, 2020, at 4:03 PM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Fri, Sep 11, 2020 at 03:14:57PM -0500, Qing Zhao wrote:
>> My understanding of how this scheme helps ROP is: the attacker usually uses
>> scratch register to pass
>
> Help obstruct ROP ;-)
Thanks for catching my mis
I noticed a compiler warning about out-of-bound access. Fixed thusly.
gcc/
* config/i386/sse.md (mov): Fix operand indices.
pushed as obvious
--
Nathan Sidwell
diff --git i/gcc/config/i386/sse.md w/gcc/config/i386/sse.md
index a728b979f01..a784346a23b 100644
--- i/gcc/config/i38
libstdc++-v3/ChangeLog:
* include/std/memory: Move #include inside C++11
conditional includes.
Tested x86_64-pc-linux-gnu, committed to master.
---
libstdc++-v3/include/std/memory | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/memor
> On Sep 11, 2020, at 3:36 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 11, 2020 at 03:17:19PM -0500, Qing Zhao wrote:
>>> On Sep 11, 2020, at 3:05 PM, Segher Boessenkool
>>> wrote:
>>> On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote:
> On Sep 11, 2020, at 12:13 PM, Segher
Hi!
On Fri, Sep 11, 2020 at 03:14:57PM -0500, Qing Zhao wrote:
> My understanding of how this scheme helps ROP is: the attacker usually uses
> scratch register to pass
Help obstruct ROP ;-)
> parameters to the sys call in the gadget, if clearing the scratch registers
> immediately before “ret
I discovered that we'd accept constraints on block-scope function
decls inside templates. This fixes that.
gcc/cp/
* decl.c (grokfndecl): Don't attach to local extern.
gcc/testsuite/
* concepts/local-extern.C: New.
pushed to trunk
nathan
--
Nathan Sidwell
diff
On Fri, Sep 11, 2020 at 03:17:19PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 3:05 PM, Segher Boessenkool
> > wrote:
> > On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote:
> >>> On Sep 11, 2020, at 12:13 PM, Segher Boessenkool
> >>> wrote:
> >>> On Fri, Sep 11, 2020 at 11:52:29AM -
Hi,
gcc-9 branch is missing NEON intrinsics for loads and stores.
Attached patches pass bootstrap and regression testing on Graviton2
aarch64-linux.
Ok to commit to gcc-9 branch?
Thanks,
Sebastian
0001-add-intrinsics-for-vld1-q-_x4-and-vst1-q-_x4.patch
Description: 0001-add-intrinsics-for-vl
> On Sep 11, 2020, at 3:05 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote:
>>> On Sep 11, 2020, at 12:13 PM, Segher Boessenkool
>>> wrote:
>>> On Fri, Sep 11, 2020 at 11:52:29AM -0500, Qing Zhao wrote:
I don’t understand why it’s not corre
Hi!
On Fri, Sep 11, 2020 at 02:55:03PM -0500, will schmidt wrote:
> > > --- a/gcc/testsuite/gcc.target/powerpc/pr96139-c.c
> > > +++ b/gcc/testsuite/gcc.target/powerpc/pr96139-c.c
> > > @@ -1,7 +1,7 @@
> > > /* { dg-do run } */
> > > -/* { dg-options "-O2 -Wall" } */
> > > +/* { dg-options "-O2 -
> On Sep 11, 2020, at 12:32 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> On Sep 11, 2020, at 11:14 AM, Segher Boessenkool
>>> wrote:
>>>
>>> On Fri, Sep 11, 2020 at 11:06:03AM +0100, Richard Sandiford wrote:
This might have already been discussed/answered, sorry, but:
>>>
On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 12:13 PM, Segher Boessenkool
> > wrote:
> > On Fri, Sep 11, 2020 at 11:52:29AM -0500, Qing Zhao wrote:
> >> I don’t understand why it’s not correct if we clearing call-clobbered
> >> registers
> >> AFTER restorin
On Fri, Sep 11, 2020 at 06:32:56PM +0100, Richard Sandiford wrote:
> Unlike Segher, I think this can/should be done in target-independent
> code as far as possible (like the patch seemed to do).
My problem with that is that it is both incorrect *and* inefficient. It
writes registers it should not
On Fri, 2020-09-11 at 12:37 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Sep 11, 2020 at 09:44:54AM -0500, will schmidt wrote:
> > As reported, the recently added pr96139 tests will fail on older
> > targets
> > because the tests are missing the appropriate -mvsx or -maltivec
>
Hi,
gcc-8 branch is missing NEON intrinsics for loads and stores.
Attached patches pass bootstrap and regression testing on Graviton2
aarch64-linux.
Ok to commit to gcc-8 branch?
Thanks,
Sebastian
0001-Patch-implementing-vld1_-_x3-vst1_-_x2-and-vst1_-_x3.patch
Description: 0001-Patch-implemen
> On Sep 11, 2020, at 12:18 PM, Segher Boessenkool
> wrote:
>
> On Thu, Sep 10, 2020 at 05:50:40PM -0500, Qing Zhao wrote:
>> Shrink-wrapped stuff. Quite important for performance. Not something
>> you can throw away.
>
> ^^^ !!! ^^^
>
>>> Start looking at handle_simple_exit()? t
> On Sep 11, 2020, at 12:13 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 11, 2020 at 11:52:29AM -0500, Qing Zhao wrote:
>> I don’t understand why it’s not correct if we clearing call-clobbered
>> registers
>> AFTER restoring call-preserved registers?
>
> Because the compiler backend (or
On Fri, 11 Sep 2020 at 14:35, Kyrylo Tkachov wrote:
>
> Hi Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 11 September 2020 13:23
> > To: gcc-patches@gcc.gnu.org; i...@airs.com
> > Subject: [PATCH] libgcc/config/arm/fp
On 11/09/20 18:22 +0100, Jonathan Wakely wrote:
On 11/09/20 15:41 +0100, Jonathan Wakely wrote:
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
Convert the specified duration to the target clock's duration type
before adding it to the current time in
__atomic_futex_unsigned::_M_load_wh
This is a first attempt to improve the OpenMP mapping for allocatables
and pointers; there are some more issues – cf. PR and for scalars
PR 97021.
In real world code, a usage like the following is not uncommon:
real, allocatable :: A(:,:)
!$omp target enter data map(to: A)
This maps an unalloca
Hi,
The attached patches bring the description of Ares and Neoverse-N1
to the gcc-7-arm vendor branch.
There were 2 changes to adjust the first patch to the older code in gcc-7.
Instead of:
+ "32:16", /* function_align. */
+ "32:16", /* jump_align. */
+ "32:16", /* loop_align. *
Hi!
On Fri, Sep 11, 2020 at 09:44:54AM -0500, will schmidt wrote:
> As reported, the recently added pr96139 tests will fail on older targets
> because the tests are missing the appropriate -mvsx or -maltivec
> options.
> This adds the options and clarifies the dg-require stateme
Hi Martin,
>
> can you please confirm that the difference between these two is all due to
> the last option -fno-inline-functions-called-once ? Is LTo necessary? I.e.,
> can
> you run the benchmark also built with the branch compiler and -mcpu=native
> -Ofast -fomit-frame-pointer -fno-inline-f
Qing Zhao writes:
>> On Sep 11, 2020, at 11:14 AM, Segher Boessenkool
>> wrote:
>>
>> On Fri, Sep 11, 2020 at 11:06:03AM +0100, Richard Sandiford wrote:
>>> This might have already been discussed/answered, sorry, but:
>>> when there's a choice, is there an obvious winner between:
>>>
>>> (1) c
On 11/09/20 15:41 +0100, Jonathan Wakely wrote:
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
Convert the specified duration to the target clock's duration type
before adding it to the current time in
__atomic_futex_unsigned::_M_load_when_equal_for and
_M_load_when_equal_until. This
On Thu, Sep 10, 2020 at 05:50:40PM -0500, Qing Zhao wrote:
> Shrink-wrapped stuff. Quite important for performance. Not something
> you can throw away.
^^^ !!! ^^^
> > Start looking at handle_simple_exit()? targetm.gen_simple_return()…
>
> Yes, I have been looking at this since this
On Fri, Sep 11, 2020 at 11:52:29AM -0500, Qing Zhao wrote:
> I don’t understand why it’s not correct if we clearing call-clobbered
> registers
> AFTER restoring call-preserved registers?
Because the compiler backend (or the linker! Or the dynamic linker!
Etc.) can use volatile registers for the
Hi
Thanks for your review, and sorry for the late reply. It took a while
to finish the runtime test.
> > diff --git a/gcc/config.gcc b/gcc/config.gcc
> > index 797f0ad5edd..d0e59e86a5c 100644
> > --- a/gcc/config.gcc
> > +++ b/gcc/config.gcc
> > @@ -412,7 +412,7 @@ i[34567]86-*-*)
> >
> On Sep 11, 2020, at 11:14 AM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 11, 2020 at 11:06:03AM +0100, Richard Sandiford wrote:
>> This might have already been discussed/answered, sorry, but:
>> when there's a choice, is there an obvious winner between:
>>
>> (1) clearing call-clobbered r
On Fri, Sep 11, 2020 at 9:22 AM Sunil K Pandey wrote:
>
> These tests are written for 256 bit vector. For -march=cascadelake,
> vector size changed to 512 bit. It doubles the number of fma
> instruction and test fail. Fix is to explicitly disable 512 bit
> vector by passing additional option -mno-
These tests are written for 256 bit vector. For -march=cascadelake,
vector size changed to 512 bit. It doubles the number of fma
instruction and test fail. Fix is to explicitly disable 512 bit
vector by passing additional option -mno-avx512f.
Tested on x86-64.
gcc/testsuite/ChangeLog:
PR
Sorry, I made a mistake. Please ignore it.
On Fri, Sep 11, 2020 at 9:06 AM Sunil K Pandey via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> From: Arnaud Charlet
>
> * fe.h, opt.ads (Enable_128bit_Types): New.
> * stand.ads (Standard_Long_Long_Long_Integer,
> S_Long_Long
On Fri, Sep 11, 2020 at 11:06:03AM +0100, Richard Sandiford wrote:
> This might have already been discussed/answered, sorry, but:
> when there's a choice, is there an obvious winner between:
>
> (1) clearing call-clobbered registers and then restoring call-preserved ones
> (2) restoring call-prese
From: Arnaud Charlet
* fe.h, opt.ads (Enable_128bit_Types): New.
* stand.ads (Standard_Long_Long_Long_Integer,
S_Long_Long_Long_Integer): New.
---
gcc/ada/fe.h | 1 +
gcc/ada/opt.ads | 7 +++
gcc/ada/stand.ads | 4
3 files changed, 12 insertions(+)
diff -
On 11/09/2020 13:02, Tobias Burnus wrote:
OG10 = devel/omp/gcc-10
I have merged releases/gcc-10 into that branch.
And added a bunch of mainline alias GCC 11 nvptx patches
to that branch.
2df8e0f1bc4 [libatomic] Add nvptx support
5544bca37bc [nvptx] Fix UB in nvptx_assemble_value
7e10b6b0b34 [nv
Hi!
On Fri, Sep 11, 2020 at 03:26:17PM +0800, Jojo R wrote:
> +#define printf_include() do { \
Don't use macros please, use a function?
And maybe do this in a separate patch, for ease of review. That should
be ack'ed pretty much immediately, after which it is out of the way, and
we do not have
Syntax errors in method definition lists could leave us in a function
scope. My recent change for block scope externs didn't like that.
This reimplements the parsing loop to finish the method definition we
started. AFAICT the original code was attempting to provide some
error recovery. Also wh
On 9/11/20 5:03 PM, tdevries wrote:
On 2020-09-11 16:48, Andrew Stubbs wrote:
On 11/09/2020 15:25, Tom de Vries wrote:
--- a/libgomp/testsuite/libgomp.c-c++-common/reduction-16.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/reduction-16.c
@@ -1,4 +1,5 @@
/*·{·dg-do·run·}·*/
+/*·{·dg-addition
On Fri, Sep 11, 2020 at 10:57:21AM -0400, Nathan Sidwell wrote:
> On 9/10/20 10:15 PM, Marek Polacek via Gcc-patches wrote:
> > Since we now have DECL_DECLARED_CONSTINIT_P, we no longer need
> > LOOKUP_CONSTINIT.
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> looks good,
On 2020-09-11 16:48, Andrew Stubbs wrote:
On 11/09/2020 15:25, Tom de Vries wrote:
--- a/libgomp/testsuite/libgomp.c-c++-common/reduction-16.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/reduction-16.c
@@ -1,4 +1,5 @@
/*·{·dg-do·run·}·*/
+/*·{·dg-additional-options·"-foffload=-latomic"·}·*/
On 9/10/20 10:15 PM, Marek Polacek via Gcc-patches wrote:
Since we now have DECL_DECLARED_CONSTINIT_P, we no longer need
LOOKUP_CONSTINIT.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
looks good, thanks for noticing. BTW, you now have
> /* Set constexpr flag on vars (fun
On 11/09/2020 15:25, Tom de Vries wrote:
--- a/libgomp/testsuite/libgomp.c-c++-common/reduction-16.c
+++ b/libgomp/testsuite/libgomp.c-c++-common/reduction-16.c
@@ -1,4 +1,5 @@
/*·{·dg-do·run·}·*/
+/*·{·dg-additional-options·"-foffload=-latomic"·}·*/
This will probably break amdgcn, where lib
Hi,
As reported, the recently added pr96139 tests will fail on older targets
because the tests are missing the appropriate -mvsx or -maltivec options.
This adds the options and clarifies the dg-require statements.
sniff-regtested OK when specifying older targets o
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
Convert the specified duration to the target clock's duration type
before adding it to the current time in
__atomic_futex_unsigned::_M_load_when_equal_for and
_M_load_when_equal_until. This removes the risk of the timeout being
rounded dow
On Fri, Sep 11, 2020 at 04:24:42PM +0200, Tom de Vries wrote:
> I've got an updated version of this patch. It:
> - no longer supplies the __atomic_load_16, since that's now handled by
> libatomic
> - the __sync_val_compare_and_swap now uses __atomic_compare_and_swap,
> which also falls back on
[ Fixing ENOPATCH. ]
On 9/11/20 4:24 PM, Tom de Vries wrote:
> On 9/2/20 1:48 PM, Tom de Vries wrote:
>> On 9/2/20 12:44 PM, Jakub Jelinek wrote:
>>> On Wed, Sep 02, 2020 at 12:22:28PM +0200, Tom de Vries wrote:
And test-case passes on x86_64 with this patch (obviously, in
combination wi
On 9/2/20 1:48 PM, Tom de Vries wrote:
> On 9/2/20 12:44 PM, Jakub Jelinek wrote:
>> On Wed, Sep 02, 2020 at 12:22:28PM +0200, Tom de Vries wrote:
>>> And test-case passes on x86_64 with this patch (obviously, in
>>> combination with trigger patch above).
>>>
>>> Jakub, WDYT?
>>
>> I guess the norm
On Fri, Sep 11, 2020 at 08:07:39AM +0200, Richard Biener wrote:
> On Thu, Sep 10, 2020 at 5:12 PM Segher Boessenkool
> wrote:
> > On Thu, Sep 10, 2020 at 04:33:30PM +0200, Richard Biener wrote:
> > > On Thu, Sep 10, 2020 at 4:22 PM Aaron Sawdey
> > > wrote:
> > > > If it feels like a hack, that
This is now committed and backported to GCC 10.
Andrew
On 10/09/2020 15:03, Andrew Stubbs wrote:
This patch prevents an ICE (segmentation fault) the occurs for amdgcn
because the test is trying to use -fexceptions which is unsupported on
the target.
Arguably it should fail more gracefully, b
This is now backported to GCC 10.
Andrew
On 11/09/2020 11:17, Andrew Stubbs wrote:
This patch fixes an execution failure in which the compiler would
corrupt TImode values due to missed early clobber problems with
partially overlapping register allocations. In fact, adding early
clobber const
On 11/09/20 14:37 +0100, Jonathan Wakely wrote:
On 11/09/20 13:55 +0100, Jonathan Wakely wrote:
On 11/09/20 12:23 +, Christophe Lyon via Libstdc++ wrote:
When building with -fno-exceptions, __GLIBCXX_THROW_OR_ABORT expands to
abort(), causing warnings:
unused parameter '__ecode'
unused para
On 11/09/20 13:55 +0100, Jonathan Wakely wrote:
On 11/09/20 12:23 +, Christophe Lyon via Libstdc++ wrote:
When building with -fno-exceptions, __GLIBCXX_THROW_OR_ABORT expands to
abort(), causing warnings:
unused parameter '__ecode'
unused parameter '__what'
This patch adds __attribute__((un
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
This series ensures that the std::future::wait_* functions use
std::chrono::steady_clock when required, introduces
std::chrono::__detail::ceil to make that easier to do, and then makes
use of that function to simplify and improve the fix fo
On 9/11/20 5:35 AM, Alexandre Oliva wrote:
I guess this means we withdraw the patch. Thanks again!
The original motivation for this was a failing fsf-testsuite-gcc test on
vxworks7. If the patch is wrong, then I suppose the alternative is to
modify the test, or else kill it?
On 11/09/20 12:23 +, Christophe Lyon via Libstdc++ wrote:
When building with -fno-exceptions, bad_exception_allowed is set but
not used, causing a warning during the build.
This patch adds __attribute__((unused)) to avoid it.
OK, thanks.
2020-09-11 Torbjörn SVENSSON
Christoph
On 11/09/20 12:23 +, Christophe Lyon via Libstdc++ wrote:
When building with -fno-exceptions, __throw_exception_again expands to
nothing, causing a "suggest braces around empty body in an 'if'
statement" warning.
This patch adds braces, like what was done in eh_personality.cc in svn
r193295
On 11/09/20 12:23 +, Christophe Lyon via Libstdc++ wrote:
When building with -fno-exceptions, __GLIBCXX_THROW_OR_ABORT expands to
abort(), causing warnings:
unused parameter '__ecode'
unused parameter '__what'
This patch adds __attribute__((unused)) to avoid them.
OK, thanks.
2020-09-11
Hi,
On Fri, Sep 11 2020, Tamar Christina wrote:
> Hi Martin,
>
>> On Fri, Aug 21 2020, Tamar Christina wrote:
>> >>
>> >> Honza's changes have been motivated to big extent as an enabler for
>> >> IPA-CP heuristics changes to actually speed up 548.exchange2_r.
>> >>
>> >> On my AMD Zen2 machine, th
The previous re-org made the cost of SLP vector stmts in loop
vectorization ignored. The following rectifies this mistake.
Bootstrapped & tested on x86_64-unknown-linux-gnu, pushed.
2020-09-11 Richard Biener
PR tree-optimization/97020
* tree-vect-slp.c (vect_slp_analyze_opera
On Sep 11, 2020, Alan Modra wrote:
> I also thought it reasonable to error on an explicit -mcmodel=medium
> or -mcmodel=large with either of -mminimal-toc or -mno-minimal-toc,
> since the toc options really are specific to small model code. Why
> change that?
Thanks. I think the key piece of i
Hi Christophe,
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 11 September 2020 13:23
> To: gcc-patches@gcc.gnu.org; i...@airs.com
> Subject: [PATCH] libgcc/config/arm/fp16.c: Add missing prototypes
>
> This patch adds the missing prototyp
When building with -fno-exceptions, bad_exception_allowed is set but
not used, causing a warning during the build.
This patch adds __attribute__((unused)) to avoid it.
2020-09-11 Torbjörn SVENSSON
Christophe Lyon
libstdc++-v3/
* libsupc++/eh_call.cc: Avoid warning wi
When building with -fno-exceptions, __throw_exception_again expands to
nothing, causing a "suggest braces around empty body in an 'if'
statement" warning.
This patch adds braces, like what was done in eh_personality.cc in svn
r193295 (git g:54ba39f599fc2f3d59fd3cd828a301ce9b731a20)
2020-09-11 To
This patch adds the missing prototypes for the fonctions defined in fp16.c, to
avoid these warnings during the build:
/libgcc/config/arm/fp16.c:169:1: warning: no previous prototype for
'__gnu_h2f_internal' [-Wmissing-prototypes]
/libgcc/config/arm/fp16.c:194:1: warning: no previous prototype for
When building with -fno-exceptions, __GLIBCXX_THROW_OR_ABORT expands to
abort(), causing warnings:
unused parameter '__ecode'
unused parameter '__what'
This patch adds __attribute__((unused)) to avoid them.
2020-09-11 Torbjörn SVENSSON
Christophe Lyon
libstdc++-v3/
*
pz_tmp_base and pz_tmp_dot are always set, but used only when
_PC_NAME_MAX is defined.
This patch moves their declaration and definition undef #ifdef
_PC_NAME_MAX to avoid this warning.
2020-09-11 Torbjörn SVENSSON
Christophe Lyon
fixincludes/
* fixfixes.c (pz_tmp_ba
OG10 = devel/omp/gcc-10
I have merged releases/gcc-10 into that branch.
And added a bunch of mainline alias GCC 11 nvptx patches
to that branch.
2df8e0f1bc4 [libatomic] Add nvptx support
5544bca37bc [nvptx] Fix UB in nvptx_assemble_value
7e10b6b0b34 [nvptx] Fix printing of 128-bit constant (nega
> From: Eric Botcazou
> Date: Fri, 11 Sep 2020 13:09:48 +0200
> > @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> > condition, lose = 1;
> >mark_set_resources (trial, &set, 0, MARK_SRC_DEST_CALL);
> >mark_referenced_resources (trial, &needed, true);
> > +
> From: Hans-Peter Nilsson
> Date: Fri, 11 Sep 2020 13:24:18 +0200
> > > @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> > > condition, lose = 1;
> > >mark_set_resources (trial, &set, 0, MARK_SRC_DEST_CALL);
> > >mark_referenced_resources (trial, &needed,
On Fri, 2020-09-11 at 12:31 +0200, Andrea Corallo wrote:
> Hi Dave,
>
> thanks for the review!
>
> David Malcolm writes:
>
> [...]
>
> > Was there a reason for using reinterpret_cast here, rather than
> > static_cast?
>
> Yes the reason is that apparently we can't use static_cast for that:
>
> From: Eric Botcazou
> CC: "gcc-patches@gcc.gnu.org"
> Date: Fri, 11 Sep 2020 13:09:48 +0200
> received-spf: None (smtp1.axis.com: no sender authenticity information
> available from domain of postmas...@mail-wr1-f54.google.com) identity=helo;
> client-ip=209.85.221.54; receiver=smtp1.axis.
> @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> condition, lose = 1;
>mark_set_resources (trial, &set, 0, MARK_SRC_DEST_CALL);
>mark_referenced_resources (trial, &needed, true);
> + if (filter_flags)
> + {
> + mark_set_resources (trial, &fs
On Fri, 11 Sep 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > This tries to improve BB vectorization dumps by providing more
> > precise locations. Currently the vect_location is simply the
> > very last stmt in a basic-block that has a location. So for
> >
> > double a[4], b[4];
>
Hi Martin,
> -Original Message-
> From: Martin Jambor
> Sent: Tuesday, September 8, 2020 3:01 PM
> To: Tamar Christina ; Richard Sandiford
> ; luoxhu via Gcc-patches patc...@gcc.gnu.org>
> Cc: seg...@kernel.crashing.org; luoxhu ;
> wschm...@linux.ibm.com; li...@gcc.gnu.org; Jan Hubicka
>
Richard Biener writes:
> This tries to improve BB vectorization dumps by providing more
> precise locations. Currently the vect_location is simply the
> very last stmt in a basic-block that has a location. So for
>
> double a[4], b[4];
> int x[4], y[4];
> void foo()
> {
> a[0] = b[0]; // line
Hi Dave,
thanks for the review!
David Malcolm writes:
[...]
> Was there a reason for using reinterpret_cast here, rather than
> static_cast?
Yes the reason is that apparently we can't use static_cast for that:
"error: invalid ‘static_cast’ from type ‘gcc_jit_lvalue*’ to type
‘gcc::jit::reco
This patch fixes an execution failure in which the compiler would
corrupt TImode values due to missed early clobber problems with
partially overlapping register allocations. In fact, adding early
clobber constraints does not fix the issue because IRA doesn't check
that for move instructions pr
On 9/8/20 8:51 AM, Tom de Vries wrote:
> Hi,
>
> Add nvptx support to libatomic.
>
> Given that atomic_test_and_set is not implemented for nvptx (PR96964), the
> compiler translates __atomic_test_and_set falling back onto the "Failing all
> else, assume a single threaded environment and simply pe
Kees Cook via Gcc-patches writes:
> [tried to clean up quoting...]
>
> On Tue, Sep 08, 2020 at 10:00:09AM -0500, Qing Zhao wrote:
>>
>> > On Sep 7, 2020, at 8:06 AM, Rodriguez Bahena, Victor
>> > wrote:
>> >
>> >>> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
>> >>> So, my questi
I'm finally getting round to merging this series!
On 29/05/20 07:17 +0100, Mike Crowe via Libstdc++ wrote:
If std::future::wait_until is passed a time point measured against a clock
that is neither std::chrono::steady_clock nor std::chrono::system_clock
then the generic implementation of
__atom
On Fri, Sep 11, 2020 at 09:46:37AM +0200, Christophe Lyon via Gcc-patches wrote:
> I'm seeing an ICE with this new test on most of my arm configurations,
> for instance:
> --target arm-none-linux-gnueabi --with-cpu cortex-a9
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/gcc/x
This is a regression present on the mainline and 10 branch: the compiler
aborts on code accessing a component of a packed record type whose type is a
packed discriminated record type with variant part.
Tested on x86_64-suse-linux, applied on the mainline and 10 branch.
2020-09-11 Eric Botcazo
This is a regression present on mainline, 10 and 9 branches: the compiler goes
into an infinite recursion eventually exhausting the stack for the declaration
of a discriminated record type with an array component having a discriminant
as bound and an index type that is an enumeration type with a
This adds a missing stride entry for bit-packed arrays of record types.
Tested on x86_64-suse-linux, applied on the mainline.
2020-09-11 Eric Botcazou
* gcc-interface/misc.c (get_array_bit_stride): Return TYPE_ADA_SIZE
for record and union types.
--
Eric Botcazoudiff --git
GDB can now deal with the DWARF representation just fine.
Tested on x86_64-suse-linux, applied on the mainline.
2020-09-11 Eric Botcazou
* gcc-interface/misc.c (gnat_get_fixed_point_type): Bail out only
when the GNAT encodings are specifically used.
--
Eric Botcazoudiff --g
This tries to improve BB vectorization dumps by providing more
precise locations. Currently the vect_location is simply the
very last stmt in a basic-block that has a location. So for
double a[4], b[4];
int x[4], y[4];
void foo()
{
a[0] = b[0]; // line 5
a[1] = b[1];
a[2] = b[2];
a[3] =
On Fri, Sep 11, 2020 at 04:43:50AM -0300, Alexandre Oliva wrote:
> Could you please shed any light as to the intent, so that we can sort
> out the logic that will implement it?
The history goes back to 2003 commit 9739c90c8d where a ppc64-linux
host built most of gcc with -mminimal-toc due to toc/
For review.
Fixes the two ICEs reported in PR that remained after the previous fix.
There is a side affect that is manifested in the tree dumps. Instead of
__builtin_free (ptr2->dat.data);
we get
__builtin_free ((void *) ptr2->dat.data);
I do not know the cause of this but from what I can te
1 - 100 of 109 matches
Mail list logo
