On 09/06/2018 12:24 AM, Cesar Philippidis wrote:
> This is ok (with, as I mentioned above, the SI part split off into a
> separate patch), on the condition that you test libgomp with
> -foffload=-misa=sm_35.
>>> Adding -foffload=misa=sm_35 didn't work because the host gcc doesn't
>>> s
On 09/06/2018 12:24 AM, Cesar Philippidis wrote:
> I'll commit the attached patch shortly. x86_64 with nvptx offloading
> regression testing didn't yield any new failures, nor did the standalone
> nvptx testing. I'll follow up with an SImode patch later.
I'm sorry, I guess I was not clear enough h
OK.
On Wed, Sep 5, 2018 at 8:13 PM, Marek Polacek wrote:
> On Wed, Sep 05, 2018 at 08:01:53PM -0400, Marek Polacek wrote:
>> Jonathan suggested to handle std::move and std::forward specially for the
>
> And for the record I meant "suggested handling"!
On Wed, Sep 5, 2018 at 11:08 AM, David Malcolm wrote:
> On Thu, 2018-08-30 at 18:18 -0400, Jason Merrill wrote:
>> On Thu, Aug 23, 2018 at 2:08 PM, David Malcolm
>> wrote:
>> > This is a followup to:
>> >
>> > "[PATCH] C++: underline param in print_conversion_rejection (more
>> > PR c++/85110)"
On Wed, Sep 05, 2018 at 08:01:53PM -0400, Marek Polacek wrote:
> Jonathan suggested to handle std::move and std::forward specially for the
And for the record I meant "suggested handling"!
Jonathan suggested to handle std::move and std::forward specially for the
purpose of -Wreturn-local-addr, because it's a fairly common mistake to
return a local var by reference.
Now that we have is_std_move_p it's fairly trivial to extend the warning.
Bootstrapped/regtested on x86_64-linux, ok f
Nothing ever speculated here, move along... Regtested for
cris-elf, observing the maintenance-provoking test-cases now
passing.
PR target/86779
* config/cris/cris.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Redefine
to speculation_safe_value_not_needed.
Index: gcc/config/cris
On 09/05/2018 07:30 AM, Tom de Vries wrote:
> On 09/05/2018 12:19 AM, Cesar Philippidis wrote:
>> On 09/02/2018 07:57 AM, Cesar Philippidis wrote:
>>> On 09/01/2018 12:04 PM, Tom de Vries wrote:
On 08/31/2018 04:14 PM, Cesar Philippidis wrote:
>>>
> Is this patch OK for trunk?
>
>
On 5 September 2018 20:44:05 CEST, Janne Blomqvist
wrote:
>On Wed, Sep 5, 2018 at 6:00 PM Bernhard Reutner-Fischer <
>rep.dot@gmail.com> wrote:
>
>> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
>> index 38827ed4637..6596bd87c09 100644
>> --- a/gcc/fortran/match.c
>> +++ b/gcc/fortra
OK, thanks.
On Wed, Sep 5, 2018 at 4:09 PM, Marek Polacek wrote:
> On Tue, Sep 04, 2018 at 05:29:00PM -0400, Jason Merrill wrote:
>> On Tue, Sep 4, 2018 at 3:02 PM, Marek Polacek wrote:
>> > On Thu, Aug 30, 2018 at 09:22:26AM -0400, Jason Merrill wrote:
>> >> On Wed, Aug 29, 2018 at 8:03 PM, Mar
Inhibit constant propagation inlining SYMBOL_REF loads into
UNSPECV_CAS. Even though reload can later undo it, the resulting
code will be less efficient.
gcc/ChangeLog:
2018-09-05 Ilya Leoshkevich
PR target/80080
* config/s390/predicates.md: Add nonsym_memory_operand.
On Tue, Sep 04, 2018 at 05:29:00PM -0400, Jason Merrill wrote:
> On Tue, Sep 4, 2018 at 3:02 PM, Marek Polacek wrote:
> > On Thu, Aug 30, 2018 at 09:22:26AM -0400, Jason Merrill wrote:
> >> On Wed, Aug 29, 2018 at 8:03 PM, Marek Polacek wrote:
> >> > I've now gotten to the point where I question
This patch teaches the gimplifier how to pass certain OpenACC reduction
variables as firstprivate, and not with an implicit copy directive. This
is matches the default behavior for the implicit data mappings of scalar
variables inside OpenACC parallel regions. It should be noted that the
gimplifier
At present, GCC fixes the vector length on all targets. However, that is
an artificial restriction. This patch introduces a new
TARGET_GOACC_ADJUST_PARALLELISM hook that enables the runtime to correct
the default number of acc workers and vectors. Extra care need to be
done to ensure that large vec
At present, gfortran does not encode the gang, worker or vector
parallelism clauses when it creates acc routines dim attribute for
subroutines and functions. While support for acc routine is lacking in
other areas in gfortran (including modules), this patch is important
because it encodes the paral
Patch for PR 86957 " gcc should warn about missing profiles for a compilation unit
or a new function with -fprofile-use".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957
The patch adds -Wmissing-profile warning flag to alert user about cases when
there is no profile data for a compilation un
On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:
> Hi,
>
> The fortran frontend still uses stack-based handling of (symbol) names
> with fixed-sized buffers. Furthermore these buffers often are too small
> when dealing with F2003 identifiers which can be up t
On Wed, Sep 5, 2018 at 6:00 PM Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 38827ed4637..6596bd87c09 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -1274,15 +1274,22 @@ not_yes:
> case '%'
On Tue, Sep 4, 2018 at 10:05 AM Bernd Edlinger
wrote:
> On 03/09/2018, 21:25 Janne Blomqvist wrote:
> > On Fri, Aug 24, 2018 at 11:06 PM Bernd Edlinger <
> bernd.edlin...@hotmail.de>
> > wrote:
> >
> >> Hi!
> >>
> >>
> >> This is an alternative approach to handle overlength strings in the
> >> Fo
Please send fortran patches to the fortran list as well!
On Wed, Sep 5, 2018 at 7:56 PM Toon Moene wrote:
>
>
>
> Forwarded Message
> Subject: [PATCH 19/25] GCN libgfortran.
> Date: Wed, 5 Sep 2018 12:51:20 +0100
> From: a...@codesourcery.com
> To: gcc-patches@gcc.gnu.org
>
>
>
On Wed, Sep 5, 2018 at 7:57 PM Toon Moene wrote:
>
>
>
> Forwarded Message
> Subject: [PATCH 18/25] Fix interleaving of Fortran stop messages
> Date: Wed, 5 Sep 2018 12:51:19 +0100
> From: a...@codesourcery.com
> To: gcc-patches@gcc.gnu.org
>
>
> Fortran STOP and ERROR STOP use
Hello!
IRA is able to generate temporary output memory location by itself, so
there is no need to manually provide one in the pattern. Based on this
functionality, attached patch rewrites float_truncate patterns in a
much simpler and elegant way. It also introduces "enabled" attribute
that handles
Same, please send fortran patches to the fortran list as well!
On Wed, Sep 5, 2018 at 7:55 PM Toon Moene wrote:
>
>
>
> Forwarded Message
> Subject: [PATCH 17/25] Fix Fortran STOP.
> Date: Wed, 5 Sep 2018 12:51:18 +0100
> From: a...@codesourcery.com
> To: gcc-patches@gcc.gnu.or
Please send fortran patches to the fortran list as well!
On Wed, Sep 5, 2018 at 7:54 PM Toon Moene wrote:
>
>
>
> Forwarded Message
> Subject: [PATCH 08/25] Fix co-array allocation
> Date: Wed, 5 Sep 2018 12:49:40 +0100
> From: a...@codesourcery.com
> To: gcc-patches@gcc.gnu.or
On 09/05/2018 10:57 AM, Michael Matz wrote:
Hi,
On Wed, 5 Sep 2018, Aldy Hernandez wrote:
No apologies needed. I welcome all masochists to join me in my personal hell
:).
;-)
How can this test and following code catch all problematic cases? Assume
a range of [253..257], truncating to
Richard,
thanks for the answer, got it.
On 09/05/2018 07:51 PM, Richard Earnshaw (lists) wrote:
On 05/09/18 17:43, Denis Khalikov wrote:
Thanks for the answers.
I understood that, this hack makes more mess in codegen for arm,
but can you please clarify what did you mean by
Only a single regi
On 05/09/18 17:43, Denis Khalikov wrote:
> Thanks for the answers.
>
> I understood that, this hack makes more mess in codegen for arm,
> but can you please clarify what did you mean by
>
>>Only a single register can be used
>> as the frame chain.
>
> As far as I understood, GCC for arm with THU
Thanks for the answers.
I understood that, this hack makes more mess in codegen for arm,
but can you please clarify what did you mean by
>Only a single register can be used
> as the frame chain.
As far as I understood, GCC for arm with THUMB2 mode uses r7 register as
frame pointer register by d
Hi Denis,
>> Adding support for a frame chain would require an ABI change. It
> would have to
> > work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> > effort.
> Clang already works that way.
No, that's incorrect like Richard pointed out. Only a single register can be
u
On Tue, 21 Jun 2016 at 00:19, Jeff Law wrote:
>
> On 06/18/2016 01:31 PM, Bernhard Reutner-Fischer wrote:
> > A branch with a name matching scan-assembler pattern triggers
> > inappropriate FAIL.
> >
> > E.g. branch fixups-testsuite and
> > - gcc.target/i386/pr65871-?.c (scan-assembler-not "test")
Document that the parameter can be null.
Committed to trunk.
commit a7fcd4545416835228f1c0efc8c8b2f21d85262d
Author: Jonathan Wakely
Date: Wed Sep 5 16:17:07 2018 +0100
* libsupc++/cxxabi.h (__cxa_demangle): Clarify doxygen comment.
diff --git a/libstdc++-v3/libsupc++/cxxabi.h
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-23 Bernhard Reutner-Fischer
* module.c (import_iso_c_binding_module): Use pointer comparison
instead instead of strcmp.
---
gcc/fortran/module.c | 25 ++---
1 file changed, 10 insertions(+), 15
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-20 Bernhard Reutner-Fischer
* gfortran.h (struct CInteropKind_t): Make name a pointer.
* misc.c (get_c_kind): Use pointer comparison on name to
determine index.
* symbol.c (generate_isocbinding_symb
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-23 Bernhard Reutner-Fischer
* module.c (use_iso_fortran_env_module): Use stringpool and use
pointer comparison instead of strcmp.
---
gcc/fortran/module.c | 16
1 file changed, 8 insertions(+), 8
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-24 Bernhard Reutner-Fischer
* class.c (finalizer_insert_packed_call): Use stringpool.
(generate_finalization_wrapper): Likewise.
(gfc_find_derived_vtab): Likewise.
(find_intrinsic_vtab): Likewise.
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-24 Bernhard Reutner-Fischer
* primary.c (match_charkind_name): Return stringpool node.
(match_string_constant): Use stringpool node for name.
---
gcc/fortran/primary.c | 21 -
1 file changed, 1
From: Bernhard Reutner-Fischer
Use the existing helper function to create type names. The helper
function uses the stringpool already.
gcc/fortran/ChangeLog:
2017-11-24 Bernhard Reutner-Fischer
* decl.c (build_sym): Use stringpool node instead of stack
variables.
(gf
From: Bernhard Reutner-Fischer
compiling gfortran.dg/typebound_proc_31.f90 leaked the type-bound
structs:
56 bytes in 1 blocks are definitely lost.
at 0x4C2CC05: calloc (vg_replace_malloc.c:711)
by 0x151EA90: xcalloc (xmalloc.c:162)
by 0x8E3E4F: gfc_get_typebound_proc(gfc_typebound_proc*)
From: Bernhard Reutner-Fischer
This replaces the remaining occurrences of names and name manipulation
to go through the stringpool. Required to make TYPE (IS) handling work
later on.
gcc/fortran/ChangeLog:
2017-11-14 Bernhard Reutner-Fischer
* class.c (gfc_build_class_symbol): Use p
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-12-12 Bernhard Reutner-Fischer
* trans-openmp.c (gfc_trans_omp_array_reduction_or_udr): Use
stringpool for clause reduction code.
---
gcc/fortran/trans-openmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-29 Bernhard Reutner-Fischer
* module.c (load_needed): Use stringpool when generating symbols
and module names.
---
gcc/fortran/module.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
dif
From: Bernhard Reutner-Fischer
gfc_match_name does check for too long names already. Since
gfc_new_symbol is also called for symbols with internal names containing
compiler-generated prefixes, these internal names can easily exceed the
max_identifier_length mandated by the standard.
gcc/fortran/
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-26 Bernhard Reutner-Fischer
* class.c (finalize_component): Use stringpool.
(finalization_scalarizer): Likewise.
* frontend-passes.c (create_var): Likewise.
(get_len_trim_call): Likewise.
*
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-28 Bernhard Reutner-Fischer
* module.c (struct pointer_info): Change binding_label to const
pointer.
(free_pi_tree): Do not free binding_label.
(load_commons): Use stringpool for binding_label.
From: Bernhard Reutner-Fischer
This gets rid of some of the str[n]*cmp in favour of (faster) pointer
equality checks.
gcc/fortran/ChangeLog:
2017-11-02 Bernhard Reutner-Fischer
* check.c (gfc_check_move_alloc): Use pointer comparison instead
of strcmp.
* class.c (fin
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-29 Bernhard Reutner-Fischer
* iresolve.c (gfc_resolve_ctime_sub): Use stringpool for
intrinsic subroutine name.
(gfc_resolve_fdate_sub): Likewise.
(gfc_resolve_gerror): Likewise.
(gfc_resolv
From: Bernhard Reutner-Fischer
Copying the sym->name ruins pointer equality checks and first and
foremost is not needed nowadays.
gcc/fortran/ChangeLog:
2018-09-02 Bernhard Reutner-Fischer
* decl.c (gfc_match_volatile, gfc_match_asynchronous): Do not
copy sym->name.
---
gcc
From: Bernhard Reutner-Fischer
Add matched names into the stringpool.
gcc/fortran/ChangeLog:
2017-10-26 Bernhard Reutner-Fischer
* match.c (gfc_match): Use pointer to pointer when matching a
name via "%n" format. Adjust all callers.
(gfc_match_label, gfc_match_iterat
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-29 Bernhard Reutner-Fischer
* match.c (gfc_get_common): Use stringpool for mangled name.
---
gcc/fortran/match.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/fortran/match.c b/gcc/fortran/ma
From: Bernhard Reutner-Fischer
Due to a typo a user operator used in a reduction was not found in the
symtree so would have been written multiple times (in theory).
E.g. user operator ".add." was looked up as ".ad" instead of "add".
For gcc-8 branch and earlier one would
- memcpy (name,
From: Bernhard Reutner-Fischer
Switch type bound procedures to use the stringpool.
gcc/fortran/ChangeLog:
2017-11-24 Bernhard Reutner-Fischer
* decl.c (gfc_match_decl_type_spec): Use stringpool.
* module.c (mio_expr): Likewise.
(mio_typebound_proc): Likewise.
From: Bernhard Reutner-Fischer
Occurrences of name2 in this patch will be fixed later in this series.
gcc/fortran/ChangeLog:
2017-10-23 Bernhard Reutner-Fischer
* match.h (gfc_match_name): Pass argument by reference. Adjust
all callers.
(match_common_name): Likewise.
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-11-15 Bernhard Reutner-Fischer
* gfortran.h (struct gfc_common_head, struct gfc_intrinsic_arg):
Make name a pointer.
* intrinsic.c (add_sym): Use stringpool for name.
* match.c (gfc_get_common): Likewi
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
2017-10-29 Bernhard Reutner-Fischer
* gfortran.h (struct gfc_use_rename): Use pointers for
local_name and use_name.
* match.c (gfc_match): Set name to NULL on failed match.
* module.c (gfc_match_use): Use p
From: Bernhard Reutner-Fischer
Ideally we would populate mstrings structs with strings obtained through
the stringpool. Doing so by means of minit wouldn't work out too well
though, see comment in gfortran.h. We could replace the initialized
strings in gfc_init_1 but that's for a later patch.
gc
From: Bernhard Reutner-Fischer
2017-10-26 Bernhard Reutner-Fischer
* gfortran.h (struct gfc_association_list): Change name to
pointer.
* match.c (gfc_match_associate): Adjust.
---
gcc/fortran/gfortran.h | 2 +-
gcc/fortran/match.c| 6 ++
2 files changed, 3 ins
From: Bernhard Reutner-Fischer
Use a stringpool-node for those gfc_code2string values that are used as
names.
gcc/fortran/ChangeLog:
2017-10-26 Bernhard Reutner-Fischer
* interface.c (gfc_match_generic_spec, gfc_check_dtio_interfaces,
gfc_find_typebound_dtio_proc, gfc_find_s
From: Bernhard Reutner-Fischer
Introduce a helper to construct a user operator from a name and the
reverse operation, i.e. a helper to construct a name from a user
operator.
gcc/fortran/ChangeLog:
2017-10-29 Bernhard Reutner-Fischer
* gfortran.h (gfc_get_uop_from_name):
(gfc
From: Bernhard Reutner-Fischer
The openmp part will be cleaned up later in this series.
gcc/fortran/ChangeLog:
2017-10-22 Bernhard Reutner-Fischer
* match.h (gfc_match_defined_op_name): Adjust prototype and add
a parameter USER_OPERATOR.
* matchexp.c (gfc_match_defin
Hi,
The fortran frontend still uses stack-based handling of (symbol) names
with fixed-sized buffers. Furthermore these buffers often are too small
when dealing with F2003 identifiers which can be up to, including 63
bytes long.
Other frontends use the stringpool since many years.
This janitorial
From: Bernhard Reutner-Fischer
Aids debugging the fortran FE.
gcc/ChangeLog:
2017-11-12 Bernhard Reutner-Fischer
* gdbinit.in: Break on gfc_internal_error.
---
gcc/gdbinit.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in
index 4db977f0bab..ac4d
Hi,
On Wed, 5 Sep 2018, Aldy Hernandez wrote:
> No apologies needed. I welcome all masochists to join me in my personal hell
> :).
;-)
> > How can this test and following code catch all problematic cases? Assume
> > a range of [253..257], truncating to 8 bits unsigned. The size of the
> > ra
On 05/09/18 15:32 +0100, Jonathan Wakely wrote:
Using a huge width in a formatted output operation results in stack
overflow due to no restriction on the size passed to alloca. This patch
causes the formatting functions to use the heap instead of the stack
when a large buffer is needed.
On Wed, 5 Sep 2018, Andrew Stubbs wrote:
> I suppose someone might choose to compile things on an alternative system for
> running on a compatible system, in which case we'd want to simply skip this
> binary.
>
> How does one normally do this?
I'd expect a configure test plus makefile conditiona
On 05/09/18 15:22, Joseph Myers wrote:
+gcn-run$(exeext): gcn-run.o
+ +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $< -ldl
I'd expect this to fail on non-Unix configurations that don't have -ldl,
and thus to need appropriate conditionals / configure tests to avoid that
build failure.
W
Using a huge width in a formatted output operation results in stack
overflow due to no restriction on the size passed to alloca. This patch
causes the formatting functions to use the heap instead of the stack
when a large buffer is needed.
PR libstdc++/87228
* include/bits/locale_
On 09/05/2018 12:19 AM, Cesar Philippidis wrote:
> On 09/02/2018 07:57 AM, Cesar Philippidis wrote:
>> On 09/01/2018 12:04 PM, Tom de Vries wrote:
>>> On 08/31/2018 04:14 PM, Cesar Philippidis wrote:
>>
Is this patch OK for trunk?
>>>
>>> Well, how did you test this (
>>> https://gcc.gnu.
On Wednesday, September 5, 2018 12:35:04 PM PDT Bernhard Reutner-Fischer
wrote:
> On Wed, 5 Sep 2018 at 03:30, Jerry DeLisle wrote:
> > On 09/04/2018 10:43 AM, Bernhard Reutner-Fischer wrote:
> > > On Tue, 4 Sep 2018 at 18:43, Andrew Benson
wrote:
> > >> As suggested by Janus, PR87103 is easily
On Wed, 5 Sep 2018, Andrew Stubbs wrote:
> + warning_at (decl ? DECL_SOURCE_LOCATION (decl) : UNKNOWN_LOCATION,
> + OPT_Wopenacc_dims,
> + (dims[GOMP_DIM_VECTOR]
> +? "using vector_length (64), ignoring %d"
> +: "usi
On Thu, 2018-08-30 at 18:18 -0400, Jason Merrill wrote:
> On Thu, Aug 23, 2018 at 2:08 PM, David Malcolm
> wrote:
> > This is a followup to:
> >
> > "[PATCH] C++: underline param in print_conversion_rejection (more
> > PR c++/85110)"
> > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01480.h
On 05/09/18 14:55, Denis Khalikov wrote:
> Hi Wilco,
> thanks for the answer.
>
>> Adding support for a frame chain would require an ABI change. It would
> have to
>> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
>> effort.
>
> Clang already works that way.
> Please
On 09/05/2018 08:58 AM, Michael Matz wrote:
Hi,
On Tue, 4 Sep 2018, Aldy Hernandez wrote:
to make the result ~[0, 5], is it? At least the original code dropped
that to VARYING. For the same reason truncating [3, 765] from
short to unsigned char isn't [3, 253]. But maybe I'm missing somet
Hi Wilco,
thanks for the answer.
> Adding support for a frame chain would require an ABI change. It
would have to
> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> effort.
Clang already works that way.
Please look at this commit:
http://llvm.org/viewvc/llvm-project/
On Wed, Sep 05, 2018 at 03:14:40PM +0200, Jakub Jelinek wrote:
> It isn't really a GIMPLE transform, just needs to provide the callers
> with a tree. Specifically, if it passes several initial checks, it
> expands the X expression unconditionally and then just uses the result of
> that. What I co
Hi Wilco,
thanks for the answer.
> Adding support for a frame chain would require an ABI change. It
would have to
> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> effort.
Clang already works that way.
Please look at this commit:
http://llvm.org/viewvc/llvm-project/
On Wed, 2018-09-05 at 09:39 -0400, David Malcolm wrote:
> On Wed, 2018-09-05 at 12:49 +0100, a...@codesourcery.com wrote:
> > The plain "sorry" diagnostic only gives the "current" location,
> > which
> > is
> > typically the last line of the function or translation unit by time
> > we get to
> > th
On Wed, 2018-09-05 at 12:49 +0100, a...@codesourcery.com wrote:
> The plain "sorry" diagnostic only gives the "current" location, which
> is
> typically the last line of the function or translation unit by time
> we get to
> the back end.
>
> GCN uses "sorry" to report unsupported language feature
regression will disappear completely one month after this patch
committed to trunk.
Tested with make check with no new regressions.
OK to trunk?
testsuite/ChangeLog:
2018-09-05 Joey Ye
* lib/gcov.exp (verify-intermediate): Add missing close.
gcov-20180905.patch
Description: gcov
On Wed, Sep 05, 2018 at 02:42:36PM +0200, Richard Biener wrote:
> IIRC you said we're already doing x % power-of-two == 0 optimized but the
> new
> code isn't in that place?
For unsigned %, there is no need for anything special, we just
expand that as x % (power-of-two - 1) == 0, as any other % p
Hi,
On Tue, 4 Sep 2018, Aldy Hernandez wrote:
> > to make the result ~[0, 5], is it? At least the original code dropped
> > that to VARYING. For the same reason truncating [3, 765] from
> > short to unsigned char isn't [3, 253]. But maybe I'm missing something.
Sorry for chiming in, but this
On Wed, Sep 5, 2018 at 2:40 PM Andrew Stubbs wrote:
>
> On 05/09/18 13:05, Richard Biener wrote:
> > On Wed, Sep 5, 2018 at 1:51 PM wrote:
> >>
> >>
> >> GCN uses V64BImode to represent vector masks in the middle-end, and DImode
> >> bit-masks to represent them in the back-end. These must be con
On Tue, 4 Sep 2018, Jakub Jelinek wrote:
> Hi!
>
> Improve expansion of x % c1 == c2 and x % c1 != c2 checks.
>
> As mentioned in Hacker's Delight book, section 10-{16,17}, we can improve
> generated code for modulo by constant, if we only use the result to equality
> compare against some other
On 05/09/18 13:05, Richard Biener wrote:
On Wed, Sep 5, 2018 at 1:51 PM wrote:
GCN uses V64BImode to represent vector masks in the middle-end, and DImode
bit-masks to represent them in the back-end. These must be converted at expand
time and the most convenient way is to simply use a SUBREG.
On Wed, 5 Sep 2018, a...@codesourcery.com wrote:
> diff --git a/libgcc/config/gcn/crt0.c b/libgcc/config/gcn/crt0.c
> new file mode 100644
> index 000..f4f367b
> --- /dev/null
> +++ b/libgcc/config/gcn/crt0.c
> @@ -0,0 +1,23 @@
> +/* Copyright (C) 2017 Free Software Foundation, Inc.
Copyright
On Wed, 5 Sep 2018, a...@codesourcery.com wrote:
> This patch creates a new macro SPECIAL_REGNO_P which disables regrename. In
> other words, the register is fixed once allocated.
Creating new target macros is generally suspect - the presumption is that
target hooks should be used instead, unle
Hi Denis,
> We are working on applying Address/LeakSanitizer for the full Tizen OS
> distribution. It's about ~1000 packages, ASan/LSan runtime is installed
> to ld.so.preload. As we know ASan/LSan has interceptors for
> allocators/deallocators such as (malloc/realloc/calloc/free) and so on.
> O
On Wed, Sep 5, 2018 at 2:01 PM Ilya Leoshkevich wrote:
>
> gcc/ChangeLog:
>
> 2018-09-05 Ilya Leoshkevich
>
> PR target/80080
> * combine.c (rest_of_handle_combine): Perform jump threading.
>
> gcc/testsuite/ChangeLog:
>
> 2018-09-05 Ilya Leoshkevich
>
> PR target/800
On Tue, 4 Sep 2018 at 17:29, Richard Earnshaw (lists)
wrote:
>
> On 29/08/18 11:46, Kyrill Tkachov wrote:
> > Hi Christophe,
> >
> > On 13/07/18 17:10, christophe.l...@st.com wrote:
> >> From: Christophe Lyon
> >>
> >> The FDPIC register is hard-coded to r9, as defined in the ABI.
> >>
> >> We ha
On Wed, Sep 5, 2018 at 1:51 PM wrote:
>
>
> GCN uses V64BImode to represent vector masks in the middle-end, and DImode
> bit-masks to represent them in the back-end. These must be converted at
> expand
> time and the most convenient way is to simply use a SUBREG.
x86 with AVX512 uses SImode in
gcc/ChangeLog:
2018-09-05 Ilya Leoshkevich
PR target/80080
* combine.c (rest_of_handle_combine): Perform jump threading.
gcc/testsuite/ChangeLog:
2018-09-05 Ilya Leoshkevich
PR target/80080
* gcc.target/s390/pr80080-4.c: New test.
---
gcc/combine.c
On Wed, Sep 05, 2018 at 12:50:25PM +0100, a...@codesourcery.com wrote:
> 2018-09-05 Andrew Stubbs
>
> gcc/
> * simplify-rtx.c (convert_packed_vector): New function.
> (simplify_immed_subreg): Recognised Boolean vectors and call
> convert_packed_vector.
> ---
> + in
On Wed, Sep 05, 2018 at 12:48:49PM +0100, a...@codesourcery.com wrote:
> +++ b/gcc/combine.c
> @@ -8621,7 +8621,13 @@ gen_lowpart_or_truncate (machine_mode mode, rtx x)
> {
>/* Bit-cast X into an integer mode. */
>if (!SCALAR_INT_MODE_P (GET_MODE (x)))
> - x = gen_lowpart
The GCN toolchain must use the LLVM assembler and linker because there's no
binutils port. The LLVM tools do not have the same diagnostic style as
binutils, so the "blank line(s) in output" tests are inappropriate (and very
noisy).
The LLVM tools also have different command line options, so it's
This collection of miscellaneous patches configures the testsuite to run on AMD
GCN in a standalone (i.e. not offloading) configuration. It assumes you have
your Dejagnu set up to run binaries via the gcn-run tool.
2018-09-05 Andrew Stubbs
Kwok Cheung Yeung
Julian Br
The GCN/HSA loader ignores the load address and uses a random location, so we
build all GCN binaries as PIE, by default.
This patch makes the necessary testsuite adjustments to make this work
correctly.
2018-09-05 Andrew Stubbs
gcc/testsuite/
* gcc.dg/graphite/scop-19.c: Chec
There are a number of tests that fail because they assume that exceptions are
available, but GCN does not support them, yet.
This patch adds "dg-require-effective-target exceptions" in all the affected
tests. There's probably an automatic way to test for exceptions, but the
current implementatio
Fortran STOP and ERROR STOP use a different function to print the "STOP" string
and the message string. On GCN this results in out-of-order output, such as
"ERROR STOP ".
This patch fixes the problem by making estr_write use the proper Fortran write,
not C printf, so both parts are now output th
This patch contains the GCN port of libgcc. I've broken it out just to keep
both parts more manageable.
We have the usual stuff, plus a "gomp_print" implementation intended to provide
a means to output text to console without using the full printf. Originally
this was because we did not have a
This patch contains the GCN port of libgfortran. We use the minimal
configuration created for NVPTX. That's all that's required, besides the
target-independent bug fixes posted already.
2018-09-05 Andrew Stubbs
Kwok Cheung Yeung
Julian Brown
Tom de Vri
The minimal libgfortran setup was created for NVPTX, but will also be used by
AMD GCN.
This patch simply removes an assumption that NVPTX is the only user.
Specifically, NVPTX exit is broken, but AMD GCN exit works just fine.
2018-09-05 Andrew Stubbs
libgfortran/
* runtime/mi
1 - 100 of 151 matches
Mail list logo
