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 this
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 part
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
> > sharedstat
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 la
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 cases.
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
>>>
>>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmin
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
>>> e
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 likely
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
> apply_pass_by_r
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 (emit_library_ca
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 follo
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 eve
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
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 muc
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 mo
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 origi
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 function_arg_info
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 inst
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
> target.def
> 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 f
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 you
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 restr
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, 'gcc-9.1.0
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 a
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:
* config/riscv/
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
a
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 he
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 >
> >
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 o
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) (c
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 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=41861
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 unsi
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 intrinsi
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). Unfor
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
retrievi
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 long
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 mor
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 complexity
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 expressions
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> (normal
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 manu
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 fun
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 the
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 ins
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 arguments
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: R
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.
* doc/tm.
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 "arg.name
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.
* config/
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.
* config/a
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 cleaner
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.
>
>
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
> 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
> >
[...]
> * 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 calls
rather than checking explicitly for ebpf in all these files.
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 partly the result of the added detection
Hi Seguer! Thanks for reviewing :)
> @@ -538,6 +539,9 @@ proc check_effective_target_stack_size { } {
> if [target_info exists gcc,stack_size] {
> return 1
> }
> +if [istarget bpf-*-*] {
> + return 1
> +}
You should still set the prop
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
>
> @@ -546,7 +550,11 @@ proc check_effective_target_stack_size { } {
> proc dg-effective-target-value { effective_target } {
> if { "$effective_target" == "stack_size" } {
On Fri, Aug 16, 2019 at 8:15 PM Jeff Law wrote:
>
> On 8/16/19 12:09 PM, Marc Glisse wrote:
> > On Fri, 16 Aug 2019, Jeff Law wrote:
> >
> >> This patch improves our ability to detect dead stores by handling cases
> >> where the size memcpy, memset, strncpy, etc call is not constant. This
> >> ad
On Fri, Aug 16, 2019 at 2:17 PM Robin Dapp wrote:
>
> > So - what are you really after? (sorry if I don't remeber, testcase(s)
> > are missing
> > from this patch)
> >
> > To me it seems that 1) loses information if A + CST was done in a signed
> > type
> > and we know that overflow doesn't happe
Hi Jeff.
First of all, thanks for reviewing the port.
> +++ b/libgcc/config/bpf/t-bpf
> @@ -0,0 +1,24 @@
> +HOST_LIBGCC2_CFLAGS += -O0
> +LIB2ADDEH =
I'd like to understand the motivation behind the -O0, but otherwise I
don't see anything particularly concerning here.
O
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
> index in the vtable or
On Fri, Aug 16, 2019 at 1:06 PM Martin Liška wrote:
>
> Hi.
>
> The patch is a mechanical clean up that changes some
> functions and data structures to use const_tree instead
> of tree.
I think this kind of changes are obvious.
Richard.
> Martin
On 14/08/2019 08:48, Eric Botcazou wrote:
[Sorry for the delay, I missed your question...]
Interesting. Does it work for the general case of a reverse subtract,
which I need to handle as wel?
Not clear, Visium only uses it for SNE and combined NEG/SNE.
I worked through the logic. I'm pre
On Fri, Aug 16, 2019 at 11:29:30AM +0930, Alan Modra wrote:
> On Thu, Aug 15, 2019 at 01:24:07PM -0500, Segher Boessenkool wrote:
> > On Thu, Aug 15, 2019 at 01:35:10PM +0930, Alan Modra wrote:
> > > Supporting TLS for -mpcrel turns out to be relatively simple, in part
> > > due to deciding that !T
On Mon, 19 Aug 2019, Richard Biener wrote:
>
> Uros noted that STV with !TImode isn't supposed to run before combine.
> The following adjusts things accordingly and now the pass runs twice
> for TARGET_64BIT. I've also adjusted another gpr->xmm move to
> use (vec_merge (vec_duplicate..)) style r
Uros noted that STV with !TImode isn't supposed to run before combine.
The following adjusts things accordingly and now the pass runs twice
for TARGET_64BIT. I've also adjusted another gpr->xmm move to
use (vec_merge (vec_duplicate..)) style rather than using a subreg.
This isn't strictly necces
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
> sharedstatedir
> sysconfdir
(etc.)
You seem to have generated this with the wrong versio
On Sat, Aug 17, 2019 at 02:50:56AM +0200, Jose E. Marchesi wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d8402949bc..bcf81e8f337 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -57,6 +57,7 @@ arm portRamana Radhakrishnan
>
> arm port Kyrylo Tkachov
On Sun, Aug 18, 2019 at 07:33:20PM -0600, Jeff Law wrote:
> On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> So I think we probably want an effective target check for indirect calls
> rather than checking explicitly for ebpf in all these files.
+1
> It also seems like rather than checking for ebpf o
Hi Jose,
On Sat, Aug 17, 2019 at 02:50:53AM +0200, Jose E. Marchesi wrote:
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -526,7 +526,8 @@ proc check_effective_target_trampolines { } {
>|| [istarget nvptx-*-*]
>|| [istarget hppa2.0w
On 16/08/2019 15:55, Steve Kargl wrote:
On Fri, Aug 16, 2019 at 03:25:03PM +0100, Mark Eggleston wrote:
In section 6.1.10 BOZ literal constants of the gfortran manual
(gfortran.pdf) the final paragraph refers to integer overflow error. As
a result of Steve Kargl's work on BOZ constants these e
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.
ChangeLog:
gcc/fortran/ChangeLog
Mark Eggleston
Generate target-dependent info into a file named ada_target_properties.
This information is used by tools for static analysis: they need to know
the size of standard types for a given run-time library. This metadata
is meant to be saved at the root of the run-time directory.
Tested on x86_64-pc-li
This patch enables gap detection in type extensions.
With the -gnatw.h switch, on 64-bit machines,
the following test should get warnings:
gcc -c gaps.ads -gnatw.h
gaps.ads:16:07: warning: 48-bit gap before component "Comp2"
gaps.ads:17:07: warning: 8-bit gap before component "Comp3"
package Gap
This patch adds a formal function parameter "=" (L, R : Element_Type) to
SPARK containers. The equality that is used by default for Element_Type
after this patch is the primitive equality and not the predefined any
more. It also allows to use any function with the appropriate signature
for the equa
This patch corrects the code generated by the -gnateV switch in the case
of a private type whose full type is a modular type, removing spurious
run-time failures.
In addition, this corrects the initialization of exception occurrences
in exception handlers to avoid leaving data uninitialized, which
If the -gnatwf switch is used to activate warnings on unreferenced
formal parameters, the warning is no longer given if the subprogram is
dispatching, because such warnings tend to be noise. It is quite common
to have a parameter that is necessary just because the subprogram is
overriding, or just
This patch fixes a compiler abort on an object declaration for a
class-wide type whose expression is a call to an expression function
that returns type extension.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-19 Ed Schonberg
gcc/ada/
* sem_res.adb (Resolve_Call): A call t
The new routines convert back and forth between private type OS_Time and
a long integer which can be used in package Ada.Calendar.Conversions
routines to convert to Ada.Calendar.Time.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-19 Dmitriy Anisimkov
gcc/ada/
* libgnat/s-
This change lifts the restriction that was still present in the new
on-demand instantiation scheme for the body of generics instantiated in
non-main units.
The instantiations that are compilation units were still dealt with in
the old-fashioned way, that is to say the decision of instantiating the
This fixes a fallout of a recent change clearing the
Is_Generic_Actual_Type on the implicit full view of a private actual
type in an instance. This flag is used to help disambiguating formal
types instantiated on the same actual type within an instance, but it
should be cleared outside the instanc
This fixes a bogus compilation error when a unit with SPARK_Mode
containing a pragma Elaborate_Body is with-ed by a generic unit
containing an inlined subprogram, and front-end inlining is enabled.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-19 Eric Botcazou
gcc/ada/
*
This fixes a fallout of the recent change keeping the
Is_Generic_Instance flag on the wrapper package built for the
instantiation of a generic subprogram.
There is no need to visit the Instance_Spec of an
N_Subprogram_Instantiation node anymore because the regular processing
for an N_Package_Decla
1 - 100 of 110 matches
Mail list logo
