On November 20, 2021 7:03:02 AM GMT+01:00, apinski--- via Gcc-patches
wrote:
>From: Andrew Pinski
>
>The problem here is that int_fits_type_p will return false if we just
>change the sign of things like -2 (or 254) so we should accept the case
>where we just change the sign (and not the precisio
From: Andrew Pinski
The problem here is that int_fits_type_p will return false if we just
change the sign of things like -2 (or 254) so we should accept the case
where we just change the sign (and not the precision) of the type.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions
Thanks for your reviews!
Here's the updated patch, ready for another review.
See comments/questions below.
I'll update the other patches over the weekend.
Le jeudi 20 mai 2021 à 15:29 -0400, David Malcolm a écrit :
> On Wed, 2021-05-19 at 20:32 -0400, Antoni Boucher via Jit wrote:
> > Hello.
> >
On Mon, 2021-09-27 at 20:53 -0400, Antoni Boucher wrote:
> I fixed an issue (it would show an error message when
> gcc_jit_type_dyncast_function_ptr_type was called on a type different
> than a function pointer type).
>
> Here's the updated patch.
Sorry about the delay in responding.
The updated
Hi,
On Fri, Nov 19 2021, Iain Sandoe wrote:
> At least some version(s) of makeinfo (4.8) do not like @option {-}
> the brace has to follow the @option without any whitespace.
>
> makeinfo 4.8 is installed on Darwin systems and this breaks bootstrap.
> The amendment follows the style of the sur
On Friday, 19 November 2021 23:26:57 CET Jason Merrill wrote:
> On 11/19/21 04:53, Matthias Kretz wrote:
> > My motivation for printing a function template specialization differently
> > is:
> >
> > 1. It's a different function definition that's being called. The user
> > (caller) might be surpris
Hi Richard,
Thanks for the detailed comment. I am attaching a newer version of the patch
which does have required fixes included. Bellow you can see my response to your
feedbacks:
> you need to check TYPE_OVERFLOW_WRAPS on TREE_TYPE (@0),
> otherwise you check on boolean.
Fixed it.
> no need f
On 11/19/21 04:53, Matthias Kretz wrote:
On Thursday, 18 November 2021 20:24:36 CET Jason Merrill wrote:
On 11/17/21 17:51, Matthias Kretz wrote:
Right, I had already added a `gcc_assert (!TMPL_ARGS_HAVE_MULTIPLE_LEVELS
(args))` to my new set_non_default_template_args_count function and found
c
On Thu, Nov 11, 2021 at 3:25 AM Kewen Lin wrote:
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (movdi_internal, movdf_internal): Fix split
> condition.
I had been hoping Max would reply (as I'm just doing legacy work
around this these days), but seeing that he hasn't. This is app
This fixes a bogus -Wuninitialized warning: there's nothing to initialize
in empty classes, so don't add them into our uninitialized set.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/19808
gcc/cp/ChangeLog:
* init.c (emit_mem_initializers): Don't add is_re
On Thu, Nov 18, 2021 at 06:45:42PM -0500, David Malcolm wrote:
> On Thu, 2021-11-18 at 14:08 -0600, Segher Boessenkool wrote:
> > We need some way to describe these things in Gimple and RTL as well,
> > and not just on function calls: also on other expressions. Adding
> > attributes that allow to
On Mon, 15 Nov 2021, Patrick Palka wrote:
> This makes fast_float handle the situation where std::from_chars is
> specified to return result_out_of_range, i.e. when the parsed value
> is outside the representable range of the floating-point type.
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17
On Mon, 15 Nov 2021, Patrick Palka wrote:
> This performs the following modifications to our local copy of fast_float
> in order to make it more readily usable in our std::from_chars
> implementation:
>
> * Remove system #includes
> * Replace stray call to assert
> * Use the standard librar
At least some version(s) of makeinfo (4.8) do not like @option {-}
the brace has to follow the @option without any whitespace.
makeinfo 4.8 is installed on Darwin systems and this breaks bootstrap.
The amendment follows the style of the surrounding code.
tested on Darwin9, 18, 19, 20, 21, pus
On 19/11/2021 19.11, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 12 Nov 2021, at 17:35, Olivier Hainque wrote:
>
> Your error triggers on O2ggnu++0x.gch and we configure with
> --disable-libstdcxx-pch.
>
> Can you see if adding this to your configuration options helps
> on your end?
ISTR I alr
PR analyzer/103217 reports a false positive from -Wanalyzer-malloc-leak.
The root cause is due to overzealous state merger, where the
state-merging code decided to merge these two states by merging
the stores:
state A:
clusters within frame: ‘main’@1
cluster for: one_3: CONJURED(val_4 = str
Tested x86_64-linux, pushed to trunk.
This ensures all constructors are checked.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_istringstream/cons/char/1.cc: Check all
constructors.
* testsuite/27_io/basic_istringstream/cons/wchar_t/1.cc:
Likewise.
* tes
Tested x86_64-linux, pushed to trunk.
This replaces a __gthread_active_p() check with __is_single_threaded()
so that std::locale initialization doesn't use __gthread_once if it
happens before the first thread is created.
This means that _S_initialize_once() might now be called twice instead
of o
Tested powerpc64le-linux (and x86_64-linux clang), pushed to trunk.
All writes into the allocated buffer need to be via traits_type::assign
to begin lifetimes.
libstdc++-v3/ChangeLog:
PR libstdc++/103295
* include/bits/basic_string.tcc (_M_construct): Use the
traits assi
Unfortunately dejagnu doesn't honor #if/#endif, so this test was failing
with -std=c++11:
FAIL: g++.dg/cpp0x/lambda/lambda-nested9.C -std=c++11 (test for errors, line
37)
Fixed thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Mikael's fix for PR97896. In that case it is a 1-liner. :-)
That fix is available on mainline and on 11-branc
As described in detail in the PR, in C++20 implicitly capturing 'this'
via the '=' capture default is deprecated, but in C++17 explicitly
capturing 'this' alongside a '=' capture default is ill-formed. This
means it's impossible to write a C++17 lambda that captures 'this' and
that also has a '='
Excerpts from Iain Sandoe's message of November 19, 2021 4:59 pm:
> Depending on the permutation of CPU, OS version and shared/non-
> shared library inclusion, we get can get two warnings from the
> external tools (ld64, dsymutil) which are not actually GCC issues
> but relate to the external tools
On Sat, Nov 20, 2021 at 12:31:19AM +0530, Siddhesh Poyarekar wrote:
> > Neither of these are equivalent to what it used to do before.
> > If some target has e.g. pointers wider than size_t, then previously we could
> > compute bytes that doesn't fit into size_t and would return NULL which
> > event
On Fri, 19 Nov 2021, Martin Jambor wrote:
> can I add the following caveat to the gcc-12/changes.html file?
Of course you can. :-)
Actually, we should, and I'm glad you thought of it.
Thank you,
Gerald
On 11/19/21 22:36, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:29AM +0530, Siddhesh Poyarekar wrote:
* tree-object-size.h (compute_builtin_object_size): Return tree
instead of HOST_WIDE_INT.
* builtins.c (fold_builtin_object_size): Adjust.
* gimple-fold.c (
On 11/19/21 13:13, Richard Biener wrote:
On November 19, 2021 4:00:01 PM GMT+01:00, Andrew MacLeod
wrote:
On 11/19/21 04:21, Richard Biener wrote:
On Thu, Nov 18, 2021 at 8:30 PM Andrew MacLeod via Gcc-patches
wrote:
At issue here is the dynamic approach we currently use for outgoing edge
c
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/103332
PR libstdc++/102958
* testsuite/21_strings/basic_string/capacity/char/1.cc: Add
-Wno-stringop-overflow.
* testsuite/21_strings/basic_string/operators/char/1.cc:
Likew
Tested powerpc64le-linux (and clang on x86_64-linux), pushed to trunk.
Clang gives errors for constexpr std::string because the memory returned
by std::allocator::allocate does not contain any objects yet, and
attempting to set them using char_traits::assign or char_traits::copy
fails with:
assi
On Thu, Oct 21, 2021 at 12:22:12PM -0500, Paul A. Clarke wrote:
> Power10 ISA added `vextract*` instructions which are realized in the
> `vec_extractm` instrinsic.
>
> Use `vec_extractm` for `_mm_movemask_ps`, `_mm_movemask_pd`, and
> `_mm_movemask_epi8` compatibility intrinsics, when `_ARCH_PWR10
On November 19, 2021 4:00:01 PM GMT+01:00, Andrew MacLeod
wrote:
>On 11/19/21 04:21, Richard Biener wrote:
>> On Thu, Nov 18, 2021 at 8:30 PM Andrew MacLeod via Gcc-patches
>> wrote:
>>> At issue here is the dynamic approach we currently use for outgoing edge
>>> calculations. It isn't normally
Hi Rasmus,
> On 12 Nov 2021, at 17:35, Olivier Hainque wrote:
> We have had to use for stdbool a similar trick as we had
> for stdint (need to preinclude yyvals.h), which we will need to
> propagate somehow. I'm not yet sure how to reconcile that with
> your observations.
>> In file included fr
Hi!
On Fri, Oct 22, 2021 at 12:28:49PM -0500, Paul A. Clarke wrote:
> Power9 ISA added `vabsdub` instruction which is realized in the
> `vec_absd` instrinsic.
>
> Use `vec_absd` for `_mm_sad_epu8` compatibility intrinsic, when
> `_ARCH_PWR9`.
>
> Also, the realization of `vec_sum2s` on little-en
Hi,
can I add the following caveat to the gcc-12/changes.html file?
Thanks,
Martin
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 5f0214bd..fd7af717 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -72,6 +72,8 @@ a work-in-progress.
b
Hi,
On Fri, Nov 19 2021, Jan Hubicka wrote:
>> > Hi,
>> >
>> > On Fri, Nov 12 2021, Martin Jambor wrote:
>> > > Hi,
>> > >
>> > > using -fno-semantic-interposition has been reported by various people
>> > > to bring about considerable speed up at the cost of strict compliance
>> > > to the ELF sy
On Fri, 19 Nov 2021 at 16:04, Iain Sandoe via Libstdc++
wrote:
>
> Depending on the permutation of CPU, OS version and shared/non-
> shared library inclusion, we get can get warnings from the external
> tools (ld64, dsymutil) which are not actually libstdc++ issues but
> relate to the external too
On Fri, Nov 19, 2021 at 3:47 AM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> On Fri, 28 Oct 2016 10:55:18 -0700
> Ian Lance Taylor wrote:
>
> > This patch to libgo redirects the output of a grep command in
> > mkrsysinfo.sh to /dev/null. The output otherwise appears in the
>
> grep -q exi
Hi Jason,
> On 18 Nov 2021, at 23:42, Iain Sandoe wrote:
>
>
>
>> On 18 Nov 2021, at 22:13, Jason Merrill via Gcc-patches
>> wrote:
>>
>> On 11/5/21 11:46, Iain Sandoe wrote:
>>> The way in which a C++20 coroutine is specified discards any value
>>> tree aw_r = TREE_VEC_ELT (vec, 2);
On Wed, Nov 10, 2021 at 12:31:29AM +0530, Siddhesh Poyarekar wrote:
> * tree-object-size.h (compute_builtin_object_size): Return tree
> instead of HOST_WIDE_INT.
> * builtins.c (fold_builtin_object_size): Adjust.
> * gimple-fold.c (gimple_fold_builtin_strncat): Likewise.
>
On 11/19/21 21:48, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:28AM +0530, Siddhesh Poyarekar wrote:
Put all accesses to object_sizes behind functions so that we can add
dynamic capability more easily.
gcc/ChangeLog:
* tree-object-size.c (object_sizes_grow, object_sizes_release,
On 11/19/21 04:21, Richard Biener wrote:
On Thu, Nov 18, 2021 at 8:30 PM Andrew MacLeod via Gcc-patches
wrote:
At issue here is the dynamic approach we currently use for outgoing edge
calculations. It isn't normally a problem, but once you get a very
large number of possible outgoing values (i
On Wed, Nov 10, 2021 at 12:31:28AM +0530, Siddhesh Poyarekar wrote:
> Put all accesses to object_sizes behind functions so that we can add
> dynamic capability more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c (object_sizes_grow, object_sizes_release,
> object_sizes_unknown_p,
On 11/18/21 10:10 AM, Jan Hubicka wrote:
I don't know what the guidance is on using vec in IPA passes
but with respect to existing practice elsewhere, there are
existing uses of vec and auto_vec with non-POD types and vec
does work with them (see the vec_default_construct and
vec_copy_construct
Depending on the permutation of CPU, OS version and shared/non-
shared library inclusion, we get can get warnings from the external
tools (ld64, dsymutil) which are not actually libstdc++ issues but
relate to the external tools themselves. This is already pruned
in the main testsuite, this adds it
On Wed, Nov 10, 2021 at 12:31:27AM +0530, Siddhesh Poyarekar wrote:
> A simple cleanup to allow inserting dynamic size code more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c: New enum.
> (object_sizes, computed, addr_object_size,
> compute_builtin_object_size, init_object
Depending on the permutation of CPU, OS version and shared/non-
shared library inclusion, we get can get two warnings from the
external tools (ld64, dsymutil) which are not actually GCC issues
but relate to the external tools. These are already pruned in
the main testsuite, this adds them to the l
On Wed, Nov 10, 2021 at 12:31:26AM +0530, Siddhesh Poyarekar wrote:
> - Instead of bailing out on non-constant sizes with
> __builtin_object_size, it should be possible to use ranger to
> get an upper and lower bound on the size expression and use that to
> implement __builtin_object_size.
I
On 11/19/21 05:06, Jakub Jelinek wrote:
Hi!
decl_attributes and its caller cplus_decl_attributes sometimes add
implicit attributes, e.g. optimize attribute if #pragma GCC optimize
is active, target attribute if #pragma GCC target is active, or
e.g. omp declare target attribute if in between #pra
On 11/18/21 6:56 PM, Jason Merrill via Gcc-patches wrote:
On 11/18/21 19:24, Marek Polacek wrote:
On Thu, Nov 18, 2021 at 05:10:47PM -0500, Jason Merrill wrote:
On 11/8/21 18:41, Marek Polacek wrote:
@@ -1311,13 +1462,25 @@ emit_mem_initializers (tree mem_inits)
if (!COMPLETE_TYPE_P (curr
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584205.html
On 11/11/21 2:46 PM, Martin Sebor wrote:
Attached is a v2 of the solution I posted earlier this week
with a few tweaks made after a more careful consideration of
the problem and possible false negatives and positives.
1)
On 11/19/21 04:21, Richard Biener wrote:
On Thu, Nov 18, 2021 at 8:30 PM Andrew MacLeod via Gcc-patches
wrote:
At issue here is the dynamic approach we currently use for outgoing edge
calculations. It isn't normally a problem, but once you get a very
large number of possible outgoing values (i
se absolute switch table addresses for zero cycle moves.
This option enables using absolute addresses in switch tables if the
power10 zero cycle move tuning is turned on. The combination of using
absolute addresses in switch tables along with zero cycle moves seems to
give the best performance.
Set power10 fusion if -mtune=power10.
In doing the patch for zero cycle moves for switch statements and indirect
jumps, I noticed the fusion support is only done if -mcpu=power10. This option
enables power10 fusion if we use -mtune=power10.
I have built and run the testsuites on little endian po
Add power10 zero cycle moves for switches.
Power10 will fuse adjacenet 'mtctr' and 'bctr' instructions to form zero
cycle moves. This code exploits this fusion opportunity.
I have built bootstrapped compilers with this patch on little endian power9 and
power10 systems with no regressions. Can I
The next set of 3 patches add zero cycle move support to the Power10. Zero
cycle moves are where the move to LR/CTR/TAR register that is adjacent to the
jump to LR/CTR/TAR register can be fused together.
At the moment, these set of three patches add support for zero cycle moves for
indirect jumps
On Fri, 19 Nov 2021 15:12:35 +0100 (CET)
Richard Biener via Gcc-patches wrote:
> On Fri, 19 Nov 2021, Giuliano Belinassi wrote:
> > -It defaults to the location of the output file; options
> > +It defaults to the location of the output file, unless the output
> > +file is a special file like @co
On 11/19/21 05:15, Aldy Hernandez wrote:
On 11/18/21 8:28 PM, Andrew MacLeod wrote:
@@ -376,6 +366,14 @@ range_def_chain::get_def_chain (tree name)
return NULL;
}
+ // Terminate the def chains if we see too many cascading stmts.
+ if (m_logical_depth == param_ranger_logical_dep
On 11/19/21 15:06, Richard Biener wrote:
Can you please revert it?
Sure, done as 79e9f721d1a6f370ce0534745baeeb5a56da948e.
Martin
On Fri, 19 Nov 2021, Giuliano Belinassi wrote:
> The `configure` scripts generated with autoconf often tests compiler
> features by setting output to `/dev/null`, which then sets the dump
> folder as being /dev/* and the compilation halts with an error because
> GCC cannot create files in /dev/. T
On Fri, Nov 19, 2021 at 2:38 PM Alexandre Oliva via Gcc-patches
wrote:
>
>
> When we create copies of SSA_NAMEs to hold "detached" copies of the
> values for the hardening tests, we end up with assignments to
> SSA_NAMEs that refer to the same decls. That would be generally
> desirable, since it
On Fri, Nov 19, 2021 at 2:22 PM Martin Liška wrote:
>
> On 11/19/21 09:59, Alexandre Oliva wrote:
> > So I find the abstraction useful. However, I don't have plans to add
> > other kinds of debug stmts, and I don't know of anyone else who does, so
> > I won't stand in the way if others think remo
Hi,
As of macOS 11, libunwind now requires more stack space than 16k, so
default to a larger stack size. This is only applied to X86 as the
PAGESIZE is still 4k, however on AArch64 it is 16k.
Regression tested on x86_64-linux-gnu and x86_64-apple-darwin20,
committed to mainline and backported to
Hi,
This patch fixes a EXC_BAD_ACCESS issue seen on Darwin when the
libphobos DSO gets unloaded. Based on reading libgcc's emutls
implementation, as it doesn't call __gthread_key_delete directly,
neither should libphobos.
Bootstrapped and regression tested on x86_64-linux-gnu and
x86_64-apple-da
Ping.
On 2021/11/4 4:23 PM, Chung-Lin Tang wrote:
Hi Jakub,
As Thomas reported and submitted a patch a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2019-April/519932.html
https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522738.html
There's an issue with the Fortran front-end when mapp
Hi Jakub,
attached is a rebased version of this "OpenMP fixes/adjustments" patch.
This version removes some of the (ort == C_ORT_OMP || ort == C_ORT_ACC) stuff
that's not needed
in handle_omp_array_sections_1 and [c_]finish_omp_clauses.
Note that this is meant to be patched atop of the recent a
The `configure` scripts generated with autoconf often tests compiler
features by setting output to `/dev/null`, which then sets the dump
folder as being /dev/* and the compilation halts with an error because
GCC cannot create files in /dev/. This is a problem when configure is
testing for compiler
When we create copies of SSA_NAMEs to hold "detached" copies of the
values for the hardening tests, we end up with assignments to
SSA_NAMEs that refer to the same decls. That would be generally
desirable, since it enables the variable to be recognized in dumps,
and makes coalescing more likely i
On 11/19/21 09:59, Alexandre Oliva wrote:
So I find the abstraction useful. However, I don't have plans to add
other kinds of debug stmts, and I don't know of anyone else who does, so
I won't stand in the way if others think removing these abstractions is
a positive change.
Hello.
I've alread
On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer wrote:
>
> On Thu, 18 Nov 2021, Eric Gallager wrote:
> > I'd find it easier to just edit the page linked to in wwwdocs instead,
> > so I'm going to start seeing what I can do to update it. I figured I'd
> > start by removing the references to Java in
On Fri, Nov 19, 2021 at 12:50 PM Andrew Pinski wrote:
>
> On Fri, Nov 19, 2021 at 2:16 AM Richard Biener via Gcc-patches
> wrote:
> >
> > On Wed, Nov 17, 2021 at 7:25 AM apinski--- via Gcc-patches
> > wrote:
> > >
> > > From: Andrew Pinski
> > >
> > > The Linux kernel started to fail compile wh
On 11/19/21 13:45, Segher Boessenkool wrote:
On Fri, Nov 19, 2021 at 01:31:21PM +0100, Martin Liška wrote:
All right, so I can't send an email from my local machine and git imap-send
does not work as it goes through Thunderbird.
Hrm, painful (for you). You should figure out how you can do the
On Fri, 19 Nov 2021, Bernhard Reutner-Fischer wrote:
> On Fri, 19 Nov 2021 10:35:26 +0100 (CET)
> Richard Biener via Gcc-patches wrote:
>
> > On Fri, 19 Nov 2021, Alexandre Oliva wrote:
> >
> > > On Nov 18, 2021, Richard Biener wrote:
> > >
> > > > IMHO a more reasonable thing to do would b
On Fri, 19 Nov 2021, Jan Hubicka wrote:
> Hi,
> this patch removes test for function not having call chain guarding
> modref use in ref_maybe_used_by_call_p_1. It never made sense since
> modref treats call chain accesses explicitly. It was however copied from
> earlier check for ECF_CONST (which
On Fri, Nov 19, 2021 at 01:31:21PM +0100, Martin Liška wrote:
> All right, so I can't send an email from my local machine and git imap-send
> does not work as it goes through Thunderbird.
Hrm, painful (for you). You should figure out how you can do the basics
of the patch-based workflow that we a
On 11/19/21 13:25, Martin Liška wrote:
Fine. I've just done that.
All right, so I can't send an email from my local machine and git imap-send
does not work as it goes through Thunderbird.
So my last attempt is attaching the email so that you can add the .eml file.
Martin--- Begin Message ---
On Fri, 19 Nov 2021 10:35:26 +0100 (CET)
Richard Biener via Gcc-patches wrote:
> On Fri, 19 Nov 2021, Alexandre Oliva wrote:
>
> > On Nov 18, 2021, Richard Biener wrote:
> >
> > > IMHO a more reasonable thing to do would be to not treat
> > > -o /dev/null as a source for -dumpdir and friends
On 11/19/21 12:43, Segher Boessenkool wrote:
On Fri, Nov 19, 2021 at 12:32:09PM +0100, Martin Liška wrote:
On 11/18/21 19:59, Segher Boessenkool wrote:
Please resend, without line wrapping (format=flawed).
Done in the original [v4] email, see here:
https://gcc.gnu.org/pipermail/gcc-patches/20
Hi,
this patch removes test for function not having call chain guarding
modref use in ref_maybe_used_by_call_p_1. It never made sense since
modref treats call chain accesses explicitly. It was however copied from
earlier check for ECF_CONST (which seems dubious too, but I would like
to discuss it
On Friday, 19 November 2021 10:53:27 CET Matthias Kretz wrote:
> > >> Ah, you're trying to omit defaulted parms from the ? I'm not
> > >> sure
> > >> that's necessary, leaving them out of the [with ...] list should be
> > >> sufficient.
> > >
> > > I was thinking about all the std::allocator defau
On 11/19/21 10:45, Stefan Schulze Frielinghaus wrote:
...
> diff --git a/gcc/testsuite/gcc.target/s390/20211119.c
> b/gcc/testsuite/gcc.target/s390/2029.c
> new file mode 100644
> index 000..1a6df4f4b89
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/2029
> > Hi,
> >
> > On Fri, Nov 12 2021, Martin Jambor wrote:
> > > Hi,
> > >
> > > using -fno-semantic-interposition has been reported by various people
> > > to bring about considerable speed up at the cost of strict compliance
> > > to the ELF symbol interposition rules See for example
> > > https
On Fri, Nov 19, 2021 at 2:16 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, Nov 17, 2021 at 7:25 AM apinski--- via Gcc-patches
> wrote:
> >
> > From: Andrew Pinski
> >
> > The Linux kernel started to fail compile when the jump threader was improved
> > (r12-2591-g2e96b5f14e4025691). This f
On Fri, 28 Oct 2016 10:55:18 -0700
Ian Lance Taylor wrote:
> This patch to libgo redirects the output of a grep command in
> mkrsysinfo.sh to /dev/null. The output otherwise appears in the
grep -q exists since at least SUSv2, fwiw.
thanks,
> middle of a build log, where it is harmless but conf
On Fri, Nov 19, 2021 at 12:32:09PM +0100, Martin Liška wrote:
> On 11/18/21 19:59, Segher Boessenkool wrote:
> >Please resend, without line wrapping (format=flawed).
>
> Done in the original [v4] email, see here:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584267.html
Which you didn
On Tue, Nov 16, 2021 at 11:51 PM Navid Rahimi via Gcc-patches
wrote:
>
> Hi GCC community,
>
> This patch will add the missed pattern described in bug 102232 [1] to the
> match.pd.
>
> Tree-optimization/96779: Adding new optimization to match.pd:
>
> * match.pd (-x == x) -> (x == 0):
On 11/18/21 19:59, Segher Boessenkool wrote:
Please resend, without line wrapping (format=flawed).
Done in the original [v4] email, see here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584267.html
Martin
On Fri, Nov 12, 2021 at 07:30:35AM +, Tamar Christina via Gcc-patches wrote:
> @@ -2099,7 +2124,7 @@ spaceship_replacement (basic_block cond_bb, basic_block
> middle_bb,
>|| !tree_fits_shwi_p (rhs)
>|| !IN_RANGE (tree_to_shwi (rhs), -1, 1))
> return false;
> - if (orig_us
On Thu, 18 Nov 2021 at 22:05, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Hi
>
> Here is a proposal to limit performance impact of _GLIBCXX_DEBUG
> mode on __erase_nodes_if.
>
> As you can see I am adding erase overloads on the Debug container
> to accept base iterato
On Fri, Nov 19, 2021 at 11:20 AM Richard Biener
wrote:
>
> On Thu, Nov 11, 2021 at 3:13 PM Philipp Tomsich
> wrote:
> >
> > The RISC-V Zbb extension adds an XLEN (i.e. SImode for rv32, DImode
> > for rv64) bswap instruction (rev8). While, with the current master,
> > SImode is synthesized correc
On Thu, Nov 11, 2021 at 3:13 PM Philipp Tomsich
wrote:
>
> The RISC-V Zbb extension adds an XLEN (i.e. SImode for rv32, DImode
> for rv64) bswap instruction (rev8). While, with the current master,
> SImode is synthesized correctly from DImode, HImode is not.
>
> This change adds an appropriate ex
On 11/18/21 8:28 PM, Andrew MacLeod wrote:
@@ -376,6 +366,14 @@ range_def_chain::get_def_chain (tree name)
return NULL;
}
+ // Terminate the def chains if we see too many cascading stmts.
+ if (m_logical_depth == param_ranger_logical_depth)
+return NULL;
+
+ // Increase
On Wed, Nov 17, 2021 at 7:25 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> The Linux kernel started to fail compile when the jump threader was improved
> (r12-2591-g2e96b5f14e4025691). This failure was due to the IPA splitting code
> decided now to split off the basic block whi
On Tue, Nov 16, 2021 at 7:05 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Mon, Nov 15, 2021 at 3:00 PM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener via Gcc-patches writes:
> >> > On Fri, Nov 12, 2021 at 7:05 PM Richard Sandiford via Gcc-patches
> >> >
On Tue, Nov 16, 2021 at 5:24 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Wed, Nov 10, 2021 at 1:48 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> This patch extends the reduction code to handle calls. So far
> >> it's a structural change only; a late
Hi!
decl_attributes and its caller cplus_decl_attributes sometimes add
implicit attributes, e.g. optimize attribute if #pragma GCC optimize
is active, target attribute if #pragma GCC target is active, or
e.g. omp declare target attribute if in between #pragma omp declare target
and #pragma omp end
On Tue, Nov 16, 2021 at 3:40 PM Martin Liška wrote:
>
> On 11/11/21 08:15, Richard Biener wrote:
> > So I'd try to do no functional change first, improving the costing and
> > setting up the transform to simply pick up the stmts to "fold" as discovered
> > during analysis (as I hinted you possibly
Excerpts from Iain Sandoe's message of November 19, 2021 10:21 am:
> Hi Iain
>
>> On 19 Nov 2021, at 08:32, Iain Buclaw wrote:
>
>> This patch fixes a stage2 bootstrap failure in the D front-end on
>> darwin due to libgphobos being dynamically linked despite
>> -static-libphobos being on the com
On Thursday, 18 November 2021 20:24:36 CET Jason Merrill wrote:
> On 11/17/21 17:51, Matthias Kretz wrote:
> > Right, I had already added a `gcc_assert (!TMPL_ARGS_HAVE_MULTIPLE_LEVELS
> > (args))` to my new set_non_default_template_args_count function and found
> > cp/ constraint.cc:2896 (get_mapp
On Tue, Nov 16, 2021 at 2:53 PM Martin Liška wrote:
>
> On 11/11/21 08:15, Richard Biener wrote:
> > If you look at simplify_using_entry_checks then this is really really
> > simple,
> > so I'd try to abstract this, recording sth like a unswitch_predicate where
> > we store the condition we unswi
.md (define_peephole2): Variable insn points
to the first matched insn. Use peep2_next_insn(1) to refer to
the second matched insn.
gcc/testsuite/ChangeLog:
* gcc.target/s390/2029.c: New test.
---
gcc/config/s390/s390.md | 2 +-
gcc/testsuite
1 - 100 of 118 matches
Mail list logo
