Hi!
On Sat, Jan 23, 2021 at 01:03:31AM +0100, Jakub Jelinek wrote:
> On Fri, Jan 22, 2021 at 05:45:54PM -0600, Segher Boessenkool wrote:
> > On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> > > The x86 __m64 type is defined as:
> > > /* The Intel API is flexible enough that we
Those are the fold-vec-extract-* changes. And they fix a regression
on AIX. Another difference to detangle.
I'm referring to the new fold-vec-insert-* failures. I fixed the p9
failures, but some of the tests now ICE when targeting P8.
Thanks, David
On Fri, Jan 22, 2021 at 8:03 PM Segher
On Fri, Jan 22, 2021 at 03:02:47PM -0500, David Edelsohn wrote:
> All of these testcases no fail on AIX. This was not tested properly.
> Please fix.
They fail on -m32 Linux as well: all failures are an unexpected count
of addi insns. This may be related to the LRA regression we have (just
based
Hi!
On Fri, Jan 22, 2021 at 08:02:28PM +0100, Jakub Jelinek wrote:
> On Mon, Sep 21, 2020 at 10:12:20AM +0200, Richard Biener wrote:
> > On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > > these testcases now fails because they contains an invalid type puning
> > > that happens via const VALUE_TYPE *v
On Sat, Jan 23, 2021 at 01:03:31AM +0100, Jakub Jelinek via Gcc-patches wrote:
> The problem is that the testcase uses the
> _mm_loadl_pi
> API, and per the Intel intrinsic rules it is ok when that intrinsic
> loads from wide range of types, e.g. including pairs of integers or
> 4 shorts or 8
On Fri, Jan 22, 2021 at 05:45:54PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> > The x86 __m64 type is defined as:
> > /* The Intel API is flexible enough that we must allow aliasing with other
> >vector types, and their scalar
Hi Jakub,
On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> The x86 __m64 type is defined as:
> /* The Intel API is flexible enough that we must allow aliasing with other
>vector types, and their scalar components. */
> typedef int __m64 __attribute__ ((__vector_size__ (8),
Hi Jason,
Attached changes. I just edited the patch file directly.
Kind regards,
Anthony
From 7984020f16e715017e62b8637d2e69c1aec3478a Mon Sep 17 00:00:00 2001
From: Anthony Sharp
Date: Thu, 21 Jan 2021 15:26:25 +
Subject: [PATCH] c++: Private inheritance access diagnostics fix [PR17314]
This is referenced by my recent release notes changes for GCC 11:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564164.html
Pushed as 9cead79073862f207c1df4f7bcacb6e43d01384f.
gcc/ChangeLog:
* doc/invoke.texi (GCC_EXTRA_DIAGNOSTIC_OUTPUT): Add @findex
directive.
---
On Fri, Jan 22, 2021 at 04:44:42PM -0500, Jason Merrill wrote:
> On 1/22/21 4:01 PM, Marek Polacek wrote:
> > On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > On 1/21/21 5:45 PM, Marek Polacek wrote:
> > > > I discovered very strange code in
Hi!
And ditto for powerpc. Written as separate patch because it was dependent
on the no-strict-aliasing patch.
Committed to trunk as obvious.
2021-01-22 Jakub Jelinek
* gcc.target/powerpc/m128-check.h (CHECK_EXP, CHECK_FP_EXP): Fix a
typo, UINON_TYPE to UNION_TYPE.
---
Hi!
Spotted while fixing the rs6000 aliasing issue.
Regtested on x86_64-linux and i686-linux, committed to trunk as obvious.
2021-01-22 Jakub Jelinek
* gcc.target/i386/m128-check.h (CHECK_EXP, CHECK_FP_EXP): Fix a typo,
UINON_TYPE to UNION_TYPE.
*
On 1/22/21 4:45 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Jason Merrill wrote:
On 1/22/21 1:58 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Jason Merrill wrote:
On 1/22/21 12:59 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka
Hi!
As mentioned in the PR, the compiler behaves differently during strncmp
and strncasecmp folding between 32-bit and 64-bit hosts targeting 64-bit
target. I think that is highly undesirable.
The culprit is the host_size_t_cst_p predicate that is used by
fold_const_call, which punts if the
On Fri, 22 Jan 2021, Jason Merrill wrote:
> On 1/22/21 1:58 PM, Patrick Palka wrote:
> > On Fri, 22 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/22/21 12:59 PM, Patrick Palka wrote:
> > > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > > >
> > > > > On Fri, 22 Jan 2021, Patrick Palka wrote:
>
On 1/22/21 4:01 PM, Marek Polacek wrote:
On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches wrote:
On 1/21/21 5:45 PM, Marek Polacek wrote:
I discovered very strange code in inject_parm_decls:
if (args && is_this_parameter (args))
{
On Fri, Jan 22, 2021 at 02:47:06PM +0100, Richard Biener wrote:
> On Thu, 21 Jan 2021, Segher Boessenkool wrote:
> > What is holding up this patch still? Ke Wen has pinged it every month
> > since May, and there has still not been a review.
Richard Sandiford wrote:
> FAOD (since I'm on cc:), I
On 1/22/21 3:07 PM, Anthony Sharp wrote:
Hi Jason,
Thanks for getting back to me so quickly.
> Why two gcc-comit-mklog? That would generate the log entries twice.
It did in fact generate the log entries twice, but I deleted out the
second copy. Perhaps it would have made more sense to do
On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/21/21 5:45 PM, Marek Polacek wrote:
> > I discovered very strange code in inject_parm_decls:
> >
> > if (args && is_this_parameter (args))
> > {
> > gcc_checking_assert (current_class_ptr ==
---
htdocs/gcc-11/changes.html | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 67e29619..ba09587d 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@
---
htdocs/gcc-11/changes.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index ba09587d..08a4c93a 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -184,7 +184,8 @@ a work-in-progress.
---
htdocs/gcc-11/changes.html | 45 --
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 3c18ef18..93c421e3 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@
---
htdocs/gcc-11/changes.html | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 93c421e3..67e29619 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -562,8 +562,16 @@ a
---
htdocs/gcc-11/changes.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 05b182bc..3c18ef18 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -331,6 +331,12 @@ a work-in-progress.
libgccjit
---
htdocs/gcc-11/changes.html | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 7eeffb98..05b182bc 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -519,6 +519,10 @@ a work-in-progress.
I've taken the liberty of pushing these changes to the website,
having checked that they validate.
Corrections welcome.
Thanks
Dave
On Thu, Jan 21, 2021 at 6:51 PM Segher Boessenkool
wrote:
>
> Hi!
>
> You never committed 2/4? That makes it harder to review this one :-)
>
> On Sat, Oct 10, 2020 at 03:08:24AM -0500, Xionghu Luo wrote:
> > gcc/ChangeLog:
> >
> > 2020-10-10 Xionghu Luo
> >
> > *
Hi Jason,
Thanks for getting back to me so quickly.
> Why two gcc-comit-mklog? That would generate the log entries twice.
It did in fact generate the log entries twice, but I deleted out the second
copy. Perhaps it would have made more sense to do git commit --amend
instead.
> Instead of
On 1/22/21 1:58 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Jason Merrill wrote:
On 1/22/21 12:59 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Thu, 21 Jan 2021, Jason Merrill wrote:
On 1/21/21 11:22 AM, Patrick Palka
All of these testcases no fail on AIX. This was not tested properly.
Please fix.
Thanks, David
On Thu, Jan 21, 2021 at 7:19 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Sat, Oct 10, 2020 at 03:08:25AM -0500, Xionghu Luo wrote:
> > 2020-10-10 Xionghu Luo
> >
> > *
I have backported a number of patches from mainline to the devel/omp/gcc-10
branch:
* openmp: Add support for the OpenMP 5.0 task detach clause
(de460a5faff80a2338ccd46f249c964fa34b4c16)
* libgomp: Don't access gomp_sem_t as int using atomics unconditionally
On January 22, 2021 3:49:41 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>When GCC is emitting .debug_line or .gnu.debuglto_.debug_line section
>by
>itself (happens either with too old or non-GNU assembler, with
>-gno-as-loc-support or with -flto) on empty translation units, it
>violates
>the DWARF
ChangeLog:
2021-01-22 Jonathan Wright
* MAINTAINERS (Write After Approval): Add myself.
From 32a93eac7adbb34bb50ed07a9841c870b7ebcb7a Mon Sep 17 00:00:00 2001
From: Jonathan Wright
Date: Fri, 22 Jan 2021 19:09:11 +
Subject: [PATCH] MAINTAINERS: Add myself for write after
On January 22, 2021 8:02:28 PM GMT+01:00, Jakub Jelinek
wrote:
>On Mon, Sep 21, 2020 at 10:12:20AM +0200, Richard Biener wrote:
>> On Mon, 21 Sep 2020, Jan Hubicka wrote:
>> > these testcases now fails because they contains an invalid type
>puning
>> > that happens via const VALUE_TYPE *v
On Mon, Sep 21, 2020 at 10:12:20AM +0200, Richard Biener wrote:
> On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > these testcases now fails because they contains an invalid type puning
> > that happens via const VALUE_TYPE *v pointer. Since the check function
> > is noinline, modref is needed to
On Fri, 22 Jan 2021, Jason Merrill wrote:
> On 1/22/21 12:59 PM, Patrick Palka wrote:
> > On Fri, 22 Jan 2021, Patrick Palka wrote:
> >
> > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > >
> > > > On Thu, 21 Jan 2021, Jason Merrill wrote:
> > > >
> > > > > On 1/21/21 11:22 AM, Patrick Palka
On 1/22/21 12:59 PM, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Fri, 22 Jan 2021, Patrick Palka wrote:
On Thu, 21 Jan 2021, Jason Merrill wrote:
On 1/21/21 11:22 AM, Patrick Palka wrote:
Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
the
On Thu, 21 Jan 2021 at 21:35, Daniel Engel wrote:
>
> Hi Christophe,
>
> On Thu, Jan 21, 2021, at 2:29 AM, Christophe Lyon wrote:
> > On Sat, 16 Jan 2021 at 17:13, Daniel Engel wrote:
> > >
> > > Hi Christophe,
> > >
> > > On Fri, Jan 15, 2021, at 4:30 AM, Christophe Lyon wrote:
> > > > On Fri,
On Linux/x86_64,
ee78c20e74d30284fee36e22a64e86e45e676029 is the first bad commit
commit ee78c20e74d30284fee36e22a64e86e45e676029
Author: liuhongt
Date: Fri Dec 18 15:56:06 2020 +0800
Lower AVX512 vector comparison to AVX version when dest is vector.
caused
FAIL:
As Jakub points out in the PR, I was mixing up
DECL_HAS_IN_CHARGE_PARM_P (which is true for the abstract maybe-in-charge
constructor) and DECL_HAS_VTT_PARM_P (which is true for a base constructor
that needs to handle virtual bases).
Tested x86_64-pc-linux-gnu, applying to trunk.
Hi!
The x86 __m64 type is defined as:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
and so matches the comment above it in that reads and stores
On Fri, 22 Jan 2021, Patrick Palka wrote:
> On Fri, 22 Jan 2021, Patrick Palka wrote:
>
> > On Thu, 21 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > > > the expression
On 1/22/21 12:02 PM, Marek Polacek wrote:
On Thu, Jan 21, 2021 at 05:41:06PM -0500, Jason Merrill via Gcc-patches wrote:
On 1/21/21 2:44 PM, Marek Polacek wrote:
@@ -3349,7 +3349,12 @@ write_expression (tree expr)
else if (dependent_name (expr))
{
tree name =
On Jan 22 2021, Nick Alcock via Gcc-patches wrote:
> (The purpose of this check is opaque to me: neither libcody
> nor GCC ever includes , and though is
> widely included, it is not directly included by any of the
> headers checking this macro... for now I've fixed things
> to conform to the
On Fri, 22 Jan 2021, Patrick Palka wrote:
> On Thu, 21 Jan 2021, Jason Merrill wrote:
>
> > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > > the expression tmp::integral (because it's type-dependent, and also
> > >
Hi Paul,
Regtested on FC33/x86_64 - OK in a few weeks for 9- and 10-branches?
Yes, I think this is obvious enough for a backport.
Thanks for the patch!
Best regards
Thomas
Searching for sighander_t is unlikely to succeed anywhere.
The attempt to #include is also not working,
and fixing it shows that doing an AC_DEFINE in the body of
an AC_CHECK_TYPE like that is also risky: both fixed.
(The purpose of this check is opaque to me: neither libcody
nor GCC ever
Fixed as 'obviously correct' as
r11-6863-gbf8ee9e4eed6ba1a6d77b4cf168df480e1f954da
The _data component was preventing the detection of the procedure pointer
component and the conversion of the function. Once diagnosed, the fix is
obvious.
Regtested on FC33/x86_64 - OK in a few weeks for 9- and
On Thu, 21 Jan 2021, Jason Merrill wrote:
> On 1/21/21 11:22 AM, Patrick Palka wrote:
> > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > the expression tmp::integral (because it's type-dependent, and also
> > current_class_ptr is set) within the trailing return type,
On Thu, Jan 21, 2021 at 05:41:06PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/21/21 2:44 PM, Marek Polacek wrote:
> > @@ -3349,7 +3349,12 @@ write_expression (tree expr)
> > else if (dependent_name (expr))
> > {
> > tree name = dependent_name (expr);
> > - gcc_assert
On 1/22/21 3:30 AM, Jakub Jelinek wrote:
Hi!
Alex' 2 years old change to build_zero_init_1 to return NULL pointer with
reference type for references breaks the sanitizers, the assignment of NULL
to a reference typed member is then instrumented before it is overwritten
with a non-NULL address
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 22 January 2021 13:09
> To: Kyrylo Tkachov via Gcc-patches
> Cc: Kyrylo Tkachov
> Subject: Re: [PATCH] tree-ssa-mathopts: Use proper poly_int64 comparison
> with param_avoid_fma_max_bits [PR 98766]
>
> Kyrylo Tkachov
On 12/17/20 5:12 PM, Thomas Greenslade (thomgree) via Gcc-patches wrote:
build_aggr_conv did not correctly handle string literal member initializers.
Extended can_convert_array to handle this case. The additional checks of
compatibility of character types, and whether string literal will fit,
GNU style (followed in the header file) is to insert a space between
the function name and the arguments. Same for the other functions.
Ah, yes - will change.
Since other patches like this are on their way, would you mind
going through the process on https://gcc.gnu.org/gitwrite.html
to get
Hi Tom!
Ping.
Grüße
Thomas
On 2021-01-13T12:59:14+0100, I wrote:
> Hi Tom!
>
> On 2020-10-09T13:56:09+0200, Tom de Vries wrote:
>> The nvptx-as assembler verifies the ptx code using ptxas, if there's any
>> in the PATH.
>>
>
> After quite some digression to first add a testsuite to
Thanks for doing this. The patch looks good with one very minor nit fixed:
Jonathan Wright writes:
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index
> f7efee61de4c5268acf446555af4a93fece6b169..da696d9fee2ffbabc9d89f2e9299fbde086cfee1
> 100644
> ---
> gcc/ChangeLog:
>
> PR gcov-profile/98739
> * common.opt: Add missing sign symbol.
> * value-prof.c (get_nth_most_common_value): Restore handling
> of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and
> PROFILE_REPRODUCIBILITY_MULTITHREADED.
>
> libgcc/ChangeLog:
>
>
Hi!
When GCC is emitting .debug_line or .gnu.debuglto_.debug_line section by
itself (happens either with too old or non-GNU assembler, with
-gno-as-loc-support or with -flto) on empty translation units, it violates
the DWARF 5 requirements.
The standard says:
"The first entry is the current
Header unit names come from the path the preprocessor determines, and
thus can be absolute. This tweaks the testsuite to elide that
absoluteness when embedded in a CMI name. We were also not
distinguishing link and execute tests by the $std flags, so append
them when necessary.
PR
> >
> > I would make this go in separately from the feature itself (it is build
> > machinery change).
>
> All right.
>
> > Especially since you say it does not reach
> > reproducibility anyway until we patch hashtables?
>
> Yep, I'm testing a patch that should improve the reproducible build.
Hi,
As subject, this patch rewrites integer mla Neon intrinsics to use
RTL builtins rather than inline assembly code, allowing for better
scheduling and optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
If ok, please commit to master (I don't have commit
There's a simpler patch that can restore the behavior.
TOP N counter pruning is elided.
Martin
>From 4b4956acfda45f6102338a27a9c962171ca4094b Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 22 Jan 2021 11:27:16 +0100
Subject: [PATCH] Restore profile reproducibility.
gcc/ChangeLog:
PR
On 1/22/21 2:51 PM, Jan Hubicka wrote:
diff --git a/Makefile.in b/Makefile.in
index 247cb9c8711..03785200dc7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS))
STAGEtrain_TFLAGS
> > It is definitly doable (gcov machinery is quite flexible WRT having more
> > types of counters).
>
> Yes, that would introduce back the dropped TOPN counters which I intentionally
> dropped.
We could bring back topn counters or the easier dominating vlaue ones
and add command line option.
The previous change made AVX512 mask vectors correct but disregarded
the possibility of generic (BLKmode) boolean vectors which are exposed
by the frontends already.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-01-22 Richard Biener
PR middle-end/98793
*
On 1/22/21 3:10 PM, Jan Hubicka wrote:
On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
On 1/22/21 2:38 PM, Jan Hubicka wrote:
This looks like reasonable solution for Linux (i was thinking of it too)
but I wonder what about setups w/o mmap support, like mingw32?
The code still uses
On Thu, Jan 21, 2021 at 10:36 PM Alexandre Oliva wrote:
>
>
> Ada makes extensive use of nested functions, which turn all automatic
> variables of the enclosing function that are used in nested ones into
> members of an artificial FRAME record type.
>
> The address of a local variable is usually
> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
> >
> > On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > > This looks like reasonable solution for Linux (i was thinking of it too)
> > > but I wonder what about setups w/o mmap support, like mingw32?
> >
> > The code still uses malloc approach
>
> I remember we had issues with streaming running in parallel with
> threads. Can't we get here corruption without atomic updates of nndoes
> and the next pointer?
>
> I also remember that these parlalel updates was pretty bad, because if
> you have multithreaded concurent update of very
On Fri, Jan 22, 2021 at 2:42 PM Martin Liška wrote:
>
> On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > This looks like reasonable solution for Linux (i was thinking of it too)
> > but I wonder what about setups w/o mmap support, like mingw32?
>
> The code still uses malloc approach then.
>
> > I
> On 1/22/21 2:38 PM, Jan Hubicka wrote:
> > This looks like reasonable solution for Linux (i was thinking of it too)
> > but I wonder what about setups w/o mmap support, like mingw32?
>
> The code still uses malloc approach then.
>
> > I think we need some fallback there. I was wondering if
> diff --git a/Makefile.in b/Makefile.in
> index 247cb9c8711..03785200dc7 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
> STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS))
> STAGEtrain_TFLAGS = $(filter-out
On Thu, 21 Jan 2021, Segher Boessenkool wrote:
> Hi!
>
> What is holding up this patch still? Ke Wen has pinged it every month
> since May, and there has still not been a review.
I don't like it, it feels wrong but I don't have a good suggestion
that had positive feedback. Since a reviewer /
On 1/22/21 2:38 PM, Jan Hubicka wrote:
This looks like reasonable solution for Linux (i was thinking of it too)
but I wonder what about setups w/o mmap support, like mingw32?
The code still uses malloc approach then.
I think we need some fallback there. I was wondering if simply
disabling
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not
PING^3
On 1/14/21 10:03 AM, Martin Liška wrote:
PING^2
On 1/6/21 3:21 PM, Martin Liška wrote:
PING
On 12/4/20 2:30 PM, Martin Liška wrote:
On 12/4/20 10:03 AM, Richard Biener wrote:
Otherwise 0001- looks good to me.
Pushed that to master.
As said I'd like to see opinions
from others on
Hello.
AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
like
what Richard suggested. So instead of usage of malloc, we should use mmap memory
chunks that serve as a memory pool for struct gcov_kvp.
Malloc is used as a fallback when mmap is not available. I also drop
On 1/22/21 2:07 PM, Jan Hubicka wrote:
This is OK. To save future debugging, perhaps I would keep the code
printing the tp first run value to dump file and do
fprintf (dump_file, "Read tp_first_run: %d; ignored because profile
reproducibility is multithreaded\n",
Kyrylo Tkachov via Gcc-patches writes:
> diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
> index
> d6201d3cb943e145720c18fbf3aadd853fd87b44..800815b855c759075b4326361cc4db7183f1c543
> 100644
> --- a/gcc/tree-ssa-math-opts.c
> +++ b/gcc/tree-ssa-math-opts.c
> @@ -3252,8 +3252,8
> On 1/21/21 8:13 PM, Martin Liška wrote:
> > Yes, it will be a better place!
> >
> > Martin
>
> There's an updated version of the patch.
>
> Thoughts?
> Thanks,
> Martin
> From 0be300d1d69e98624f7be5b54931126965f1436e Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Fri, 22 Jan 2021
On 1/21/21 8:13 PM, Martin Liška wrote:
Yes, it will be a better place!
Martin
There's an updated version of the patch.
Thoughts?
Thanks,
Martin
>From 0be300d1d69e98624f7be5b54931126965f1436e Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 22 Jan 2021 14:00:30 +0100
Subject: [PATCH]
On 1/21/21 3:20 PM, Joseph Myers wrote:
On Thu, 21 Jan 2021, Nathan Sidwell wrote:
Do you want expandargv altered alongs the lines you mention? Or a bug filed?
[in order for my patch to be acceptable]
The patch is OK as-is. Filing a bug for expandargv handling of missing
files might be a
On 1/21/21 8:16 PM, Jan Hubicka wrote:
On 1/21/21 8:03 PM, Jan Hubicka wrote:
What exactly is suggested?
This one.
Martin
From 22bbf5342f2b73fad6c0286541bba6699c617380 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 21 Jan 2021 09:02:31 +0100
Subject: [PATCH 1/2] Restore
Segher Boessenkool writes:
> Hi!
>
> What is holding up this patch still? Ke Wen has pinged it every month
> since May, and there has still not been a review.
FAOD (since I'm on cc:), I don't feel qualified to review this.
Tree-level loop stuff isn't really my area.
Thanks,
Richard
>
>
>
Hi Rainer, Jonathan
>>>why? I've just double-checked the OpenGroup pages: all of the functions
>>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>>have Technical Corrigenda applied. IIUC IEEE 1003.1-2017 is just a
>>>revision of the -2008 standard, not a new issue (XPG8
The use of -nostdlib and -nodefaultlibs disables the processing of
LIB_SPEC (%L) as specified by LINK_COMMAND_SPEC and thus disables the
default linker script for RTEMS. Move the linker script to
STARTFILE_SPEC which is controlled by -nostdlib and -nostartfiles. This
fits better since the linker
Hi Jonathan,
> On 22/01/21 12:04 +0100, Rainer Orth wrote:
>>why? I've just double-checked the OpenGroup pages: all of the functions
>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>have Technical Corrigenda applied. IIUC IEEE 1003.1-2017 is just a
>>revision of the
On 22/01/2021 11:42, Andrew Stubbs wrote:
@@ -20294,15 +20315,6 @@ add_location_or_const_value_attribute (dw_die_ref die,
tree decl, bool cache_p)
if (list)
{
add_AT_location_description (die, DW_AT_location, list);
-
- addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE
The previous change exposed a miscompile when trying to interpret
CHREC_RIGHT correctly which in fact it already was to the extent
it is used. The following reverts this part of the change, only
retaining the singling out of HOST_WIDE_INT_MIN.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
Hi all, Jakub,
I need to implement DWARF for local variables that exist in an
alternative address space. This happens for OpenACC gang-private
variables (or will when the patches are committed) on AMD GCN, at least.
This is distinct from pointer variables that reference other address
On 22/01/21 12:04 +0100, Rainer Orth wrote:
why? I've just double-checked the OpenGroup pages: all of the functions
listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
have Technical Corrigenda applied. IIUC IEEE 1003.1-2017 is just a
revision of the -2008 standard, not a new
On 22/01/21 09:57 +, CHIGOT, CLEMENT via Libstdc++ wrote:
Hi Rainer
> 3) POSIX 2017 and non-POSIX functions
> Many of the *_l functions being used in GNU or dragonfly models aren't
> POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all.
> However, there are really useful in
Hi Clement,
>> > 3) POSIX 2017 and non-POSIX functions
>> > Many of the *_l functions being used in GNU or dragonfly models aren't
>> > POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all.
>> > However, there are really useful in the code, thus I've made a double
>> >
This commit adds a new testsuite for the CTF debug format.
2021-01-22 Indu Bhagat
gcc/testsuite/
* gcc.dg/debug/ctf/ctf-1.c: New test.
* gcc.dg/debug/ctf/ctf-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-anonymous-struct-1.c: Likewise.
*
Hi people!
Last year we submitted a first patch series introducing support for
the CTF debugging format in GCC [1]. We got a lot of feedback that
prompted us to change the approach used to generate the debug info,
and this patch series is the result of that.
This implementation works, but there
On 21/01/21 17:36 +0100, Rainer Orth wrote:
Hi Clement,
Here is a new version of the patch. I've tested on Linux and AIX.
There are still some tests failing but it starts having a good shape !Â
However, I have few questions:
1) locale.name and syscalls
just a terminology nit: none of
This commit introduces support for generating CTF debugging
information from GCC.
2021-01-22 Indu Bhagat
Jose E. Marchesi
Weimin Pan
gcc/
* Makefile.in: Add ctfout.* files to GTFILES. Add new object files.
* common.opt: Add CTF debug info options.
2021-01-22 Indu Bhagat
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h: New Prototype.
---
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
index 2354386f7b4..0082ee9f350 100644
This commit documents the new command line options introduced by the
CTF debug format.
2021-01-22 Indu Bhagat
* doc/invoke.texi: Document the CTF debug info options.
---
gcc/doc/invoke.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/invoke.texi
On Fri, 22 Jan 2021, Jakub Jelinek wrote:
> Hi!
>
> In the PR Andrew said he has implemented a simplification that has been
> added to LLVM, but that actually is not true, what is in there are
> X * (X cmp 0.0 ? +-1.0 : -+1.0) simplifications into +-abs(X)
> but what has been added into GCC are
1 - 100 of 111 matches
Mail list logo
