On 10/6/2021 4:22 AM, Aldy Hernandez wrote:
[Here go the bits by Richi, tested on x86-64 Linux, and ongoing tests
on aarch64 and ppc64le.]
There is a lot of fall-out from this patch, as there were many threading
tests that assumed the restrictions introduced by this patch were valid.
Some
On 21-10-16 18:57:39, Segher Boessenkool wrote:
> On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote:
> > Only powerpc64-unknown-freebsd was checked for.
> >
> > Signed-off-by: Piotr Kubaj
>
> Thanks!
>
> I pushed this now, with commit message (including changelog, which is
>
Changes since v5[5]:
- Reworked all builtins to accept the FE_* macros as parameters and
so be agnostic to libc implementations. Largely based of
fpclassify. To that end, there is some new files changed:
+ Change the argument list for the builtins declarations in
builtins.def
On Sat, Oct 16, 2021 at 04:09:05AM +0200, Piotr Kubaj wrote:
> Only powerpc64-unknown-freebsd was checked for.
>
> Signed-off-by: Piotr Kubaj
Thanks!
I pushed this now, with commit message (including changelog, which is
required):
===
gcc/configure: Check for powerpc64le*-*-freebsd*
Only
These two redirected from golang.org to pkg.go.dev.
---
htdocs/gcc-5/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-5/changes.html b/htdocs/gcc-5/changes.html
index a346c7f6..05e796dd 100644
--- a/htdocs/gcc-5/changes.html
+++
This patch is mostly motivated by distribution needs in general
and Debian/Ubuntu needs in particular – but I think it makes
sense for all GCC 11 users.
GCC's AMD GCN support uses LLVM's assembler and linker mc/lld
and thus requires compatibility with LLVM. On mainline, support
for LLVM 13 was
On Sat, Oct 16, 2021 at 3:59 PM H.J. Lu wrote:
>
> On Sat, Oct 16, 2021 at 12:53 PM David Edelsohn wrote:
> >
> > On Sat, Oct 16, 2021 at 1:13 PM H.J. Lu wrote:
> > >
> > > On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn wrote:
> > > >
> > > > On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu wrote:
>
On Sat, Oct 16, 2021 at 12:53 PM David Edelsohn wrote:
>
> On Sat, Oct 16, 2021 at 1:13 PM H.J. Lu wrote:
> >
> > On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn wrote:
> > >
> > > On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn
>
On Sat, Oct 16, 2021 at 1:13 PM H.J. Lu wrote:
>
> On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn wrote:
> >
> > On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu wrote:
> > >
> > > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn wrote:
> > > >
> > > > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu wrote:
> >
On 10/15/2021 9:27 AM, Martin Liška wrote:
On 10/14/21 16:27, Jeff Law wrote:
So what's the preferred way to handle this? We're in the process of
evaluating -frename-registers on our target right now and subject to
verification of a couple issues, our inclination is to turn it on for
our
* value-query.cc (get_ssa_name_ptr_info_nonnull): Change
set_ptr_nonull to set_ptr_nonnull in comments.
---
gcc/value-query.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index ab133aab114..17ebd86ce5f 100644
---
On Sat, Oct 16, 2021 at 10:14 AM H.J. Lu via Gcc-patches
wrote:
>
> Go on master branch isn't buildable on AIX. What should I do
> next to get my libffi sync patches into master branch?
Is the only problem you are having the missing-objcopy problem? To
fix that one, install the GNU binutils.
>
> Fortran has for a long time 'character(len=5), allocatable" or
> "character(len=*)". In the first case, the "5" can be ignored as both
> caller and callee know the length. In the second case, the length is
> determined by the argument, but it cannot be changed.
>
> Since a not-that-short
Hi Honza,
On 16.10.21 20:23, Jan Hubicka via Gcc-patches wrote:
FAIL: gfortran.dg/deferred_type_param_6.f90 -O1 execution test
FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test
Sorry for the breakage. This time it seems like bug in Fortran FE
which was previously latent:
Hi,
>
> FAIL: gfortran.dg/deferred_type_param_6.f90 -O1 execution test
> FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test
Sorry for the breakage. This time it seems like bug in Fortran FE
which was previously latent:
__attribute__((fn spec (". . R ")))
void subfunc
On Sat, Oct 16, 2021 at 10:04 AM David Edelsohn wrote:
>
> On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu wrote:
> >
> > On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn wrote:
> > >
> > > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu wrote:
> >
On Sat, Oct 16, 2021 at 7:48 AM H.J. Lu wrote:
>
> On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn wrote:
> >
> > On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu wrote:
> > >
> > > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > >
> On 16 Oct 2021, at 10:27, Andrew Pinski via Gcc-patches
> wrote:
>
> On Fri, Oct 15, 2021 at 6:53 AM Andrew MacLeod via Gcc-patches
> wrote:
>>
>> I've been looking at the pathological time issue ranger has with the
>> testcase from, uh.. PR 97623 I think. I've lost the details,
On Linux/x86_64,
99b287b8ef51a0be52f7400879a619dc5f993f31 is the first bad commit
commit 99b287b8ef51a0be52f7400879a619dc5f993f31
Author: Jan Hubicka
Date: Sat Oct 16 14:45:06 2021 +0200
Fix wrong code in ldost-strlen-1.c
caused
FAIL: gfortran.dg/deferred_type_param_6.f90 -O1
On Sat, Oct 16, 2021 at 8:46 AM Richard Biener via Gcc-patches
wrote:
>
> On October 16, 2021 2:47:51 PM GMT+02:00, Jan Hubicka via Gcc-patches
> wrote:
> >Hi,
> >while updating compute_points_to_sets I missed that the code not only
> >sets the nonlocal/escaped flags but also initializes pt.
The www.dwarfstd.org webmasters suggested (via a redirect) to adjust
http links to https.
---
htdocs/gcc-4.7/changes.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/gcc-4.7/changes.html b/htdocs/gcc-4.7/changes.html
index 5103e5ee..dae1735d 100644
---
---
htdocs/codingconventions.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index 21cc95de..e4d30510 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -146,7 +146,7 @@ a large
On October 16, 2021 2:47:51 PM GMT+02:00, Jan Hubicka via Gcc-patches
wrote:
>Hi,
>while updating compute_points_to_sets I missed that the code not only
>sets the nonlocal/escaped flags but also initializes pt. With my
>previous change if uses_global_memory is false pt is not updated
>correctly
On Sat, 16 Oct 2021, 14:49 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi
>
> Here is the new proposal. My only concern is that we are also using
> hash or equal_to functors in the guard destructor.
>
Can we catch any exception there, invalidate all iterators, and not
Hi
Here is the new proposal. My only concern is that we are also using
hash or equal_to functors in the guard destructor.
I am going to enhance merge normal implementation to make use of
the cached hash code when hash functors are the same between the source
and destination of
Hi,
while updating compute_points_to_sets I missed that the code not only
sets the nonlocal/escaped flags but also initializes pt. With my
previous change if uses_global_memory is false pt is not updated
correctly which may lead to wrong code.
This is fixed by the following patch I comitted to
On Fri, Oct 15, 2021 at 5:22 PM David Edelsohn wrote:
>
> On Fri, Oct 15, 2021 at 8:06 PM H.J. Lu wrote:
> >
> > On Wed, Oct 13, 2021 at 6:42 AM H.J. Lu wrote:
> > >
> > > On Wed, Oct 13, 2021 at 6:03 AM Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 2:56 PM H.J. Lu
On Fri, Oct 15, 2021 at 6:53 AM Andrew MacLeod via Gcc-patches
wrote:
>
> I've been looking at the pathological time issue ranger has with the
> testcase from, uh.. PR 97623 I think. I've lost the details, but
> kept the file since it was showing unpleasant behaviour.
>
> Most of the time
28 matches
Mail list logo
