On Mon, Aug 10, 2020 at 11:39:26PM -0300, Alexandre Oliva wrote:
> Erhm, I don't get why it's important that they be zeroed. It seems to
> me that restoring their original values, or setting them to random
> values, would be just as good defenses from having them set within the
In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96563
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-08-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96558
--- Comment #1 from Arseny Solokha ---
The internal loop can be simplified a bit:
do
{
long int lf = (long int) f1 ? h1 : 0;
ky += lf;
vh = lf | f1;
f1 = 1;
}
while (vh < (f1 ^ 2));
I'm trying to debug a problem cropping up in value range propagation.
Ironically I probably own an original copy 1995 copy of the paper it's
based on but that's not going to be much help since I'm lost in the
weeds. It's running on some optimization (my structure reorg
optimization) generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
--- Comment #1 from Arseny Solokha ---
testsuite/gcc.target/s390/20041109-1.c is another similar case which clobbers
SP on PowerPC. Maybe it's time to turn
warning: listing the stack pointer register 'sp' in a clobber list is
deprecated
into
Hi:
The issue is described in the bugzilla.
Bootstrap is ok, regression test for i386/x86-64 backend is ok.
Ok for trunk?
ChangeLog
gcc/
PR target/96350
* config/i386/i386.c (ix86_legitimate_constant_p): Return
false for ENDBR immediate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96551
--- Comment #1 from Hongtao.liu ---
For `vec_unpacku_float_hi_v16si` `vec_unpacku_float_lo_v16si`
---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index cf083ca28aa..2e60f596bc1 100644
--- a/gcc/config/i386/sse.md
+++
On Aug 7, 2020, Qing Zhao wrote:
> So, I believe that the call-used registers (especially those registers
> that pass parameters) need to be zeroed
> In order to mitigate the ROP attack.
Erhm, I don't get why it's important that they be zeroed. It seems to
me that restoring their original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96164
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96164
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:215927a736d21d8cff8baeb50f687911a00149b9
commit r10-8602-g215927a736d21d8cff8baeb50f687911a00149b9
Author: Patrick Palka
On Mon, 2020-08-10 at 13:51 +0300, Darius Galis wrote:
>
> I've found the following patch
> https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg00983.html, but it
> is not in the latest sources.
> Could please let me know why it was not added? I'm willing to do any
> rework necessary in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96534
--- Comment #3 from xlwu at synopsys dot com ---
(In reply to xlwu from comment #2)
> (In reply to Martin Liška from comment #1)
> > (In reply to xlwu from comment #0)
> > > since gcc9, the gcov did not support intermediate format and replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96563
Bug ID: 96563
Summary: Failure to optimize loop with condition to simple
arithmetic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96534
--- Comment #2 from xlwu at synopsys dot com ---
(In reply to Martin Liška from comment #1)
> (In reply to xlwu from comment #0)
> > since gcc9, the gcov did not support intermediate format and replace with
> > json format , our application
Now that dg-ice is available, let's try it out.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/88003
* g++.dg/cpp1y/auto-fn61.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/auto-fn61.C | 13 +
1 file changed, 13 insertions(+)
create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88003
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c01b22f12291691d1ce89f82211f00eae4398e18
commit r11-2642-gc01b22f12291691d1ce89f82211f00eae4398e18
Author: Marek Polacek
Date:
This patch by Clément Chigot changes the Go frontend and library to
use an eqtype function on AIX. The AIX linker is not able to merge
identical type descriptors in a single symbol if they are coming from
different object or shared object files. This results into several
pointers referencing the
Hi JOJO,
The patch looks good but the changlog lacks a leading text with commit
description.
On 8/10/20 4:17 PM, Jojo R wrote:
From: jojo
gcc/ChangeLog:
* config/csky/csky_opts.h (float_abi_type): New.
* config/csky/csky.h (TARGET_SOFT_FLOAT): New.
On Aug 10, 2020, at 2:30 PM, Marek Polacek via Gcc-patches
wrote:
>
> Thanks a lot. Here's the latest version of my patch, which only adds dg-ice
> at this point.
>
> So, um, OK?
Ok.
On Mon, Aug 10, 2020 at 05:16:15PM +0100, Richard Sandiford wrote:
> Senthil Kumar via Gcc-patches writes:
> > The wiki suggests using post-reload splitters, so that's the
> > direction I took, but I ran into an issue where split_insn
> > bails out early if RTX_FRAME_RELATED_P is true -
On Aug 7, 2020, at 6:16 AM, Nathan Sidwell wrote:
>
> On 8/6/20 8:01 PM, Mike Stump wrote:
>> On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote:
>>>
XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error)
PASS: g++.dg/foo.C -std=c++17 (test for excess errors)
Which one of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562
--- Comment #1 from Maxim Egorushkin ---
Correction:
Span f(unsigned char* p, unsigned char* q) {
return {p, static_cast(q - p)};
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562
Bug ID: 96562
Summary: Rather poor assembly generated for
copy-list-initialization in return statement.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
On Mon, Aug 10, 2020 at 08:58:54AM -0400, Nathan Sidwell wrote:
> On 8/10/20 4:48 AM, Richard Sandiford wrote:
> > Marek Polacek via Gcc-patches writes:
> > > > > > sure.
> > > > > > * develop patch
> > > > > > * run testsuite
> > > > > > * observe unexpected ICEs
> > > > > > * load g++.log into
On 8/10/20 2:18 PM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Patrick Palka wrote:
In the below testcase, semantic analysis of the requires-expressions in
the generic lambda must be delayed until instantiation of the lambda
because the requirements depend on the lambda's template arguments.
On Mon, Aug 10, 2020 at 09:48:06AM +0100, Richard Sandiford wrote:
> Marek Polacek via Gcc-patches writes:
> >> > > sure.
> >> > > * develop patch
> >> > > * run testsuite
> >> > > * observe unexpected ICEs
> >> > > * load g++.log into editor
> >> > > * ^sinternal comp
> >> > > * gets to first
Hi!
On Mon, Aug 10, 2020 at 05:47:53PM +0200, Hans-Peter Nilsson wrote:
> > All of this was added in https://gcc.gnu.org/g:64b8935d4809 , which also
> > adds the
> >
> > + /* Disallow this recombination if both new_cost and old_cost are
> > + greater than zero, and new_cost is greater than
On 8/10/20 2:08 PM, Andrew MacLeod wrote:
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
int_range is the type which allows for up to X subranges.
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
int_range is the type which allows for up to X subranges.
calculations will be merged to fit within X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #7 from Martin
On 8/10/20 2:46 PM, Martin Sebor wrote:
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ //
>>
>>> If so, I am okay with name “call-clobbered” if this name sounds better.
>>
>> It's more obvious, at least to me.
In the current option list of GCC:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96561
Bug ID: 96561
Summary: missing warning for buffer overflow with negative
offset
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Gentle reminder, this time with tests.
I've added one for list::remove cause I think there was none, for
forward_list we had remove_freed.cc.
I added
// { dg-options "-g -O0" }
in the new tests otherwise it doesn't fail, that's life with UB. I know
that it can pass also with those options.
"Stubbs, Andrew" writes:
> Is GET_INNER_MODE valid for scalers though?
Yeah, GET_MODE_INNER (x) == x for scalars. That makes GET_MODE_INNER
useful for stripping vectorness or complexness without having to check
for them first. It's also useful when working out what the valid shift
ranges are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
On Thu, 6 Aug 2020, Patrick Palka wrote:
> On Wed, 5 Aug 2020, Jason Merrill wrote:
>
> > On 8/4/20 8:00 PM, Patrick Palka wrote:
> > > On Tue, 4 Aug 2020, Patrick Palka wrote:
> > >
> > > > In the testcase below, we never substitute function-template arguments
> > > > into f15's
On 8/10/20 11:50 AM, Andrew MacLeod wrote:
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+
On 8/9/20 10:03 PM, Peter Bergner wrote:
> PR96506 shows a problem where we ICE on illegal usage, namely using MMA
> types for function arguments and return values. The solution is to flag
> these illegal usages as errors early, before we ICE.
>
> The patch below is currently bootstrapping and
On 10 Aug 2020 17:23, Richard Sandiford wrote:
Andrew Stubbs writes:
> On 06/08/2020 04:54, Richard Sandiford wrote:
>>> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
>>> index f9b0e9714d9..d7067989ad7 100644
>>> --- a/gcc/emit-rtl.c
>>> +++ b/gcc/emit-rtl.c
>>> @@ -947,6 +947,11 @@
On Mon, Aug 10, 2020 at 1:49 PM Jonathan Wakely wrote:
>
> On 10/08/20 09:45 -0400, Andres Rodriguez wrote:
> >*ping*
>
> As it says at https://gcc.gnu.org/lists.html all patches for libstdc++
> need to be sent to the libstdc++ mailing as well as the gcc-patches
> list. Otherwise I won't see
On Mon, 10 Aug 2020, Patrick Palka wrote:
> In the below testcase, semantic analysis of the requires-expressions in
> the generic lambda must be delayed until instantiation of the lambda
> because the requirements depend on the lambda's template arguments. But
> tsubst_requires_expr does
On 10/08/20 13:24 +0100, Jonathan Wakely wrote:
The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.
libstdc++-v3/ChangeLog:
PR libstdc++/94681
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:5b065f0563262a0d6cd1fea8426913bfdd841301
commit r11-2638-g5b065f0563262a0d6cd1fea8426913bfdd841301
Author: Jonathan Wakely
Date:
On Mon, Aug 10, 2020 at 05:29:49PM +, GT wrote:
> > For PowerPC, if all you want to support is b which requires VSX, then the
> > right thing is for !TREE_PUBLIC functions return 0 if !TARGET_VSX and
> > otherwise set vecsize_mangle to 'b' and in the end return 1, for exported
> > functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #7 from Peter Bergner ---
(In reply to seurer from comment #6)
> That changed the test to unsupported on the p8 where it had failed
> previously.
[snip]
> # of unsupported tests1
That is what I would expect on a
On Mon, Aug 10, 2020 at 03:05:26PM +0200, Aldy Hernandez wrote:
> For the record. The final patch (below) passes tests on ppc64le for both
> trunk, and the ranger-staging branch with ranger enabled.
>
> Aldy
>
> gcc/ChangeLog:
>
> * ipa-fnsummary.c (evaluate_conditions_for_known_args):
>
Yes, the goal is that anything that may take multi ranges be rewritten to
use an irange * and use the API exclusively. Then when multi ranges are
passed down eventually, things will work transparently.
Aldy
On Mon, Aug 10, 2020, 19:50 Andrew MacLeod wrote:
> On 8/10/20 12:35 PM, Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96560
Bug ID: 96560
Summary: Substitution triggers compile-time error when it
shouldn't
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #8 from Jörn Heusipp ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jörn Heusipp from comment #5)
> > and just pray and hope that libstdc++ will not change its non-conforming
> > SFINAE-using implementation details
On 8/10/20 12:35 PM, Martin Sebor via Gcc-patches wrote:
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into
On 10/08/20 09:45 -0400, Andres Rodriguez wrote:
*ping*
As it says at https://gcc.gnu.org/lists.html all patches for libstdc++
need to be sent to the libstdc++ mailing as well as the gcc-patches
list. Otherwise I won't see them, and everybody else will ignore them.
On Tue, Aug 4, 2020 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #10 from Marc Glisse ---
We now generate just
sqrtpd %xmm0, %xmm0
for 2 and 4,
sqrtpd (%rdi), %xmm0
for 3, and
movupd (%rdi), %xmm0
sqrtpd %xmm0, %xmm0
for 1 (for alignment reasons I guess, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96559
Bug ID: 96559
Summary: Wrong code with -march=z900 -mtune=z9-109
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
‐‐‐ Original Message ‐‐‐
On Friday, August 7, 2020 4:59 PM, Jakub Jelinek wrote:
> On Fri, Aug 07, 2020 at 08:35:52PM +, Bert Tenjy via Gcc-patches wrote:
>
> > The document describing POWER Architecture Vector Function interface is
> > tentatively at:
> >
On Mon, Aug 10, 2020 at 06:58:52PM +0200, Richard Biener wrote:
> We want to construct / destruct on push/pop, not on allocation.
> We also want to use std::move upon reallocation (but then we can't use
> realloc, can we?)
I guess so, but we could stop using xrealloc or ggc_realloc only for
Hi,
in the code about DO loop warning I recently introduced, there was
a hidden NULL pointer dereference found by Jürgen Reuter and fixed
as obvious and simple in r11-2636.
Fix NULL pointer dereference in doloop_contained_function_call.
Thanks to Jürgen for the bug report and to Dominique for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #7 from Jonathan Wakely ---
btw in practice the fact this is SUSPENDED today is absolutely no different to
the status yesterday. It didn't work in GCC yesterday and it doesn't work
today. The only change is I've publicly stated my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #6 from CVS Commits ---
The master branch has been updated by Thomas Kथà¤nig :
https://gcc.gnu.org/g:a5da50ed65a835dc1ed6179e3f2b6164fd6e4969
commit r11-2636-ga5da50ed65a835dc1ed6179e3f2b6164fd6e4969
Author: Thomas Koenig
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #6 from Jonathan Wakely ---
(In reply to Jörn Heusipp from comment #5)
> > Status: SUSPENDED
>
> Well, coming from bug 95642, which has been marked as a duplicate of this
> bug, this is *very* disappointing.
>
>
> The C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96558
Bug ID: 96558
Summary: [11 Regression] ICE in extract_constrain_insn, at
recog.c:2195 (error: insn does not satisfy its
constraints)
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
On August 10, 2020 3:51:28 PM GMT+02:00, Jakub Jelinek via Gcc-patches
wrote:
>On Mon, Aug 10, 2020 at 02:57:31PM +0200, Aldy Hernandez wrote:
>> > I think it would be nice to see e.g. in -fdump-tree-gimple dump
>> > on ipa-fnsummary.c what value_range ctors does it call for the
>auto_vec and
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482
--- Comment #6 from Yevhenii Kolesnikov ---
(In reply to Jan Hubicka from comment #4)
> that patch makes ccp to actually use the bit info ipa-cp determines. Before
> we used it only to detect pointer alignments if I remember correctly. So it
>
On Sat, Aug 08, 2020 at 03:33:51PM +0200, Thomas König wrote:
> Hi Michael,
>
> I have shortened the distribution list somewhat for the Fortran-relevant
> parts.
>
> >I want to discuss changes that I think we need to make across the open source
> >toochain to allow us to change the long double
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/26/20 11:41 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
On 7/16/20 4:53 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96497
--- Comment #4 from Jakub Jelinek ---
Should be fixed for 11, I think we should backport to 10.3 too eventually.
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/26/20 11:42 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
On 7/13/20 6:05 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548786.html
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/551152.html
On 7/31/20 5:55 PM, Martin Sebor wrote:
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #5 from Jörn Heusipp ---
> Status: SUSPENDED
Well, coming from bug 95642, which has been marked as a duplicate of this bug,
this is *very* disappointing.
The C++17 standard absolutely clearly specifies that the constructor is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #3 from Jürgen Reuter ---
Created attachment 49038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49038=edit
Final reproducer, some 70 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96557
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #6 from seurer at gcc dot gnu.org ---
That changed the test to unsupported on the p8 where it had failed previously.
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
Hi,
> On Aug 7, 2020, at 5:59 PM, Segher Boessenkool
> wrote:
>
>> From my understanding (I am not a security expert though), this patch should
>> serve two purpose:
>>
>> 1. Erase the registers upon return to avoid information leak;
>
> But only some of the registers.
All the call-used
On 8/10/20 5:47 AM, Aldy Hernandez wrote:
On 8/6/20 9:30 PM, Martin Sebor wrote:
On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote:
+ // Remove the unknown parts of a multi-range.
+ // This will transform [5,10][20,MAX] into [5,10].
Is this comment correct? Wouldn't this result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96101
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96557
Bug ID: 96557
Summary: Diagnostics: Can you tell me why it's not a constant
expression?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Andrew Stubbs writes:
> On 06/08/2020 04:54, Richard Sandiford wrote:
>>> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
>>> index f9b0e9714d9..d7067989ad7 100644
>>> --- a/gcc/emit-rtl.c
>>> +++ b/gcc/emit-rtl.c
>>> @@ -947,6 +947,11 @@ validate_subreg (machine_mode omode, machine_mode
>>> imode,
Senthil Kumar via Gcc-patches writes:
> Hi,
>
> I'm working on converting the AVR backend to MODE_CC, following
> the steps described for case #2 in the CC0 transition wiki page,
> and I've implemented the first three bullet
> points
In the below testcase, semantic analysis of the requires-expressions in
the generic lambda must be delayed until instantiation of the lambda
because the requirements depend on the lambda's template arguments. But
tsubst_requires_expr does semantic analysis even during regeneration of
the lambda,
On 7/23/20 3:29 PM, Jeff Law wrote:
>>> What's driving this change?
>>
>> Peter noticed IRA allocates stuff to volatile registers while it is life
>> through a call, and then LRA has to correct that, not optimal.
> I can't recall if IRA or LRA handles the need to save them to the stack, but
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #16 from Jonathan Wakely ---
When you choose RESOLVED you can pick various types of resolution, FIXED,
INVALID, DUPLICATE, MOVED, WORKSFORME etc.
> From: Segher Boessenkool
> Date: Fri, 17 Jul 2020 02:05:19 +0200
> On Tue, Jul 14, 2020 at 04:33:42PM -0500, Segher Boessenkool wrote:
> > > If combine only did lower-cost combinations (perhaps with
> > > Richard Sandifords lower-size-when-tied suggestion), I guess
> > > this wouldn't happen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96543
--- Comment #3 from Jonathan Wakely ---
No, it's fine. I've categorized it as a diagnostic bug, i.e. a bug in a
warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
--- Comment #6 from Jonathan Wakely ---
Thanks, I thought this might reveal some new issues :-)
I'll fix it asap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #2 from Jürgen Reuter ---
Created attachment 49037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49037=edit
2nd reproducer, single file, shortening further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96497
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5c64df80df274c753bfc8415bd902e1180e76f6a
commit r11-2635-g5c64df80df274c753bfc8415bd902e1180e76f6a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last
(Back from vacation, found that this had an unanswered question,
quoted last.)
> From: Segher Boessenkool
> Date: Tue, 14 Jul 2020 23:58:05 +0200
> Hi!
>
> On Mon, Jul 06, 2020 at 04:01:54AM +0200, Hans-Peter Nilsson via Gcc-patches
> wrote:
> > Most comments, including the second sentence in
On 8/8/20 5:23 AM, Jakub Jelinek wrote:
Hi!
The following valid testcase is rejected, because cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling
Christophe Lyon writes:
> On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
> wrote:
>>
>> The stack_protect_test patterns were leaving the canary value in the
>> temporary register, meaning that it was often still in registers on
>> return from the function. An attacker might therefore have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #1 from Jürgen Reuter ---
Created attachment 49036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49036=edit
First reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Bug ID: 96556
Summary: [11.0 regression] ICE via segmentation violation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Bug ID: 96555
Summary: "template argument involves template parameter(s)"
with dot or arrow operator in partial specialization
Product: gcc
Version: 11.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #3 from
Hi folks,
long time, no see. I was asked by Damian to do some Coarray stuff in gfortran
so here is the first step on fixing a bug. The issue at hand is, that the
coarray handling is not propagated correctly and later on the coarray-token
not generated/retrieved from the correct position leading
1 - 100 of 224 matches
Mail list logo