ping
On Tue, Apr 14, 2020 at 2:53 PM Kito Cheng wrote:
> - The alignment for local variable was adjust during
> estimate_stack_frame_size,
>however it seems wrong spot to adjust that, expand phase will adjust
> that
>but it little too late to some gimple optimization, which rely on
> ce
Please find attached a patch for PR39695 (this time it is attached).
Commit message:
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result
The following testcase shows a missed optimization that then leads to
wrong-code when issueing SMed stores on exits. When we were able to
compute an ordered sequence of stores for an exit we need to emit
that in the correct order and we can emit it disregarding to any
conditional for whether a sto
The command line option to enable Armv8.1-M Mainline Security Extensions
has a typo and this patch corrects it.
Committed it under the obvious rule.
### Attachment also inlined for ease of reply###
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.ht
When TARGET_VTABLE_USES_DESCRIPTORS is defined then function pointers in
the vtable are output by ASM_OUTPUT_FDESC. The only current user of
this is ia64, but its implementation of ASM_OUTPUT_FDESC lacks a call to
assemble_external. Thus if there is no other reference to the function
the weak dec
On Mon, May 18, 2020 at 9:27 AM Kito Cheng wrote:
>
> ping
>
> On Tue, Apr 14, 2020 at 2:53 PM Kito Cheng wrote:
>>
>> - The alignment for local variable was adjust during
>> estimate_stack_frame_size,
>>however it seems wrong spot to adjust that, expand phase will adjust that
>>but it
This fixes always-inlining across -fnon-call-exception boundaries
for conditions which we do not allow to throw.
Bootstrapped and tested onx x86_64-unknown-linux-gnu, applied.
2020-05-18 Richard Biener
PR middle-end/95171
* tree-inline.c (remap_gimple_stmt): Split out trapping
Hi.
The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used with -fstack-protector-explicit).
First par
On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
> The patch adds new no_stack_protect attribute. The change is requested
> from kernel folks and is direct equivalent of Clang's no_stack_protector.
> Unlike Clang, I chose to name it no_stack_protect because we already
> have stack_prot
On 5/18/20 12:41 PM, Jakub Jelinek wrote:
On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_prote
On Mon, May 18, 2020 at 01:00:01PM +0200, Martin Liška wrote:
> On 5/18/20 12:41 PM, Jakub Jelinek wrote:
> > On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
> > > The patch adds new no_stack_protect attribute. The change is requested
> > > from kernel folks and is direct equivalent o
On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> > The optimize attribute is used to specify that a function is to be compiled
> > with different optimization options than specified on the command line.
> > ```
> >
> > It's pretty clear about the command line arguments (that are ig
ChangeLog:
2020-05-18 Alex Coplan
* MAINTAINERS (Write After Approval): Add myself.
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 336346a37a5..5528aad5e23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -353,6 +353,7 @@ William Cohen
Michael C
* Martin Liška:
> The patch adds new no_stack_protect attribute. The change is requested
> from kernel folks and is direct equivalent of Clang's no_stack_protector.
> Unlike Clang, I chose to name it no_stack_protect because we already
> have stack_protect attribute (used with -fstack-protector-ex
On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> > > The optimize attribute is used to specify that a function is to be
> > > compiled
> > > with different optimization options than specified on the command l
On Wed, May 13, 2020 at 12:48 PM Marco Elver wrote:
> > Hello, Jakub,
> >
> > On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov wrote:
> > >
> > > On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote:
> > > >
> > > > On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > > > > FWIW this is:
Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
and Tiger Lake processor families.
OK for master?
Thanks.
H.J.
--
* config/i386/driver-i386.c (host_detect_local_cpu): Support
Intel Airmont, Tremont, Comet Lake, Ice Lake and Tiger Lake
processor fami
On Mon, May 18, 2020 at 1:58 PM H.J. Lu wrote:
>
> Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> and Tiger Lake processor families.
>
> OK for master?
OK.
Please also update cpuinfo.c from libgcc and corresponding
gcc.target/i386/builtin_target.c testcase.
Thanks,
Uro
On Mon, May 18, 2020 at 5:18 AM Uros Bizjak wrote:
>
> On Mon, May 18, 2020 at 1:58 PM H.J. Lu wrote:
> >
> > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> > and Tiger Lake processor families.
> >
> > OK for master?
>
> OK.
I am checking in my patch.
> Please also upd
On Fri, May 15, 2020 at 10:48:56PM +, Joseph Myers wrote:
> On Fri, 15 May 2020, Jozef Lawrynowicz wrote:
>
> > The attached patch fixes many GCC and G++ tests for 16-bit targets. These
> > targets can have the following properties:
> > - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types
On Mon, May 18, 2020 at 2:34 PM H.J. Lu wrote:
>
> On Mon, May 18, 2020 at 5:18 AM Uros Bizjak wrote:
> >
> > On Mon, May 18, 2020 at 1:58 PM H.J. Lu wrote:
> > >
> > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> > > and Tiger Lake processor families.
> > >
> > > OK
On Sun, 2020-05-17 at 18:42 -0400, David Malcolm via Gcc-patches wrote:
> On Sun, 2020-05-17 at 18:39 -0400, David Malcolm via Gcc-patches
> wrote:
> > On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
>
> [...snip...]
>
> > How about something like this (though I even haven't checked if it
On Mon, May 18, 2020 at 5:43 AM Uros Bizjak wrote:
>
> On Mon, May 18, 2020 at 2:34 PM H.J. Lu wrote:
> >
> > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak wrote:
> > >
> > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu wrote:
> > > >
> > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lak
Hi,
This patch for PR d/92216 was already applied to mainline before the
GCC-10 release, however due to a second bug report (PR d/95184)
against the GCC-9 release, I've decided it's best to apply it there too.
Backport is a merge of r10-7199 and r10-7504.
Bootstrapped and regression tested on x8
This adjusts the way we compute the stmt insert location for
invariants in BB vectorization context to deal with eventually
sharing invariant SLP nodes for multiple uses. We can no longer
use a single use stmt location then but there's a simple way out.
Bootstrapped and tested on x86_64-unknown
Hi David,
On Sun, 2020-05-17 at 18:53 -0400, David Malcolm wrote:
> BTW, it looks like it's using the wrong location for event (2). It
> ought to be showing a call to "signal", not an assignment. Please can
> you file a bug about this, and attach the source in question so I can
> take a look at
Hi,
Looking at the results of building all targets (with D the front-end),
I noticed this configuration failed due to support being removed in
SVN r263506.
OK?
Regards,
Iain.
---
contrib/ChangeLog:
* config-list.mk (LIST): Remove rs6000-ibm-aix5.3.0.
---
contrib/config-list.mk | 2 +-
On Mon, May 18, 2020 at 9:38 AM Iain Buclaw wrote:
>
> Hi,
>
> Looking at the results of building all targets (with D the front-end),
> I noticed this configuration failed due to support being removed in
> SVN r263506.
>
> OK?
>
> Regards,
> Iain.
>
> ---
> contrib/ChangeLog:
>
> * config-
Hello,
On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
> > The patch adds new no_stack_protect attribute. The change is requested
> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
> > Unlike Clang, I chose to name it no_stack_protect because we already
> > h
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2020-05-18 Richard Biener
* tree-vectorizer.h (_slp_tree::vectype): Add field.
(SLP_TREE_VECTYPE): New.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_VECTYPE.
(vec
Hi,
I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on
external and invariant SLP nodes to avoid (re-)computing that
in other places. The responsible entity for specifying the
desired vector type is vectorizable_* - vectorization analysis
of the user (when we start to share those n
On 18/05/2020 04:20, duanbo (C) wrote:
> Hi,
>
> This changes the definition of Pmode for aarch64 port.
> Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even
> under ILP32.
> Because of that definition, machine mode of symbol_ref which is supposed to
> be SImode becomes D
Hi David,
On Mon, May 18, 2020 at 08:45:36AM -0400, David Malcolm wrote:
> Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can delay
> calling replacement_fn until inside signal_unsafe_call::emit, after the
> warning has been emitted.
>
> It could even become a member function of si
* Michael Matz:
> Hello,
>
> On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
>
>> > The patch adds new no_stack_protect attribute. The change is requested
>> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
>> > Unlike Clang, I chose to name it no_stack_protec
On Mon, 2020-05-18 at 16:47 +0200, Mark Wielaard wrote:
> Hi David,
>
> On Mon, May 18, 2020 at 08:45:36AM -0400, David Malcolm wrote:
> > Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can
> > delay
> > calling replacement_fn until inside signal_unsafe_call::emit, after
> > the
> >
Hi David,
On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote:
> On Mon, 2020-05-18 at 16:47 +0200, Mark Wielaard wrote:
> > On Mon, May 18, 2020 at 08:45:36AM -0400, David Malcolm wrote:
> > > Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can
> > > delay
> > > calling re
gcc/ChangeLog:
2020-05-18 Uroš Bizjak
* config/i386/i386-expand.c (ix86_expand_fp_absneg_operator):
Do not emit FLAGS_REG clobber for TFmode.
* config/i386/i386.md (*tf2_1): Rewrite as
define_insn_and_split. Mark operands 1 and 2 commutative.
(*nabstf2_1): Ditto.
(absn
Richard Biener writes:
> Hi,
>
> I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on
> external and invariant SLP nodes to avoid (re-)computing that
> in other places.
Nice.
> The responsible entity for specifying the
> desired vector type is vectorizable_* - vectorization analysis
>
> -Original Message-
> From: Kyrylo Tkachov
> Sent: 15 May 2020 11:57
> To: Alex Coplan ; gcc-patches@gcc.gnu.org
> Cc: nd ; ni...@redhat.com; Richard Earnshaw
> ; Ramana Radhakrishnan
>
> Subject: RE: [PATCH] [arm] Don't generate invalid LDRD insns
>
> Hi Alex,
>
> > -Original Mes
Hello,
On Mon, 18 May 2020, Florian Weimer wrote:
> >> In glibc, we already have this:
> >>
> >> /* Used to disable stack protection in sensitive places, like ifunc
> >>resolvers and early static TLS init. */
> >> #ifdef HAVE_CC_NO_STACK_PROTECTOR
> >> # define inhibit_stack_protector \
> >
gcc/ChangeLog:
2020-05-18 Uroš Bizjak
PR target/95169
* config/i386/i386-expand.c (ix86_expand_int_movcc):
Avoid reversing a non-trapping comparison to a trapping one.
testsuite/ChangeLog:
2020-05-18 Uroš Bizjak
PR target/95169
* gcc.target/i386/pr95169.c: New test.
* Michael Matz:
>> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
>> all for some reason, the frame pointer is always missing?
>
> Not for me:
I see. I didn't know that -fno-omit-frame-pointer only applies to
non-leaf functions. For them, the behavior I see matches yo
Hello,
On Mon, 18 May 2020, Florian Weimer wrote:
> * Michael Matz:
>
> >> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
> >> all for some reason, the frame pointer is always missing?
> >
> > Not for me:
>
> I see. I didn't know that -fno-omit-frame-pointer only app
I've gone ahead and pushed this patch to the website.
No new validation errors.
---
htdocs/gcc-10/changes.html | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 2bc25d92..abbafa58 100644
--- a/htdocs
On 5/16/20 4:43 AM, Richard Sandiford wrote:
Sorry for the empty subject line earlier...
Jason Merrill writes:
On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:
On 5/15/20 8:08 AM, Richard Sandiford wrote:
Those are all good examples. Mind putting that into a patch
for the coding conven
Hi,
I do not have write permissions. I was wondering if I could get write
after approval permissions. I'm new to GCC but I would like to
contribute as much as I can, even if it is just small fixes on
documentations like the ones discussed here.
Thanks!
On 16/05/2020 19:57, Richard Biener wr
On Mai 18 2020, Florian Weimer via Gcc-patches wrote:
> * Michael Matz:
>
>>> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
>>> all for some reason, the frame pointer is always missing?
>>
>> Not for me:
>
> I see. I didn't know that -fno-omit-frame-pointer only applie
On 5/10/20, Eric Gallager wrote:
> On 1/10/20, Jason Merrill wrote:
>> Back in 2009 Manuel sent a patch to avoid useless -Wconversion warnings
>> on compound assignment of types that get promoted to int:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html
>>
>> Joseph argued that those
Already fixed by r10-8124-gceae6a13366d9646e172fc943fe8e221b70f0920.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/95143
* g++.dg/cpp0x/sfinae66.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/sfinae66.C | 32 +++
1 file changed, 32 insertions(+)
crea
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 virtuals, and thus provide a general repository to do all
things subst &
Martin Sebor writes:
> On 5/16/20 4:43 AM, Richard Sandiford wrote:
>> Sorry for the empty subject line earlier...
>>
>> Jason Merrill writes:
>>> On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:
>>>
On 5/15/20 8:08 AM, Richard Sandiford wrote:
>> Those are all good examples. Mind
We already moved the value_range class into its own class in the last
release. I think it's time to move the value_range_equiv stuff into its
own class, as it's a distraction from the VRP code.
I've moved it to value-range-equiv.*, and gave it a semblance of order,
by putting the constructors
On May 18, 2020 7:59:45 PM GMT+02:00, Aldy Hernandez via Gcc-patches
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
As a follow-up to the patch moving array bounds checking into its own
class, this moves the class into its own files. As I've mentioned
previously, having it in tree-vrp just pollutes the file with unrelated
stuff.
Jeff, I know you've mentioned you'd like to move the array bounds
checking to
On 5/18/20 2:02 PM, Richard Sandiford wrote:
Martin Sebor writes:
On 5/16/20 4:43 AM, Richard Sandiford wrote:
Sorry for the empty subject line earlier...
Jason Merrill writes:
On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:
On 5/15/20 8:08 AM, Richard Sandiford wrote:
Those are all
Hi Peter and Segher,
> > You should always CC the PPC maintainers on PPC patches.
> > I've CC'd both Segher and David.
Thanks a lot for doing that. And well understood for future patches.
> > >>> This commit adds a powerpc_vsx_ok dg-require-effective-target directive
> > >>> to that test, and th
On 5/16/20 6:33 PM, Marek Polacek wrote:
Current cfns.h includes register-qualified variables and that wouldn't
play well when bootstrapping with GCC that uses the C++17 dialect,
because 'register' was removed in C++17. Regenerating it using the
command specified in cfns.h luckily cleaned this u
On 5/16/20 6:33 PM, Marek Polacek wrote:
This feels extremely obscure but at least it's an opportunity to fix the
comments. P0002R1 removed deprecated operator++(bool) in C++17 so let's
avoid adding a builtin overload candidate for ++ when the type is bool.
Bootstrapped/regtested on x86_64-pc-l
The validator triggered on another file that was recently edited,
and searching our whole tree for similar occurrences these two are
the remaining ones.
The only drawback is that ids must not start with a digit, so I used
ids in line with what we have in gcc-3.2/changes.html and later.
(I believe
On 5/16/20 6:32 PM, Marek Polacek wrote:
+ const int q1 = cp_type_quals (pointee1);
+ const int q2 = cp_type_quals (pointee2);
+ const int quals = q1 | q2;
result_type = cp_build_qualified_type (result_type,
-(cp_type_quals (pointee1)
-
On 5/16/20 6:34 PM, Marek Polacek wrote:
Since GCC 9, C++17 support is no longer experimental. It was too late
to change the default C++ dialect to C++17 in GCC 10, but I think now
it's time to pull the trigger (C++14 was made the default in GCC 6.1).
We're still missing two C++17 library featur
On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote:
> > --- a/libgomp/testsuite/libgomp.c++/for-27.C
> > +++ b/libgomp/testsuite/libgomp.c++/for-27.C
> > @@ -151,6 +151,12 @@ f4 (const I &x, const I &y)
> > else if (results[i]) \
> > abort ()
> > +/
On Mon, May 18, 2020 at 10:04:07PM +0200, Jakub Jelinek wrote:
> On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote:
> > > --- a/libgomp/testsuite/libgomp.c++/for-27.C
> > > +++ b/libgomp/testsuite/libgomp.c++/for-27.C
> > > @@ -151,6 +151,12 @@ f4 (const I &x, const I &y)
> > > el
In a couple of places in build_over_call we were calling
cp_stabilize_reference but only using the result once, so it isn't needed.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-05-18 Jason Merrill
* call.c (build_over_call): Remove unnecessary
cp_stabil
On Mon, May 18, 2020 at 03:50:55PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/16/20 6:32 PM, Marek Polacek wrote:
> > + const int q1 = cp_type_quals (pointee1);
> > + const int q2 = cp_type_quals (pointee2);
> > + const int quals = q1 | q2;
> > result_type = cp_build_qualified_type (
On 5/18/20 4:37 AM, Martin Liška wrote:
Hi.
The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used wit
On 5/13/20 12:22 PM, Marek Polacek wrote:
DR 2289 clarified that since structured bindings have no C compatibility
implications, they should be unique in their declarative region, see
[basic.scope.declarative]/4.2.
The duplicate_decls hunk is the gist of the patch, but that alone would
not be en
On 5/11/20 9:10 AM, Patrick Palka wrote:
It looks like hash table sanitization is now safe to enable for the
decl_specializations and type_specializations tables, probably ever
since PR94454 was fixed.
Bootstrapped and regtested on x86_64-pc-linux-gnu with the attached
debugging patch that makes
On 5/7/20 12:47 PM, Patrick Palka wrote:
In fn_type_unifcation, we are passing NULL_TREE as the 'in_decl'
parameter to coerce_template_parms, and this is causing template
type/value mismatch error messages to get suppressed regardless of the
value of 'complain'.
This means that when substitution
On 5/8/20 2:16 PM, Martin Sebor wrote:
-Wclass-memaccess is suppressed for write accesses to trivially
copyable but otherwise nontrivial class types by character types
but the suppression neglects to consider the equivalent accesses
by std::byte. The attached patch extends the same privilege als
Hi!
On Mon, May 18, 2020 at 11:54:31AM -0700, Joel Brobecker wrote:
> > (Don't forget the changelog?)
>
> Thank you, Segher. Pushed to master, and for 8, 9 and 10.
Thanks!
> I did include the ChangeLog indeed. I tend to avoid sending them
> in the diff, because they usually don't apply out of t
On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/13/20 12:22 PM, Marek Polacek wrote:
> > DR 2289 clarified that since structured bindings have no C compatibility
> > implications, they should be unique in their declarative region, see
> > [basic.scope.declarati
On 5/7/20 7:03 PM, Marek Polacek wrote:
On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote:
Hi,
On 29/01/20 19:00, Jason Merrill wrote:
On 1/29/20 4:31 AM, Paolo Carlini wrote:
Hi,
in this regression we issue a diagnostic about an incomplete type
(only a warning by default) and th
On 5/7/20 9:57 PM, Marek Polacek wrote:
On Thu, May 07, 2020 at 06:09:30PM -0600, Martin Sebor wrote:
On 5/7/20 5:03 PM, Marek Polacek via Gcc-patches wrote:
On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote:
Hi,
On 29/01/20 19:00, Jason Merrill wrote:
On 1/29/20 4:31 AM, Paolo C
On 5/7/20 10:55 AM, Marek Polacek wrote:
On Wed, May 06, 2020 at 05:26:32PM -0400, Jason Merrill wrote:
On 5/5/20 6:17 PM, Marek Polacek wrote:
An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles
On 5/6/20 4:31 PM, Marek Polacek wrote:
Since r10-6527 fold_for_warn calls maybe_constant_value, which means it
can fold more than it previously could. In this testcase it means that
cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able
to fold op1 to an INTEGER_CST. But then
On 5/18/20 12:02 PM, Richard Sandiford wrote:
Martin Sebor writes:
On 5/16/20 4:43 AM, Richard Sandiford wrote:
Sorry for the empty subject line earlier...
Jason Merrill writes:
On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:
On 5/15/20 8:08 AM, Richard Sandiford wrote:
Those are al
Greetings,
The attached patch is proposed for rs6000/linux64.h.
The problem it addresses is that the current checking only tests for
existence not for an incompatible/compatible setting.
For example:
$ powerpc64-linux-gnu-gcc -mcmodel=medium -mminimal-toc foo.c
is an incompatible set of swit
On Mon, May 18, 2020 at 05:24:58PM +0200, Mark Wielaard wrote:
> On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote:
> > Overall, I like it, but it looks like there's a problem with the
> > location of the fix-it hint: it looks like it might be replacing the
> > whole of the underlined s
On Tue, May 19, 2020 at 01:19:13AM +0200, Mark Wielaard wrote:
> On Mon, May 18, 2020 at 05:24:58PM +0200, Mark Wielaard wrote:
> > On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote:
> > > Overall, I like it, but it looks like there's a problem with the
> > > location of the fix-it hint
Hi,
After having so much trouble working on the `execute' function inside
gcc.c, I decided to refactor it so that it could be more digestible.
Since I am using it on my branch, I am submitting this patch for
"battlefield" testing.
Bootstrapped and ran the testsuite on Linux x86_64.
-
Refact
On Mon, May 18, 2020 at 5:57 AM H.J. Lu wrote:
>
> On Mon, May 18, 2020 at 5:43 AM Uros Bizjak wrote:
> >
> > On Mon, May 18, 2020 at 2:34 PM H.J. Lu wrote:
> > >
> > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak wrote:
> > > >
> > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu wrote:
> > > > >
>
On Tue, May 19, 2020 at 4:17 AM H.J. Lu wrote:
>
> On Mon, May 18, 2020 at 5:57 AM H.J. Lu wrote:
> >
> > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak wrote:
> > >
> > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu wrote:
> > > >
> > > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak wrote:
> > > > >
>
This fixes an integer overflow warning that ultimatively happens because
of TREE_OVERFLOW propagating through transforms and the existing guard
against this,
375 if (TREE_OVERFLOW_P (ret)
376 && !TREE_OVERFLOW_P (op0)
377 && !TREE_OVERFLOW_P (op1))
378
Jiufu Guo writes:
Hi,
I'd like to ping this patch for trunk on stage 1.
This patch could fix the issue on incorrect COUNT/FREQUENCES of loop
unrolled blocks, and also could help the improve the cold/hot issue of
the unrolled loops.
patch is also at
https://gcc.gnu.org/legacy-ml/gcc-patches/202
Committed, thanks :)
On Wed, May 13, 2020 at 6:37 AM Jim Wilson wrote:
> On Sun, Apr 12, 2020 at 7:54 PM Kito Cheng wrote:
> > On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson wrote:
> > > Do we really need this now? It is a new feature not a bug fix, so it
> > > might be better to wait until we re
This documents new GCC 10 behavior on diagnostic options and -flto.
Looks OK?
Thanks,
Richard.
2020-05-19 Richard Biener
PR lto/95190
* doc/invoke.texi (flto): Document behavior of diagnostic
options.
---
gcc/doc/invoke.texi | 8
1 file changed, 8 insertio
While bootstrapping GCC on S/390 the following warning is raised:
gcc/fortran/matchexp.c: In function 'match match_level_5(gfc_expr**)':
gcc/fortran/matchexp.c:401:18: error: 'e' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
401 |gfc_free_expr (e);
|
88 matches
Mail list logo
