https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028
--- Comment #1 from Nikita ---
Here is the link demonstrating the issue on https://godbolt.org/z/bc6669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97028
Bug ID: 97028
Summary: Compilation errors for AVX512 intrinsic with
-masm=intel
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
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
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #4 from Jonathan Wakely ---
The change to max_align_t was done in r240248 in 2016, glibc's malloc was
changed some time after.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #3 from Jonathan Wakely ---
operator new just gets its memory from malloc.
GCC changed the alignment of max_align_t on x86 targets, but if you don't have
a newer malloc then it won't know about that change and so disagrees with
> 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
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{}
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.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #2 from Mikhail Kremniov ---
(In reply to Andrew Pinski from comment #1)
> malloc is not controlled by gcc.
Yeah, I shouldn't have mentioned malloc because there seems to be no
requirement for it to align the returned addresses by
Snapshot gcc-9-20200911 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200911/
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
> 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
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
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
On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist
wrote:
> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote:
> >
> > Hi
> >
> > Over at RTEMS, we ran into a case where the C++ atomics may not be right
> > for one of the lower level x86 models. We will investigate whether it can
> > be made
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
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
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
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
On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote:
>
> Hi
>
> Over at RTEMS, we ran into a case where the C++ atomics may not be right
> for one of the lower level x86 models. We will investigate whether it can
> be made right but this has led to the discussion of dropping older models
> and
> 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
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
---
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
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027
Bug ID: 97027
Summary: missing warning on buffer overflow storing a larger
scalar into a smaller array
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97026
Bug ID: 97026
Summary: -flto and DW_AT_GNU_macros
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
--- Comment #1 from Andrew Pinski ---
malloc is not controlled by gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
> 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025
Bug ID: 97025
Summary: In -m32 mode the alignment of pointers returned by
malloc or operator new is less than
alignof(std::max_align_t)
Product: gcc
Version:
> 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
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
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:
> 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()?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #18)
> > Why aren't KFmode, IFmode and TFmode all 128??? Mike?
>
> This comes from rs6000-modes.h:
>
> /* We order the 3 128-bit floating point types so that
> 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
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]
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from anlauf at gcc dot gnu.org ---
> > This may lead to a total mess, and I am unable to test it, but can you try:
On Fri, Sep 11, 2020 at 1:40 PM Florian Weimer wrote:
> * Joel Sherrill:
>
> > I don't know that we have a huge issue in making the i486 a minimum.
> > I was proposing a Pentium II or P6 as a baseline since that moves you
> > up to having a TBR and initial SMP support.
>
> Sorry, what's a TBR?
>
* Joel Sherrill:
> I don't know that we have a huge issue in making the i486 a minimum.
> I was proposing a Pentium II or P6 as a baseline since that moves you
> up to having a TBR and initial SMP support.
Sorry, what's a TBR?
> But I think there are still embedded x86 clones that I am not sure
On Fri, Sep 11, 2020 at 1:07 PM Florian Weimer wrote:
> * Joel Sherrill:
>
> > With that in mind, what's the lowest/oldest i386 CPU model we
> > should consider as the new base model?
>
> The 80486 has a CMPXCHG instruction (4-byte CAS). Starting from CAS,
> you can build the rest. There might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P4 |P3
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024
--- Comment #2 from John Haiducek ---
For the sake of convenience (so there are links to click) the above-mentioned
bugs were bug 92587 and bug 82996.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97018
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Summary|[10/11
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024
--- Comment #1 from John Haiducek ---
This bug shows some similarity to 92587 and 82996, but I suspect they are
distinct. 92587 had a much more complicated MWE and the OP was unable to reduce
it to a single file. 82996 did not involve class
* Joel Sherrill:
> With that in mind, what's the lowest/oldest i386 CPU model we
> should consider as the new base model?
The 80486 has a CMPXCHG instruction (4-byte CAS). Starting from CAS,
you can build the rest. There might be some caveats about the memory
model implementation (it may not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97024
Bug ID: 97024
Summary: Overriding finalization on polymorphic types triggers
ICE error in generate_finalization_wrapper
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97023
Bug ID: 97023
Summary: missing warning on buffer overflow in chained mempcpy
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97023
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
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)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97018
H.J. Lu changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97022
Bug ID: 97022
Summary: -Werror flag aborts compilation of "current" git pull
on main
Product: gcc
Version: new-ra
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97018
--- Comment #5 from Sunil Pandey ---
(In reply to Richard Biener from comment #1)
> Do they PASS on the GCC 10 branch?
GCC 10 branch has same issue. Same patch should be applied to GCC 10 too.
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-*-*)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97018
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97018
--- Comment #3 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:40e99ed5f4e59c6d0a8e81cd6544c9b4e7ec2fe7
commit r11-3163-g40e99ed5f4e59c6d0a8e81cd6544c9b4e7ec2fe7
Author: Sunil K Pandey
Date: Thu
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97021
Bug ID: 97021
Summary: [OpenMP] copy out of allocatable scalars does not
work.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97019
--- Comment #1 from Segher Boessenkool ---
Cool, if that helps, great!
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,
>
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
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
Hi
Over at RTEMS, we ran into a case where the C++ atomics may not be right
for one of the lower level x86 models. We will investigate whether it can
be made right but this has led to the discussion of dropping older models
and setting a new minimum model. Right now, our base is a i386 w/FPU. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 96903, which changed state.
Bug 96903 Summary: [11 regression] excess errors from gcc.dg/pr89350.c after
r11-2973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:f36a8168f04dfbde9d4c64421c1058975b28ff9a
commit r11-3162-gf36a8168f04dfbde9d4c64421c1058975b28ff9a
Author: Martin Sebor
Date: Fri
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97015
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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·}·*/
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
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
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
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
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
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
On Fri, 2020-09-11 at 12:14 +0100, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > On Fri, 2020-09-11 at 12:17 +0200, Ilya Leoshkevich wrote:
> > > On Fri, 2020-09-11 at 10:46 +0100, Richard Sandiford wrote:
> > > > Ilya Leoshkevich via Gcc writes:
> > > > > On Wed, 2020-09-09 at 16:09
[ 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97020
--- Comment #6 from Tamar Christina ---
I do think these are related to the bug I mentioned, I did isolate a small test
function but I'll wait till trunk builds again to be able to test this patch :)
otherwise the nightly CI will pick it up.
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
1 - 100 of 229 matches
Mail list logo
