On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
No I meant something like that
(define_special_memory_constraint "a" ...)
(define_predicate "my_special_predicate" ...
{
if (lra_in_progress_p)
return REG_P
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 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.
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 Mon, 19 Aug 2019, Tejas Joshi wrote:
> How can I add a target hook to specify the FP_INT_* values from libm ?
See target.def.
You'll need a GCC-specific enum (GCC_FP_INT_*, say) that GCC uses
internally, and a hook that maps between that and FP_INT_*. I'm guessing
that for the likely
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" ...)
> >
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
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
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
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 19/08/2019 14:57, Paul Koning wrote:
On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the
following code:
#include
typedef uint32_t uuint32_t
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the
following code:
#include
typedef uint32_t uuint32_t __attribute__((aligned(1)));
uint32_t getuuint32(uint8_t p[]) {
return *(uuint32_t*)p;
}
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" ...)
(define_predicate "my_special_predicate" ...
Hello.
The fromfp/fromfpx variants round to integers with a specified number
of bits, to a specified rounding mode. They come with their own
complications as Joseph had stated in an initial mail and expected to
expand them in AArch64 :
> The fromfp / fromfpx / ufromfp / ufromfpx functions (round
Hi Richard,
On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote:
> Tejas Joshi writes:
> >> It's just a different name, nothing more, nothing less. Because it is
> >> a different name it can not be accidentally generated from actual
> >> truncations.
> >
> > I have introduced
On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
> Correct, but note that you can only pack structs and unions, not basic types.
> there is no way of under-aligning a basic type except by wrapping it in a
> struct.
I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been
> On Aug 19, 2019, at 8:46 AM, Markus Fröschle wrote:
>
> All,
>
> this is my first post on these lists, so please bear with me.
>
> My question is about gcc's __attribute__((aligned()). Please consider the
> following code:
>
> #include
>
> typedef uint32_t uuint32_t
> but an unspec is of course easiest for now.
So, at this point, should I proceed with UNSPEC considering the
complications that might arise as Richard points out?
On Sat, 17 Aug 2019 at 13:51, Richard Sandiford
wrote:
>
> Tejas Joshi writes:
> > Hi,
> >
> >> It's just a different name,
> On Aug 19, 2019, at 10:08 AM, Alexander Monakov wrote:
>
> On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
>
>> Correct, but note that you can only pack structs and unions, not basic types.
>> there is no way of under-aligning a basic type except by wrapping it in a
>> struct.
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472
--- Comment #6 from Eric Botcazou ---
I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91482
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91488
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
I dug into this, and his site still exists, and he's got a new blog,
alas the older items appear to be gone.
Committed.
Gerald
Index: gcc-4.3/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/porting_to.html,v
Time to rotate some news again.
Committed.
Gerald
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1134
diff -u -r1.1134 index.html
--- index.html 12 Aug 2019 08:46:23 - 1.1134
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91472
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91476
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91477
--- Comment #1 from Richard Biener ---
This is due to limitations in the encoding space for locations which causes us
to drop column numbers at some point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
Richard Biener changed:
What|Removed |Added
Keywords||lto, needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Mon Aug 19 14:45:38 2019
New Revision: 274672
URL: https://gcc.gnu.org/viewcvs?rev=274672=gcc=rev
Log:
2019-08-19 Richard Biener
PR tree-optimization/91403
*
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.
>
>
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:
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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 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
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=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.
> >
> >
I've merged trunk revision 274678 to the gccgo branch.
Ian
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
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
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
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
> 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
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: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
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: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 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
>
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
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,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91484
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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 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
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
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
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.
*
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
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
> "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>
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490
Bug ID: 91490
Summary: [9/10 Regression] bogus argument missing terminating
nul warning on strlen of a flexible array member
Product: gcc
Version: 9.0
Status:
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
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&&)':
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
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 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
>
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
The following applies manual tail-recusion transform to add chains
SLP generates.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-08-19 Richard Biener
PR tree-optimization/91403
* tree-scalar-evolution.c (follow_ssa_edge_binary): Inline
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.
*
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
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
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).
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=91492
Bug ID: 91492
Summary: [10 regression] Ada documentation issue starting with
r274637
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330
Martin Jambor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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,
> On Fri, Aug 16, 2019 at 2:07 PM Jan Hubicka wrote:
> >
> > >
> > > When we compare OBJ_TYPE_REF_TOKEN and OBJ_TYPE_REF_OBJECT
> > > and they are equal, are there cases where types_same_for_odr returns
> > > false?
> >
> > OBJ_TYPE_REF_OBJECT is pointer to the instance, OBJ_TYPE_REF_TOKEN is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
--- Comment #26 from Richard Biener ---
/* Match arithmetic done in a different type where we can easily
substitute the result from some earlier sign-changed or widened
operation. */
if (INTEGRAL_TYPE_P (type)
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
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
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
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
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
1 - 100 of 188 matches
Mail list logo
