Thank you (and others) for your answers. Now I'm just as smart as before,
however.
Is it a supported, documented, 'long term' feature we can rely on or not?
If yes, I would expect it to be properly documented. If not, never mind.
> Gesendet: Montag, 19. August 2019 um 16:08 Uhr
> Von:
On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
>> References to dependencies on really, really old versions of
>> binutils (talking 10+ years here) which I think we can remove.
>> Let me follow-up with some of you with concrete suggestions
>> around that.
>
> The alpha*-*-* section currently has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #8 from Bernd Edlinger ---
Author: edlinger
Date: Tue Aug 20 05:32:49 2019
New Revision: 274691
URL: https://gcc.gnu.org/viewcvs?rev=274691=gcc=rev
Log:
2019-08-20 Bernd Edlinger
PR middle-end/89544
* function.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18206
Eric Gallager changed:
What|Removed |Added
Component|target |driver
--- Comment #4 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210
Eric Gallager changed:
What|Removed |Added
Depends on||44209
Summary|Extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91495
Bug ID: 91495
Summary: std::transform_reduce with unary op is implemented in
the parallel case but not the basic case
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Hello.
The deadline for final evaluations is 26th of August and there are
certain things that I need to submit along with the code.
A link has to be submitted of the codes that I have written and I am
thinking of doing it as a github gist along with links to commits to
my gcc fork. I know that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91494
Bug ID: 91494
Summary: Performance Regression when upgrading from 8.3.0 to
9.0
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433
--- Comment #2 from George Fan ---
The compiler option for botan is "-fstack-protector -m64 -pthread -lbotan-2
-ldl -lrt", which the compiler option for crafty is "-pthread -lstdc++
-fprofile-use -lm". While the sub-architecture is coffee lake.
On 8/19/19 8:10 AM, Richard Biener wrote:
On Sat, Aug 17, 2019 at 12:43 AM Martin Sebor wrote:
With the recent enhancement to the strlen handling of multibyte
stores the g++.dg/warn/Warray-bounds-4.C for zero-length arrays
started failing on hppa (and probably elsewhere as well). This
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91493
Bug ID: 91493
Summary: g++ 9.2.1 crashes compiling clickhouse
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
--- Comment #3 from dave.anglin at bell dot net ---
On 2019-08-19 2:51 a.m., rguenth at gcc dot gnu.org wrote:
> Is this a new failure, thus can it be bisected somehow?
The failure was introduced in r273662:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91347
--- Comment #18 from dave.anglin at bell dot net ---
On 2019-08-19 4:36 a.m., ebotcazou at gcc dot gnu.org wrote:
> Created attachment 46728
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46728=edit
> Execution test
Works on hppa without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91492
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
On Mon, Aug 19, 2019 at 5:01 AM Segher Boessenkool
wrote:
>
> On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > --- a/configure
> > +++ b/configure
> > @@ -754,6 +754,7 @@ infodir
> > docdir
> > oldincludedir
> > includedir
> > +runstatedir
> > localstatedir
> >
On Mon, 2019-08-19 at 17:05 -0600, Jeff Law wrote:
>
> There's a real good chance Martin Liska has already fixed this. He's
> made a couple fixes in the last week or so with the interactions
> between
> the GC system and the symbol tables.
>
>
> 2019-08-15 Martin Liska
>
> PR
On 8/19/19 4:59 PM, Steve Ellcey wrote:
> I was wondering if anyone could help me investigate a bug I am
> seeing in the GCC garbage collector. This bug (which may or may not
> be PR 89179) is causing a segfault in GCC, but when I try to create
> a preprocessed source file, the bug doesn't
On 8/12/19 9:21 AM, Dragan Mladjenovic wrote:
> On 09.08.2019. 23:31, Jeff Law wrote:
>> On 8/5/19 4:47 AM, Dragan Mladjenovic wrote:
>>> From: "Dragan Mladjenovic"
>>>
>>> gcc/ChangeLog:
>>>
>>> 2019-08-05 Dragan Mladjenovic
>>>
>>> * config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define
On 8/15/19 1:47 PM, Bernd Edlinger wrote:
> On 8/15/19 6:29 PM, Richard Biener wrote:
Please split it into the parts for the PR and parts making the
asserts not trigger.
>>> Yes, will do.
>>>
> Okay, here is the rest of the PR 89544 fix,
> actually just an optimization, making the
I was wondering if anyone could help me investigate a bug I am seeing
in the GCC garbage collector. This bug (which may or may not be PR
89179) is causing a segfault in GCC, but when I try to create a
preprocessed source file, the bug doesn't trigger. The problem is with
the garbage collector
On 8/19/19 1:53 PM, Matthew Beliveau wrote:
>> Jeff
>
> DSE-3.patch
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-08-19 Matthew Beliveau
>
> * tree-ssa-dse.c (dse_optimize_redundant_stores): Improved check to
> catch more redundant zero initialization
On 8/18/19 10:29 AM, Gerald Pfeifer wrote:
> On Sat, 9 Dec 2017, Jakub Jelinek wrote:
>>> Some users on FreeBSD noticed a problem when trying to use GCC to
>>> build things in a standalone environment that manifests itself as
>>>
>>>
On 8/19/19 10:19 AM, Steve Kargl wrote:
> On Mon, Aug 19, 2019 at 09:08:12AM -0600, Jeff Law wrote:
>> On 8/19/19 3:11 AM, Mark Eggleston wrote:
>>> The intrinsics DIM, MOD and MODULO can accept arguments of different
>>> kinds and return values with the larger of the two kinds. Notes to this
>>>
On Tue, 30 Jul 2019, Martin Sebor wrote:
> On 7/30/19 1:13 AM, Akshat Garg wrote:
> > Hi,
> > This patch includes C front-end code for a type qualifier _Dependent_ptr.
>
> Just some very high-level comments/questions. I only followed
> the _Dependent_ptr discussion from a distance and I'm
On 8/19/19 9:24 AM, Richard Sandiford wrote:
> This patch adds a flag that tells targets whether an argument
> has been converted to pass-by-reference form. This replaces
> assign_parm_data_one::passed_pointer in function.c.
>
> The flag is set automatically for places that call
>
On 8/19/19 9:23 AM, Richard Sandiford wrote:
> This patch makes the two main calls.c argument-processing
> routines track the state of the argument in a function_arg_info
> instead of using separate mode variables.
>
>
> 2019-08-19 Richard Sandiford
>
> gcc/
> * calls.c
On 8/19/19 9:22 AM, Richard Sandiford wrote:
> This patch adds a function_arg_info field to assign_parm_data_one,
> so that:
>
> - passed_type -> arg.type
> - promoted_mode -> arg.mode
> - named_arg -> arg.named
>
> We can then pass this function_arg_info directly to the converted
> hooks.
On Tue, 30 Jul 2019, Jakub Jelinek wrote:
> Furthermore, some comments claimed that the proper EXCESS_PRECISION_STANDARD
> handling requires FE support, but that also doesn't seem to be the case
> these days, some FEs even just use EXCESS_PRECISION_STANDARD by default
> (go, D).
>
> So, the
On 16/08/19 16:35 +0100, Jonathan Wakely wrote:
The x86 attributes such as ms_abi, stdcall, fastcall etc. alter the
function type, which means that functions with one of those attributes
do not match any of the partial specializations of std::is_function.
Rather than duplicating the list for
This Go patch by Than McIntosh adds some new debugging output
methods/functions, to dump named objects, package bindings, and the
top level Gogo package list. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On 8/19/19 9:21 AM, Richard Sandiford wrote:
> This patch adds a helper routine that applies pass-by-reference
> semantics to an existing function_arg_info.
>
> The c6x part means that c6x_function_arg and c6x_function_arg_advance
> see the same "named" value as pass_by_reference did, rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79817
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 8/19/19 9:20 AM, Richard Sandiford wrote:
> Use function_arg_info for TARGET_MUST_PASS_IN_STACK.
>
> The hook is passed the promoted mode instead of the original type mode.
>
> The expr.h reference in the documentation is no longer correct, but
> pointing to calls.h or calls.c doesn't help
I've merged trunk revision 274678 to the gccgo branch.
Ian
On 8/19/19 9:19 AM, Richard Sandiford wrote:
> Use function_arg_info for TARGET_CALLEE_COPIES.
>
> The hook is passed the unpromoted type mode instead of the promoted mode.
>
> The aarch64 definition is redundant, but worth keeping for emphasis.
>
>
> 2019-08-19 Richard Sandiford
>
> gcc/
On 8/19/19 9:18 AM, Richard Sandiford wrote:
> Use function_arg_info for TARGET_FUNCTION_ARG_ADVANCE.
>
> There seems to be a bit of confusion around this one. Almost all
> callers pass the same arguments as TARGET_FUNCTION_ARG, meaning
> that the mode is the promoted mode rather than the type
On 8/19/19 9:16 AM, Richard Sandiford wrote:
> This patch makes both TARGET_FUNCTION_ARG and
> TARGET_FUNCTION_INCOMING_ARG take a function_arg_info.
> They have to be done together since many targets use the
> same function for both.
>
> The hooks are passed the promoted mode instead of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #31 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #28)
> (In reply to Richard Biener from comment #26)
> > This is the powers of simplify_subreg I guess. We're lucky it doesn't do
> > this to arbitrary arithmetic.
> >
> >
On 8/19/19 9:16 AM, Richard Sandiford wrote:
> Use function_arg_info for TARGET_SETUP_INCOMING_ARGS.
>
> The hook is passed the promoted mode instead of the original type mode.
>
>
> 2019-08-19 Richard Sandiford
>
> gcc/
> * target.def (setup_incoming_varargs): Take a
On 8/19/19 9:15 AM, Richard Sandiford wrote:
> Use function_arg_info for TARGET_PASS_BY_REFERENCE.
>
> The hook is passed the unpromoted type mode instead of the promoted mode.
>
>
> 2019-08-19 Richard Sandiford
>
> gcc/
> * target.def (pass_by_reference): Take a function_arg_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91484
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
On 8/19/19 9:14 AM, Richard Sandiford wrote:
> This patch adds the function_arg_info class and uses it for
> TARGET_ARG_PARTIAL_BYTES.
>
> The hook is passed the promoted mode instead of the original type mode.
>
> The arguments aren't mentioned in the documentation, which is why the
>
> It also seems like rather than checking for ebpf on files with large
> stacks, we should be using the generic mechanisms to defined the
allowed
> size of the stack (mentioned in prior review) & mark test which use
too
> much space. This would almost certainly
In addition to Segher's comments:
jema...@gnu.org (Jose E. Marchesi) writes:
> [...]
> +/* This file contains the definition of the kernel helpers that are
> + available to eBPF programs.
> +
> + The primary source for information on kernel helpers is the
> + linux/include/uapi/linux/bpf.h
Hello,
This should have the changes you wanted!
Thank you,
Matthew Beliveau
On Fri, Aug 16, 2019 at 12:30 PM Jeff Law wrote:
>
> On 8/13/19 9:09 AM, Matthew Beliveau wrote:
> > Hello,
> >
> > This should have the changes you all asked for! Let me know if I
> > missed anything!
> >
> > Thank
On 8/19/19 9:12 AM, Richard Sandiford wrote:
> This patch splits out another idiom from the va_arg gimplification
> routines, so that there's only one place to update later.
>
>
> 2019-08-19 Richard Sandiford
>
> gcc/
> * calls.h (must_pass_va_arg_in_stack): Declare.
> * calls.c
On 8/19/19 9:11 AM, Richard Sandiford wrote:
> This patch splits out a common idiom from the va_arg gimplification
> routines, so that there's only one place to update later.
>
>
> 2019-08-19 Richard Sandiford
>
> gcc/
> * calls.h (pass_va_arg_by_reference): Declare.
> * calls.c
On 8/19/19 8:23 AM, Jose E. Marchesi wrote:
>
> [...]
> > * gcc.dg/Wframe-larger-than-2.c: Likewise.
> > * gcc.dg/Wframe-larger-than.c: Likewise.
> > * gcc.dg/Wrestrict-11.c: Likewise.
> So I think we probably want an effective target check for indirect
x5 is used as an alternate link register, so using it for sibcalls
will confuse hardware return-address stacks and reduce performance for
implementations that have one.
The reason I excluded a0-a7 is that those are used to pass arguments
to the sibcallee. It's of course possible that's more
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file,
When using the -msave-restore flag we end up with calls to
_riscv_save_0 and _riscv_restore_0. These functions adjust the stack
and save or restore the return address. Due to grouping multiple
save/restore stub functions together the save/restore 0 calls actually
save s0, s1, s2, and the return
The current SIBCALL_REGS are x6, x7, and x28 to x31. These are all
caller saved registers, however, they are not all of the caller saved
registers.
I don't see any reason why we couldn't add t1, and a0 to a7 into this
set, and this is what this patch does.
gcc/ChangeLog:
*
The following two patches are an attempt at further reducing code size
when compiling with -msave-restore by attempting to claw back some of
the tail call cases where we currently include a call to
__riscv_save_0 and __riscv_restore_0.
Any feedback, or suggestions for improvements, or for better
This libgo patch by Cherry Zhang enables stricter GC checking in libgo.
With https://golang.org/cl/190599
(https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01220.html), along with
what we do in greyobject, we ensure that we only mark allocated heap
objects. As a result we can be more strict in GC:
On Wed, Aug 14, 2019, 11:44 AM Pedro Alves wrote:
> On 7/12/19 9:24 AM, Jakub Jelinek wrote:
> > I'd just arrange that when being compiled with clang we compile with
> > -Wno-mismatched-tags to get rid of their misdesigned warning and not add
> > such misdesigned warning to GCC, that will just
On Fri, Aug 16, 2019 at 06:20:20PM -0700, Jason Merrill wrote:
> On 8/16/19 2:29 PM, Marek Polacek wrote:
> > This patch is an attempt to fix the annoying -Wunused-but-set-* warnings
> > that
> > tend to occur with constexpr if. When we have something like
> >
> >template < typename T >
> >
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote:
> ? As I remember there were a few other ideas from Richard Biener and
> Segher Boessenkool.? I also proposed to add a new address register which
> will be always a fixed stack memory slot at the end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426
--- Comment #4 from David Malcolm ---
(In reply to Thomas Koenig from comment #2)
> Having had occasion to look at a few hundred multi-line error messages
> today, I have now changed my mind on what I would consider best :-)
>
> I now think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426
--- Comment #3 from David Malcolm ---
Created attachment 46732
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46732=edit
Prototype patch to colorize the (1) and (2) in the example given
Hi Mike,
Some comments on this patch:
On Wed, Aug 14, 2019 at 05:59:13PM -0400, Michael Meissner wrote:
> Due to some of the existing load and store insns not using the traditional
> operands[0] and operands[1], the functions that test whether an insn is
> prefixed only use the insn and not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91492
Bug ID: 91492
Summary: [10 regression] Ada documentation issue starting with
r274637
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91491
Bug ID: 91491
Summary: [9 Regression] glib2.0 build not working when built
with -O2 on x86_64-linux-gnu
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Hi Cale,
On Mon, 19 Aug 2019 at 19:50, Cale McCollough wrote:
>
> My name is Cale McCollough and I'm the author of the Fastest Method to
> Print Integers and Floating-point Numbers, the Puff algorithm, that
> eliminates over half of the division instructions from the
> industry-standard mod 100
On Wed, Aug 07, 2019 at 07:12:19PM +0100, Richard Sandiford wrote:
> The AArch64 port uses define_splits to prefer moving certain float
> constants via integer registers over loading them from memory. E.g.:
>
> (set (reg:SF X) (const_double:SF C))
>
> splits to:
>
> (set (reg:SI tmp)
My name is Cale McCollough and I'm the author of the Fastest Method to
Print Integers and Floating-point Numbers, the Puff algorithm, that
eliminates over half of the division instructions from the
industry-standard mod 100 div 100 technique, saving hundreds to thousands
of clock cycles and
On Thu, Aug 15, 2019 at 02:11:25PM +0100, Prathamesh Kulkarni wrote:
> On Thu, 8 Aug 2019 at 11:22, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 1 Aug 2019 at 15:34, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Thu, 25 Jul 2019 at 11:56, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Wed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330
Martin Jambor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Monday 15 July 2019 at 17:47:47 +0100, Mike Crowe wrote:
> The pthread_cond_clockwait function was recently added[1] to glibc,
> and is due to be released in glibc 2.30. If this function is available
> in the C library it can be used it to fix
>
On Mon, Jul 08, 2019 at 04:41:06PM +0100, Joel Hutton wrote:
> On 01/07/2019 18:03, James Greenhalgh wrote:
>
> >> gcc/testsuite/ChangeLog:
> >>
> >> 2019-06-12 Joel Hutton
> >>
> >> * gcc.target/aarch64/fmul_scvtf_1.c: New test.
> > This testcase will fail on ILP32 targets where
On Mon, Aug 19, 2019 at 09:08:12AM -0600, Jeff Law wrote:
> On 8/19/19 3:11 AM, Mark Eggleston wrote:
> > The intrinsics DIM, MOD and MODULO can accept arguments of different
> > kinds and return values with the larger of the two kinds. Notes to this
> > effect have been added as they were missing
On Thu, Aug 15, 2019 at 12:28:27PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> On 8/6/19 10:51 AM, Richard Earnshaw (lists) wrote:
> On 18/07/2019 18:18, James Greenhalgh wrote:
> > On Mon, Jun 10, 2019 at 06:21:05PM +0100, Sylvia Taylor wrote:
> >> Greetings,
> >>
> >> This patch adds the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79817
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 09/08/2019 17:15, Richard Earnshaw (lists) wrote:
PR target/91386 is a situation where a peephole2 pattern substitution
is discarded late because the selected instructions contain
frame-related notes that we cannot redistribute (because the pattern
has more than one insn in the output).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #23 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Aug 19 16:11:30 2019
New Revision: 274675
URL: https://gcc.gnu.org/viewcvs?rev=274675=gcc=rev
Log:
[aarch64] PR target/91386 Use copy_rtx to avoid modifying original insns in
I'm of the mind that we should advertise some of the new cool
C++ changes going into GCC 10, esp. those that are user-visible.
Checking this in.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-10/changes.html,v
ping
Remove the remaining Neon adddi3, subdi3 and negdi2 patterns. As a result
adddi3, subdi3 and negdi2 can now always be expanded early irrespectively of
whether Neon is available. Also expand the extenddi patterns at the same
time. Several Neon arch attributes are no
ping
Like the logical operations, expand all shifts early rather than only
sometimes. The Neon shift expansions are never emitted (not even with
-fneon-for-64bits), so they are not useful. So all the late expansions
and Neon shift patterns can be removed, and shifts are
ping
Cleanup the logical DImode operations since the current implementation is way
too complicated. Thumb-1, Thumb-2, VFP/Neon and iwMMXt all work differently,
resulting in a bewildering number of expansions, patterns and splits across
several md files. All this
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
for simple
ping
Currently the Arm backend selects the alternative sched pressure algorithm.
The issue is that this doesn't take register pressure into account, and so
it causes significant additional spilling on Arm where there are only 14
allocatable registers. SPEC2006 shows significant codesize
> "Jonathan" == Jonathan Wakely writes:
Jonathan> Given that the problem does exist, I think being able to disable the
Jonathan> GCC build flags for non-GCC components in the build tree makes sense.
Jonathan> I'm not sure if Jeff deferring to me means I can approve the patch
Jonathan>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #17 from Viktor Ostashevskyi ---
Ok, got following today with GCC 9.2 with "-O2 -fno-inline -flto=20":
ld.bfd: /tmp/tests.oKru4z.ltrans32.ltrans.o: in function
`std::__shared_ptr::operator=(std::__shared_ptr&&)':
This patch adds a flag that tells targets whether an argument
has been converted to pass-by-reference form. This replaces
assign_parm_data_one::passed_pointer in function.c.
The flag is set automatically for places that call
apply_pass_by_reference_rules. Places that apply
pass-by-reference
This patch makes the two main calls.c argument-processing
routines track the state of the argument in a function_arg_info
instead of using separate mode variables.
2019-08-19 Richard Sandiford
gcc/
* calls.c (emit_library_call_value_1): Merge arg and orig_arg
into a single
This patch adds a function_arg_info field to assign_parm_data_one,
so that:
- passed_type -> arg.type
- promoted_mode -> arg.mode
- named_arg -> arg.named
We can then pass this function_arg_info directly to the converted
hooks.
Between the initialisation of the assign_parm_data_one and
This patch adds a helper routine that applies pass-by-reference
semantics to an existing function_arg_info.
The c6x part means that c6x_function_arg and c6x_function_arg_advance
see the same "named" value as pass_by_reference did, rather than
pass_by_reference seeing "true" and the others seeing
Use function_arg_info for TARGET_MUST_PASS_IN_STACK.
The hook is passed the promoted mode instead of the original type mode.
The expr.h reference in the documentation is no longer correct, but
pointing to calls.h or calls.c doesn't help much either. I just left
this as-is since it's not related
Use function_arg_info for TARGET_CALLEE_COPIES.
The hook is passed the unpromoted type mode instead of the promoted mode.
The aarch64 definition is redundant, but worth keeping for emphasis.
2019-08-19 Richard Sandiford
gcc/
* target.def (callee_copies): Take a function_arg_info
Use function_arg_info for TARGET_FUNCTION_ARG_ADVANCE.
There seems to be a bit of confusion around this one. Almost all
callers pass the same arguments as TARGET_FUNCTION_ARG, meaning
that the mode is the promoted mode rather than the type mode.
But the calls.c handling for normal typed
This patch makes both TARGET_FUNCTION_ARG and
TARGET_FUNCTION_INCOMING_ARG take a function_arg_info.
They have to be done together since many targets use the
same function for both.
The hooks are passed the promoted mode instead of the original type mode.
2019-08-19 Richard Sandiford
gcc/
Use function_arg_info for TARGET_SETUP_INCOMING_ARGS.
The hook is passed the promoted mode instead of the original type mode.
2019-08-19 Richard Sandiford
gcc/
* target.def (setup_incoming_varargs): Take a function_arg_info
instead of a mode and tree.
* doc/tm.texi:
Use function_arg_info for TARGET_PASS_BY_REFERENCE.
The hook is passed the unpromoted type mode instead of the promoted mode.
2019-08-19 Richard Sandiford
gcc/
* target.def (pass_by_reference): Take a function_arg_info instead
of a mode, type and named flag.
*
This patch adds the function_arg_info class and uses it for
TARGET_ARG_PARTIAL_BYTES.
The hook is passed the promoted mode instead of the original type mode.
The arguments aren't mentioned in the documentation, which is why the
target.def change is so small.
The patch changes "true" to
This patch splits out another idiom from the va_arg gimplification
routines, so that there's only one place to update later.
2019-08-19 Richard Sandiford
gcc/
* calls.h (must_pass_va_arg_in_stack): Declare.
* calls.c (must_pass_va_arg_in_stack): New function.
*
This patch splits out a common idiom from the va_arg gimplification
routines, so that there's only one place to update later.
2019-08-19 Richard Sandiford
gcc/
* calls.h (pass_va_arg_by_reference): Declare.
* calls.c (pass_va_arg_by_reference): New function.
*
For the SVE calling conventions, function_arg and function_arg_advance
need to know whether an argument is being passed by reference or not.
The simplest way of providing that information would have been to add a
new parameter, or convert the "named" parameter into a bitmask. But it
seemed
On 8/19/19 3:11 AM, Mark Eggleston wrote:
> The intrinsics DIM, MOD and MODULO can accept arguments of different
> kinds and return values with the larger of the two kinds. Notes to this
> effect have been added as they were missing from the documentation.
>
> Please find attached the patch.
>
>
On Mon, Aug 19, 2019 at 09:14:22AM -0400, Vladimir Makarov wrote:
> On 2019-08-19 3:35 a.m., John Darrington wrote:
> >On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
> > No I meant something like that
> >
> > (define_special_memory_constraint "a" ...)
> >
1 - 100 of 188 matches
Mail list logo