On Wed, May 26, 2021 at 3:56 PM Jason Merrill wrote:
>
> Ping.
The non-C++ parts are OK.
Richard.
> On 5/17/21 1:58 PM, Jason Merrill wrote:
> > On 5/17/21 3:56 AM, Richard Biener wrote:
> >> On Fri, May 14, 2021 at 2:23 AM Martin Sebor via Gcc-patches
> >> wrote:
> >>>
> >>> On 5/13/21 1:26 P
On 5/28/21 8:41 AM, Richard Biener wrote:
> On Fri, 28 May 2021, Bernd Edlinger wrote:
>
>>
>>
>> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> I was wondering, why gimple-match.c and generic-match.c
>>> are not built early but always last, which slows down parallel
>>> makes significa
On Fri, 28 May 2021, Bernd Edlinger wrote:
>
>
> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> > Hi,
> >
> > I was wondering, why gimple-match.c and generic-match.c
> > are not built early but always last, which slows down parallel
> > makes significantly.
> >
> > The reason seems to be that gen
on 2021/5/27 下午8:55, Richard Sandiford wrote:
> Sorry for the slow reponse.
>
> "Kewen.Lin" writes:
>> diff --git a/gcc/vec-perm-indices.c b/gcc/vec-perm-indices.c
>> index ede590dc5c9..57dd11d723c 100644
>> --- a/gcc/vec-perm-indices.c
>> +++ b/gcc/vec-perm-indices.c
>> @@ -101,6 +101,70 @@ vec_
On 5/26/2021 11:29 AM, Andrew MacLeod via Gcc-patches wrote:
On 5/26/21 7:07 AM, Andrew Pinski wrote:
On Wed, May 26, 2021 at 2:01 AM Andrew Pinski wrote:
On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger
wrote:
On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
On Sun, May 23, 2021
On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> Hi,
>
> I was wondering, why gimple-match.c and generic-match.c
> are not built early but always last, which slows down parallel
> makes significantly.
>
> The reason seems to be that generated_files does not
> mention gimple-match.c and generic-match
On 5/26/2021 5:18 PM, Martin Sebor via Gcc-patches wrote:
While checking objects whose addresses are passed to functions
declared to take const pointers and making sure they're initialized
the GCC 11 -Wmaybe-uninitialized enhancement assumes that the actual
argument is a pointer.
That's norma
Hi,
I was wondering, why gimple-match.c and generic-match.c
are not built early but always last, which slows down parallel
makes significantly.
The reason seems to be that generated_files does not
mention gimple-match.c and generic-match.c.
This comment in Makefile.in says it all:
$(ALL_HOST_OB
On 5/27/21 5:55 PM, David Malcolm wrote:
On Thu, 2021-05-27 at 10:41 -0600, Martin Sebor wrote:
On 5/27/21 5:19 AM, Richard Sandiford wrote:
Thanks for doing this.
Martin Sebor via Gcc-patches writes:
[…]
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Seb
On 5/27/2021 4:28 PM, Segher Boessenkool wrote:
On Thu, May 27, 2021 at 12:58:10PM -0700, H.J. Lu wrote:
You missed:
config/cr16/cr16.md: (clobber (cc0))]
config/cr16/cr16.md: [(parallel [(set (cc0)
config/cr16/cr16.md: [(set (cc0)
config/cr16/cr16.md: [(cc0) (const_int 0)]))]
config/cr1
On 5/27/21 6:07 PM, Matthias Kretz wrote:
On Thursday, 27 May 2021 23:15:46 CEST Jason Merrill wrote:
On 5/27/21 2:54 PM, Matthias Kretz wrote:
Also hiding all inline namespace by default might make some error messages
harder to understand:
namespace Vir {
inline namespace foo {
stru
I chose option A, so everything is a size_t, now.
I also renamed the dyncast functions.
Here's the new patch.
Le jeudi 27 mai 2021 à 18:19 -0400, David Malcolm a écrit :
> On Tue, 2021-05-25 at 20:19 -0400, Antoni Boucher wrote:
> > @David: PING
> >
> > As far as I know, the only remaining questi
Here's the patch with the condition removed.
I believe everything is now fixed.
Thanks!
Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit :
> On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote:
> > I updated the patch according to the comments by Tom Tromey.
> >
> > There's one quest
Hi!
On Fri, May 21, 2021 at 02:45:18PM -0500, Peter Bergner wrote:
> Getting back to this now that trunk is open again...
>
> On 3/31/21 2:17 PM, Segher Boessenkool wrote:
> > On Tue, Mar 30, 2021 at 06:49:29PM -0500, Peter Bergner wrote:
> >> The mma_assemble_input_operand predicate does not acc
On 27.05.21 21:58, Joseph Myers wrote:
On Thu, 27 May 2021, Tobias Burnus wrote:
@Joseph: I CC'ed you in case you have comments regarding
c-parser.c's c_parser_check_balanced_raw_token_sequence
Pilot error on my side – doing three things in parallel
(fixing a patch, updating docs + attending
This patch removes HTML quoting from the Texinfo file gccgo.html.
Committed to mainline.
Ian
diff --git a/gcc/go/gccgo.texi b/gcc/go/gccgo.texi
index ce6b518bb7b..fa0e4882403 100644
--- a/gcc/go/gccgo.texi
+++ b/gcc/go/gccgo.texi
@@ -495,7 +495,7 @@ like (after importing the @code{os} package):
On Thu, May 27, 2021 at 12:58:10PM -0700, H.J. Lu wrote:
> You missed:
>
> config/cr16/cr16.md: (clobber (cc0))]
> config/cr16/cr16.md: [(parallel [(set (cc0)
> config/cr16/cr16.md: [(set (cc0)
> config/cr16/cr16.md: [(cc0) (const_int 0)]))]
> config/cr16/cr16.md: [(set (cc0)
> config/cr16/cr
On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote:
> I updated the patch according to the comments by Tom Tromey.
>
> There's one question left about your question regarding
> C_MAYBE_CONST_EXPR, David:
>
> I am not sure if we can get a C_MAYBE_CONST_EXPR from libgccjit, and
> it
> indeed s
Hi!
Whoops, I forgot to reply to this...
On Wed, May 05, 2021 at 06:25:49PM +, Koning, Paul wrote:
> > void g(void);
> > void h(void);
> > void i(void);
> > void f(long a, long b)
> > {
> >if (a < b)
> >g();
> >if (a == b)
> >h();
> >if
On Tue, 2021-05-25 at 20:19 -0400, Antoni Boucher wrote:
> @David: PING
>
> As far as I know, the only remaining question is about using
> `ssize_t`
> for the return type of some functions.
> Here's why I use this type:
>
> That seemed off to return NULL for the functions returning a
> size_t to
On Thursday, 27 May 2021 23:15:46 CEST Jason Merrill wrote:
> On 5/27/21 2:54 PM, Matthias Kretz wrote:
> > Also hiding all inline namespace by default might make some error messages
> > harder to understand:
> >
> > namespace Vir {
> >inline namespace foo {
> > struct A {};
> >}
> >
On Thu, 2021-05-27 at 10:41 -0600, Martin Sebor wrote:
> On 5/27/21 5:19 AM, Richard Sandiford wrote:
> > Thanks for doing this.
> >
> > Martin Sebor via Gcc-patches writes:
> > > […]
> > > On 5/24/21 5:08 PM, David Malcolm wrote:
> > > > On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
> >
(Resend, the previous version messed up your questions and my answers,
hopefully this time it’s better)
Hi, Richard,
Thanks a lot for your comments.
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Wed, 12 May 2021, Qing Zhao wrote:
Hi,
This is the 3rd versio
On 5/27/21 11:25 AM, Matthias Kretz wrote:
On Thursday, 27 May 2021 17:07:40 CEST Jason Merrill wrote:
On 5/26/21 5:29 PM, Matthias Kretz wrote:
New revision which can also be compiled with GCC 4.8.
From: Matthias Kretz
Ensure dump_template_decl for function templates never prints template
p
On 5/27/21 11:30 AM, Dr. Matthias Kretz wrote:
On Thursday, 27 May 2021 17:18:58 CEST Jason Merrill wrote:
On 5/26/21 5:27 PM, Matthias Kretz wrote:
From: Matthias Kretz
dump_type on 'const std::string' should not print 'const string' unless
TFF_UNQUALIFIED_NAME is requested.
gcc/cp/ChangeLo
On 5/27/21 2:54 PM, Matthias Kretz wrote:
On Thursday, 27 May 2021 19:39:48 CEST Jason Merrill wrote:
On 5/4/21 7:13 AM, Matthias Kretz wrote:
From: Matthias Kretz
This attribute overrides the diagnostics output string for the entity it
appertains to. The motivation is to improve QoI for libr
On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote:
On 4/27/21 1:58 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches
wrote:
PR 90904 notes that auto_vec
On 5/25/21 2:59 AM, Eric Botcazou wrote:
[PATCH 2/11] use xxx_no_warning APIs in Ada.
Looks good to me, but remove the useless pair of parentheses in the 3rd hunk.
The hunk was actually incorrect, thanks for drawing my attention
to it! The second argument to the function is the option. To
There is no need to call ix86_fixup_binary_operands when there are
only one or no memory operands allowed.
2021-05-27 Uroš Bizjak
gcc/
* config/i386/mmx.md (addv2sf3): Do not call
ix86_fixup_binary_operands_no_copy.
(subv2sf3): Ditto.
(mulv2sf3): Ditto.
(v2sf3): Ditto.
On Mon, May 24, 2021 at 1:23 PM Joseph Myers wrote:
>
> On Sat, 22 May 2021, H.J. Lu via Gcc-patches wrote:
>
> > 1. Update PUSH_ARGS to accept an argument. When the PUSH instruction
> > usage is optional, pass the number of bytes to push to PUSH_ARGS so that
> > the backend can decide if PUSH in
Dear Fortranners,
frontend optimization tries to inline matmul, but then it also needs
to take care of the assignment to the result array. If that one is
not of canonical type, we currently get an ICE. The straightforward
solution is to simply punt in those cases and avoid inlining.
Regtested o
1. Replace PUSH_ARGS with a target calls hook, TARGET_PUSH_ARGUMENT, which
takes an integer argument. When it returns true, push instructions will
be used to pass outgoing arguments. If the argument is nonzero, it is
the number of bytes to push and indicates the PUSH instruction usage is
optional
On Thu, May 27, 2021 at 07:58:03PM +, Joseph Myers wrote:
> On Thu, 27 May 2021, Tobias Burnus wrote:
>
> > @Joseph: I CC'ed you in case you have comments regarding
> > c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update)
> > and c_parser_check_tight_balanced_raw_token_sequ
On Mon, May 03, 2021 at 10:55:36PM +, Segher Boessenkool wrote:
> This removes CC0 and all directly related infrastructure.
>
> CC_STATUS, CC_STATUS_MDEP, CC_STATUS_MDEP_INIT, and NOTICE_UPDATE_CC
> are deleted and poisoned. CC0 is only deleted (some targets use that
> name for something else
On Thu, 27 May 2021, Tobias Burnus wrote:
> @Joseph: I CC'ed you in case you have comments regarding
> c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update)
> and c_parser_check_tight_balanced_raw_token_sequence (new); the latter
> is essentially cp_parser_skip_balanced_tokens w
Hi, Richard,
Thanks a lot for your comments.
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Wed, 12 May 2021, Qing Zhao wrote:
Hi,
This is the 3rd version of the patch for the new security feature for GCC.
Please take look and let me know your comments and
Jason, I wonder if you could review this patch that Richard has
apparently decided to defer to others.
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
Thanks
On 5/11/21 2:02 PM, Martin Sebor wrote:
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
On 5
On Thursday, 27 May 2021 19:39:48 CEST Jason Merrill wrote:
> On 5/4/21 7:13 AM, Matthias Kretz wrote:
> > From: Matthias Kretz
> >
> > This attribute overrides the diagnostics output string for the entity it
> > appertains to. The motivation is to improve QoI for library TS
> > implementations,
On Thu, May 27, 2021 at 08:30:33PM +0200, Tobias Burnus wrote:
> + if (c_parser_next_token_is (parser, CPP_NAME))
> +{
> + const char *p = IDENTIFIER_POINTER (c_parser_peek_token
> (parser)->value);
> + bool parse_iter = (strcmp ("iterator", p) == 0);
> + if (parse_iter)
I'd a
@Joseph: I CC'ed you in case you have comments regarding
c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update)
and c_parser_check_tight_balanced_raw_token_sequence (new); the latter
is essentially cp_parser_skip_balanced_tokens with slight adaptions.
On 27.05.21 10:22, Jakub Je
On Linux/x86_64,
04ba00d4ed735242c5284d2c623a3a9d42d94742 is the first bad commit
commit 04ba00d4ed735242c5284d2c623a3a9d42d94742
Author: Uros Bizjak
Date: Thu May 27 09:22:01 2021 +0200
i386: Add uavg_ceil patterns for 4-byte vectors [PR100637]
caused
FAIL: gcc.target/i386/pr100637-3w.c
This testcase revealed that we were using PACK_EXPANSION_EXTRA_ARGS a lot
more than necessary; use_pack_expansion_extra_args_p meant to use it in the
case of corresponding arguments in different argument packs differing in
whether they are pack expansions, but it was mistakenly also returning true
On 5/27/21 11:05 AM, Patrick Palka wrote:
Here, we're not finding the parameter pack inside the static_assert because
STATIC_ASSERT trees are tcc_exceptional, and we weren't explicitly walking
them in cp_walk_subtrees.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trun
On 5/27/2021 10:00 AM, Martin Sebor via Gcc-patches wrote:
When attribute nonnull is applied to an argument of an erroneous
type the attribute positional argument validation function ICEs
while printing a warning that mentions the invalid type.
The attached patch changes the validation functi
On 5/4/21 7:13 AM, Matthias Kretz wrote:
From: Matthias Kretz
This attribute overrides the diagnostics output string for the entity it
appertains to. The motivation is to improve QoI for library TS
implementations, where diagnostics have a very bad signal-to-noise ratio
due to the long namespac
We have been talking for a long time of a debug mode with less impact on
performances.
I propose to simply use the existing _GLIBCXX_ASSERTIONS macro.
libstdc++: [_GLIBCXX_ASSERTIONS] Activate basic debug checks
Use _GLIBCXX_ASSERTIONS as a _GLIBCXX_DEBUG light mode. When
defined it a
On 5/27/21 5:19 AM, Richard Sandiford wrote:
Thanks for doing this.
Martin Sebor via Gcc-patches writes:
[…]
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
Subsequent patches then replace invocations of the TREE_NO_WARNING()
macro and the gimp
When attribute nonnull is applied to an argument of an erroneous
type the attribute positional argument validation function ICEs
while printing a warning that mentions the invalid type.
The attached patch changes the validation function to ignore
erroneous types on the assumption that they must h
On Thursday, 27 May 2021 17:18:58 CEST Jason Merrill wrote:
> On 5/26/21 5:27 PM, Matthias Kretz wrote:
> > From: Matthias Kretz
> >
> > dump_type on 'const std::string' should not print 'const string' unless
> > TFF_UNQUALIFIED_NAME is requested.
> >
> > gcc/cp/ChangeLog:
> > PR c++/100763
On Thursday, 27 May 2021 17:07:40 CEST Jason Merrill wrote:
> On 5/26/21 5:29 PM, Matthias Kretz wrote:
> > New revision which can also be compiled with GCC 4.8.
> >
> > From: Matthias Kretz
> >
> > Ensure dump_template_decl for function templates never prints template
> > parameters after the f
On 5/26/21 5:27 PM, Matthias Kretz wrote:
From: Matthias Kretz
dump_type on 'const std::string' should not print 'const string' unless
TFF_UNQUALIFIED_NAME is requested.
gcc/cp/ChangeLog:
PR c++/100763
* error.c: Call dump_scope when printing a typedef.
+ if (! (f
On 5/26/21 5:29 PM, Matthias Kretz wrote:
New revision which can also be compiled with GCC 4.8.
From: Matthias Kretz
Ensure dump_template_decl for function templates never prints template
parameters after the function name (it did with -fno-pretty-templates)
and skip output of irrelevant & con
Here, we're not finding the parameter pack inside the static_assert because
STATIC_ASSERT trees are tcc_exceptional, and we weren't explicitly walking
them in cp_walk_subtrees.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/99893
On 5/26/21 10:51 PM, Joseph Myers wrote:
This commit breaks the build of glibc for powerpc64le-linux-gnu. Compile
the following code with -O2 -mlong-double-128 -mabi=ibmlongdouble and I
get the error
opts-bug.c:8:1: error: '-mabi=ibmlongdouble' requires '-mlong-double-128'
8 | {
| ^
PING
On Thu, May 13, 2021 at 8:02 PM Aldy Hernandez wrote:
>
>
>
> On 5/12/21 5:08 PM, Jakub Jelinek wrote:
> > On Wed, May 12, 2021 at 05:01:00PM -0400, Aldy Hernandez via Gcc-patches
> > wrote:
> >>
> >> PR c/100521
> >> * gimple-range.cc (range_of_builtin_call): Skip out on
> >>
Matthias Klose writes:
> On 1/18/21 2:55 PM, Gaius Mulley via Gcc-patches wrote:
>> Richard Biener writes:
>>> I've just done ./configure --enable-languages=m2; make -j24
>>>
>>> I would suggest to not rush this in now during stage4
>>> but instead take the opportunity of this "quiet" phase
>>>
On Wed, 26 May 2021, Tim Song wrote:
> On Wed, May 26, 2021 at 1:43 PM Patrick Palka wrote:
> >
> > On Wed, 26 May 2021, Tim Song wrote:
> > >
> > > On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++
> > > wrote:
> > > >
> > > > - else if constexpr (input_iterator<_Out>
> > > > -
On 5/26/21 7:36 PM, Patrick Palka wrote:
This implements the wording changes of CWG 1315, which permits non-type
template arguments in a partial specialization to use template
parameters more freely. Delightfully, it seems the only change needed
is to remove a few checks from process_partial_spe
This patch fixes an ICE in the C FE (discovered by Tobias) when a user
tries to use a dereference of a non-pointer-valued base (e.g. a plain
struct) in an OpenMP clause.
This patch has been tested on a tree that already has the following patches by
Chung-Lin applied:
(a) https://gcc.gnu.org/pip
Sorry for the slow reponse.
"Kewen.Lin" writes:
> diff --git a/gcc/vec-perm-indices.c b/gcc/vec-perm-indices.c
> index ede590dc5c9..57dd11d723c 100644
> --- a/gcc/vec-perm-indices.c
> +++ b/gcc/vec-perm-indices.c
> @@ -101,6 +101,70 @@ vec_perm_indices::new_expanded_vector (const
> vec_perm_indi
2021-05-27 Uroš Bizjak
gcc/
PR target/100637
* config/i386/i386-expand.c (ix86_expand_int_sse_cmp):
For TARGET_XOP bypass SSE comparisons for all supported vector modes.
* config/i386/mmx.md (*xop_maskcmp3): New insn pattern.
(*xop_maskcmp3): Ditto.
(*xop_maskcmp_uns3):
At the moment I sent that patch I remembered that Victor is also
working on vabs, so sorry if this conflicts with his work.
On Thu, 27 May 2021 at 13:21, Christophe Lyon
wrote:
>
> This patch adds support for auto-vectorization of absolute value
> computation using vabs.
>
> We use a similar pat
Joern Rennecke writes:
> At the moment, for a match_dup in a define_cond_exec, you'd have to
> give the number in the
> resulting pattern(s) rather than in the substitute pattern. That's
> not only wrong, but can also
> be impossible when the pattern should apply to multiple patterns with
> diffe
On 5/19/21 3:37 PM, Bernd Edlinger wrote:
> On 5/19/21 3:27 PM, Jonathan Wakely wrote:
>> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * incl
Joern Rennecke writes:
> Bootstrapped on x86_64-pc-linux-gnu.
>
> 2020-12-10 Joern Rennecke
>
> Fix bug in the define_subst handling that made match_scratch unusable for
> multi-alternative patterns.
OK, and sorry for the slow response.
The changelog won't pass, but I'll leave you to
On 1/18/21 2:55 PM, Gaius Mulley via Gcc-patches wrote:
> Richard Biener writes:
>> I've just done ./configure --enable-languages=m2; make -j24
>>
>> I would suggest to not rush this in now during stage4
>> but instead take the opportunity of this "quiet" phase
>> to prepare an integration branch
This patch adds support for auto-vectorization of absolute value
computation using vabs.
We use a similar pattern to what is used in neon.md and extend the
existing neg2 expander to match both 'neg' and 'abs'. This
implies renaming the existing abs2 define_insn in neon.md to
avoid a clash with th
Thanks for doing this.
Martin Sebor via Gcc-patches writes:
> […]
> On 5/24/21 5:08 PM, David Malcolm wrote:
>> On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
>>> Subsequent patches then replace invocations of the TREE_NO_WARNING()
>>> macro and the gimple_no_warning_p() and gimple_set_no
Jakub Jelinek writes:
> On Thu, May 27, 2021 at 01:07:09PM +0800, Hongtao Liu via Gcc-patches wrote:
>> + /* Flag used for call_insn indicates it's a fake call. */
>> + RTX_FLAG (insn, used) = 1;
>
>> + /* CALL_INSN use "used" flag to indicate it's a fake call. */
>> + if (i == STACK
The variable global_options_set is a reflection of which options have
been explicitly set from the command line in the structure
global_options. But it doesn't describe the contents of a
cl_target_option. cl_target_option is a set of options to apply and
once configured should represent a viable
The expression evaluator changes to the range_query API provide
everything determine_value_range does. This patch replaces all uses
with calls into the range_query API.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
* calls.c (get_size_range): Use range_of_expr instead of
determine
Right now, range_of_expr only works with constants, SSA names, and
pointers. Anything else gets returned as VARYING. This patch adds the
capability to deal with arbitrary expressions, inasmuch as these
tree codes are implemented in range-ops.cc.
This will give us the ability to ask for the range
Before the fix to the ranger dependency chain yesterday (commit
7f0cfeb1) I thought an ICE I was seeing was due to my get_range_query
patchet. This was not the case, but this small change crept in while I
was debugging the failure.
I'm reverting the change as was approved.
Tested on x86-64 Linux
As discussed...
This patch moves all the global range code from gimple-range.cc into
value-query.cc. It also moves get_range_info and get_ptr_nonnull from
tree-ssanames.c into their only uses, and removes external access to them.
No functional changes.
Pushed.
gcc/ChangeLog:
* gimple-
Fixed in trunk.
On Thu, May 27, 2021 at 2:32 AM sunil.k.pandey wrote:
>
> On Linux/x86_64,
>
> fe9a499cb8775cfbcea356ab0cae5c365971cf86 is the first bad commit
> commit fe9a499cb8775cfbcea356ab0cae5c365971cf86
> Author: Aldy Hernandez
> Date: Wed May 19 18:27:47 2021 +0200
>
> Convert Wall
On x86-32 warn_ptrdiff_anti_range_add() and warn_int_anti_range()
degrade to the same function so ICF is folding the latter into a call
into the former. This is causing no warnings to be emitted for
warn_int_anti_range.
Fixed by passing -fno-ipa-icf to the test.
Long term, we really should be fi
On Wed, May 26, 2021 at 10:15:28PM +0200, Tobias Burnus wrote:
> @@ -15508,6 +15511,57 @@ c_parser_omp_iterators (c_parser *parser)
>return ret ? ret : error_mark_node;
> }
>
> +/* OpenMP 5.0:
> + affinity ( [aff-modifier :] variable-list )
> + aff-modifier:
> + iterator ( iterators-
2021-05-27 Uroš Bizjak
gcc/
PR target/100637
* config/i386/mmx.md (uavgv4qi3_ceil): New insn pattern.
(uavgv2hi3_ceil): Ditto.
gcc/testsuite/
PR target/100637
* gcc.target/i386/pr100637-3b.c (avgu): New test.
* gcc.target/i386/pr100637-3w.c (avgu): Ditto.
Bootstrapped
Hi,
On Tue, 25 May 2021 at 18:17, Aldy Hernandez via Gcc-patches
wrote:
>
> Adjustments per discussion.
>
> OK pending tests?
>
The xfail removal causes failures on 32 bits platforms (eg arm, or
aarch64 with -mabi=ilp32):
FAIL: gcc.dg/Wstringop-overflow-55.c pr? (test for warnings, line 86)
On Thu, May 27, 2021 at 01:07:09PM +0800, Hongtao Liu via Gcc-patches wrote:
> + /* Flag used for call_insn indicates it's a fake call. */
> + RTX_FLAG (insn, used) = 1;
> + /* CALL_INSN use "used" flag to indicate it's a fake call. */
> + if (i == STACK_POINTER_REGNUM
> + && !
On Wed, May 26, 2021 at 8:41 PM Richard Biener
wrote:
>
> On Wed, May 26, 2021 at 7:06 AM Hongtao Liu wrote:
> >
> > On Tue, May 25, 2021 at 6:24 PM Richard Biener
> > wrote:
> > >
> > > On Mon, May 24, 2021 at 11:52 AM Hongtao Liu wrote:
> > > >
> > > > Hi:
> > > > Details described in PR.
>
On Thu, May 27, 2021 at 7:03 AM Hongtao Liu wrote:
>
> Hi:
> This is an updated patch which implements vzeroupper as call_insn
> which has a special vzeroupper ABI, also in this patch i reverted
> r11-7684, r10-6451, r10-3677 which seems to fix the same issue but in
> a different way.
> Bootst
82 matches
Mail list logo
