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 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]
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!
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
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.
*
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
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
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
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
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
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 later on.
That change has been done to fix
Hi!
As discussed in the PR, the problem here is that the routines changed in
this patch sign extend the difference of index and low_bound from the
precision of the index, so e.g. when index is unsigned int and contains
value -2U, we treat it as index -2 rather than 0xfffeU on 64-bit
On Wed, 20 Jan 2021 at 17:23, Martin Liška wrote:
>
> On 1/19/21 5:55 PM, Prathamesh Kulkarni wrote:
> > Hi,
> > The attached patch fixes the issue mentioned in PR, by adding
> > arm_fp16_format to checked_options in optc-save-gen.awk.
> > Is this OK to commit in stage-4 if testing passes or
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 (X cmp 0.0 ? +-1.0 : -+1.0)
simplifications into
On Thu, Jan 21, 2021 at 06:35:48PM -0300, 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
> -Original Message-
> From: Tamar Christina
> Sent: 21 January 2021 18:54
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: [PATCH]Arm: Add NEON and MVE complex mul, mla and mls
> patterns.
>
> Hi All,
On Thu, Jan 21, 2021 at 07:42:43PM -0300, Alexandre Oliva wrote:
> On Jan 21, 2021, Alexandre Oliva wrote:
>
> > But I was wrong. The bootstrap with the added assert has just failed,
> > as early as stage2 libiberty. Looking into it...
>
> Uhh, I take that back. I just goofed in the assert,
Hi all,
We ICE here because we end up comparing a poly_int64 with a scalar using <=
rather than known_le.
This patch fixes that in the way richi suggests in the PR.
Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for trunk?
Thanks,
Kyrill
gcc/ChangeLog:
PR
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
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/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
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
> 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
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
This fixes factor_out_conditional_conversion to avoid creating overlapping
lifetimes for abnormals. It also makes sure we do deal with a conditional
conversion (at least for one PHI arg def) - for the testcase that wasn't the
case.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
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
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
> > 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
> > implementation
On Fri, 22 Jan 2021, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, the problem here is that the routines changed in
> this patch sign extend the difference of index and low_bound from the
> precision of the index, so e.g. when index is unsigned int and contains
> value -2U, we treat it
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
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
>> >
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 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
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.
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
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
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,
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
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 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
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
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
> 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
> 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
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
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
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",
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
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
> ---
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 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 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
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
> 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:
>
>
> 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
> 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
>
> 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
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
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
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
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
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 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
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 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.
> >
> > 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.
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,
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
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 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,
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
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 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
> > >
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
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 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 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 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:
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 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 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
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.
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 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
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, 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
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
---
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 | 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.
I've taken the liberty of pushing these changes to the website,
having checked that they validate.
Corrections welcome.
Thanks
Dave
---
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.
---
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 | 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 | 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
@@
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
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
1 - 100 of 111 matches
Mail list logo
