Hi,
This patch repairs vpopcnt tests.
06.02.2018 Olga Makhotina
gcc/testsuite/
PR target/83828
* gcc.target/i386/avx512bitalg-vpopcntb-1.c: Fix test.
* gcc.target/i386/avx512bitalg-vpopcntw-1.c: Ditto.
* gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Ditto.
The option is not supported on the original Solaris' grep. Given that there
is also a redirection to /dev/null at the end, it is superfluous.
Tested on x86_64-suse-linux, applied on the mainline as obvious.
2018-02-06 Eric Botcazou
config/
* gcc-plugin.m4 (GCC_ENABLE_PLUGINS): Remo
On Mon, Feb 5, 2018 at 10:53 PM, Thomas Koenig wrote:
> Am 05.02.2018 um 13:09 schrieb Janne Blomqvist:
>>
>> On Sun, Feb 4, 2018 at 9:49 PM, Thomas Koenig
>> wrote:
>>>
>>> Hello world,
>>>
>>> in the attached patch, I have used flexible array members for
>>> using the different descriptor types
On 01/29/2018 12:51 PM, Joseph Myers wrote:
> On Mon, 29 Jan 2018, vladimir.mezent...@oracle.com wrote:
>
>>> What about powerpc __divkc3?
>>>
>>> What was the rationale for using soft-fp rather than adding appropriate
>>> built-in functions as suggested in a comment?
>> I had a version with built
The -Walloca pass can receive a malformed alloca, courtesy of someone
providing a faulty prototype. This was causing an ICE because we
assumed alloca calls had at least one argument, which the testcase does not:
+void *alloca ();
+__typeof__(alloca ()) a () { return alloca (); }
I don't belie
On Fri, Jan 05, 2018 at 12:22:44PM +, Wilco Dijkstra wrote:
> The shrinkwrap optimization added late in GCC 7 allows each callee-save to
> be delayed and done only across blocks which need a particular callee-save.
> Although this reduces unnecessary memory traffic on code paths that need
> few
> This patch adds new intrinsics: pconfig, wbnoinvd and wbinvd.
>
> 05.02.2018 Olga Makhotina
>
> gcc/
> * common/config/i386/i386-common.c (OPTION_MASK_ISA_PCONFIG_SET,
> OPTION_MASK_ISA_PCONFIG_UNSET, OPTION_MASK_ISA_WBNOINVD_SET,
> OPTION_MASK_ISA_WBNOINVD_UNSET): New definitions.
> (ix86_han
Rainer Orth writes:
> As described in the PR, cc1 SEGVs compiling gcc.dg/rtl/x86_64/final.c on
> targets that default to -fno-dwarf2-cfi-asm. However, the test is
> compile-only, so doesn't depend on the toolchain's support for cfi
> directives. Besides, it scans the output for those, so depend
On 05/02/18 11:52, Tamar Christina wrote:
Hi All,
This patch silences the warnings that were emitted when certain ACLE macros
were being redefined
when using the new target pragma or attribute to change architecture level.
It also keeps better track of which arch directives have already been
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Nick Clifton
> Sent: Monday, February 5, 2018 4:15 PM
> To: hjl.to...@gmail.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: RFA: PR 84154: Fix checking -mibt and -mshstk options fo
On 02/02/18 15:43, Kyrill Tkachov wrote:
> Hi Richard,
>
> On 02/02/18 15:25, Richard Earnshaw (lists) wrote:
>> On 02/02/18 15:10, Kyrill Tkachov wrote:
>>> Hi all,
>>>
>>> In this [8 Regression] PR we ICE because we can't recognise the insn:
>>> (insn 59 58 43 7 (set (reg:DI 124)
>>> (r
On 02/02/18 20:55, Eric Botcazou wrote:
>> But, that is not what the builtin setjmp/longjmp tests have.
>
> Yes, but I don't think that we want to risk breaking a working compiler on
> some targets because peculiar tests don't pass on another. I think that
> init_eh is OK for x32 so SJLJ except
On 12/21/2017 10:46 PM, Cesar Philippidis wrote:
I've committed this patch to openacc-gcc-7-branch.
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index bf1f127d8d6..f674c74ec82 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
offloaded = is_gimple_omp_offloaded (entry_stmt);
Hi Igor,
>> Attached is a potential patch for PR 84145:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145
> Coincidentally, I have worked on the same patch.
Great minds, etc :-)
> Please look at the patch, I uploaded it to the bug. The main differences are
>
> - updated the output mes
On Tue, Feb 6, 2018 at 3:38 AM, Richard Earnshaw (lists)
wrote:
> On 02/02/18 20:55, Eric Botcazou wrote:
>>> But, that is not what the builtin setjmp/longjmp tests have.
>>
>> Yes, but I don't think that we want to risk breaking a working compiler on
>> some targets because peculiar tests don't p
On Fri, Jan 26, 2018 at 02:21:11PM +, Richard Sandiford wrote:
> I hadn't realised that on big-endian targets, VEC_UNPACK*HI_EXPR unpacks
> the low-numbered lanes and VEC_UNPACK*LO_EXPR unpacks the high-numbered
> lanes. This meant that both the SVE patterns and the handling of
> fully-masked
Hi Martin,
> My only suggestions are to consider how control characters and
> excessively messages are handled in other contexts and adopt
> the same approach here.
Are there other places where user-supplied messages are displayed by gcc ?
> In the tests I did, control characters
> were mostly
On 2/5/18 10:48 PM, David Edelsohn wrote:
> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote:
>> I did also try calling expand_divmod() here which did generate correct
>> code, the problem was that it wasn't as clean/optimized as the change
>> to gen_divdi3.
>
> Why not fix it at the site of t
When -Wstringop-truncation sees a strncpy call where the specified bound
is equal to the size of the destination, it looks at the next statement
to see if it's dst[i] = '\0';, and if it is, it doesn't warn. But it
needs to look at the next nondebug statement, otherwise we can get a
false positive
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
> --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> @@ -0,0 +1,20 @@
> +/* PR tree-optimization/84228 */
> +/* { dg-do compile } */
> +/* { dg-options "-Wstringop-truncat
On Tue, Feb 06, 2018 at 06:42:06AM -0600, Peter Bergner wrote:
> On 2/5/18 10:48 PM, David Edelsohn wrote:
> > On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote:
> >> I did also try calling expand_divmod() here which did generate correct
> >> code, the problem was that it wasn't as clean/optimiz
On Tue, Feb 06, 2018 at 01:57:36PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
> > --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> > +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> > @@ -0,0 +1,20 @@
> > +/* PR tree-optimization/8
>
> I think unify_scc is only ever called from WPA so you can elide the
> flag_ltrans checks.
>
> Otherwise OK.
Thanks, I have updated this and also dropped the sanity check from symtab.c
because, well, it finds another bugs in target versioning I will handle
incrementally. I also noticed I
Hi DJ,
I've updated the patch (extend.texi) as you suggested.
Please let me know if this is OK to check-in, thank you!
Best Regards,
Sebastian
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c(revision 257142)
+++ config/rl78/rl7
PING
> -Original Message-
> From: Sebastian Perta [mailto:sebastian.pe...@renesas.com]
> Sent: 08 January 2018 10:57
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] -mjsr option bug fix
>
> Hi,
>
> The -mjsr option in RX should ensure the that BSR instruction is not
> generated, only JS
PING
> -Original Message-
> From: Sebastian Perta [mailto:sebastian.pe...@renesas.com]
> Sent: 09 January 2018 14:46
> To: 'gcc-patches@gcc.gnu.org'
> Subject: [PATCH] RX movsicc degrade fix
>
> Hello,
>
> In recent versions of GCC the define_expand "movsicc" has stopped being
> used by
On Tue, 2018-02-06 at 12:39 +, Nick Clifton wrote:
> Hi Martin,
>
> > My only suggestions are to consider how control characters and
> > excessively messages are handled in other contexts and adopt
> > the same approach here.
>
> Are there other places where user-supplied messages are display
> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: Tuesday, February 6, 2018 1:16 PM
> To: Tsimbalist, Igor V ; hjl.to...@gmail.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: PR 84154: Fix checking -mibt and -mshstk options for control
> flow protection
>
> Hi Ig
On Tue, Feb 6, 2018 at 3:08 PM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: Nick Clifton [mailto:ni...@redhat.com]
>> Sent: Tuesday, February 6, 2018 1:16 PM
>> To: Tsimbalist, Igor V ; hjl.to...@gmail.com
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: PR 84154: Fix checking -
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, January 31, 2018 9:57 PM
> To: Uros Bizjak ; Kirill Yukhin
>
> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
>
> Subject: [PATCH] Fix ICE with CET and -g (PR target/84146)
>
> Hi!
>
> We ICE on the
Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your
suggestions and re-tested the changes. Everything is still sane.
Since this is ARM-specific and fairly specific, i wonder if it would be
reasonable to consider it for inclusion at the current stage.
Regards,
Luis
Changes in
This libgo patch corrects the runtime structfield type to match the
reflect type, which is the one actually generated by the compiler.
The offset field in structfield has changed to offsetAnon, and now
requires a shift to get the actual offset value. This fixes
https://golang.org/issue/23391. Boo
On Mon, Feb 5, 2018 at 11:26 AM, Ian Lance Taylor wrote:
> On Mon, Feb 5, 2018 at 10:47 AM, Rainer Orth
> wrote:
>>
>>> This patch to the Go frontend checks for negative numbers with very
>>> small magnitudes that will round to negative zero, and forces them to
>>> positive zero instead. This im
In this PR we are ICEing here:
bool
operation_no_trapping_overflow (tree type, enum tree_code code)
{
gcc_checking_assert (ANY_INTEGRAL_TYPE_P (type));
...because we are being passed a pointer type from find_trapping_overflow.
Fixed by avoiding passing non-integrals from find_trapping_overflo
On 2/6/18 6:42 AM, Peter Bergner wrote:
> On 2/5/18 10:48 PM, David Edelsohn wrote:
>> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote:
>>> I did also try calling expand_divmod() here which did generate correct
>>> code, the problem was that it wasn't as clean/optimized as the change
>>> to ge
Hi Carl,
On Thu, Feb 01, 2018 at 11:31:55AM -0800, Carl Love wrote:
> The following patch contains fixes for the builtins to add and extract
> a word from a char vector. The existing names for the builtins that do
> this are not consistent with the ABI. Additionally, the supported
> arguments a
On Tue, Feb 06, 2018 at 10:43:21AM -0500, Aldy Hernandez wrote:
> In this PR we are ICEing here:
>
> bool
> operation_no_trapping_overflow (tree type, enum tree_code code)
> {
> gcc_checking_assert (ANY_INTEGRAL_TYPE_P (type));
>
> ...because we are being passed a pointer type from find_trappin
On 02/06/2018 06:23 AM, Marek Polacek wrote:
On Tue, Feb 06, 2018 at 01:57:36PM +0100, Jakub Jelinek wrote:
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
--- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
+++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
@@ -0,0 +1,2
I have committed this patch to suppress some more irrelevant options
from the output of "gcc --target-help" for the powerpcspe backend.
I have tested this by rebuilding GCC and checking the output of "gcc
--target-help".
2018-02-02 Andrew Jenner
* config/powerpcspe/powerpcspe.opt
On 02/02/2018 21:29, Joseph Myers wrote:
On Fri, 2 Feb 2018, Andrew Jenner wrote:
This patch adds a section to invoke.texi for the new PowerPC SPE backend,
mostly copied from the PowerPC backend but with irrelevant options removed.
I think a lot of the remaining options are also irrelevant to
Here we ICE because get_range_strlen's result might not be an array of
two integer constants -- for a VLA the array might contain a non-constant.
So beef up the check before converting to wide_int.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-02-06 Marek Polacek
PR tree-
On Tue, Feb 6, 2018 at 10:43 AM, Peter Bergner wrote:
> On 2/6/18 6:42 AM, Peter Bergner wrote:
>> On 2/5/18 10:48 PM, David Edelsohn wrote:
>>> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote:
I did also try calling expand_divmod() here which did generate correct
code, the problem
Ok for trunk, though generally looking at just next stmt is very
fragile, might be
better to look at the strncpy's vuse immediate uses if they are
within the
same basic block and either don't alias with it, or are the store it is
looking for, or something similar.
I guess some
FOR_EACH_IMM_USE_F
Hi Bill,
On Mon, Feb 05, 2018 at 12:28:34PM -0600, Bill Schmidt wrote:
> It's been determined that we won't recommend use of the recently added
> undocumented option -mno-speculate-indirect-jumps. This patch provides
> a warning indicating that the option is deprecated. We will leave the
> code
On 2/6/18 10:20 AM, David Edelsohn wrote:
> Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR
> iterator, as Segher suggested?
Well it works _if_ we use the first patch that changes the gen_*
patterns. If we go this route, I agree we should use the SDI
iterator instead of GPR.
On Tue, Feb 6, 2018 at 3:57 PM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Wednesday, January 31, 2018 9:57 PM
>> To: Uros Bizjak ; Kirill Yukhin
>>
>> Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
>>
>> Subject: [PATCH] Fi
On Feb 6, 2018, at 10:33 AM, Segher Boessenkool
wrote:
>
> Hi Bill,
>
> On Mon, Feb 05, 2018 at 12:28:34PM -0600, Bill Schmidt wrote:
>> It's been determined that we won't recommend use of the recently added
>> undocumented option -mno-speculate-indirect-jumps. This patch provides
>> a warning
On Mon, 5 Feb 2018, vladimir.mezent...@oracle.com wrote:
> My implementation avoids these issues.
> I use soft-fp instead built-in functions because performance with built-in
> functions (like __builtin_ilogb) is in two times worse.
> Also libm is needed for built-in functions.
I think you still
Alan Hayward writes:
> This patch adds support for CLOBBER_HIGH in the generation code.
>
> An aarch64 will require 31 clobber high expressions, plus two
> clobbers.
>
> The exisiting gen code restricts to 26 vector operands by virtue
> of using the operators [a-z]. This patch extends this to 52 b
On February 6, 2018 2:29:42 PM GMT+01:00, Jan Hubicka wrote:
>>
>> I think unify_scc is only ever called from WPA so you can elide the
>flag_ltrans checks.
>>
>> Otherwise OK.
>
>Thanks, I have updated this and also dropped the sanity check from
>symtab.c
>because, well, it finds another bugs
On 02/06/2018 10:52 AM, Jakub Jelinek wrote:
On Tue, Feb 06, 2018 at 10:43:21AM -0500, Aldy Hernandez wrote:
In this PR we are ICEing here:
bool
operation_no_trapping_overflow (tree type, enum tree_code code)
{
gcc_checking_assert (ANY_INTEGRAL_TYPE_P (type));
...because we are being pass
On 02/06/2018 05:39 AM, Nick Clifton wrote:
Hi Martin,
My only suggestions are to consider how control characters and
excessively messages are handled in other contexts and adopt
the same approach here.
Are there other places where user-supplied messages are displayed by gcc ?
There are a f
On Tue, 6 Feb 2018, vladimir.mezent...@oracle.com wrote:
> I compared with __builtin_ilogb. There is a same performance degradation.
I'm not clear on exactly what you compared with.
Do you mean the *existing* __builtin_ilogb? That's only supported for
constant arguments that are not zero, inf
Hi!
On Mon, Feb 05, 2018 at 05:57:51PM -0500, Michael Meissner wrote:
> > We have
> >
> > (define_code_attr su [(sign_extend "s")
> > (zero_extend "u")
> > (fix "s")
> > (unsigned_fix "s")
> >
On Tue, 6 Feb 2018, Andrew Jenner wrote:
> Okay to commit to trunk?
As you're powerpcspe maintainer I'm not sure what you're asking for
approval for. Are you asking rs6000 port maintainers to approve the
removal of the documentation for options that no longer exist in that
port?
--
Joseph S
On 06/02/2018 17:19, Joseph Myers wrote:
On Tue, 6 Feb 2018, Andrew Jenner wrote:
Okay to commit to trunk?
As you're powerpcspe maintainer I'm not sure what you're asking for
approval for. Are you asking rs6000 port maintainers to approve the
removal of the documentation for options that no
On Tue, Feb 06, 2018 at 10:36:41AM -0600, Peter Bergner wrote:
> On 2/6/18 10:20 AM, David Edelsohn wrote:
> > Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR
> > iterator, as Segher suggested?
>
> Well it works _if_ we use the first patch that changes the gen_*
> patterns. If
Rainer Orth writes:
> When compiling MariaDB 10.2 (which uses cfi directives in inline asm,
> but gets the conditionals wrong) on Solaris 11.4 with an
> x86_64-pc-solaris2.11 gcc using gas, I noticed that this one incorrectly
> doesn't use cfi directives although it could/should.
>
> Looking clos
Rainer Orth writes:
> While investigating PR bootstrap/84017, it turned out that it *is*
> possible to enable COMDAT group support on Solaris 10 with Solaris ld in
> some circumstances. I'm posting my findings and the resulting patch
> here for reference only; this is certainly not GCC 8 materia
On 05/02/2018 18:16, Jonathan Wakely wrote:
On 01/02/18 22:48 +0100, François Dumont wrote:
Hi
As we just bump version namespace it might be interesting to do
the following change now. What do you think ?
I'd rather not make the code harder to read in all those places just
for an optiona
On 2/6/18 11:39 AM, Segher Boessenkool wrote:
> Yes, if you make [u]divdi3 work for SDI (i.e. also for -m32) we'll never
> have to special-case it again (also [u]moddi3?)
Maybe, but there are no explicit calls to those, so I left them
as is, since if we touch those, then we probably need to look a
On Tue, Feb 06, 2018 at 11:15:21AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Feb 05, 2018 at 05:57:51PM -0500, Michael Meissner wrote:
> > > We have
> > >
> > > (define_code_attr su [(sign_extend "s")
> > > (zero_extend "u")
> > > (fi
On Fri, Feb 02, 2018 at 03:13:21PM -0500, Jason Merrill wrote:
> > Or should I change the switch body to do other kind = overrides?
>
> I think we want to avoid clobbering NON_LVALUE_EXPR location wrappers, too.
>
> This has gotten large enough that it should break out into its own function.
>
>
On 02/02/2018 09:17 AM, Richard Sandiford wrote:
Richard Sandiford writes:
Segher Boessenkool writes:
Hi!
On Fri, Jan 26, 2018 at 01:25:51PM +, Richard Sandiford wrote:
if (SCALAR_INT_MODE_P (inmode))
new_out_reg = gen_lowpart_SUBREG (outmode, reg);
else
Hi!
As the following testcase shows, dom2 miscompiles floating point x - x
into 0.0 even when x could be infinity and x - x then a NaN.
The corresponding match.pd optimization is:
/* Simplify x - x.
This is unsafe for certain floats even in non-IEEE formats.
In IEEE, it is unsafe because it
Hi!
The last year's bss_initializer_p change apparently broke xen. While it is
reasonable not to put const variables into .bss* sections by default,
refusing to put them when the user asks for it through using section
attribute seems unnecessary. If users screws up, he can get section flag
confl
Since -fcf-protection requires both -mshstk and -mibt, use
-fcf-protection=return with -mshstk in cet-intrin-4.c.
OK for trunk?
H.J.
--
PR target/84243
* gcc.target/i386/cet-intrin-4.c (dg-options): Use
-fcf-protection=return.
---
gcc/testsuite/gcc.target/i386/cet-intrin-
Since ix86_option_override_internal sets the CF_SET bit in
flag_cf_protection and it can be called more than once via pragma,
we need to mask out the CF_SET bit when checking flag_cf_protection.
OK for trunk if there is no regression?
H.J.
---
PR target/84248
* config/i386/i386.c
On 12/11/2017 09:52 PM, Alexandre Oliva wrote:
+/* output symbol LAB1 as an unsigned LEB128 quantity. */
+
+void
+dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED,
+ const char *comment, ...)
I'm having trouble understanding the use of symbols for
> -Original Message-
> From: Lu, Hongjiu
> Sent: Tuesday, February 6, 2018 10:03 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak ; Tsimbalist, Igor V
>
> Subject: [PATCH] Use -fcf-protection=return in cet-intrin-4.c
>
> Since -fcf-protection requires both -mshstk and -mibt, use
> -fcf-
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> Sent: Tuesday, February 6, 2018 10:09 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Uros Bizjak ; Tsimbalist, Igor V
>
> Subject: [PATCH] i386: Mask out the CF_SET bit for -
On Thu, 1 Feb 2018, Segher Boessenkool wrote:
>> Just the move ofseems
>> unclear to me? Can you omit that?
> The entries are alphabetic, except that one. Should have put it in
> a separate patch, sorry.
Actually it was fine as I just realize.
I got confused by hppa and nvptx (which is sor
On Tue, Feb 06, 2018 at 11:15:21AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Feb 05, 2018 at 05:57:51PM -0500, Michael Meissner wrote:
> > > We have
> > >
> > > (define_code_attr su [(sign_extend "s")
> > > (zero_extend "u")
> > > (fi
Am 06.02.2018 um 09:53 schrieb Janne Blomqvist:
/* Make the INTEGER*4 array for passing to date_and_time. */
- gfc_array_i4 *avalues = xmalloc (sizeof (gfc_array_i4));
+ gfc_array_i4 *avalues = xmalloc (sizeof (gfc_full_array_i4));
Since date_and_time requires the values array to always
[ was: Re: [PATCH,WIP] Use functional parameters for data mappings in
OpenACC child functions ]
On 02/06/2018 12:46 PM, Tom de Vries wrote:
On 12/21/2017 10:46 PM, Cesar Philippidis wrote:
I've committed this patch to openacc-gcc-7-branch.
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
i
On Tue, Feb 6, 2018 at 3:28 PM, Jakub Jelinek wrote:
> On Fri, Feb 02, 2018 at 03:13:21PM -0500, Jason Merrill wrote:
>> > Or should I change the switch body to do other kind = overrides?
>>
>> I think we want to avoid clobbering NON_LVALUE_EXPR location wrappers, too.
>>
>> This has gotten large
Hi Igor,
> Here is the updated patch. Please note the subject should say PR 84145.
the two new testcases FAIL on all non-x86 targets (I've seen that on
sparc-sun-solaris2.11, there's a gcc-testresults posting for
powerpc64le-unknown-linux-gnu, and PR testsuite/84243 reports it for
aarch64-none-li
Sebastian Perta writes:
> I've updated the patch (extend.texi) as you suggested.
> Please let me know if this is OK to check-in, thank you!
Looks OK to me, but wait a day or two for a docs person to comment on...
> -On RX targets, you may specify one or more vector numbers as arguments
> +On RX
> -Original Message-
> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> Sent: Tuesday, February 6, 2018 11:50 PM
> To: Tsimbalist, Igor V
> Cc: gcc-patches@gcc.gnu.org; Nick Clifton ;
> hjl.to...@gmail.com; Uros Bizjak
> Subject: Re: PR 84154: Fix checking -mibt and -mshstk opti
Hi!
As mentioned on IRC, operation_could_trap_helper_p returns true
for division or modulo with -ftrapv; the operations could trap in certain
cases (e.g. division by -1 of minimum signed value, but we don't have any
library functions for division/modulo for -ftrapv nor instrument it in any
way).
Hi,
on a rather old x86_64-linux machine GCC doesn't build anymore with r257414:
libtool: compile: /xxx/Gcc/svn-dirs/trunk-build/./gcc/xg++
-B/xxx/Gcc/svn-dirs/trunk-build/./gcc/ -nostdinc++ -nostdinc++
-I/xxx/Gcc/svn-dirs/trunk-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-g
> -Original Message-
> From: Paolo Carlini [mailto:paolo.carl...@oracle.com]
> Sent: Wednesday, February 7, 2018 12:46 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: Nick Clifton ; hjl.to...@gmail.com; Uros Bizjak
>
> Subject: Re: PR 84154: Fix checking -mibt and -mshstk op
Hi,
On 07/02/2018 01:02, Tsimbalist, Igor V wrote:
The issue is known and is covered by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84248. The patch has been
posted
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00276.html
Ok, thanks, I missed the above.
Paolo.
On 02/06/2018 08:53 AM, Joseph Myers wrote:
> The files in libgcc/soft-fp must be verbatim copies of the master sources
> in glibc. So you can't make any local changes to them, and if you think
> changes are needed you need to patch things upstream in glibc first, with
> a proper extended explan
On Tue, 6 Feb 2018, vladimir.mezent...@oracle.com wrote:
> We see 'struct _FP_STRUCT_LAYOUT' is declared twice (in lines 206 and
_FP_STRUCT_LAYOUT is not a struct tag. It is a macro that may be defined
to empty, or to an attribute, and defaults to empty in soft-fp.h if not
otherwise defined in
This patch to the Go frontend by Cherry Zhang makes a single backend
type for methods table of identical interface types. Otherwise
identical interface types will get an identical backend type, but can
have different method tables, which is inconsistent and can leave
incomplete placeholdser around
The attached patch fixes PR fortran/82049. Prior to this
patch, gfortran was fouling up the resolution of the charlen
expression in the testcase. The immediately tries to resolve
the length while parsing the type-spec.
While here, I've introduced an optimization that causes
gfc_match_type_spec()
On 02/05/2018 02:52 PM, Jason Merrill wrote:
On 02/04/2018 07:07 PM, Martin Sebor wrote:
To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change t
On Feb 6, 2018, Jason Merrill wrote:
> On 12/11/2017 09:52 PM, Alexandre Oliva wrote:
>> +/* output symbol LAB1 as an unsigned LEB128 quantity. */
>> +
>> +void
>> +dw2_asm_output_symname_uleb128 (const char *lab1 ATTRIBUTE_UNUSED,
>> +const char *comment, ...)
> I'
On Jan 30, 2018, Richard Sandiford wrote:
>> But it is my understanding that both of the following are correct:
>>
>> return (verylongcondition
>> && otherlongcondition__);
>>
>> return verylongcondition
On February 6, 2018 9:40:37 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As the following testcase shows, dom2 miscompiles floating point x - x
>into 0.0 even when x could be infinity and x - x then a NaN.
>The corresponding match.pd optimization is:
>/* Simplify x - x.
> This is unsafe for certa
Here's an incremental patch with the changes I made in response to your
requests. I'll post the complete updated patch momentarily.
diff --git a/gcc/common.opt b/gcc/common.opt
index 55d9cdd714ff..7e024fdab124 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2957,9 +2957,12 @@ Common Driver R
Here's the updated version of the LVU patch, integrating changes
requested or proposed by yourself and by Jakub.
for include/ChangeLog
* dwarf2.def (DW_AT_GNU_locviews): New.
* dwarf2.h (enum dwarf_location_list_entry_type): Add
DW_LLE_GNU_view_pair.
(DW_LLE_view
On Jan 25, 2018, Alexandre Oliva wrote:
> On Jan 24, 2018, Jakub Jelinek wrote:
>> On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote:
>>> +DW_LLE_GNU_view_pair = 0x09,
>>> +#define DW_LLE_view_pair DW_LLE_GNU_view_pair
>> This looks wrong. The proposal has not been accepted y
94 matches
Mail list logo
