https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #43 from John David Anglin ---
The fix for PR 94694 fixed the build on hppa2.0w-hp-hpux11.11.
We are left with the following new fails in dec_math.f90:
FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors)
FAIL:
On Thu, 23 Apr 2020 at 10:03, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Srinath Parvathaneni
> > Sent: 22 April 2020 14:00
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov
> > Subject: [GCC][PATCH][ARM]: Modify the MVE polymorphic variant
> > arguments to match
On 24/04/20 12:17 +0100, Jonathan Wakely wrote:
On 24/04/20 12:57 +0200, Gerald Pfeifer wrote:
On Thu, 23 Apr 2020, Jonathan Wakely wrote:
This no longer works, so direct people to the mailman listinfo pages
instead.
OK to commit to wwwdocs?
Yes, thank you!
I was wondering whether we could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #42 from Jakub Jelinek ---
I think this one is not fixed yet, there is some pa hpux specific patch. See
e.g. #c39.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #41 from Richard Biener ---
If this is now fixed can you close the bug as such please, John?
On 24/04/20 12:57 +0200, Gerald Pfeifer wrote:
On Thu, 23 Apr 2020, Jonathan Wakely wrote:
This no longer works, so direct people to the mailman listinfo pages
instead.
OK to commit to wwwdocs?
Yes, thank you!
I was wondering whether we could keep something similar to this nice
form, but
On Fri, Apr 24, 2020 at 08:15:36AM +0200, Richard Biener wrote:
> On Thu, Apr 23, 2020 at 4:54 PM Eric Botcazou wrote:
> > > > > What is wrong with DF?
> > > >
> > > > It's slow and memory hungry?
> > >
> > > Very true, of course. But can this be significantly better?
> >
> > That's a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742
Jakub Jelinek changed:
What|Removed |Added
Summary|Incorrect "no return|[8/9/10 Regression]
I've had a couple of conversations now in which the shortness
of arm_sve.h was causing confusion, with people thinking that
the types and intrinsics were missing. It seems worth adding
a comment to explain what's going on.
Tested on aarch64-linux-gnu, pushed.
Richard
2020-04-24 Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
On Thu, 23 Apr 2020, Jonathan Wakely wrote:
> This no longer works, so direct people to the mailman listinfo pages
> instead.
>
> OK to commit to wwwdocs?
Yes, thank you!
I was wondering whether we could keep something similar to this nice
form, but could not come up with a good way. So a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #17 from Jakub Jelinek ---
Created attachment 48367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48367=edit
gcc10-pr94734.patch
Updated patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742
Bug ID: 94742
Summary: Incorrect "no return statement" warning with
[[noreturn]] and __FUNCTION__
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity:
On Tue, 14 Apr 2020 at 10:38, Andre Vieira (lists)
wrote:
>
> On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
> > Several ARM/MVE tests can be compiled even if the toolchain does not
> > support -mfloat-abi=hard (softfp is OK).
> >
> > Use dg-add-options arm_v8_1m_mve or
On Apr 23, 2020, Martin Sebor wrote:
> Sure. I'd go with _fileio but that's just a suggestion.
Okiedokie, here's the patch using fileio instead of tmpnam for the
effective target name. I'm going to check it in shortly.
introduce target fileio and require it in tests that use tmpnam
Some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #16 from Jakub Jelinek ---
Created attachment 48366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48366=edit
gcc10-pr94734.patch
So like this? The store data races thing can be covered by the non-addressable
auto var checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:cbd2a10dd9edadb262934aed64c0959339da68d1
commit r10-7941-gcbd2a10dd9edadb262934aed64c0959339da68d1
Author: Haijian Zhang
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #13)
> Even better.
Note none of the committed testcases would be handled with this. There's
also the issue of store data races (not sure if the notrap handling is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #14 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #10)
> bar is still miscompiled by some other optimization though
> (and GCC 9 didn't do that), so we have some other regression.
Sorry for the false alarm, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #13 from Jakub Jelinek ---
Even better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #12 from rguenther at suse dot de ---
On Fri, 24 Apr 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
>
> --- Comment #11 from Jakub Jelinek ---
> If we don't want to revert the change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #11 from Jakub Jelinek ---
If we don't want to revert the change completely, could we perhaps do:
--- gcc/tree-ssa-phiopt.c.jj2020-03-19 10:23:50.542872359 +0100
+++ gcc/tree-ssa-phiopt.c 2020-04-24 10:54:10.341716841 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #7 from Segher Boessenkool ---
Needs -mvsx -mlittle -O0 to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #10 from Jakub Jelinek ---
Yeah.
add_or_mark_expr could be extended to handle more complex addresses (perhaps
get_inner_reference and hash on the decl + offset expression and taking into
account the bitpos/bitsize then?
Further
On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of
On Fri, Apr 24, 2020 at 9:52 AM Zhanghaijian (A)
wrote:
>
>
>
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Friday, April 24, 2020 2:19 PM
> > To: Zhanghaijian (A)
> > Cc: Segher Boessenkool ;
> > gcc-patches@gcc.gnu.org
> > Subject: Re:
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 24 April 2020 08:49
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][wwwdocs] Add -moutline-atomics for AArch64 on gcc-9 and
> gcc-8
>
> Add the backported functionality of -moutline-atomics for AArch64 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> In particular tree_could_trap_p woudl consider the load possibly trapping
> due to the variable indexing but the patch seems to override that which
> I agree
Hello, Segher,
On Apr 23, 2020, Segher Boessenkool wrote:
> On Thu, Apr 23, 2020 at 05:08:55AM -0300, Alexandre Oliva wrote:
>> I wasn't sure simplify_gen_subreg might possibly emit any code in
>> obscure cases,
> It never does, it just returns an RTX. Where would it emit the insns to?
I'm
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, April 24, 2020 2:19 PM
> To: Zhanghaijian (A)
> Cc: Segher Boessenkool ;
> gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate
> fp min/max
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #8 from Richard Biener ---
In particular tree_could_trap_p woudl consider the load possibly trapping
due to the variable indexing but the patch seems to override that which
I agree is bogus. I think we need to revert it and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #16 from Xavier ---
(In reply to Martin Sebor from comment #14)
> That said and codegen improvements aside, I think the submitted test case is
> sufficiently tricky that I don't see issuing a warning for it as a problem.
> All
Add the backported functionality of -moutline-atomics for AArch64 to the
gcc-9 and gcc-8 changes.html
Validates. Is this OK?
diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index
83dd1bc010a6e4debb76790b3fe62275bf0e0657..83e57db181294110f71a5d59960fb4d3fed7be98
100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #11 from Thomas Koenig ---
Fixed on all open branches.
Thanks a lot for the bug report!
Regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #10 from CVS Commits ---
The releases/gcc-8 branch has been updated by Thomas Kथà¤nig
:
https://gcc.gnu.org/g:aadc54867cc200ad7d073222769b9de7f13b5bcd
commit r8-10218-gaadc54867cc200ad7d073222769b9de7f13b5bcd
Author: Thomas König
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741
--- Comment #1 from Daniel Adamski ---
Oh, I just checked in godbolt and it seems it is already fixed in "trunk"
version: https://godbolt.org/z/hyCQCX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741
Bug ID: 94741
Summary: stringop-truncation is triggered or not depending on
surrounding members
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity:
> On 23 Apr 2020, at 19:39, Jonathan Wakely wrote:
> Patch submitted for approval now:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html
Thanks Jonathan :)
Hi.
One can also have enabled gcc_checking_assert in a release build
and that's why coro_body_contains_bind_expr_p can't be guarded
in a CHECKING_P macro.
I'm going to install it as obvious. I've just tested both release and
non-release builds.
Thanks,
Martin
gcc/cp/ChangeLog:
2020-04-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
:
https://gcc.gnu.org/g:2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
commit r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
Author: Thomas König
On Fri, Apr 24, 2020 at 5:05 AM Zhanghaijian (A)
wrote:
>
> Thanks for your suggestions. For safety, I put back
> flag_unsafe_math_optimizations.
> Attached please find the v3 patch which is suitable for git am. Bootstrap and
> tested on aarch64 Linux platform.
> Is the v3 patch ok?
OK.
On Thu, Apr 23, 2020 at 4:54 PM Eric Botcazou wrote:
>
> > > > What is wrong with DF?
> > >
> > > It's slow and memory hungry?
> >
> > Very true, of course. But can this be significantly better?
>
> That's a good question worth investigating in my opinion, because DF didn't
> quite achieve its
101 - 147 of 147 matches
Mail list logo
