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:
> > > > >
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:
> > > > >
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.
-
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
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
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
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
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/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/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
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
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
> >
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
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
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
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
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
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
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
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
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 , const I )
> > > else
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 , const I )
> > else if (results[i]) \
> > abort ()
> > +//
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
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)
-
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
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
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
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
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
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
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
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
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
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
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(+)
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
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
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
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
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
---
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
* 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
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.
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 \
>
> -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
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
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.
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
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
>
* 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
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
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
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
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.
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
> >
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:
>
> *
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 +-
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
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
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
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
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
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 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
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
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,
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
Please find attache a patch for PR39695
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 symbol's namespace (ns).
84 matches
Mail list logo
