https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97277
Bug ID: 97277
Summary: Lambda in fold expressions capture arguments are
default initialized
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
--- Comment #1 from David Weese ---
The README.txt also contains the steps to reproduce the pwm.s assemblies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
Bug ID: 97276
Summary: A whole if-block is ignored by avr-gcc 9.3.0
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
On 10/2/20 4:44 PM, Alejandro Colomar wrote:
I know, they aren't perfect.
But they are still very useful,
and don't see a good reason to not document them.
"aren't perfect" is an understatement
More important, lots of things in GNU C are useful but shouldn't be documented
in the man
Hi Paul,
On 2020-10-02 22:19, Paul Eggert wrote:
> On 10/2/20 1:03 PM, Alejandro Colomar wrote:
>> I know it's not in stdint,
>> but I mean that it behaves as any other stdint type.
With caveats, of course.
>
> It doesn't. There's no portable way to use scanf and printf on it.
I didn't need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96331
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #20 from Sergei Trofimovich ---
(In reply to Martin Jambor from comment #18)
> I proposed the patch on the mailing list (I guess I should put Martin's name
> at least to the testsuite ChangeLog and probably to both):
>
>
On Linux/x86_64,
7ee1c0413e251ff0b6a6d526209ef038b9835320 is the first bad commit
commit 7ee1c0413e251ff0b6a6d526209ef038b9835320
Author: Nathan Sidwell
Date: Fri Oct 2 11:13:26 2020 -0700
c++: Hash table iteration for namespace-member spelling suggestions
caused
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97014
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95808
Jonathan Wakely changed:
What|Removed |Added
Keywords|wrong-code |accepts-invalid
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95806
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Hi Olivier,
On Thu, Oct 01, 2020 at 11:30:55AM +0200, Olivier Hainque wrote:
> This change reworks CPP_BUILTINS_SPEC for powerpc-vxworks to
> prepare for the upcoming addition of 32 and 64 bit ports for
> VxWorks 7r2.
Cool, looking forward to it!
Your attachment is not quotable (it is
Hi.
Thanks for the review.
I attached the updated patch file.
I don't have a copyright assignment, but I'll look at that.
On Fri, Oct 02, 2020 at 04:24:26PM -0400, David Malcolm wrote:
On Fri, 2020-10-02 at 16:17 -0400, David Malcolm wrote:
On Tue, 2020-09-01 at 21:01 -0400, Antoni Boucher via
Snapshot gcc-9-20201002 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20201002/
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
On 29/09/20 19:35 +0300, Ville Voutilainen via Libstdc++ wrote:
On Tue, 29 Sep 2020 at 14:20, Jonathan Wakely wrote:
I think this is what we want:
template
constexpr inline __same_types = (is_same_v<_Tp, _Types> && ...);
is_same_v is very cheap, it uses the built-in directly, so you
On 01/10/20 03:29 +, sotrdg sotrdg via Libstdc++ wrote:
From fb8d644a4c315058af141a3e84fcc083d665c8b9 Mon Sep 17 00:00:00 2001
From: ejsvifq_mabmip
Date: Wed, 30 Sep 2020 23:26:47 -0400
Subject: [PATCH] Fix a long term performance issue of fstream on Windows since
MSVCRT defines BUFSIZ as
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dr.duncan.p.simpson at gmail dot com
Target Milestone: ---
Host: amd64-linux-gnu
Target: aarch64-linux-gnu
Build: 11.0.0 20201002
Created attachment 49303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #19 from Bill Long ---
On an ia64 Intel target that does not support x87 floating point, it seems that
having IEEE_SUPPORT_DATATYPE (1._10) return .true. is as error. If that is
fixed, will the rest of the issue fall into place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #2 from Bill Long ---
Any update on a fix for this? (The original customer is asking.)
This fixes a linker error for older ARM cores without 64-bit atomics.
I think the { dg-add-options libatomic } is no longer needed, but it's
harmless to keep it there.
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic_float/value_init.cc: Use float
instead of double so that
On 26/09/20 20:42 +0100, Jonathan Wakely wrote:
Glibc 2.32 adds a global variable that says whether the process is
single-threaded. We can use this to decide whether to elide atomic
operations, as a more precise and reliable indicator than
__gthread_active_p.
This means that guard variables for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719
--- Comment #5 from Nikhil Benesch ---
Ah, sorry, I was imprecise before. By “system gmp” I meant a gmp installed by
Homebrew, as in `brew install gmp`.
I believe this is a third option from the two you listed. (At least, it is on
non-macOS
On 10/1/20 5:49 PM, Marek Polacek wrote:
No one is interested in the mangled name of the C++20 template parameter
object for a class NTTP. So instead of printing
required for the satisfaction of ‘positive’ [with T =
X<::_ZTAXtl5ratioLin1ELi2EEE>]
let's print
required for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
The generation of the library call for the MINLOC/MAXLOC intrinsic
mishandled the optional KIND argument and resulted in a bad
argument list passed to the library function. The fix is obvious.
Regtested on x86_64-pc-linux-gnu.
OK for master? As it technically wrong code, OK for backports?
Hi Paul,
On 2020-10-02 22:14, Paul Eggert wrote:
> On 10/2/20 11:38 AM, Alejandro Colomar wrote:
>
>> .I void *
>>
>> renders with a space in between.
>
> That's odd, as "man(7)" says "All of the arguments will be printed next
> to each other without intervening spaces". I'd play it safe and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719
--- Comment #4 from Iain Sandoe ---
(In reply to Nikhil Benesch from comment #3)
> For posterity, I could reproduce this issue even with the suggested
> `./configure` arguments, i.e., excluding the `--enable-multilib` option.
> I worked around
On Fri, 2020-10-02 at 16:17 -0400, David Malcolm wrote:
> On Tue, 2020-09-01 at 21:01 -0400, Antoni Boucher via Jit wrote:
> > Hello.
> > This WIP patch implements new reflection functions in the C API as
> > mentioned in bug 96889.
> > I'm looking forward for feedbacks on this patch.
> > It's
On 10/2/20 1:03 PM, Alejandro Colomar wrote:
I know it's not in stdint,
but I mean that it behaves as any other stdint type.
It doesn't. There's no portable way to use scanf and printf on it. You can't
reliably convert it to intmax_t. It doesn't have the associated _MIN and _MAX
macros that
On Tue, 2020-09-01 at 21:01 -0400, Antoni Boucher via Jit wrote:
> Hello.
> This WIP patch implements new reflection functions in the C API as
> mentioned in bug 96889.
> I'm looking forward for feedbacks on this patch.
> It's WIP because I'll probably add a few more reflection functions.
>
On 10/2/20 11:38 AM, Alejandro Colomar wrote:
.I void *
renders with a space in between.
That's odd, as "man(7)" says "All of the arguments will be printed next to each
other without intervening spaces". I'd play it safe and quote the arg anyway.
> %p works with any object pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719
Nikhil Benesch changed:
What|Removed |Added
CC||nikhil.benesch at gmail dot com
---
Hi Paul,
On 2020-10-02 21:54, Paul Eggert wrote:
> On 10/2/20 12:01 PM, Alejandro Colomar wrote:
>> If you propose not to document the stdint types either,
>
> This is not a stdint.h issue. __int128 is not in stdint.h and is not a
> system data type in any real sense; it's purely a compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested fix:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 3b3bd8629cd..9e9898c2bbf 100644
--- a/gcc/fortran/trans-intrinsic.c
+++
On 10/2/20 12:01 PM, Alejandro Colomar wrote:
If you propose not to document the stdint types either,
This is not a stdint.h issue. __int128 is not in stdint.h and is not a system
data type in any real sense; it's purely a compiler issue. Besides, do we start
repeating the GCC manual too,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about generic function parameters and
return value
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul
Signed-off-by: Alejandro Colomar
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
Hi Michael,
Here I added a wfix fixing some wording issues and a few typos
spotted by Paul and Jonathan in the (many) threads.
As previously, it is squashed into a single commit.
Thanks again for those who reviewed the patch!
BTW, for those who don't have a local repo of the man-pages,
below
Here's the patch to remove DECL_ANTICIPATED, and with it hiddenness is
managed entirely in the symbol table. Sadly I couldn't get rid of the
actual field without more investigation -- it's repurposed for
OMP_PRIVATIZED_MEMBER. It looks like a the VAR-related flags in
lang_decl_base are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97274
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi Paul,
On 2020-10-02 19:52, Paul Eggert wrote:
Why describe __int128_t in these man pages at all? __int128_t is not a
property of either the kernel or of glibc, so it's out of scope.
Well, as I see it, [unsigned] __int128 is as good as [u]int64_t.
They are part of the C interface in Linux.
Hi!
On Fri, Oct 02, 2020 at 04:41:05PM +0930, Alan Modra wrote:
> This moves an #ifdef block of code from calls.c to
> targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000,
> define REG_PARM_STACK_SPACE or OUTGOING_REG_PARM_STACK_SPACE macros
> that might vary depending on the
Hi Paul,
On 2020-10-02 18:53, Paul Eggert wrote:
> On 10/2/20 8:14 AM, Alejandro Colomar wrote:
>
>> +.I void *
>
> GNU style is a space between "void" and "*", so this should be '.I
> "void\ *"', both here and elsewhere. The backslash prevents a line break.
.I void *
renders with a space in
For 'no such binding' errors, we iterate over binding levels to find a
close match. At the namespace level we were using DECL_ANTICIPATED to
skip undeclared builtins. But (a) there are other unnameable things
there and (b) decl-anticipated is about to go away. This changes the
namespace
Hi Eric,
On Fri, Oct 02, 2020 at 10:26:24AM +0200, Eric Botcazou wrote:
> > Don't call it "mask" please: *all* of our basic rotate instructions
> > already have something called "mask" (that is the "m" in "rlwnm" for
> > example; and "rotlw d,a,b" is just an extended mnemonic for
> > "rlwnm
Why describe __int128_t in these man pages at all? __int128_t is not a property
of either the kernel or of glibc, so it's out of scope.
On Fri, Oct 02, 2020 at 05:33:13PM +, Joseph Myers wrote:
> On Fri, 2 Oct 2020, Tobias Burnus wrote:
>
> > However, this flag can be added into the offload-target's libgomp.spec,
> > which avoids all kind of issues. That's what this patch now does.
> >
> > I tested it with x86_64-gnu-linux
On Fri, 2 Oct 2020, Tobias Burnus wrote:
> However, this flag can be added into the offload-target's libgomp.spec,
> which avoids all kind of issues. That's what this patch now does.
>
> I tested it with x86_64-gnu-linux w/o + w/ nvptx-none. Result:
> * x86_64-gnu-linux's libgomp.spec:
>
On Fri, Oct 02, 2020 at 10:46:12AM +0200, Aldy Hernandez wrote:
> On 10/2/20 2:17 AM, David Edelsohn wrote:
> >On Thu, Oct 1, 2020 at 8:02 PM Andrew MacLeod wrote:
> >Thanks for investigating. And I definitely am not suggesting that you
> >delay the great progress on Ranger to flatten and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97274
--- Comment #2 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #1)
> The linker issues the warning, because the symbol in glibc is annotated to
> cause a warning. It has nothing to do with GCC.
Hmm. There's still a question of
On 06/09/2020 17.23, Armin Brauns wrote:
> There were some differences between the actual code in do_spec_1, its
> source comment, and the documentation in doc/invoke.texi. These should
> now be resolved.
PING: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553321.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97274
--- Comment #1 from Jonathan Wakely ---
The linker issues the warning, because the symbol in glibc is annotated to
cause a warning. It has nothing to do with GCC.
The patch switches to a hybrid EVRP pass which utilizes both the Ranger
and the classic EVRP pass.
it introduces a new undocumented option:
-fevrp-mode= which can be one of the following options
evrp-only : This is classic EVRP mode, identical to whats in trunk now.
rvrp-only : This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97274
Bug ID: 97274
Summary: Need ability to ensure no warning about tmpnam
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
This is the ranger component that pulls all the others bits together.
Its API is basically the range_query we've already pushed into the
compiler. The main ones a client are likely to use are
bool range_of_stmt (irange , gimple *, tree name = NULL)
bool range_of_expr (irange , tree name,
These are the various caches used by the ranger.
- non-null-ref : Tracks non-null pointer dereferences in blocks so we
can properly calculate non-null pointer ranges
- on entry cache : Block ranges tracks the calucalted values sof
ssa-names on entry to each basic block.
- global cache:
This is the true core of the ranger.
The GORI (Generates Outgoing Range Information) engine contains all the
smarts to utilize the functionality provided via range-ops in order to
calculate outgoing ranges on an edge, based on the control flow at the exit.
It functions *only* at the basic
On 10/2/20 2:10 AM, David Laight wrote:
> Also, you should
> warn that because one can convert from any pointer type to void * and
> then to any other pointer type, it's a deliberate hole in C's
> type-checking.
That isn't what the C standard says at all.
What is says is that you can
This file produces constant edge ranges. It provides a class which can
be instantiated and will return the range on any edge.
This was originally suppose to be trivial, but switches mucked that up :-)
There are 2 basic expressions that can result ina constant range on an
edge:
Note there is
This patch set contains the various components that make up a ranger.
Ranger files are prefixed by "gimple-range".
gimple-range-cache.{h,cc} : Various caches used by the ranger.
gimple-range-edge.{h,cc} : Outgoing edge range calculations,
particularly switch edge ranges.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97268
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Where to start?
This is the culmination of numerous years work on the ranger for
generating accurate on-demand ranges in GCC.
There are 2 patch sets as a part of this submission
1) The ranger & Enhancements to EVRP
3) Other passes converted to Ranger
There is still some missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Known to work|
ctor_omit_inherited_parms was being somewhat abused. What I'd missed
is that it checks for a base-dtor name, before proceeding with the
check. But we ended up passing it that during cloning before we'd
completed the cloning. It was also using DECL_ORIGIN to get to the
in-charge ctor, but we
On 10/2/20 8:14 AM, Alejandro Colomar wrote:
+.I void *
GNU style is a space between "void" and "*", so this should be '.I "void\ *"',
both here and elsewhere. The backslash prevents a line break.
+Conversions from and to any other pointer type are done implicitly,
+not requiring casts at
Richard Biener writes:
> This introduces a permute optimization phase for SLP which is
> intended to cover the existing permute eliding for SLP reductions
> plus handling commonizing the easy cases.
>
> It currently uses graphds to compute a postorder on the reverse
> SLP graph and it handles all
From: Thomas Rodgers
Updated patch incorporating latest feedback (revised).
Add support for -
* atomic_flag::wait/notify_one/notify_all
* atomic::wait/notify_one/notify_all
* counting_semaphore
* binary_semaphore
* latch
libstdc++-v3/ChangeLog:
* include/Makefile.am
> On Oct 1, 2020, at 11:20 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi, Richard,
>>
>> To answer the question, which registers should be included in “ALL”.
>> I studied X86 hard register set in more details. And also consulted with
>> H.J.Lu, And found:
>>
>> In the
> On Oct 2, 2020, at 10:15 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>>
>>> Going back to the default hook, I guess one option is:
>>>
>>> rtx zero = CONST0_RTX (reg_raw_mode[regno]);
>>> rtx_insn *insn = emit_insn (gen_rtx_SET (regno_reg_rtx[regno], zero));
>>> if
Signed-off-by: Alejandro Colomar
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
Qing Zhao writes:
>>
>> Going back to the default hook, I guess one option is:
>>
>> rtx zero = CONST0_RTX (reg_raw_mode[regno]);
>> rtx_insn *insn = emit_insn (gen_rtx_SET (regno_reg_rtx[regno], zero));
>> if (!valid_insn_p (insn))
>> sorry (…);
>
> “Sorry” here will tell the user
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about generic function parameters and
return value
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul
Hi Michael,
I'm sorry I forgot to increase the version count.
And given there are conversations continuing in old threads,
you may mix them easily. I'm a bit lost in the emails too.
I'll resend the latest patch (identically) as v4
(there's no v3, but this is the 4th time or so, so let's call it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
--- Comment #11 from Tobias Burnus ---
Cross ref: the submitted patch is at
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555352.html
> -Original Message-
> From: Alex Coplan
> Sent: 02 October 2020 15:49
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: [PATCH][GCC 10] arm: Add support for Neoverse N2 CPU
>
> This patch backports the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
Bug ID: 97273
Summary: Strange behaviour of unordered_set when vector is
included (i686)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
This patch backports the AArch32 support for Arm's Neoverse N2 CPU to
GCC 8.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for GCC 8 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-n2): New.
* config/arm/arm-tables.opt:
This patch backports the AArch32 support for Arm's Neoverse N2 CPU to
GCC 9.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for GCC 9 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-n2): New.
* config/arm/arm-tables.opt:
This patch backports the AArch32 support for Arm's Neoverse N2 CPU to
GCC 10.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for GCC 10 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-n2): New.
* config/arm/arm-tables.opt:
> -Original Message-
> From: Alex Coplan
> Sent: 02 October 2020 15:41
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: [PATCH] arm: Add missing part number for Neoverse V1
>
> This patch adds vendor and part
This patch adds vendor and part numbers which were missing from the
initial entry for Neoverse V1 in AArch32 GCC.
OK for trunk and backports to GCC 10 and 9?
I believe GCC 8 handles these differently so that will need fixing
separately.
Thanks,
Alex
---
gcc/ChangeLog:
*
Hi all,
This GCC 8 patch duplicates the Cortex-A72 tuning struct that's currently used
for Neoverse V1 and AARCH64_EXTRA_TUNE_PREFER_ADVSIMD_AUTOVEC tune flag to
prefer Advanced SIMD over SVE autovectorisation.
Bootstrapped and tested on GCC 8, pushing to the branch.
Thanks,
Kyrill
gcc/
Hi all,
This GCC 9 patch duplicates the Neoverse N1 tuning struct that's currently used
for Neoverse V1 and AARCH64_EXTRA_TUNE_PREFER_ADVSIMD_AUTOVEC tune flag to
prefer Advanced SIMD over SVE autovectorisation.
Bootstrapped and tested on GCC 9, pushing to the branch.
Thanks,
Kyrill
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
--- Comment #8 from Ev Drikos ---
Created attachment 49301
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49301=edit
test-case with a module
Hello again,
Here is another test-case with a module.
It's a question if this should fail or
>
> Going back to the default hook, I guess one option is:
>
> rtx zero = CONST0_RTX (reg_raw_mode[regno]);
> rtx_insn *insn = emit_insn (gen_rtx_SET (regno_reg_rtx[regno], zero));
> if (!valid_insn_p (insn))
> sorry (…);
“Sorry” here will tell the user that the implementation on
Hi all,
This patch adds a Neoverse V1-specific tuning struct that currently is just a
deduplication of the N1 struct it was using before and specifying the SVE width.
This will allow us to tweak Neoverse V1 things in the future as needed.
Bootstrapped and tested on aarch64-none-linux-gnu.
On Fri, Oct 02, 2020 at 10:46:33AM +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 03:24:08PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> > > On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze
On 10/2/20 9:26 AM, Martin Liška wrote:
Yes, you simply get all sorts of conditions that hold when a
condition is
true, not just those based on the SSA name you put in. But it occured
to me that the use-case is somewhat different - for switch-conversion
you want to know whether the test
Hi Joe,
> -Original Message-
> From: Gcc-patches On Behalf Of Joe
> Ramsay
> Sent: 19 August 2020 17:12
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v2][GCC] arm: Add +nomve and +nomve.fp options to -
> mcpu=cortex-m55
>
> From: Joe Ramsay
>
> Hi all,
>
> This patch rearranges
Hi Joe,
> -Original Message-
> From: Gcc-patches On Behalf Of Joe
> Ramsay
> Sent: 13 August 2020 14:16
> To: Joe Ramsay ; gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Remove coercion from scalar argument to vmin &
> vmax intrinsics
>
> From: Joe Ramsay
>
> Hi,
>
> This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
Bug ID: 97272
Summary: Wrong answer from MAXLOC with character arg
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
> On Oct 1, 2020, at 11:20 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi, Richard,
>>
>> To answer the question, which registers should be included in “ALL”.
>> I studied X86 hard register set in more details. And also consulted with
>> H.J.Lu, And found:
>>
>> In the
On Fri, 2 Oct 2020, Jan Hubicka wrote:
> Hi,
> this patch implements tracking of access ranges. This is only applied when
> base pointer is an arugment. Incrementally i will extend it to also track
> TBAA basetype so we can disambiguate ranges for accesses to same basetype
> (which makes is
This introduces a permute optimization phase for SLP which is
intended to cover the existing permute eliding for SLP reductions
plus handling commonizing the easy cases.
It currently uses graphds to compute a postorder on the reverse
SLP graph and it handles all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #6 from m farazma ---
(In reply to Jonathan Wakely from comment #5)
> Neither of those cases are constants, and the warning documentation (and the
> actual diagnostic itself) talk about constants.
>
> But there's still no warning
On Fri, 2 Oct 2020, Jan Hubicka wrote:
> Hi,
> as discussed this patch makes return value and arg specifiers to be 2
> characters long and updates (I hope) all fnspec strings.
> I also enabled part of the verification (just accepting the fortran bug
> with 'R' and 'W' in return value specifiers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Hi Jonathan,
On 2020-10-02 15:27, Jonathan Wakely wrote:
On Fri, 2 Oct 2020 at 14:20, Alejandro Colomar wrote:
On 2020-10-02 15:06, Jonathan Wakely wrote:
> On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages)
> wrote:
>>
>> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely
1 - 100 of 214 matches
Mail list logo
