[AMD Public Use]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Saturday, December 5, 2020 1:06 AM
> To: Uros Bizjak
> Cc: Kumar, Venkataramanan ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
> [CAUTION:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #7 from Jeffrey A. Law ---
If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
target type, it's a lot like a narrowing subreg in the RTL world.
I don't know what the semantics are for the widening case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
--- Comment #2 from Brad Bell ---
That fixed my test result.
Sorry I missed that.
Thanks.
On Wed, Dec 02, 2020 at 09:50:33PM -0500, Jason Merrill wrote:
> On 12/2/20 6:18 PM, Marek Polacek wrote:
> > In this testcase we are crashing trying to gimplify a switch, because
> > the types of the switch condition and case constants have different
> > TYPE_PRECISIONs.
> >
> > This started
verify_sequence_points uses verify_tree to recursively walk the
subexpressions of an expression, and while recursing, it also
keeps lists of expressions found after/before a sequence point.
For a large expression, the list can grow significantly. And
merge_tlist is at least N(n^2): for a list of
On Wed, Dec 02, 2020 at 09:01:48PM -0500, Jason Merrill wrote:
> On 12/2/20 6:18 PM, Marek Polacek wrote:
> > -fsanitize=vptr initializes all vtable pointers to null so that it can
> > catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That
> > means that evaluating a vtable reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98101
scott snyder changed:
What|Removed |Added
CC||s...@li-snyder.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Andrew Pinski changed:
What|Removed |Added
Host|Linux |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Bug ID: 98151
Summary: integer output gives different results with -O2 and
-O3
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
On 12/4/20 4:33 PM, Martin Sebor wrote:
I'm looking for a way to get the FUNCTION_DECL for the library
(i.e., non-built-in) form of a function given the corresponding
built-in DECL. Is there an API I can all with either the built
-in DECL or its code to get it in the middle end?
In C, what I'm
I've now merged trunk revision
918a5b84a2c51dc9d011d39461cc276e6558069d to the gccgo branch.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
--- Comment #2 from Nick Krempel ---
Realised it doesn't need C++20 and was able to repro back in gcc 6.1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
--- Comment #1 from Nick Krempel ---
The following slightly simpler code also repros the issue:
int main() {
[]()noexcept(({constexpr int&=1;}));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] |[10 Regression] Accessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:625e002396f7d0108f845bfba6a6f4f4fcadad05
commit r11-5756-g625e002396f7d0108f845bfba6a6f4f4fcadad05
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:43e84ce7d62be121445e17cc0ee009a81fb285d7
commit r11-5755-g43e84ce7d62be121445e17cc0ee009a81fb285d7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
Bug ID: 98150
Summary: Segfault from statement expression in lambda noexcept
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
I'm looking for a way to get the FUNCTION_DECL for the library
(i.e., non-built-in) form of a function given the corresponding
built-in DECL. Is there an API I can all with either the built
-in DECL or its code to get it in the middle end?
In C, what I'm looking for appears to be
Ping?
Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
>
> 2020-11-08 Samuel Thibault
>
> gcc/
> * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
> target (but not *-*-kfreebsd*-gnu |
This libgo patch updates the type descriptor name in the fieldtrack C
support code. We were using the old name, but nothing noticed because
it is a weak reference that is permitted to be nil, so that it works
with code that does not use the field tracking library. Bootstrapped
and ran Go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a95753214b55d21e5b44eeb098cccf88d44c94dd
commit r11-5752-ga95753214b55d21e5b44eeb098cccf88d44c94dd
Author: Jason Merrill
Date:
The check in do_class_deduction to handle passing one class placeholder
template parm as an argument for itself needed to be extended to also handle
equivalent parms from other templates.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/93083
* pt.c
On 12/4/20 4:33 PM, Patrick Palka wrote:
The re-normalization performed from diagnose_nested_requirement doesn't
always work because we may have already lost the necessary template
context that determines the set of in-scope template parameters used by
the nested-requirement. This leads to
On 12/4/20 4:33 PM, Patrick Palka wrote:
I've convinced myself to do away with the whole diagnose_requires_expr /
tsubst_requires_expr consolidation, since that part is just a pure
refactoring change and the added overloadedness of the flags is not
ideal. This simplifies the patch considerably.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #10)
> Seems like that, if nbyte <= MAX_CHUNK, we do not take account of the
> possibility of a short read.
Yes, that seems to be the better/right place.
Snapshot gcc-9-20201204 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20201204/
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:34e72e050bf4e23689af7061f6381b95339eb7fa
commit r9-9099-g34e72e050bf4e23689af7061f6381b95339eb7fa
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #2 from Brecht Sanders
---
Did a bit more digging...
Seems COMPILER_PATH uses ';' as separator on Windows, not ':'.
So besides the .exe issue parse_env_var() also needs to separate the list by a
different separator.
Something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #10 from Thomas Koenig ---
(In reply to anlauf from comment #9)
> The patch seems to regtest ok, but certainly needs some wider testing.
Actually, I think the bug is in io/unix.c:raw_read. That should take
care of repeating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:316a185ee29c9e6ec060762e76d25b64c60fd665
commit r10-9122-g316a185ee29c9e6ec060762e76d25b64c60fd665
Author: Harald Anlauf
On 12/4/20 2:55 PM, Mike Stump wrote:
> On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches
> wrote:
>> This patch fixes a handful of tests with non-unique names which confuse
>> the living hell out of compare_tests, particularly if one of two tests
>> [x]fail while the other is [x]pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98149
Bug ID: 98149
Summary: missing spelling hint for misspelled calls to member
functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches
wrote:
>
> This patch fixes a handful of tests with non-unique names which confuse
> the living hell out of compare_tests, particularly if one of two tests
> [x]fail while the other is [x]pass which compare_tests will flag as a
> regression
The re-normalization performed from diagnose_nested_requirement doesn't
always work because we may have already lost the necessary template
context that determines the set of in-scope template parameters used by
the nested-requirement. This leads to normalization producing atoms
that have
During satisfaction, the flag info.noisy() controls three things:
whether to diagnose ill-formed satisfaction (such as the satisfaction
value of an atom being non-bool or non-constant); whether to diagnose
unsatisfaction; and whether to bypass the satisfaction cache.
The flag turns out to be too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 49687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49687=edit
Untested patch (proof of concept)
Here's a possible patch that retries after short reads.
Not regtested.
On Thu, 3 Dec 2020, Jason Merrill wrote:
> On 12/3/20 9:24 AM, Patrick Palka wrote:
> > During satisfaction, the flag info.noisy() controls three things:
> > whether to diagnose fatal errors (such as the satisfaction value of an
> > atom being non-bool); whether to diagnose unsatisfaction; and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #6 from Andrew Macleod ---
and when the precision is different what? assume 0's for the missing bits?
If we allow and want that behaviour, we should change the documentation to
reflect that...
On 12/4/20 12:27 PM, Jakub Jelinek wrote:
Hi!
We currently incorrectly reject the first testcase, because
cxx_fold_indirect_ref_1 doesn't attempt to handle UNION_TYPEs.
As the second testcase shows, it isn't that easy, because I believe we need
to take into account the active member and prefer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96675
--- Comment #6 from Marek Polacek ---
(In reply to Giorgio Audrito from comment #5)
> I add that a very similar problem happens with -Wtype-limits, I found this
> minimal example:
>
> template
> struct foo {
> bool bar(unsigned y) {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #14 from Sergei Trofimovich ---
The gcc patch also fixes original liferea+webkit-gtk-2.28.4 crash. Thank you!
On 12/4/20 3:39 AM, Richard Biener wrote:
On Thu, Dec 3, 2020 at 10:46 PM Jeff Law via Gcc-patches
wrote:
On 12/3/20 10:53 AM, Jason Merrill via Gcc-patches wrote:
It looks cleaner if we can use a vec* directly as a range for the C++11
range-based 'for' loop, without needing to indirect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #13 from CVS Commits ---
The releases/gcc-10 branch has been updated by Hans-Peter Nilsson
:
https://gcc.gnu.org/g:ac2347289d4d8000a078b540b6c9c2c74bb33471
commit r10-9121-gac2347289d4d8000a078b540b6c9c2c74bb33471
Author:
> On Fri, Dec 4, 2020 at 6:50 PM Kumar, Venkataramanan
> wrote:
> >
> > [AMD Public Use]
> >
> > Hi Uros
> >
> > > -Original Message-
> > > From: Uros Bizjak
> > > Sent: Friday, December 4, 2020 2:30 PM
> > > To: Kumar, Venkataramanan
> > > Cc: gcc-patches@gcc.gnu.org; Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #36 from abebeos at lazaridis dot com ---
Created attachment 49686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49686=edit
Patch by Senthil Kumar Selvaraj, non-cc0-avr-backend
this should(!) be the final patch, derived from:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #12 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:eb79f4db49c5f5a807555e9d374524664eb537bf
commit r11-5749-geb79f4db49c5f5a807555e9d374524664eb537bf
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #5 from Jeffrey A. Law ---
The best way to think about V_C_E is that it's the same bits, just viewed in a
different type whereas a cast can do things like sign/zero extension,
truncation of floating point values to integers, etc).
From: Aaron Sawdey
This patch adds the first batch of patterns to support p10 fusion. These
will allow combine to create a single insn for a pair of instructions
that that power10 can fuse and execute. These particular ones have the
requirement that only cr0 can be used when fusing a load with a
On 11/24/20 11:39 AM, Martin Sebor wrote:
> On 11/24/20 10:44 AM, Andrew MacLeod wrote:
>> On 11/24/20 12:42 PM, Andrew MacLeod wrote:
>>> On 11/23/20 4:38 PM, Martin Sebor wrote:
On 11/21/20 6:26 AM, Andrew MacLeod wrote:
> On 11/21/20 12:07 AM, Jeff Law wrote:
>>
>> On
On Fri, 4 Dec 2020, Richard Biener via Gcc-patches wrote:
> Per rule changes to targets are allowed at any point per discretion of target
> maintainers. Heck, we even accept _new_ targets during stage3/4!
For architectures that are neither primary nor secondary targets, that's
definitely the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148
--- Comment #2 from Luis Machado ---
In my particular example, The DWARF information tells us the value is at the
following expression...
<11ac> DW_AT_GNU_call_site_value: 6 byte block: 8d ec 0 f6 4 2d
(DW_OP_breg29 (x29): 108;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148
--- Comment #1 from Luis Machado ---
You can find the sources for this testcase in binutils-gdb repo, at
gdb/testsuite/gdb.ada/O2_float_param.
On 12/2/20 6:06 PM, Jim Wilson wrote:
> On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches
> mailto:gcc-patches@gcc.gnu.org>> wrote:
>
>
> Kito's recent change to multilib handling seems to have exposed a
> latent
> mcore bug.
>
> The mcore 210 does not support little
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148
Bug ID: 98148
Summary: [AArch64] Wrong location expression for function entry
values
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
On 12/4/20 7:51 AM, Hans-Peter Nilsson via Gcc-patches wrote:
>> From: Martin Sebor via Gcc-patches
>> Date: Fri, 4 Dec 2020 01:49:51 +0100
>> On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote:
>>> Belatedly, here's an updated version, using Martin Sebor's
>>> suggested wording
On Fri, Dec 04, 2020 at 07:32:43PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
> wrote:
> > A splitter can *already* split to only one insn.
>
> Oh... brown paper bag time... I really don't know where and when I
> pick that info, since the docs indeed say:
At
On 12/4/20 4:45 AM, Richard Biener wrote:
> split_constant_offset currently gives up looking at ranges when
> dealing with possibly wrapping operations for looking through
> conversions when the downstream analysis does not yield a SSA name.
> That's overly conservative and we have a nice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> > On Fri, Dec 4, 2020 at 6:57 PM Jakub Jelinek wrote:
> > >
> > > On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > > > > I was trying that first,
On Fri, Dec 4, 2020 at 7:09 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> > No, I didn't want to burden you with the additional task - the patch
> > is OK as it is. I was just thinking out loud, as I remembered that
> > changing bt patterns to combine
‐‐‐ Original Message ‐‐‐
On Thursday, August 20, 2020 1:48 PM, Segher Boessenkool
wrote:
> On Thu, Aug 20, 2020 at 04:19:36PM +, GT wrote:
>
> > > Great! Please repost with what I already pointed out fixed, that
> > > explanation added, and working links to the documentation?
> >
>
Hi!
On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 6:57 PM Jakub Jelinek wrote:
> >
> > On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > > > I was trying that first, but it didn't work. Without the
> > > > > clobber it actually works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #13 from Jakub Jelinek ---
wrong-code should be now fixed, keeping open if Richard or Honza don't want to
improve handling of non-replaceable delete operators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:78c4a9feceaccf487516aa1eff417e0741556e10
commit r11-5748-g78c4a9feceaccf487516aa1eff417e0741556e10
Author: Jakub Jelinek
Date:
On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> No, I didn't want to burden you with the additional task - the patch
> is OK as it is. I was just thinking out loud, as I remembered that
> changing bt patterns to combine splitter regressed one testcase. IIRC
> combination of two
[AMD Public Use]
Hi Uros,
> -Original Message-
> From: Uros Bizjak
> Sent: Friday, December 4, 2020 11:31 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi...@ucw.cz)
>
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
On Fri, Dec 4, 2020 at 6:57 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > > I was trying that first, but it didn't work. Without the
> > > > clobber it actually works right, we don't have the rotate insn with the
> > > > masking and no clobber, so
On December 4, 2020 6:06:20 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, we shouldn't treat non-replaceable operator
>new/delete (e.g. with the placement new) as replaceable ones.
>
>There is some pending discussion that perhaps operator delete called
>from
>delete if not
From: Richard Biener
Sent: Friday, December 4, 2020 12:36 AM
To: David Blaikie
Cc: Alexander Yermolovich ; Jakub Jelinek ;
Mark Wielaard ; gcc@gcc.gnu.org ;
ikud...@accesssoftek.com ; mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
On Fri, Dec 4, 2020 at 6:50 PM Kumar, Venkataramanan
wrote:
>
> [AMD Public Use]
>
> Hi Uros
>
> > -Original Message-
> > From: Uros Bizjak
> > Sent: Friday, December 4, 2020 2:30 PM
> > To: Kumar, Venkataramanan
> > Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi...@ucw.cz)
> >
> >
On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > I was trying that first, but it didn't work. Without the
> > > clobber it actually works right, we don't have the rotate insn with the
> > > masking and no clobber, so in the end combiner does add the clobber there
> > > (or would
On Fri, Dec 4, 2020 at 6:42 PM Uros Bizjak wrote:
>
> On Fri, Dec 4, 2020 at 6:41 PM Jakub Jelinek wrote:
> >
> > On Fri, Dec 04, 2020 at 06:37:02PM +0100, Uros Bizjak wrote:
> > > > + "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1))
> > > > + == GET_MODE_BITSIZE (mode) - 1"
> > > > +
[AMD Public Use]
Hi Uros
> -Original Message-
> From: Uros Bizjak
> Sent: Friday, December 4, 2020 2:30 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi...@ucw.cz)
>
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96226, which changed state.
Bug 96226 Summary: Failure to optimize shift+not to rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ac2a6962b91128e700ee52db686dcdb2bab93790
commit r11-5747-gac2a6962b91128e700ee52db686dcdb2bab93790
Author: Jakub Jelinek
Date:
On Fri, Dec 4, 2020 at 6:41 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 06:37:02PM +0100, Uros Bizjak wrote:
> > > + "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1))
> > > + == GET_MODE_BITSIZE (mode) - 1"
> > > + [(set (match_dup 4) (match_dup 1))
> > > + (set (match_dup 0)
> >
On Fri, Dec 04, 2020 at 06:37:02PM +0100, Uros Bizjak wrote:
> > + "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1))
> > + == GET_MODE_BITSIZE (mode) - 1"
> > + [(set (match_dup 4) (match_dup 1))
> > + (set (match_dup 0)
> > + (any_rotate:SWI48 (match_dup 4)
> > +
On Fri, Dec 4, 2020 at 6:32 PM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, we can combine ~(1 << x) into -2 r<< x, but we give
> up in the ~(1 << (x & 31)) cases, as *3_mask* don't allow
> immediate operand 1 and find_split_point prefers to split (x & 31) instead
> of the constant.
>
Hi!
As mentioned in the PR, we can combine ~(1 << x) into -2 r<< x, but we give
up in the ~(1 << (x & 31)) cases, as *3_mask* don't allow
immediate operand 1 and find_split_point prefers to split (x & 31) instead
of the constant.
With these combine splitters we help combine decide how to split
Hi!
We currently incorrectly reject the first testcase, because
cxx_fold_indirect_ref_1 doesn't attempt to handle UNION_TYPEs.
As the second testcase shows, it isn't that easy, because I believe we need
to take into account the active member and prefer that active member over
other members,
Hi!
As mentioned in the PR, we shouldn't treat non-replaceable operator
new/delete (e.g. with the placement new) as replaceable ones.
There is some pending discussion that perhaps operator delete called from
delete if not replaceable should return some other fnspec, but can we handle
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:33be07be9e46f15b9556521050356c47460651ee
commit r11-5746-g33be07be9e46f15b9556521050356c47460651ee
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Christophe Lyon changed:
What|Removed |Added
Assignee|clyon at gcc dot gnu.org |unassigned at gcc dot
gnu.org
On Mon, 30 Nov 2020, Jeff Law via Gcc wrote:
> > Ping. Anybody got an opinion on the approach we should take?
> Could we set warning_threshold to a value to inhibit this behavior
> completely. It seems backwards to me that warnings have this effect.
Sounds like rate-limiting of some sort to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116
--- Comment #4 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:5a26d4a204c8a462a7e0a1a86bb2f25ecd470aad
commit r11-5745-g5a26d4a204c8a462a7e0a1a86bb2f25ecd470aad
Author: Nathan Sidwell
Date:
The changes reverted here are exposing an existing problem with alias
template comparisons. The typename_type changes are also incomplete,
possibly for similar reasons. It seems safer to revert them, fix the
underlying issue and then move forwards.
The testcases is adjusted to more robustly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96232
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
On 11/19/20, 10:52 AM, "Richard Earnshaw (lists)"
wrote:
> Having the same option have a completely different meaning would be even
> worse than not having the option at all. So no, that's a non-starter.
The attached patch 0001 removes --with-{cpu,arch,tune}-32.
Bootstrap and regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #1 from Brecht Sanders
---
Closer investigation shows the issue probably not (or not only) cause by the
.exe extension:
This is the error:
lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload.exe in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98141
--- Comment #1 from David Neill Asanza ---
Here are even shorter examples:
$ cat short01.f90
program short01
class(*), allocatable :: a, b, c
character(len=0) :: s
allocate(a, source=s) !! No problem
allocate(character(len=0)::b)
> On Dec 4, 2020, at 2:50 AM, Richard Biener wrote:
>
> On Thu, Dec 3, 2020 at 6:33 PM Richard Sandiford
> mailto:richard.sandif...@arm.com>> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>>> On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote:
Another issue is, in order to check
When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.
gcc/
PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
When SECTION_RETAIN is used, definitions marked with used attribute and
unmarked definitions are placed in a section with the same name. Instead
of issue an error:
[hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
-fdiagnostics-plain-output
c.c:2:49: error: ‘foo1’ causes a section type
When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like
int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;
since assembler will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98140
--- Comment #1 from Alexander Grund ---
It looks like this was fixed in 10.1 by this commit
https://github.com/gcc-mirror/gcc/commit/37e0df8a9be5a8232f4ccb73cdadb02121ba523f
However the codegen looks worse:
390: 20 00 9e c3 lfs
1 - 100 of 233 matches
Mail list logo
