https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801
--- Comment #1 from Andrew Pinski ---
I don't think we need a builtin. Because we could just improve the code
generation instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97399
Patrick Palka changed:
What|Removed |Added
Summary|[9/10/11 Regression] g++|[9/10 Regression] g++ 9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97399
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a8cef3cba6945730c69e15dcdad726e74b50fe58
commit r11-6878-ga8cef3cba6945730c69e15dcdad726e74b50fe58
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88548
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a8cef3cba6945730c69e15dcdad726e74b50fe58
commit r11-6878-ga8cef3cba6945730c69e15dcdad726e74b50fe58
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683
--- Comment #2 from sandra at gcc dot gnu.org ---
I'm pretty sure this is a gas bug. I used git bisect to track it down to
binutils commit ae9d2233e61a98ff8dba56be10219aa5306ffc9a which caused gcc to
start passing --gdwarf-5 on the gas command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801
Bug ID: 98801
Summary: Request for a conditional move built-in function
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at charter dot net
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98732
郑之为 changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #3 from Segher Boessenkool ---
Created attachment 50040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50040=edit
Patch
Patch in testing.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #1
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),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623
--- Comment #5 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:89100826acec92dfaa6ab8f2646b8053e7dbc67c
commit r11-6874-g89100826acec92dfaa6ab8f2646b8053e7dbc67c
Author: Marek Polacek
Date:
Snapshot gcc-9-20210122 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210122/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #12 from Alan Modra ---
Created attachment 50039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50039=edit
ELFv1 support
Revised patches. I wasn't happy with the use of a ".text" symbol in the
previous patch since some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
Alan Modra changed:
What|Removed |Added
Attachment #49701|0 |1
is obsolete|
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.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800
Patrick Palka changed:
What|Removed |Added
Summary|ICE on invalid use of |[8/9/10/11 Regression] ICE
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800
Bug ID: 98800
Summary: ICE on invalid use of non-static member function in
trailing return type since r251438
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
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))
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b485fa167ef35c8facbd7c21cb86fd1abc77efcf
commit r11-6868-gb485fa167ef35c8facbd7c21cb86fd1abc77efcf
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Bill Long from comment #10)
> Still fails with 10.2.0. Can you say which release version will include the
> fix?
According to https://gcc.gnu.org/, gcc 10.2 was released in July
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #15 from Marius Hillenbrand ---
tl;dr: I found the root cause and a way to repro on x86. When the
gnat/gcc interface converts gnat entities into tree decls,
maybe_pad_type() pads some record types. maybe_pad_type() calls
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #7 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index a2376917635..7699e98f6ea 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -689,9 +689,14 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #10 from Bill Long ---
Still fails with 10.2.0. Can you say which release version will include the
fix?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #10 from seurer at gcc dot gnu.org ---
It is still failing for me so I'd guess that Alan's patch is not submitted yet.
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 ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #2 from Carl Love ---
Segher:
Yup, I saw the buzilla. Will take a look at it.
Carl
On Fri, 2021-01-22 at 18:49 +, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
>
>
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
Bug ID: 98799
Summary: [10 Regression] vector_set_var ICE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97588
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:90cbc769006a43ed17d2384b3a0a4634f315d3fd
commit r11-6866-g90cbc769006a43ed17d2384b3a0a4634f315d3fd
Author: Jason Merrill
Date:
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #19 from Segher Boessenkool ---
We cannot allow "m" to allow pcrel memory accesses, because most
existing inline assembler code will break then. So we then need
some way to tell the compiler that some instruction *does* allow
pcrel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a9ed18295bfc6d69d40af197e059e16622cd94c6
commit r11-6865-ga9ed18295bfc6d69d40af197e059e16622cd94c6
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:25fc4d01a8ed1888e6a65597a3387349eb3c950c
commit r11-6864-g25fc4d01a8ed1888e6a65597a3387349eb3c950c
Author: Marek Polacek
Date:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #5 from Bill Long ---
Original customer is asking again...
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 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
--- Comment #8 from Jakub Jelinek ---
Created attachment 50037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50037=edit
gcc11-pr98681.patch
Therefore, if you want to use UINTVAL in that function wherever possible, we
can, but we need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:c806314b32987096d79de21e72dc0cf783e51d57
commit r10-9288-gc806314b32987096d79de21e72dc0cf783e51d57
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
--- Comment #5 from Bill Long ---
Is this fixed in a release version of GCC?
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
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
--- Comment #7 from Jakub Jelinek ---
So, for the mask, the question is if we should or shouldn't handle e.g.
unsigned
foo (unsigned int x)
{
return (x << 13) & (-1U << 13);
}
or
unsigned
bar (unsigned int x)
{
return (x << 0) & -1U;
}
I
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565
--- Comment #3 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:bf8ee9e4eed6ba1a6d77b4cf168df480e1f954da
commit r11-6863-gbf8ee9e4eed6ba1a6d77b4cf168df480e1f954da
Author: Paul Thomas
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:d7e681fc3afff24a6279058cbb0b0dc4cd96be8c
commit r11-6862-gd7e681fc3afff24a6279058cbb0b0dc4cd96be8c
Author: Martin Jambor
Date:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
--- Comment #8 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #7)
> looks strange, isn't DECL_HAS_IN_CHARGE_PARM_P (fn) false on all
> base constructors (as those are the abstract ctors with the in_charge
> parameter removed and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #16 from Xi Ruoyao ---
(In reply to Richard Biener from comment #15)
> So I see that
>
>242: 0 SECTION LOCAL DEFAULT UND
>
> and that's indeed broken (UND SECTION?) but ld complains that the SECTION
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
1 - 100 of 277 matches
Mail list logo
