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 err
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
ar
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 shoul
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 copysig
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, i
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 u
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 tree-optimization/9876
> -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,
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 based
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.
20
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 a
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 (
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 b/gcc
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 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.
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 those
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
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.
* gcc.dg/debug/ctf/ctf-anonymous-
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
>> > implementatio
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 t
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 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
spaces,
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,
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 (decl));
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 -200
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 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 o
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
>
>
> Seghe
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 -fprofile
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 go
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] D
> 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:0
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/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", node->tp_first_r
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
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 avail
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 to
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 / a
> 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 -fchecking=1,$
> 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 sim
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 think
>
> 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 frequ
> 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.
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 p
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 mallo
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
* tr
> > 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. Ho
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
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 g
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 rig
> >
> > 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.
>
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 test
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 direct
> 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:
>
>
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
> --- a/gcc/conf
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 nvptx-too
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 commi
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, wou
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 vi
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 lat
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 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,
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 10
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 includ
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 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
> > > curr
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 com
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 = dependent_name
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 tmp::i
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 th
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.
gcc/cp/ChangeLog:
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: g++.target/i386/pr88152.
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, 1
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 exp
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 wr
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 trigge
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 pointer
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 a
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
(2b93ffc7219aa53815ece2adb21f56dd
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
> >
> > * gcc.target/powerpc/fold
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 wr
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 makin
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
> >
> > * config/rs6000/rs6000-c.c
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.
https://gcc
---
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 work-in-prog
---
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.
---
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
@@ -97
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 == NUL
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 gi
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 do
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))
{
gcc_checking_assert
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:
> >
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 targ
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 wrot
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.
* gcc.target/i386/m256-
1 - 100 of 111 matches
Mail list logo
