On Tue, 20 Mar 2018, Rainer Orth wrote:
> Hi Tom,
>
> > On 03/19/2018 10:11 AM, Richard Biener wrote:
> >> On Fri, 16 Mar 2018, Tom de Vries wrote:
> >>
> >>> On 03/16/2018 12:55 PM, Richard Biener wrote:
> On Fri, 16 Mar 2018, Tom de Vries wrote:
>
> > On 02/27/2018 01:42 PM, Richa
On Tue, 20 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> Boolean !x is often expanded as ^ 1, but store merging it actually merges
> as ^ 255 (for 8-bit bool), which is incorrect.
>
> The following patch fixes it to do that ^ 1 instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux and c
On Tue, 20 Mar 2018, David Malcolm wrote:
> On Wed, 2018-03-21 at 00:39 +0100, Rainer Orth wrote:
> > Hi Malcolm,
> >
> > > > I've now tested the patch (together with the one from PR
> > > > jit/84288
> > > > for
> > > > several remaining issues). I've needed another snippet for
> > > > Solaris/
This patch fixes incorrect results for HOST_WIDE_INT positions
at opposite extremes when used with HOST_WIDE_INT sizes. It also
fixes UB when comparing such positions with unsigned HOST_WIDE_INT
sizes (although the results in that case were wrapv-correct).
Tested on aarch64-linux-gnu and x86_64-l
After the sorry we'd skip storing the argument, but that just creates an
inconsistency later when we try to deallocate the arguments. This used to
"work" because pending_stack_adjust and stack_pointer_delta were int rather
than HWI, so 1<<33 got truncated to 0.
It's not easy to back out at this p
Since the kind of the hidden character length variable is not part of
the character variable definition, we must ensure that character
lengths are always of the same kind in interfaces, regardless of how
they were declared in the source. This patch ensures this when calling
a procedure.
Regtested
On Tue, Mar 20, 2018 at 05:00:34PM -0400, Jason Merrill wrote:
> On Mon, Mar 19, 2018 at 3:50 PM, Jakub Jelinek wrote:
> > +int a(__attribute__((b((int)__builtin_inf() * 1ULL / auto;
>
> This seems like another situation like 84610 and 84642 that Alex sent
> a patch for, of 'auto' in an attri
Plus a wording change for the sake of consistency. OK to commit?
--
Eric BotcazouIndex: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.47
diff -u -r1.47 changes.html
--- ht
On 20 March 2018 at 11:58, Sudakshina Das wrote:
> Hi
>
> On 20/03/18 10:03, Richard Earnshaw (lists) wrote:
>>
>> On 14/03/18 10:11, Sudakshina Das wrote:
>>>
>>> Hi
>>>
>>> This patch fixes PR82989 so that we avoid NEON instructions when
>>> -mneon-for-64bits is not enabled. This is more of a sh
> So it failed before Toms original patch. Please add sparc-solaris
> to the list of XFAILed targets.
SPARC/Linux is affected too so sparc*-*-* instead.
--
Eric Botcazou
Hello!
Attached patch adds -test.timeout argument to runtime gotools test.
Without this argument, default 4 minute timeout instead of
$(GOTOOLS_TEST_TIMEOUT) is used which is way to short for slow
machines.
Patch was tested on alphaev68-linux-gnu.
Uros.
diff --git a/gotools/Makefile.am b/gotools
On 20 March 2018 at 18:11, Kyrill Tkachov wrote:
> Hi all,
>
> This PR shows that we get the load/store_lanes logic wrong for arm
> big-endian.
> It is tricky to get right. Aarch64 does it by adding the appropriate
> lane-swapping
> operations during expansion.
>
> I'd like to do the same on arm
On 21/03/18 09:07, Christophe Lyon wrote:
On 20 March 2018 at 18:11, Kyrill Tkachov wrote:
Hi all,
This PR shows that we get the load/store_lanes logic wrong for arm
big-endian.
It is tricky to get right. Aarch64 does it by adding the appropriate
lane-swapping
operations during expansion.
I
On Tue, Mar 20, 2018 at 7:15 PM, Bin.Cheng wrote:
> On Tue, Mar 20, 2018 at 5:56 PM, Richard Biener
> wrote:
>> On March 20, 2018 6:11:53 PM GMT+01:00, "Bin.Cheng"
>> wrote:
>>>On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez
>>>wrote:
Hi Richard.
As discussed in the PR, the prob
On Tue, Mar 20, 2018 at 7:18 PM, Bin Cheng wrote:
> Hi,
> As noted in PR84969, fuse_memset_builtins breaks dependence between different
> memsets.
> Specifically, it reorders different builtin memset partitions though it
> doesn't merge
> them in the end. This simple patch fixes this wrong code
Hi,
as I told Marek in the audit trail, I'm working on a more complete patch
consistently changing maybe_deduce_size_from_array_init for various
error recovery issues (see the trail of c++/84632 too), but since this
specific regression ultimately started with a previous change of mine
and it'
On Tue, Mar 20, 2018 at 10:44 PM, Richard Sandiford
wrote:
> Jeff Law writes:
>> On 03/20/2018 01:36 PM, Martin Liška wrote:
>>> Hi.
>>>
>>> This is a work-around to not iterate all members of array that can be huge.
>>> As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want
>>>
On 03/21/2018 10:36 AM, Richard Biener wrote:
On Tue, Mar 20, 2018 at 10:44 PM, Richard Sandiford
wrote:
Jeff Law writes:
On 03/20/2018 01:36 PM, Martin Liška wrote:
Hi.
This is a work-around to not iterate all members of array that can be huge.
As MPX will be removed in GCC 9.x, I hope it'
On Tue, Mar 20, 2018 at 11:10 PM, Jim Wilson wrote:
> This fixes a wrong-code issue on RISC-V, but in theory could be a problem for
> any SHIFT_COUNT_TRUNCATED target.
>
> The testcase computes 46 or 47 (0x2e or 0x2f), then ANDs the value with 0xf,
> and then SHIFTs the value. On a SHIFT_COUNT_TR
On Wed, Mar 21, 2018 at 9:31 AM, Richard Sandiford
wrote:
> This patch fixes incorrect results for HOST_WIDE_INT positions
> at opposite extremes when used with HOST_WIDE_INT sizes. It also
> fixes UB when comparing such positions with unsigned HOST_WIDE_INT
> sizes (although the results in that
On Wed, Mar 21, 2018 at 9:33 AM, Richard Sandiford
wrote:
> After the sorry we'd skip storing the argument, but that just creates an
> inconsistency later when we try to deallocate the arguments. This used to
> "work" because pending_stack_adjust and stack_pointer_delta were int rather
> than HWI
On Wed, Mar 21, 2018 at 09:20:40AM +0100, Richard Biener wrote:
> > + tree lhs = gimple_assign_lhs (info->stmt);
> > + if (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE && info->bitsize > 1)
>
> So I'm slightly uncomfortable with keying this just on BOOLEAN_TYPE.
> Do you think anything woul
On Wed, 21 Mar 2018, Jakub Jelinek wrote:
> On Wed, Mar 21, 2018 at 09:20:40AM +0100, Richard Biener wrote:
> > > + tree lhs = gimple_assign_lhs (info->stmt);
> > > + if (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE && info->bitsize > 1)
> >
> > So I'm slightly uncomfortable with keying this j
On Tue, Mar 20, 2018 at 05:58:43PM -0400, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 5:04 PM, Jakub Jelinek wrote:
> > --- gcc/cp/semantics.c.jj 2018-03-20 11:58:17.069356145 +0100
> > +++ gcc/cp/semantics.c 2018-03-20 21:56:43.745292245 +0100
> > @@ -1512,6 +1512,26 @@ finish_asm_stmt
On Wed, Mar 14, 2018 at 02:54:00PM +0100, Martin Liška wrote:
> > The variable is not named very well, shouldn't it be avoid_libcall or
> > something similar? Perhaps the variable should have a comment describing
> > what it is. Do you need separate argument for that bool and
> > is_move_done, ra
On 03/12/2018 01:14 PM, Richard Biener wrote:
On Thu, 22 Feb 2018, Tom de Vries wrote:
I can
rework the bit of the patch that adds an assert after canonicalize_loop_ivs
into a patch that aborts the optimization instead of ICE-ing.
I think that's something reasonable anyway.
Patch attached b
On Tue, Mar 20, 2018 at 4:26 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, Mar 19, 2018 at 10:27 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford
wrote:
> Index: gcc/tree-data-ref.c
> ===
On Wed, 21 Mar 2018, Tom de Vries wrote:
> On 03/12/2018 01:14 PM, Richard Biener wrote:
> > On Thu, 22 Feb 2018, Tom de Vries wrote:
> > > I can
> > > rework the bit of the patch that adds an assert after
> > > canonicalize_loop_ivs
> > > into a patch that aborts the optimization instead of ICE-i
Richard Biener writes:
> On Wed, Mar 21, 2018 at 9:33 AM, Richard Sandiford
> wrote:
>> Index: gcc/diagnostic.c
>> ===
>> --- gcc/diagnostic.c2018-03-01 08:20:43.589534337 +
>> +++ gcc/diagnostic.c2018-03-21 08:31:34.6356
On Wed, Mar 21, 2018 at 11:48 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Mar 21, 2018 at 9:33 AM, Richard Sandiford
>> wrote:
>>> Index: gcc/diagnostic.c
>>> ===
>>> --- gcc/diagnostic.c2018-03-01 08:20:43.
I'd flubbed the condition on when a local binding was updated, leading
to an ICE when popping them. For a local overload set we need to look
in the binding list and find the one to update. We didn't do that when
we'd already hidden a TYPE_DECL of the same name.
Fixed thusly.
nathan
--
Natha
Sandra,
this removes the now-deleted deprecated features. AFAICT these have been
gone for a long time -- 2008 is the most recent changelog entry -- so no
need to put it in any release notes.
ok?
nathan
--
Nathan Sidwell
2018-03-21 Nathan Sidwell
* doc/extend.texi (Deprecated Features): R
Richard Biener writes:
> On Wed, Mar 21, 2018 at 11:48 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, Mar 21, 2018 at 9:33 AM, Richard Sandiford
>>> wrote:
Index: gcc/diagnostic.c
===
--- gcc/di
I just had reason to look at the target maintainer list. There seems to
be a couple of CPU ports listed in MAINTAINERS that do not exist in the
config directory.
Ok to remove? (Jeff you're the lucky, 'who do I ask' recipient)
nathan
--
Nathan Sidwell
2018-03-21 Nathan Sidwell
* MAINTAIN
Hi
On 21/03/18 08:51, Christophe Lyon wrote:
On 20 March 2018 at 11:58, Sudakshina Das wrote:
Hi
On 20/03/18 10:03, Richard Earnshaw (lists) wrote:
On 14/03/18 10:11, Sudakshina Das wrote:
Hi
This patch fixes PR82989 so that we avoid NEON instructions when
-mneon-for-64bits is not enable
On Wed, Mar 21, 2018 at 12:16 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Mar 21, 2018 at 11:48 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, Mar 21, 2018 at 9:33 AM, Richard Sandiford
wrote:
> Index: gcc/diagnostic.c
> ==
On Wed, Mar 21, 2018 at 12:38 PM, Nathan Sidwell wrote:
> I just had reason to look at the target maintainer list. There seems to be
> a couple of CPU ports listed in MAINTAINERS that do not exist in the config
> directory.
>
> Ok to remove? (Jeff you're the lucky, 'who do I ask' recipient)
Ple
Hi
The test pr82989.c which was added in one of previous commits is failing
for mthumb and big-endian configurations. The aim of this test was to
check that NEON instructions are not being used for simple shift
operations. The scanning of lsl and lsr instructions and checking its
counts were just
Port maintainers CC'd, apologies if I've missed you.
NO_IMPLICIT_EXTERN_C is a target machine define that turns off wrapping
system header files in 'extern "C" { ... }'. It is the remaining
non-deprecated ARM-era compatibility behaviour. Can we deprecated it?
Unfortunately it's a negative-s
On 20 March 2018 at 21:06, Jonathan Wakely wrote:
> On 20 March 2018 at 21:02, François Dumont wrote:
>> On 20/03/2018 19:20, Jonathan Wakely wrote:
>>>
>>> On 17 March 2018 at 09:01, Jonathan Wakely wrote:
Native configuration is x86_64-pc-linux-gnu
=== libstdc
I got a bounce from:
lm32 port Sebastien Bourdeauducq
2011 seems the most recent period of activity (not counting mechanical
interface changes).
2011-11-04 Ralf Corsépius
* config/lm32/t-rtems: New.
* config.gcc (lm32-*-rtems*): Add t-rtems.
is it dead?
nat
On 03/21/2018 08:02 AM, Richard Biener wrote:
On Wed, Mar 21, 2018 at 12:38 PM, Nathan Sidwell wrote:
I just had reason to look at the target maintainer list. There seems to be
a couple of CPU ports listed in MAINTAINERS that do not exist in the config
directory.
Ok to remove? (Jeff you're t
On 03/21/2018 10:39 AM, Martin Liška wrote:
On 03/21/2018 10:36 AM, Richard Biener wrote:
On Tue, Mar 20, 2018 at 10:44 PM, Richard Sandiford
wrote:
Jeff Law writes:
On 03/20/2018 01:36 PM, Martin Liška wrote:
Hi.
This is a work-around to not iterate all members of array that can be huge.
On Wed, Mar 21, 2018 at 01:40:08PM +0100, Martin Liška wrote:
> 2018-03-21 Martin Liska
>
> PR target/84988
> * config/i386/i386.c (ix86_function_arg_advance): Do not call
> chkp_type_bounds_count if MPX is not enabled.
> ---
> gcc/config/i386/i386.c | 3 ++-
> 1 file changed
On Wed, Mar 21, 2018 at 2:07 AM, Uros Bizjak wrote:
>
> Attached patch adds -test.timeout argument to runtime gotools test.
> Without this argument, default 4 minute timeout instead of
> $(GOTOOLS_TEST_TIMEOUT) is used which is way to short for slow
> machines.
>
> Patch was tested on alphaev68-li
The lm32 architecture is still included in the standard RTEMS tool set.
However, I noticed that lm32-specific GCC bugs get not fixed. I was
about to suggest to deprecated this architecture for RTEMS.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Ph
Isn't this an OS issue rather than a general port issue. Seems to me it
will depend on the system header files. With a few notable exceptions
I'm not sure the port maintainers can answer this for all their target OSs.
R.
On 21/03/18 12:15, Nathan Sidwell wrote:
> Port maintainers CC'd, apologie
AIX still requires implicit extern C.
I previously have tried to disable the feature on AIX and it failed miserably.
Thanks, David
On Wed, Mar 21, 2018 at 8:15 AM, Nathan Sidwell wrote:
> Port maintainers CC'd, apologies if I've missed you.
>
> NO_IMPLICIT_EXTERN_C is a target machine define t
On 3/14/18 4:27 PM, Kelvin Nilsen wrote:
> 2018-03-14 Kelvin Nilsen
>
> * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
> entries for V1TI variants of __builtin_altivec_ld builtin.
> * config/rs6000/rs6000.c (altivec_expand_lv_builtin): Add test and
> handli
On 03/12/2018 01:14 PM, Richard Biener wrote:
On Thu, 22 Feb 2018, Tom de Vries wrote:
Hi,
this patch fixes an ICE in the parloops pass.
The ICE (when compiling the test-case in attached patch) follows from the fact
that here in gen_parallel_loop the call to canonicalize_loop_ivs fails to
"ba
On Wed, Mar 21, 2018 at 3:06 PM, Tom de Vries wrote:
> On 03/12/2018 01:14 PM, Richard Biener wrote:
>>
>> On Thu, 22 Feb 2018, Tom de Vries wrote:
>>
>>> Hi,
>>>
>>> this patch fixes an ICE in the parloops pass.
>>>
>>> The ICE (when compiling the test-case in attached patch) follows from the
>>>
On 03/21/2018 10:18 AM, David Edelsohn wrote:
AIX still requires implicit extern C.
I previously have tried to disable the feature on AIX and it failed miserably.
That's unfortunate :(
nathan
--
Nathan Sidwell
Joseph Myers pointed out that we call the wrong function for complex long
double multiply and divide. This patch changes the functions called from
__multc3/__divtc3 to __mulkc3/__divkc3.
I have built this on power8 systems, both a little endian system, and a big
endian system using --with-cpu=pow
On Wed, 21 Mar 2018, Tom de Vries wrote:
> On 03/12/2018 01:14 PM, Richard Biener wrote:
> > On Thu, 22 Feb 2018, Tom de Vries wrote:
> >
> > > Hi,
> > >
> > > this patch fixes an ICE in the parloops pass.
> > >
> > > The ICE (when compiling the test-case in attached patch) follows from the
> >
On Tue, Mar 20, 2018 at 11:27 PM, Alexandre Oliva wrote:
> On Mar 20, 2018, Jason Merrill wrote:
>
>> On Tue, Mar 20, 2018 at 6:07 PM, Alexandre Oliva wrote:
>>> On Mar 20, 2018, Jason Merrill wrote:
that doesn't mean it's wrong to peek.
>
>>> Huh? We're referencing members of an unrelate
On 03/02/2018 08:18 PM, Cesar Philippidis wrote:
og7-vl-part4-hooks.diff
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 5642941c6a3..507c8671704 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -5205,14 +5205,36 @@ nvptx_simt_vf ()
return PTX
When instantiating a template we end up with a rather strange binding
hierarchy -- the innermost binding is the template and the next one is
the instantiation. Anyway, the upshot is we end up trying to push a
tsubst'd lambda into the template itself and die because that's marked
as a complete
On Wed, Mar 21, 2018 at 4:42 AM, Jakub Jelinek wrote:
> On Tue, Mar 20, 2018 at 05:00:34PM -0400, Jason Merrill wrote:
>> On Mon, Mar 19, 2018 at 3:50 PM, Jakub Jelinek wrote:
>> > +int a(__attribute__((b((int)__builtin_inf() * 1ULL / auto;
>>
>> This seems like another situation like 84610 a
On 21 March 2018 at 13:11, Sudakshina Das wrote:
> Hi
>
> The test pr82989.c which was added in one of previous commits is failing
> for mthumb and big-endian configurations. The aim of this test was to
> check that NEON instructions are not being used for simple shift
> operations. The scanning o
On Tue, 2018-03-20 at 21:51 -0400, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 7:37 PM, David Malcolm
> wrote:
> > PR c++/84894 reports that the fix-it hints suggesting accessor
> > calls for
> > private fields doesn't work with -g for -O1 and above.
> >
> > The issue is that field_accessor_p
On Wed, Mar 21, 2018 at 6:26 AM, Jakub Jelinek wrote:
> On Tue, Mar 20, 2018 at 05:58:43PM -0400, Jason Merrill wrote:
>> On Tue, Mar 20, 2018 at 5:04 PM, Jakub Jelinek wrote:
>> > --- gcc/cp/semantics.c.jj 2018-03-20 11:58:17.069356145 +0100
>> > +++ gcc/cp/semantics.c 2018-03-20 21:56:43
On 21/03/18 16:33, Christophe Lyon wrote:
On 21 March 2018 at 13:11, Sudakshina Das wrote:
Hi
The test pr82989.c which was added in one of previous commits is failing
for mthumb and big-endian configurations. The aim of this test was to
check that NEON instructions are not being used for simp
OK.
On Wed, Mar 21, 2018 at 12:52 PM, David Malcolm wrote:
> On Tue, 2018-03-20 at 21:51 -0400, Jason Merrill wrote:
>> On Tue, Mar 20, 2018 at 7:37 PM, David Malcolm
>> wrote:
>> > PR c++/84894 reports that the fix-it hints suggesting accessor
>> > calls for
>> > private fields doesn't work wit
On 03/21/2018 05:11 AM, Nathan Sidwell wrote:
Sandra,
this removes the now-deleted deprecated features. AFAICT these have been
gone for a long time -- 2008 is the most recent changelog entry -- so no
need to put it in any release notes.
ok?
Yes, this is fine. At some point we might want to
On 03/02/2018 05:55 PM, Cesar Philippidis wrote:
In addition, nvptx_cta_sync and the corresponding nvptx_barsync insn,
have been extended to take a barrier ID and a thread count. The idea
here is to assign one barrier for each logical vector. Worker-single
synchronization is controlled by barrier
Hi
On 21/03/18 17:03, Kyrill Tkachov wrote:
On 21/03/18 16:33, Christophe Lyon wrote:
On 21 March 2018 at 13:11, Sudakshina Das wrote:
Hi
The test pr82989.c which was added in one of previous commits is failing
for mthumb and big-endian configurations. The aim of this test was to
check that
On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
> This is documented in the old manuals from DEC and I've found
> essentially the same documentation in Oracle/Sun's current documentation
> as well as old MIPS documentation. I have a high degree of confidence
> it exists in IBM's Fortran
On 03/21/2018 11:25 AM, Jakub Jelinek wrote:
> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
>> This is documented in the old manuals from DEC and I've found
>> essentially the same documentation in Oracle/Sun's current documentation
>> as well as old MIPS documentation. I have a high
Hi
The ICE in the bug report was happening because the macro
USE_RETURN_INSN (FALSE) was returning different values at different
points in the compilation. This was internally occurring because the
function arm_compute_static_chain_stack_bytes () which was dependent on
arm_r3_live_at_start_p () w
On Wed, Mar 21, 2018 at 10:39:06AM +0200, Janne Blomqvist wrote:
> Since the kind of the hidden character length variable is not part of
> the character variable definition, we must ensure that character
> lengths are always of the same kind in interfaces, regardless of how
> they were declared in
On 3/20/18 12:27 PM, Peter Bergner wrote:
> On 3/20/18 11:42 AM, Segher Boessenkool wrote:
>> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
>>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being
>>> defined on either my LE or BE builds. What am I missing?
>>
>>
OK.
On Wed, Mar 21, 2018 at 5:28 AM, Paolo Carlini wrote:
> Hi,
>
> as I told Marek in the audit trail, I'm working on a more complete patch
> consistently changing maybe_deduce_size_from_array_init for various error
> recovery issues (see the trail of c++/84632 too), but since this specific
> re
OK.
On Wed, Mar 21, 2018 at 1:47 PM, Jakub Jelinek wrote:
> On Wed, Mar 21, 2018 at 01:01:38PM -0400, Jason Merrill wrote:
>> >> Hmm, it would be nice to share this with the similar patterns in
>> >> unary_complex_lvalue and cp_build_modify_expr.
>>
>> > You mean just outline the
>> > if (T
Hi Eric,
>> So it failed before Toms original patch. Please add sparc-solaris
>> to the list of XFAILed targets.
>
> SPARC/Linux is affected too so sparc*-*-* instead.
actually, it's sparc*-*-* && lp64 only. Done like this after testing on
sparc-sun-solaris2.11 and i386-pc-solaris2.11.
On Thu, Mar 15, 2018 at 08:55:59AM -0400, Jason Merrill wrote:
> On Thu, Mar 15, 2018 at 7:49 AM, Marek Polacek wrote:
> > On Wed, Mar 14, 2018 at 02:06:36PM -0400, Jason Merrill wrote:
> >> On Wed, Mar 14, 2018 at 11:59 AM, Marek Polacek wrote:
> >> > cxx_constant_value doesn't understand templa
On Wed, Mar 21, 2018 at 7:29 PM, Jeff Law wrote:
> On 03/21/2018 11:25 AM, Jakub Jelinek wrote:
>> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
>>> This is documented in the old manuals from DEC and I've found
>>> essentially the same documentation in Oracle/Sun's current documentatio
On Wed, Mar 21, 2018 at 2:37 PM, Marek Polacek wrote:
> On Thu, Mar 15, 2018 at 08:55:59AM -0400, Jason Merrill wrote:
>> On Thu, Mar 15, 2018 at 7:49 AM, Marek Polacek wrote:
>> > On Wed, Mar 14, 2018 at 02:06:36PM -0400, Jason Merrill wrote:
>> >> On Wed, Mar 14, 2018 at 11:59 AM, Marek Polacek
This ICE turned out to be a latent bug exposed by moving the member fns
onto the FIELDS list.
We should be using DECL_CLONED_FUNCTION_P not DECL_CLONED_FUNCTION.
Grepping showed another place (doing a similar linkage check) affected too.
nathan
--
Nathan Sidwell
2018-03-21 Nathan Sidwell
On 03/21/2018 12:38 PM, Janne Blomqvist wrote:
> On Wed, Mar 21, 2018 at 7:29 PM, Jeff Law wrote:
>> On 03/21/2018 11:25 AM, Jakub Jelinek wrote:
>>> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
This is documented in the old manuals from DEC and I've found
essentially the sa
On Wed, Mar 21, 2018 at 02:55:36PM -0400, Jason Merrill wrote:
> On Wed, Mar 21, 2018 at 2:37 PM, Marek Polacek wrote:
> > On Thu, Mar 15, 2018 at 08:55:59AM -0400, Jason Merrill wrote:
> >> On Thu, Mar 15, 2018 at 7:49 AM, Marek Polacek wrote:
> >> > On Wed, Mar 14, 2018 at 02:06:36PM -0400, Jas
On 03/21/2018 08:49 AM, Tom de Vries wrote:
> On 03/02/2018 08:18 PM, Cesar Philippidis wrote:
>
>> og7-vl-part4-hooks.diff
>
>> diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
>> index 5642941c6a3..507c8671704 100644
>> --- a/gcc/config/nvptx/nvptx.c
>> +++ b/gcc/config/nvptx/nv
Hi!
On ia32, we don't support __int128, nor mode (TI) integers, but we do
support 128-bit __float128 and (generic) vectors containing it. The result
of a comparison of such vectors is supposed to be integral vector with the
same element size, but we really don't want to allow one in this case,
it
On Wed, Mar 21, 2018 at 01:01:38PM -0400, Jason Merrill wrote:
> >> Hmm, it would be nice to share this with the similar patterns in
> >> unary_complex_lvalue and cp_build_modify_expr.
>
> > You mean just outline the
> > if (TREE_SIDE_EFFECTS (TREE_OPERAND (lhs, 0)))
> > lhs = build2
The attached obvious patch fixes a NULL pointer dereference.
Testcase derived from report. Changelogs below.
Regtested on i686-pc-linux-gnu.
Whoever reviews this, please feel free to commit.
Thanks,
Harald
2018-03-21 Harald Anlauf
PR fortran/84957
* trans-types.c (gfc_sym_
On March 21, 2018 9:24:06 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>On the following testcase, path isolation decides to duplicate a bb and
>redirect edge from ENTRY bb to its successor to this duplicate bb and
>tree cleanup then removes all other basic blocks as unreachable.
>
>When blocks are r
Hi Harald,
The attached obvious patch fixes a NULL pointer dereference.
Testcase derived from report. Changelogs below.
Regtested on i686-pc-linux-gnu.
Whoever reviews this, please feel free to commit.
Reviewed and committed as r258745.
Thanks for the patch!
Regards
Thomas
On Wed, 21 Mar 2018, Nathan Sidwell wrote:
> Unfortunately it's a negative-sense define, that now at least most ports
> define. Do all ports define it? It's hard to determine that, because many
> ports get it set via config/gnu-user.h or similar common file.
Bare-metal ports often fail to defin
On Wed, 21 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> On ia32, we don't support __int128, nor mode (TI) integers, but we do
> support 128-bit __float128 and (generic) vectors containing it. The result
> of a comparison of such vectors is supposed to be integral vector with the
> same element size,
Hi!
On the following testcase, path isolation decides to duplicate a bb and
redirect edge from ENTRY bb to its successor to this duplicate bb and
tree cleanup then removes all other basic blocks as unreachable.
When blocks are removed, forced labels are moved to their bb->prev_bb block,
but inser
On Mar 20, 2018, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 5:57 PM, Alexandre Oliva wrote:
>> On Mar 20, 2018, Jason Merrill wrote:
> Let's put this in cp-tree.h, with warning_sentinel.
>> + (void)cleanup;
> There are lots of RAII variables without this explicit cast to void,
> and they
On Mar 20, 2018, Jason Merrill wrote:
>> -permerror (input_location,
>> - "parenthesized initializer in array new");
>> +error_at (input_location,
>> + "parenthesized initializer in array new");
> I suspect you'll n
On Mar 20, 2018, Jason Merrill wrote:
>> + if ((complain & tf_error))
>> + error ("cannot initialize multi-dimensional"
>> + " array with initializer");
> Let's also use the other diagnostic message: "array must be
> initialized with a brace-enclose
GCC Maintainers:
The following patch is a back port from mainlin of a fix for
define_insn crypto_vpermxor_ in gcc/config/rs6000/crypto.md. The
issue is the vpermxor instruction does not work correctly when the swap
optimization is applied.
The issue was found as part of commit 258530 to mainli
If an interface body includes a MODULE prefix on a subroutine
or function, then the prefix must appear on the contained
subprogram. This patch does that check, and issues an error
message.
2018-03-21 Steven G. Kargl
PR fortran/84922
* decl.c (get_proc_name): If the MODULE pref
When adding __builtin_tgmath to support a better tgmath.h
implementation, I noted that further changes might be needed regarding
the TS 18661 functions that round their results to a narrower type,
because of unresolved issues with how the corresponding type-generic
macros are defined in TS 18661.
On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote:
> On 3/20/18 12:27 PM, Peter Bergner wrote:
> > On 3/20/18 11:42 AM, Segher Boessenkool wrote:
> >> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
> >>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode be
Tested on Linux-PPC64.
2018-03-22 Ville Voutilainen
gcc/cp/
Implement P0962
* parser.c (cp_parser_perform_range_for_lookup): Change
the condition for deciding whether to use members.
testsuite/
Implement P0962
* g++.dg/cpp0x/range-for13.C: Adjust.
diff --git a/gcc
On Mar 21, 2018, Jason Merrill wrote:
> On Tue, Mar 20, 2018 at 11:27 PM, Alexandre Oliva wrote:
>> I understood you were saying it was ok to peek in this case. Would you
>> please state, for clarity, what your stance is on peeking in this case,
>> specifically, in the B::A::I::I within the de
Hi Sudakshina,
As per the ARMv8 ARM, for the offset range (-1048576 ,1048572), the
far branch instruction offset is inclusive of both the offsets. Hence,
I am using <=||=> and not <||>= as it was in previous implementation.
On 16 March 2018 at 00:51, Sudakshina Das wrote:
> On 15/03/18 15:27, Sa
On 3/21/18 7:37 PM, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote:
>> I'll note that GCC 7 does not need any of the changes to rs6000-p8swap.c,
>> since that file doesn't exist and doesn't need to exist in GCC 7, so I've
>> left those changes out.
>
> Di
1 - 100 of 104 matches
Mail list logo
