Hi!
In the following testcase, we have initially during RTL expansion a call
which can throw, followed by fallthrough into an empty block with two
similar predecessors (both calling the same function) and with a fallthrough
into an empty block with no successors (__builtin_unreachable).
That last
Hi :
This patch is about to enable support for bfloat16 which will be in Future
Cooper Lake, Please refer to
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference
for more details about BF16.
There are 3 instructions for AVX512BF16: VCV
Hi!
The following patch fixes various issues in patchable_function_entry
handling:
1) most importantly, it adds a warning if the argument(s) aren't integer
constants or if they are negative and drops the attribute
2) if (tree_fits_uhwi_p (x)) y = tree_to_uhwi (x); else gcc_unreachable ();
ma
On Fri, 12 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> In the following testcase, we have initially during RTL expansion a call
> which can throw, followed by fallthrough into an empty block with two
> similar predecessors (both calling the same function) and with a fallthrough
> into an empty block
On Fri, 12 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes various issues in patchable_function_entry
> handling:
> 1) most importantly, it adds a warning if the argument(s) aren't integer
>constants or if they are negative and drops the attribute
> 2) if (tree_fits_uhwi_p
Hi!
In r234626 Marek has added code to remove TREE_TYPE (newdecl) from
its variant list for typedefs, because we'll ggc_free the TYPE_NAME of that
type. Unfortunately, that code will ICE if TREE_TYPE (newdecl) is its own
TYPE_MAIN_VARIANT. This can happen if due to attributes the newdecl's type
On Fri, Apr 12, 2019 at 9:09 AM Liu, Hongtao wrote:
>
> Hi :
> This patch is about to enable support for bfloat16 which will be in
> Future Cooper Lake, Please refer to
> https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference
> for more
arch13 introduced instructions to perform vector element-wise byte
swaps on the way from or to memory. For a byte swap between vector
registers the vector permute instruction is required which needs a
permute pattern to be loaded into a vector register first.
With the current implementation there
Dear Gilles,
> -Ursprüngliche Nachricht-
> Von: Gilles Gouaillardet
> Gesendet: Freitag, 12. April 2019 02:25
> An: Bader, Reinhold ; Paul Richard Thomas
> ; fort...@gcc.gnu.org; gcc-patches patc...@gcc.gnu.org>
> Betreff: Re: AW: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop
On 11/04/19 21:15 -0700, Thomas Rodgers wrote:
* include/pstl/algorithm_impl.h: Uglify identfiers.
* include/pstl/numeric_impl.h: Uglify identfiers.
* include/pstl/parallel_backend_tbb.h: Uglify identfiers.
OK for trunk, thanks.
On Thu, Apr 11, 2019 at 3:02 PM Jakub Jelinek wrote:
>
> On Tue, Mar 12, 2019 at 10:58:14AM +0100, Jakub Jelinek wrote:
> > These are the only remaining cases of gcc-internal-format diagnostics using
> > HOST_WIDE_INT_PRINT*. That is wrong because the string depends on the exact
> > host, and xge
Dear Reinhold,
Thanks again for the insight !
My preference is also to avoid copy-in whenever possible.
But since my primary concern is performance (vs enforcing correctness of
the user apps), I am not willing to
use existing bugs to (fallaciously) conclude copy-in should be simply
droppe
On Fri, Apr 12, 2019 at 3:30 PM Uros Bizjak wrote:
>
> On Fri, Apr 12, 2019 at 9:09 AM Liu, Hongtao wrote:
> >
> > Hi :
> > This patch is about to enable support for bfloat16 which will be in
> > Future Cooper Lake, Please refer to
> > https://software.intel.com/en-us/download/intel-archite
Gilles & Reinhold,
Following the discussion, I have decided to remove the copy-in for
intent(in). Dominique and I have located the problem with -m32 for
PR90022 and I am working on PR89846 right now.
I will be resubmitting a bit later on.
Cheers
Paul
On Fri, 12 Apr 2019 at 01:25, Gilles Gouai
Ping.
On 04/04/2019 17:01, Sudakshina Das wrote:
> Hi Richard
>
> On 03/04/2019 11:28, Richard Henderson wrote:
>> On 4/3/19 5:19 PM, Sudakshina Das wrote:
>>> + /* PT_NOTE header: namesz, descsz, type.
>>> + namesz = 4 ("GNU\0")
>>> + descsz = 16 (Size of the program property array)
.. an additional observation. Over the last couple of days I wondered
if the amended testcase was really valid, given the non-terminal
parameter pack, beyond the evidence that all the compilers I have at
hand accept it. Note anyway, that we - and all the compilers - already
accept a version of
The following fixes a IPA PTA miscompilation involving recursion
which means two instances of the same local variables can become
live. For both testcases we confuse one for the other and cause
DSE to remove a store to the non-local one.
The fix involves adding a "shadow" variable representing
On Fri, Apr 12, 2019 at 11:03 AM Hongtao Liu wrote:
>
> On Fri, Apr 12, 2019 at 3:30 PM Uros Bizjak wrote:
> >
> > On Fri, Apr 12, 2019 at 9:09 AM Liu, Hongtao wrote:
> > >
> > > Hi :
> > > This patch is about to enable support for bfloat16 which will be in
> > > Future Cooper Lake, Please
On Fri, Nov 02, 2018 at 07:10:18AM -0400, Nathan Sidwell wrote:
> duplicate_decls is one of the more complex fns in decl.c, and I need to make
> it more complicated. But first some refactoring, so it's a little more
> understandable. Generally moving warning checks later when we know we've
> actu
On 4/11/19 6:30 PM, H.J. Lu wrote:
> On Thu, Apr 11, 2019 at 1:38 AM Martin Liška wrote:
>>
>> Hi.
>>
>> The patch is adding missing AVX512 ISAs for target and target_clone
>> attributes.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> T
Hi,
On Fri, 12 Apr 2019, Richard Biener wrote:
> @@ -332,6 +337,24 @@ struct obstack final_solutions_obstack;
> Indexed directly by variable info id. */
> static vec varmap;
>
> +/* Return whether VAR is an automatic variable. */
> +
> +static bool
> +auto_var_p (const_tree var)
> +{
> +
On 4/11/19 4:16 PM, Marek Polacek wrote:
[except.spec] says that "In a noexcept-specifier, the constant-expression,
if supplied, shall be a contextually converted constant expression of type
bool". We now have a dedicated function for creating such an expression,
so build_noexcept_spec should ma
On 4/11/19 5:36 PM, Marek Polacek wrote:
This patch deals with constexpr functions and whether or not they should be
noexcept.
CWG 1129 specified that constexpr functions are noexcept: it was a special case
in [expr.unary.noexcept]. This was accidentally removed in
but the CWG conclusion was t
On Fri, 12 Apr 2019, Michael Matz wrote:
> Hi,
>
> On Fri, 12 Apr 2019, Richard Biener wrote:
>
> > @@ -332,6 +337,24 @@ struct obstack final_solutions_obstack;
> > Indexed directly by variable info id. */
> > static vec varmap;
> >
> > +/* Return whether VAR is an automatic variable. *
Hi,
On Fri, 12 Apr 2019, Richard Biener wrote:
> > You miss PARM_DECLs and RESULT_DECLs, i.e. it's probably better to factor
> > out tree.c:auto_var_in_fn_p and place the new auto_var_p in tree.c as
> > well.
>
> Hmm, I left the above unchanged from a different variant of the patch
> where for
On Fri, 12 Apr 2019, Michael Matz wrote:
> Hi,
>
> On Fri, 12 Apr 2019, Richard Biener wrote:
>
> > > You miss PARM_DECLs and RESULT_DECLs, i.e. it's probably better to factor
> > > out tree.c:auto_var_in_fn_p and place the new auto_var_p in tree.c as
> > > well.
> >
> > Hmm, I left the above
Hi!
Just something I've noticed while looking at Ramana's patch.
As can be seen on the testcase, on arm we accept arbitrary garbage
after arm or thumb prefixes, is that really desirable?
While for fpu= or arch= we reject garbage after it and so do for
target attribute arg starting with +.
Ok if
On Fri, Apr 12, 2019 at 4:41 AM Martin Liška wrote:
>
> On 4/11/19 6:30 PM, H.J. Lu wrote:
> > On Thu, Apr 11, 2019 at 1:38 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is adding missing AVX512 ISAs for target and target_clone
> >> attributes.
> >>
> >> Patch can bootstrap on x86_64-l
On Thu, 11 Apr 2019 at 11:26, Matthew Malcomson
wrote:
>
> r269586 changed the format of some warning messages.
>
> Each switch in the warning message is now surrounded by single quotes.
>
> This commit updates the regex's in arm.exp dejagnu files to match the
> new format and remove the extra 20+
On Fri, 12 Apr 2019 at 16:16, Christophe Lyon
wrote:
>
> On Thu, 11 Apr 2019 at 11:26, Matthew Malcomson
> wrote:
> >
> > r269586 changed the format of some warning messages.
> >
> > Each switch in the warning message is now surrounded by single quotes.
> >
> > This commit updates the regex's in
Hi,
On Fri, 12 Apr 2019, Richard Biener wrote:
> > > > You miss PARM_DECLs and RESULT_DECLs, i.e. it's probably better to
> > > > factor out tree.c:auto_var_in_fn_p and place the new auto_var_p in
> > > > tree.c as well.
> > >
> > > Hmm, I left the above unchanged from a different variant of t
On 12/04/19 15:16, Christophe Lyon wrote:
> On Thu, 11 Apr 2019 at 11:26, Matthew Malcomson
> wrote:
>>
>> r269586 changed the format of some warning messages.
>>
>> Each switch in the warning message is now surrounded by single quotes.
>>
>> This commit updates the regex's in arm.exp dejagnu file
On Fri, 12 Apr 2019 at 16:23, Matthew Malcomson
wrote:
>
> On 12/04/19 15:16, Christophe Lyon wrote:
> > On Thu, 11 Apr 2019 at 11:26, Matthew Malcomson
> > wrote:
> >>
> >> r269586 changed the format of some warning messages.
> >>
> >> Each switch in the warning message is now surrounded by sing
On Fri, Apr 12, 2019 at 3:19 AM Uros Bizjak wrote:
>
> On Fri, Apr 12, 2019 at 11:03 AM Hongtao Liu wrote:
> >
> > On Fri, Apr 12, 2019 at 3:30 PM Uros Bizjak wrote:
> > >
> > > On Fri, Apr 12, 2019 at 9:09 AM Liu, Hongtao
> > > wrote:
> > > >
> > > > Hi :
> > > > This patch is about to en
On 4/11/19 1:54 AM, Richard Biener wrote:
> On Thu, 11 Apr 2019, Jakub Jelinek wrote:
>
>> Hi!
>>
>> The following testcase is miscompiled, because the result of
>> a DImode (doubleword) right shift is used in a QImode subreg as well as
>> later on pushed into a stack slot as an argument to a cons
On 4/10/19 3:27 PM, Stafford Horne wrote:
> Hello,
>
> This is a set of patches to bring FPU support to the OpenRISC backend. The
> backend also add support for 64-bit floating point operations on 32-bit cores
> using register pairs, see orfpx64a32 [0].
>
> This depends on binutils patches which
On Fri, 12 Apr 2019, Jeff Law wrote:
> We've been through the "who owns the argument slots, caller or callee"
> discussion a few times and I don't think we've ever reached any kind of
> conclusion in the general case.
Callee must own the slots for tail calls to be possible.
> I think this case si
On 4/12/19 9:32 AM, Alexander Monakov wrote:
> On Fri, 12 Apr 2019, Jeff Law wrote:
>> We've been through the "who owns the argument slots, caller or callee"
>> discussion a few times and I don't think we've ever reached any kind of
>> conclusion in the general case.
>
> Callee must own the slots
On 4/11/19 6:51 AM, Jakub Jelinek wrote:
> Hi!
>
> While doing make gcc.pot, I've noticed warnings about unterminated string
> in loongson-mmintrin.h.
> I don't have any usable mips setup, but just tried:
> /tmp/1a.c:
> # error "You must select -mloongson-mmi or -march=loongson2e/2f/3a to use
>
On 4/11/19 6:27 AM, Jakub Jelinek wrote:
> Hi!
>
> These 3 *.opt messages are printed using:
> opts-common.c:error_at (loc, option->missing_argument_error, opt);
> opts-common.c:error_at (loc, e->unknown_error, arg);
> opts-common.c:warning_at (loc, 0, decoded->warn_message, op
On 4/11/19 3:26 AM, Richard Biener wrote:
> On Thu, 11 Apr 2019, Jakub Jelinek wrote:
>
>> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
During those 2 bootstraps/regtests, data.load_found has bee
On 4/11/19 3:04 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>>
>>> During those 2 bootstraps/regtests, data.load_found has been set just
>>> on the new testcase on ia32.
>>
>> Hm
On 12/04/2019 15:12, Jakub Jelinek wrote:
Hi!
Just something I've noticed while looking at Ramana's patch.
As can be seen on the testcase, on arm we accept arbitrary garbage
after arm or thumb prefixes, is that really desirable?
While for fpu= or arch= we reject garbage after it and so do for
t
On 4/11/19 11:18 AM, Joao Moreira wrote:
> When -fpatchable-relocation-entry is used, gcc places nops on the
> prologue of each compiled function and creates a section named
> __patchable_function_entries which holds relocation entries for the
> positions in which the nops were placed. As is, gcc c
Dne 2019-04-11 17:14, Martin Jambor napsal:
Hi,
this reorganization of cgraph_node:clone_of_p() prevents verifier
falsely ICEing because it cannot recognize that a former thunk
(expanded
even before reaching pass pipeline) was cloned by IPA-CP.
It basically traverses the clone_of chain at eac
On 4/11/19 9:58 AM, Iain Buclaw wrote:
> On Sat, 6 Apr 2019 at 19:05, Iain Buclaw wrote:
>>
>> On Sat, 6 Apr 2019 at 17:27, Matthias Klose wrote:
>>>
>>> On 29.03.19 23:23, Iain Buclaw wrote:
On Mon, 18 Feb 2019 at 14:26, Matthias Klose wrote:
>
>
> sorry, I didn't mean to propo
Now that we return the original CONSTRUCTOR from finish_compound_literal,
the call to null_member_pointer_value_p in tsubst_copy_and_build was getting
confused because the CONSTRUCTOR was still empty rather than a valid PMF
value. This is a regression from GCC 8.
Tested x86_64-pc-linux-gnu, apply
On 4/2/19 3:19 PM, Martin Sebor wrote:
> This is yet another follow up on the discussion of the fix for
> the ICE in __builtin_has_attribute that started last December
> with PR88383.
>
> After my last post last week I went and added more tests to make
> sure the built-in behaves as intended by co
On Fri, 12 Apr 2019, Richard Biener wrote:
> On Fri, 12 Apr 2019, Michael Matz wrote:
>
> > Hi,
> >
> > On Fri, 12 Apr 2019, Richard Biener wrote:
> >
> > > > You miss PARM_DECLs and RESULT_DECLs, i.e. it's probably better to
> > > > factor
> > > > out tree.c:auto_var_in_fn_p and place the ne
On 4/11/19 11:20 AM, Paolo Carlini wrote:
Hi,
over the last few days I spent some time on this regression, which at
first seemed just a minor error-recovery issue, but then I noticed that
very slightly tweeking the original testcase uncovered a pretty serious
ICE on valid:
template void
fk
On 4/12/19 3:19 AM, Jakub Jelinek wrote:
In r234626 Marek has added code to remove TREE_TYPE (newdecl) from
its variant list for typedefs, because we'll ggc_free the TYPE_NAME of that
type. Unfortunately, that code will ICE if TREE_TYPE (newdecl) is its own
TYPE_MAIN_VARIANT. This can happen if
On Fri, Apr 12, 2019 at 02:46:19PM -0400, Jason Merrill wrote:
> On 4/12/19 3:19 AM, Jakub Jelinek wrote:
> > In r234626 Marek has added code to remove TREE_TYPE (newdecl) from
> > its variant list for typedefs, because we'll ggc_free the TYPE_NAME of that
> > type. Unfortunately, that code will I
On Fri, Apr 12, 2019 at 09:28:55AM -0600, Jeff Law wrote:
> On 4/10/19 3:27 PM, Stafford Horne wrote:
> > Hello,
> >
> > This is a set of patches to bring FPU support to the OpenRISC backend. The
> > backend also add support for 64-bit floating point operations on 32-bit
> > cores
> > using regi
On 4/12/19 3:56 PM, Jakub Jelinek wrote:
On Fri, Apr 12, 2019 at 02:46:19PM -0400, Jason Merrill wrote:
On 4/12/19 3:19 AM, Jakub Jelinek wrote:
In r234626 Marek has added code to remove TREE_TYPE (newdecl) from
its variant list for typedefs, because we'll ggc_free the TYPE_NAME of that
type.
If a noexcept function calls a function that might throw, doing the tail
call optimization means that an exception thrown in the called function
will propagate out, breaking the noexcept specification. So we need to
prevent the optimization in that case.
Tested x86_64-pc-linux-gnu. OK for trunk
Jason wrote:
>If a noexcept function calls a function that might throw, doing the tail
call optimization means that an exception thrown in the called function
will propagate out, breaking the noexcept specification. So we need to
prevent the optimization in that case.
>Tested x86_64-pc-linux-gnu
On Fri, Apr 12, 2019 at 10:45:25AM -0600, Jeff Law wrote:
> > gcc/ChangeLog:
> >
> > PR c/89797
> > * targhooks.c (default_vector_alignment): Avoid assuming
> > argument fits in SHWI.
> > * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in
> > a shift expression.
> >
> > g
On Fri, Apr 12, 2019 at 11:42:59PM +0200, Jakub Jelinek wrote:
> > With a suitable doc change of that nature, this is OK.
>
> Has the patch been tested at all?
> I see many new FAILs after the patch:
> make check-gcc check-c++-all RUNTESTFLAGS="--target_board=unix\{-m32,-m64\}
> dg.exp='attribute
Hi,
Now that libz_convenience.a is used, it's possible to add
subdir-objects. Running autoreconf regenerates all files cleanly with
autoconf2.69.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r270330.
--
Iain
---
libphobos/ChangeLog:
2019-04-12 Iain Buclaw
On 4/12/19 3:24 PM, Jason Merrill wrote:
> If a noexcept function calls a function that might throw, doing the tail
> call optimization means that an exception thrown in the called function
> will propagate out, breaking the noexcept specification. So we need to
> prevent the optimization in that
On 4/12/19 3:42 PM, Jakub Jelinek wrote:
On Fri, Apr 12, 2019 at 10:45:25AM -0600, Jeff Law wrote:
gcc/ChangeLog:
PR c/89797
* targhooks.c (default_vector_alignment): Avoid assuming
argument fits in SHWI.
* tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in
Tested x86_64-linux, committed to trunk.
Jonathan Wakely writes:
> On 11/04/19 21:15 -0700, Thomas Rodgers wrote:
>>
>> * include/pstl/algorithm_impl.h: Uglify identfiers.
>> * include/pstl/numeric_impl.h: Uglify identfiers.
>> * include/pstl/parallel_backend_tbb.h: Uglify id
This patch to the Go frontend by Than McIntosh improves type handling
for string concat ops on constants. This resolves a small problem
with concatenation of string constants: in a string concat X + Y where
X has named type and Y has abstract string type, ensure that the
result has X's type, and d
63 matches
Mail list logo
