Hi!
On Mon, Jun 01, 2020 at 04:01:52PM -0400, Michael Meissner wrote:
> This patch renames some functions that were added for power9 support that are
> named '_p9' to be '_hw'. This is preparation for the next patch that wants to
> extend these functions for -mcpu=power support.
_hw means
As clarified by LWG 3265, std::move_iterator is supposed to have an
assignment operator that converts from a different specialization of
std::move_iterator, which performs an assignment. That has always been
missing from libstdc++, so assigning a different type actually performs
a converting
As Martin Sebor points out, the ChangeLog entries should not be included
in the patch. So I have removed those. I also made some changes to this
patch that were necessary because of changes to the other patch.
See the patch below:
From 676b6436835434f89c8511cd68e89947c32f11c6 Mon Sep 17 00:00:00
On Wed, 10 Jun 2020, Patrick McGehearty wrote:
> I see your point about other floating point formats.
> According to the C standard, DOUBLE precision must
> have a DBL_MAX of at least 1E+37. That is (slightly)
> greater than 0x1.0p+63.
>
> Would
> #define RMIN2 (0x1.0p-53)
> #define RMINSCAL
On Tue, 2020-06-02 at 18:12 -0600, Martin Sebor wrote:
> The compute_objsize() function started out as a thin wrapper around
> compute_builtin_object_size(), but over time developed its own
> features to compensate for the other function's limitations (such
> as its inability to work with ranges).
Martin Sebor writes:
> On 6/8/20 7:07 PM, Asher Gordon wrote:
>>
>> OK, these will be easy to fix. Should my other patch¹ (which implements
>> -Wuniversal-initializer) also have PR c/95379?
>
> I'm sure that would be fine but since it's a separate enhancement
> it doesn't need to. It's up to
Replaced for consistency with the rest of the aarch64 backend.
Testing done:
Cross-compiled and regression tested on aarch64-none-elf, no issues.
---
gcc/ChangeLog:
2020-04-08 Alex Butler
* config/aarch64/aarch64.md (cb1): Replace
sprintf with snprintf
---
aarch64.md |
Hi!
Everything Will said included by reference :-)
On Mon, Jun 01, 2020 at 04:01:53PM -0400, Michael Meissner wrote:
> Add support for the new IEEE 128-bit minimum, maximum, and set compare mask
> instructions when -mcpu=future was used.
You can say "ISA 3.1 instructions" now :-) That may read
I see your point about other floating point formats.
According to the C standard, DOUBLE precision must
have a DBL_MAX of at least 1E+37. That is (slightly)
greater than 0x1.0p+63.
Would
#define RMIN2 (0x1.0p-53)
#define RMINSCAL (0x1.0p+51)
be acceptable?
Those will be in range for any
The standard requires that std::bad_optional_access' default
constructor has a non-throwing exception specification.
* include/std/optional (bad_optional_access): Define default
constructor and destructor as defaulted.
* testsuite/20_util/optional/bad_access.cc: New test.
Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier. In this case we never got around
to re-parsing it because the
On Tue, Jun 9, 2020 at 2:56 PM Alex Butler wrote:
>
> Replaced for consistency with the rest of the aarch64 backend.
>
> Testing done:
> Cross-compiled and regression tested on aarch64-none-elf, no issues.
If we 100% know the size of the buffer that passes to sprintf is
reasonable for the format
Segher:
So I have been looking at the predicate definitions that I had created.
On Fri, 2020-06-05 at 16:28 -0500, Segher Boessenkool wrote:
> > +;; Return 1 if op is a 32-bit constant signed integer
> > +(define_predicate "s32bit_cint_operand"
> > + (and (match_code "const_int")
> > +
Thanks for reviewing this. Could you please help install this patch?
Thanks,
Qian Chao.
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, June 9, 2020 8:56 PM
> To: qianchao
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95569] ICE
On 6/9/20 7:54 PM, Marek Polacek wrote:
Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier. In this case we never
On 08/06/20 8:20 pm, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG mode.
   To do so I had to return int in
On Tue, 2020-06-02 at 15:00 +0100, Richard Sandiford wrote:
> This patch uses parameter packs to define insn_gen_fn::operator().
> I guess in some ways it's C++-ification for its own sake, but it does
> make things simpler and removes the current artificial limit of 16
> arguments.
>
> Note that
On Sun, 2020-05-24 at 11:22 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Sun, May 24, 2020 at 07:03:13PM +0530, Kamlesh Kumar wrote:
> > In this patch series trying to address same by creating a struct Tuple
> > which bundles existing rtx and machine_mode and added one more
> > bool member which
On Tue, 2 Jun 2020 at 15:25, Martin Liška wrote:
>
> On 6/2/20 4:14 PM, Jonathan Wakely wrote:
> > On Tue, 2 Jun 2020 at 14:56, Jonathan Wakely wrote:
> >>
> >> On Tue, 2 Jun 2020 at 14:16, Martin Liška wrote:
> >>>
> >>> On 6/2/20 1:48 PM, Martin Liška wrote:
> I tend to this approach.
On 09/06/20 12:24 pm, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG
Hi!
On Mon, Jun 01, 2020 at 04:01:51PM -0400, Michael Meissner wrote:
> Add support for generating BRH/BRW/BRD when -mcpu=future is used.
> * config/rs6000/rs6000.md (bswaphi2_reg): If -mcpu=future,
> generate the BRH instruction.
"Add alternative for brh."? If the changelog
On 09/06/20 22:20 +0200, François Dumont via Libstdc++ wrote:
On 08/06/20 8:20 pm, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
ÃÂ ÃÂ ÃÂ Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators
On Thu, 2020-04-02 at 06:35 +, xiezhiheng wrote:
> Hi,
> I've created a bug for this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
>
> And I'm going to solve this problem by propagating def's insn to its use
> when they are at the same loop in fwprop pass.
> I mean
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo
On 09/06/20 22:35 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 12:24 pm, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
ÃÂ ÃÂ ÃÂ Here is the last of my algo patches this time to extend
On 09/06/20 22:42 +0200, François Dumont via Libstdc++ wrote:
On 09/06/20 6:11 pm, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François
On Mon, 2020-05-18 at 19:59 +0200, Aldy Hernandez wrote:
> Howdy.
>
> The main evrp domwalker seems cut and pasted from the
> substitute_and_fold_engine (or was it the other way around?). Albeit,
> there are a few things that evrp does, like set up ranges, but these can
> be set up with
On Thu, 2020-05-21 at 14:04 +0200, Martin Liška wrote:
> PING^1
>
> On 3/20/20 4:55 PM, Martin Liška wrote:
> > Ok, it would be possible, but if you take a look at options-save.c there's
> > no
> > function that will leverage that. It's a generated code so I guess we can
> > live with that?
On 6/9/20 9:33 AM, Martin Liška wrote:
I'm going to install it if there are no objections.
Pushed as 862b9b225fb.
Martin
Hello.
The patch is follow up of the kernel discussion:
https://lore.kernel.org/lkml/canpmjnnrz5ovkb6pe7k6gjfogbht_zhypkng9ad+kjndzk7...@mail.gmail.com/
The patch changes inliner in the following way:
1) do not compare caller and callee sanitizer attributes
for always_inline functions - that
On Tue, Jun 09, 2020 at 03:15:39PM +0200, Marco Elver wrote:
> gcc/
> * params.opt: Define --param=tsan-distinguish-volatile=[0,1].
> * sanitizer.def (BUILT_IN_TSAN_VOLATILE_READ1): Define new
> builtin for volatile instrumentation of reads/writes.
>
> -Original Message-
> From: Gcc-patches On Behalf Of Richard
> Biener
> Sent: 05 May 2020 14:49
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] move permutation validity check
>
>
> This delays the SLP permutation check to vectorizable_load and optimizes
> permutations only after all
> -Original Message-
> From: Richard Biener
> Sent: 09 June 2020 14:24
> To: Alex Coplan
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] move permutation validity check
>
> On Tue, Jun 9, 2020 at 3:22 PM Alex Coplan wrote:
> >
> > > -Original Message-
> >
This removes dead code that was left over from the reduction
vectorization refactoring last year.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2020-06-09 Richard Biener
* tree-vect-stmts.c (vect_transform_stmt): Remove dead code.
---
gcc/tree-vect-stmts.c |
On 6/8/20 1:07 PM, Martin Liška wrote:
Can you please test the following patch candidate:
I've just pushed 862b9b225fb which should fix that.
Can you please test the current master?
Thanks,
Martin
Hi Richard,
The 06/08/2020 16:42, Richard Sandiford wrote:
> Tamar Christina writes:
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index
> > 97da60762390db81df9cffaf316b909cd1609130..9cc8da338125afa01bc9fb645f4112d2d7ef548c
> > 100644
> > ---
Hi Richard,
The 06/09/2020 12:44, Richard Sandiford wrote:
> Tamar Christina writes:
> > Hi Richard,
> > The 06/08/2020 16:42, Richard Sandiford wrote:
> >> Tamar Christina writes:
> >> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >> > index
> >> >
On Tue, 9 Jun 2020 12:41:21 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2020-06-05T21:31:08+0100, Julian Brown
> wrote:
> >> For the OpenACC runtime API 'acc_attach' etc. routines they don't,
> >> so what's the conceptual reason that for the corresponding OpenACC
> >> directive variants,
On Tue, Jun 09, 2020 at 02:32:36PM +0200, Martin Liška wrote:
> >From 5fe0671ad79d14d1c9d0fead1a471875a4416fac Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Tue, 9 Jun 2020 13:03:55 +0200
> Subject: [PATCH] sanitizer: do not inline no-sanitize into sanitizer fn
>
> gcc/ChangeLog:
>
>
On Tue, Jun 9, 2020 at 11:47 AM qianchao wrote:
>
> Hi
>
> Commit eb72dc663e9070b281be83a80f6f838a3a878822 introduces a ICE on AArch64.
> See the discussion on the bug for details.
> Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95569
>
> Trivial patch fixing the ICE attached.
>
> Bootstrap
Hi!
On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
> Thanks, here's the combined patch I'm checking in.
>
> revamp dump and aux output names
For libgomp offloading testing, I'm seeing a number of failures like:
UNSUPPORTED:
On Tue, 9 Jun 2020 at 15:22, Jakub Jelinek wrote:
>
> On Tue, Jun 09, 2020 at 03:15:39PM +0200, Marco Elver wrote:
> > gcc/
> > * params.opt: Define --param=tsan-distinguish-volatile=[0,1].
> > * sanitizer.def (BUILT_IN_TSAN_VOLATILE_READ1): Define new
> > builtin for volatile
On Tue, Jun 9, 2020 at 3:22 PM Alex Coplan wrote:
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of Richard
> > Biener
> > Sent: 05 May 2020 14:49
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] move permutation validity check
> >
> >
> > This delays the SLP permutation
On Mon, Jun 8, 2020 at 1:04 PM Martin Liška wrote:
>
> Hello.
>
> Thank you for the approval. There's the patch that defines 4 new
> DEF_INTERNAL_OPTAB_FN.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> It also builds on ppc64le-linux-gnu.
>
> Ready to be installed?
Hi Julian!
On 2020-06-05T21:31:08+0100, Julian Brown wrote:
> On Fri, 5 Jun 2020 13:17:09 +0200
> Thomas Schwinge wrote:
>> On 2019-12-17T21:03:47-0800, Julian Brown
>> wrote:
>> > This part contains the libgomp runtime support for the
>> > GOMP_MAP_ATTACH and GOMP_MAP_DETACH mapping kinds
>>
Tamar Christina writes:
> Hi Richard,
> The 06/08/2020 16:42, Richard Sandiford wrote:
>> Tamar Christina writes:
>> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> > index
>> > 97da60762390db81df9cffaf316b909cd1609130..9cc8da338125afa01bc9fb645f4112d2d7ef548c
>> >
Pushed to master.
gcc/ChangeLog:
* gcov-dump.c (print_usage): Fix spacing for --raw option
in --help.
---
gcc/gcov-dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcov-dump.c b/gcc/gcov-dump.c
index 90cbd1ace52..ffb71ca4b68 100644
---
On Tue, Jun 09, 2020 at 02:09:06PM +0200, Martin Liška wrote:
> - return ((sanitize_flags_p (SANITIZE_ADDRESS, caller)
> -== sanitize_flags_p (SANITIZE_ADDRESS, callee))
> - && (sanitize_flags_p (SANITIZE_POINTER_COMPARE, caller)
> - == sanitize_flags_p
Hi!
On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
> Thanks, here's the combined patch I'm checking in.
>
> revamp dump and aux output names
For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
Running [...]/source-gcc/gcc/testsuite/brig.dg/dg.exp ...
PASS:
It turned out that this patch fails with LTO and partitions,
causing fails at runtime such as
libgomp: Duplicate node
via libgomp/splay-tree.c's splay_tree_insert.
In the test case, the problem occurred for functions - namely
main._omp_fn.* on the host.
If the code is run in LTO context, the
On Tue, Jun 09, 2020 at 12:01:24PM +0200, Marco Elver wrote:
> > Do we need/want Optimization here? Optimization means the option is
> > per-function, but to me whether you want to distinguish volatiles or not
> > seems to be a global decision for the whole project.
>
> Adding Optimization here
Pushed to master.
gcc/ChangeLog:
PR gcov-profile/95365
* doc/gcov.texi: Compile and link one example in 2 steps.
---
gcc/doc/gcov.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 61250c9407e..22e42da2ea6
On Tue, Jun 09, 2020 at 01:53:38PM +0200, Martin Liška wrote:
> + const sanitize_code codes[] =
> +{
> + SANITIZE_ADDRESS,
> + SANITIZE_THREAD,
> + SANITIZE_LEAK,
Why leak? That is really a link time option only, doesn't affect code
generation in any way.
On the other side,
On 6/9/20 2:01 PM, Jakub Jelinek wrote:
On Tue, Jun 09, 2020 at 01:53:38PM +0200, Martin Liška wrote:
+ const sanitize_code codes[] =
+{
+ SANITIZE_ADDRESS,
+ SANITIZE_THREAD,
+ SANITIZE_LEAK,
Why leak?
I was too eager ;)
That is really a link time option only, doesn't
On 6/9/20 2:15 PM, Jakub Jelinek wrote:
Sorry for not writing everything at once, but are the
SANITIZER_POINTER_{COMPARE,SUBTRACT} differences unimportant?
They are. I got confused that they are not
part of SANITIZE_UNDEFINED or SANITIZE_UNDEFINED_NONDEFAULT.
Anyway, good point!
Martin
>From
Hi,
On Tue, Jun 09 2020, Thomas Schwinge wrote:
> Hi!
>
> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>> Thanks, here's the combined patch I'm checking in.
>>
>> revamp dump and aux output names
>
> For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
>
> Running
> Yes, but the problem is that remap_decl isn't getting called.
Right, I can get it to be called by adding a pushdecl to grokdeclarator...
> Attaching it to the BIND_EXPR doesn't help walk_tree_1 do the right
> thing with the DECL_EXPR.
... but, indeed, this still ICEs. So the key is that the
On Tue, Jun 9, 2020 at 12:19 PM Eric Botcazou wrote:
>
> > I'm probably completely misunderstanding how TYPE_REVERSE_STORAGE_ORDER
> > works and what the constraints are. But if the memcpy is the storage order
> > barrier then what cases are OK?
> >
> > - both source and destination objects are
Add support to optionally emit different instrumentation for accesses to
volatile variables. While the default TSAN runtime likely will never
require this feature, other runtimes for different environments that
have subtly different memory models or assumptions may require
distinguishing
Hi,
So this is my rework of the code you sent me, I have not included the
'permute' code you included as I can't figure out what it is meant to be
doing. Maybe something to look at later.
I have also included three tests that show it working for some simple
cases and even a nested one.
Hi Alexandre,
> When the linker plugin is not available, dump outputs in lto runs are
> different from those outputs.exp tests expect, so skip them for now.
>
> Regstrapped on x86_64-linux-gnu. Ok to install?
>
>
> for gcc/testsuite/ChangeLog
>
> * outputs.exp (skip_lto): Set when missing
On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > > While technically OK the issue is that it does not solve the x86 issue
> > > which with incoming stack alignment < 8 bytes does not perform
> > > dynamic
On Tue, Jun 09, 2020 at 09:18:25AM -0600, Jeff Law wrote:
> On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> > On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > > > While technically OK the issue is that it does not solve the x86 issue
> > > > which with
On Tue, 2020-06-09 at 17:26 +0200, Jakub Jelinek wrote:
> On Tue, Jun 09, 2020 at 09:18:25AM -0600, Jeff Law wrote:
> > On Tue, 2020-06-09 at 16:59 +0200, Jakub Jelinek wrote:
> > > On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > > > > While technically OK the issue
On 6/9/20 1:43 AM, Richard Biener wrote:
On Mon, Jun 8, 2020 at 11:59 PM Martin Sebor via Gcc-patches
wrote:
PR 95581 reports an ICE in a call to gimple_call_arg() with
an out-of-bounds argument number (2). The attached patch avoids
the ICE but I'm not sure it's the right fix. Other than
On Tue, Jun 9, 2020 at 5:51 PM Martin Sebor wrote:
>
> On 6/9/20 1:43 AM, Richard Biener wrote:
> > On Mon, Jun 8, 2020 at 11:59 PM Martin Sebor via Gcc-patches
> > wrote:
> >>
> >> PR 95581 reports an ICE in a call to gimple_call_arg() with
> >> an out-of-bounds argument number (2). The
On 6/9/20 8:41 AM, Eric Botcazou wrote:
Yes, but the problem is that remap_decl isn't getting called.
Right, I can get it to be called by adding a pushdecl to grokdeclarator...
Attaching it to the BIND_EXPR doesn't help walk_tree_1 do the right
thing with the DECL_EXPR.
... but, indeed,
On Tue, Jun 09, 2020 at 08:54:47AM -0600, Jeff Law via Gcc-patches wrote:
> > While technically OK the issue is that it does not solve the x86 issue
> > which with incoming stack alignment < 8 bytes does not perform
> > dynamic re-alignment to align 'long long' variables appropriately.
> >
We only need to predeclare a VLA type if it's wrapped in a pointer type;
otherwise gimplify_type_sizes will handle it.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/95552
* cp-gimplify.c (predeclare_vla): Only predeclare a VLA if it's
wrapped in
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp
On Tue, 2020-06-09 at 01:00 +, Segher Boessenkool wrote:
> Some testcases failed (esp. with --with-cpu=power9) after my change
> to
> prefer xxperm over vperm when all else is equal. Fix that. (This
> also
> tightens the relevant REs somewhat).
>
> Tested on way too many configurations.
On Tue, Jun 09, 2020 at 04:02:19PM +0200, Tobias Burnus wrote:
> It turned out that this patch fails with LTO and partitions,
> causing fails at runtime such as
> libgomp: Duplicate node
> via libgomp/splay-tree.c's splay_tree_insert.
>
> In the test case, the problem occurred for functions -
The 'you' here is Richi, which Richi is probably aware but maybe not the
rest of the list :')
On 09/06/2020 15:29, Andre Vieira (lists) wrote:
Hi,
So this is my rework of the code you sent me, I have not included the
'permute' code you included as I can't figure out what it is meant to
be
On Tue, 2020-06-09 at 09:17 +0200, Richard Biener wrote:
> On Mon, Jun 8, 2020 at 11:13 PM Jeff Law via Gcc-patches
> wrote:
> >
> > We're seeing some failures due to the local-alignment pass. For example on
> > sh4:
> >
> > Tests that now fail, but worked before (16 tests):
> >
> >
On 09/06/20 17:11 +0100, Jonathan Wakely wrote:
On 09/06/20 00:02 +0100, Jonathan Wakely wrote:
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my
On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
>
> On 6/8/20 4:53 PM, Martin Liška wrote:
> > Hi.
> >
> > Thank you for the report. It's caused by fact that LLVM switch in
> > 4d474e078ac7
> > to c++14. So that I suggest to use gnu++14.
> >
> > Patch can bootstrap on x86_64-linux-gnu and
On Tue, May 26, 2020 at 6:27 AM Martin Liška wrote:
>
> On 5/26/20 1:59 PM, H.J. Lu wrote:
> > On Tue, May 26, 2020 at 2:30 AM Martin Liška wrote:
> >>
> >> On 5/25/20 7:42 PM, H.J. Lu wrote:
> >>> Here is the updated patch. OK for master?
> >>
> >> Thank you for the updated patch.
> >>
> >> I
Hi,
This patch merges the D front-end implementation with upstream dmd
13d67c575. Contains many small API changes, most contained within the
front-end, but some spill out into the codegen.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
Hi Bernhard,
For Fortran identifiers, that would be really good. Would you do that?
Is it really needed?
We do not enter internal helper names (class names, anything
artificial, anything leading underscore or leading uppercase) to the
suggestions proposals so should never actually recommend
> Like this?
Fine with me, thanks!
--
Eric Botcazou
This removes dead code left over from the reduction vectorization
refactoring last year.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-06-09 Richard Biener
* tree-vect-loop.c (vectorizable_induction): Remove dead code.
---
gcc/tree-vect-loop.c | 42
On Sun, May 31, 2020 at 4:10 PM H.J. Lu wrote:
>
> We used to expand memcmp to "repz cmpsb" via cmpstrnsi. It was changed
> by
>
> commit 9b0f6f5e511ca512e4faeabc81d2fd3abad9b02f
> Author: Nick Clifton
> Date: Fri Aug 12 16:26:11 2011 +
>
> builtins.c (expand_builtin_memcmp): Do not
On Fri, May 22, 2020 at 4:22 AM H.J. Lu wrote:
>
> On Sat, May 2, 2020 at 4:55 AM H.J. Lu wrote:
> >
> > Currently patchable area is at the wrong place. It is placed immediately
> > after function label, before both .cfi_startproc and ENDBR. This patch
> > adds UNSPECV_PATCHABLE_AREA for
May I please ping this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545426.html
Thanks!
-Lewis
On Fri, May 08, 2020 at 03:35:25PM -0400, Lewis Hyatt wrote:
> On Fri, Jan 31, 2020 at 03:31:59PM -0500, David Malcolm wrote:
> > On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote:
> >
Another part of 95369 is that we accept designated initializers with
non-aggregate types. That seems to be wrong since they're part of
aggregate initialization. clang/icc also reject it.
(Un)fortunately there are multiple contexts where we can use designated
initializers: function-like casts,
This fixes two issues in our handling of constrained class template
friend declarations.
The first issue is that we fail to set the constraints on the injected
class template declaration during tsubst_friend_class.
The second issue is that the template parameter levels within the parsed
Hi,
Hope you are safe and doing great.
Would you be interested in acquiring the records of Chemical industries
list to promote your product and service?
*Key contacts*: Ceo, Engineers, Chemists, Health and Safety Specialists,
Soil and Plant Scientists and more.
If you are interested
I think I'd prefer the fix on the other side, if reasonable. I'd give them
some time to see about a fix there before selecting this patch.
On Jun 9, 2020, at 5:42 AM, Martin Jambor wrote:
> On Tue, Jun 09 2020, Thomas Schwinge wrote:
>> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>>>
On 6/9/20 6:32 PM, Richard Biener wrote:
On Tue, Jun 9, 2020 at 10:09 AM Martin Liška wrote:
On 6/8/20 4:53 PM, Martin Liška wrote:
Hi.
Thank you for the report. It's caused by fact that LLVM switch in 4d474e078ac7
to c++14. So that I suggest to use gnu++14.
Patch can bootstrap on
On 6/9/20 3:47 PM, Marco Elver wrote:
I think one of you has to commit the patch, as we don't have access to
the GCC git repository.
I've just done that.
I also fixed few wrong formatting issues, next time please use
./contrib/check_GNU_style.py.
You'll be preparing one another patch, please
On Thu, 2020-06-04 at 11:09 +0200, Christophe Lyon wrote:
> Hi,
>
> On Thu, 4 Jun 2020 at 01:03, Jeff Law via Gcc-patches
> wrote:
> > On Fri, 2020-01-31 at 15:50 -0300, Vitor Guidi wrote:
> > > I took the required steps. The patch is attached to this email, I hope
> > > I got it right this
On Fri, 2020-06-05 at 09:57 -0300, Alexandre Oliva wrote:
> The testcase for PR51447, on x86_64, uses rbx as a global register
> variable for the global PTR variable.
>
> A runtime system might legitimately hold in rbx a value expected to be
> preserved across the call to main, but its use as a
Jakub Jelinek via Gcc-patches writes:
> On Tue, Jun 09, 2020 at 02:32:36PM +0200, Martin Liška wrote:
>> >From 5fe0671ad79d14d1c9d0fead1a471875a4416fac Mon Sep 17 00:00:00 2001
>> From: Martin Liska
>> Date: Tue, 9 Jun 2020 13:03:55 +0200
>> Subject: [PATCH] sanitizer: do not inline no-sanitize
On Wed, 2020-05-20 at 21:32 +0200, Michael Kuhn wrote:
> Hi,
>
> when specifying a non-system prefix with --with-zstd, the build fails
> because the header and library cannot be found (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95005).
>
> The attached patch fixes the problem and is
Also add comment explaining what the script does.
contrib/ChangeLog:
* gcc-changelog/git_email.py: Set exit status on error.
Committed as obvious.
commit 62963c60fc19d07615afe9d4f1b897b2f60801b2
Author: Jonathan Wakely
Date: Tue Jun 9 20:39:39 2020 +0100
gcc-changelog: Use
On Fri, 2020-06-05 at 08:18 -0700, H.J. Lu wrote:
> On Tue, May 12, 2020 at 10:28 AM Jeff Law wrote:
> > On Fri, 2020-05-08 at 06:11 -0700, H.J. Lu via Gcc-patches wrote:
> > > Don't perform CET run-time check for host when cross compiling. Instead,
> > > enable CET in cross compiler if possible
On Tue, Jun 9, 2020 at 5:04 AM Iain Sandoe wrote:
> Hi C++ folks,
>
> There are a number of places in the coroutine codegen where we need to
> build calls to promise methods.
>
> Such methods can, in several cases, also be constexpr or static (or both)
> which leads to the PR,
>
> Now the
On 09/06/20 20:42 +0100, Jonathan Wakely wrote:
Also add comment explaining what the script does.
contrib/ChangeLog:
* gcc-changelog/git_email.py: Set exit status on error.
Committed as obvious.
With that change to git_email.py I can use the following change to the
On 6/9/20 9:42 PM, Rainer Orth wrote:
Excess errors:
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'
Sorry for that, I'm going to install the following patch.
Martin
>From 20e0cd44f9c3e9402a0cd26a0332556391902cb6 Mon Sep 17 00:00:00 2001
From: Martin Liska
Hi C++ folks,
There are a number of places in the coroutine codegen where we need to
build calls to promise methods.
Such methods can, in several cases, also be constexpr or static (or both)
which leads to the PR,
Now the mechanism I use is this;
1/ lookup the method in the relevant
1 - 100 of 150 matches
Mail list logo
