On 9/9/18 3:57 AM, Bernd Edlinger wrote:
> On 09/09/18 01:47, Jeff Law wrote:
>> On 9/8/18 3:47 PM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>>
-fold_builtin_strlen (location_t loc, tree type, tree arg)
+fold_builtin_strlen (location_t loc, tree fndecl, tree type, tree arg)
{
if
On 9/13/18 7:30 AM, Bernd Edlinger wrote:
> On 08/31/18 19:45, Bernd Edlinger wrote:
>> On 08/31/18 16:42, Jeff Law wrote:
>>> On 08/31/2018 01:08 AM, Bernd Edlinger wrote:
Hi,
when re-testing the new STRING_CST semantic patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-0
On 8/24/18 3:24 PM, Bernd Edlinger wrote:
> Hi,
>
> I noticed that the latest patches to make STRING_CST
> semantics for literals and for initializers consistent
> also fixes PR 86711 and PR 86714 (but not PR 87053).
>
> The code change in the string_constant does not change
> any test case, the
Hi Carl,
On Thu, Sep 13, 2018 at 12:08:01PM -0700, Carl Love wrote:
> The _MM_SHUFFLE and _MM_SHUFFLE2 macros are currently defined in the
> i386 branch. This patch adds the two macro definitions to the rs6000
> config directory as requested.
> @@ -1163,8 +1166,8 @@ _mm_cvtss_sd (__m128d __A,
In the Go 1.11 release writebarrierptr is going away, so change the Go
frontend to call gcWriteBarrier instead. We weren't using
gcWriteBarrier before; adjust the implementation to use the putFast
method.
This revealed a problem in the kickoff function. When using cgo,
kickoff can be called on t
Since the gofrontend uses conservative garbage collection on the
stack, pointers that appeared dead can be revived while scanning the
stack. This can cause the allocation counts seen when sweeping a span
to increase. We already accept that. This patch changes the code to
update the counters when
On 9/13/18 7:30 AM, Bernd Edlinger wrote:
> On 08/31/18 19:45, Bernd Edlinger wrote:
>> On 08/31/18 16:42, Jeff Law wrote:
>>> On 08/31/2018 01:08 AM, Bernd Edlinger wrote:
Hi,
when re-testing the new STRING_CST semantic patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-0
On 8/24/18 2:18 PM, Bernd Edlinger wrote:
> Hi!
>
>
> This is an alternative approach in making STRING_CST semantics
> consistent.
>
> This means it makes STRING_CST used for literals and for initializers
> use exactly the same semantics.
>
> It makes sure that all STRING_CST have a TYPE_SIZE_U
On 8/24/18 1:59 PM, Bernd Edlinger wrote:
> Hi!
>
>
> This is an alternative approach handle overlength strings in the C FE.
>
> The difference to the previous version is that overlength
> STRING_CST never have a longer TREE_STRING_LENGTH than the TYPE_DOMAIN.
> And those STRING_CSTs are thus no
This patch to the Go frontend and libgo changes the compiler to open
code the select statement setup, rather than calling a runtime
function for each case. This is a version of a change done in the gc
runtime. I'm bringing it in now to simplify upgrading libgo to the
1.11 release. Bootstrapped a
On 9/13/18 1:41 PM, Bernd Edlinger wrote:
> On 09/13/18 20:44, Jeff Law wrote:
>> On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>>> Hi!
>>>
>>>
>>> This is an alternative approach in making STRING_CST semantics
>>> consistent.
>>>
>>> This means it makes STRING_CST used for literals and for initializer
The above has been fixed as 'obvious' on all three branches. Revisions
264249, 264251 and 264288.
Cheers
Paul
2018-09-13 Paul Thomas
PR fortran/87284
* trans-expr.c (gfc_trans_class_init_assign): Access to
to array elements of the dynamic type requires that the array
referenc
On 09/13/18 20:44, Jeff Law wrote:
> On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> This is an alternative approach in making STRING_CST semantics
>> consistent.
>>
>> This means it makes STRING_CST used for literals and for initializers
>> use exactly the same semantics.
>>
>> It makes
Bill:
Ah, I read your note as Power 8, Power 7 and the IBM AT 11. Thanks for
the clarification.
Carl Love
On Thu, 2018-09-13 at 14:11 -0500, Bill Schmidt wrote:
> On 9/13/18 2:08 PM, Carl Love wrote:
> > GCC maintainers:
> >
> > The _MM_SHUFFLE and _MM_SHUFFLE2 macros are curre
On 9/13/18 2:08 PM, Carl Love wrote:
> GCC maintainers:
>
> The _MM_SHUFFLE and _MM_SHUFFLE2 macros are currently defined in the
> i386 branch. This patch adds the two macro definitions to the rs6000
> config directory as requested.
>
> The patch has been tested on
>
> powerpc64le-unknown-l
GCC maintainers:
The _MM_SHUFFLE and _MM_SHUFFLE2 macros are currently defined in the
i386 branch. This patch adds the two macro definitions to the rs6000
config directory as requested.
The patch has been tested on
powerpc64le-unknown-linux-gnu (Power 8 LE)
With no regressions.
The req
On 09/13/18 20:42, Jeff Law wrote:
> On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>>
>> [PATCHv2] Handle overlength string literals in the fortan FE
>> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01568.html
> I've committed this patch to the trunk.
>
Hi Jeff,
I fixed the ChangeLog entry,
and com
On 8/24/18 2:18 PM, Bernd Edlinger wrote:
> Hi!
>
>
> This is an alternative approach in making STRING_CST semantics
> consistent.
>
> This means it makes STRING_CST used for literals and for initializers
> use exactly the same semantics.
>
> It makes sure that all STRING_CST have a TYPE_SIZE_U
On 8/24/18 2:18 PM, Bernd Edlinger wrote:
>
> [PATCHv2] Handle overlength string literals in the fortan FE
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01568.html
I've committed this patch to the trunk.
jeff
On 13 September 2018 at 20:41, Jason Merrill wrote:
>> Okay. Do you think we should have an sfk_kind for non-canonical
>> copy/move operations? That would presumably make it a tad more
>> straightforward to go from
>> fndecl to whatever class bits, instead of what's currently there, where we
>>
The libgo runtime package uses special comments //go:nowritebarrier,
//go:nowritebarrierrec, and //go:yeswritebarrierrec to record whether
write barriers are permitted in a function or not. The Go frontend
already implements //go:nowritebarrier, but it has been treating
//go:nowritebarrierrec as e
On Thu, Sep 13, 2018 at 12:42 PM, Ville Voutilainen
wrote:
> On 13 September 2018 at 19:36, Jason Merrill wrote:
>> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
>> wrote:
>>> On 13 September 2018 at 13:41, Ville Voutilainen
>>> wrote:
> How does this work when:
> unsigned has_co
On Thu, Sep 13, 2018 at 1:35 AM, John Darrington
wrote:
> On Mon, Sep 10, 2018 at 04:40:58PM +0100, Jason Merrill wrote:
> On Mon, Sep 10, 2018 at 3:42 PM, John Darrington
> wrote:
> > On Mon, Sep 10, 2018 at 03:36:26PM +0100, Jason Merrill wrote:
> > On Mon, Aug 27, 2018
This patch to libgo's runtime package avoids write barriers with traceback info.
Unlike the gc runtime, libgo stores traceback information in location
structs, which contain strings. Therefore, copying location structs
around appears to require write barriers, although in fact write
barriers are
Tested on visium-elf, applied on the mainline.
2018-09-13 Eric Botcazou
PR target/86812
* config/visium/visium.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define.
--
Eric BotcazouIndex: config/visium/visium.c
===
--
As pointed out by Joseph. Applied on the mainline.
2018-09-13 Eric Botcazou
* Makefile.rtl (arm% linux-gnueabi%): Always set EH_MECHANISM to -arm.
--
Eric Botcazou
> On Sep 13, 2018, at 10:58 AM, Andrew Stubbs wrote:
>
> On 13/09/18 15:49, Paul Koning wrote:
>> It's ambiguous, because the last sentence of that paragraph says "addm3 is
>> used if addptrm3 is not defined."
>
> I didn't read that as ambiguous; I read it as addm3 is assumed to work fine
>
This removes the inclusion of the unused termio.h from terminals.c.
Tested on x86_64-suse-linux, applied on the mainline.
2018-09-13 Eric Botcazou
PR ada/81103
* terminals.c: Do not include termio.h.
--
Eric BotcazouIndex: terminals.c
===
> On Sep 13, 2018, at 2:06 AM, Richard Biener wrote:
>
> On Wed, 12 Sep 2018, Alexander Monakov wrote:
>
>> On Wed, 12 Sep 2018, Richard Biener wrote:
>>> With LTO "static" is too blurry - would -finline-only-hidden be OK
>>> with you?
>>
>> This doesn't sound right - in non-pic, everything i
This libgo patch by Than McIntosh build a GC roots index to speed up
write barrier processing in bulkBarrierPreWrite and elsewhere. The GC
roots index is basically a sorted list of all roots, so as to allow
more efficient lookups of gcdata structures for globals. The previous
implementation worke
On 13 September 2018 at 19:36, Jason Merrill wrote:
> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
> wrote:
>> On 13 September 2018 at 13:41, Ville Voutilainen
>> wrote:
How does this work when:
unsigned has_complex_copy_ctor : 1;
>>> It doesn't. I need more bits. Luckily, we h
On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
wrote:
> On 13 September 2018 at 13:41, Ville Voutilainen
> wrote:
>>> How does this work when:
>>> unsigned has_complex_copy_ctor : 1;
>> It doesn't. I need more bits. Luckily, we have some available.
>
> Here. I suppose this could theoretical
Richard, Jan, as early debug experts perhaps you can clue me in?
87295 is an ICE in lookup_external_ref, we strcmp a NULL
die->die_id.die_symbol.
The die is being cloned in clone_as_declaration during a
copy_ancestor_tree walk ultimately coming from
copy_decls_for_unworthy_types.
The inco
On 13/09/18 15:49, Paul Koning wrote:
It's ambiguous, because the last sentence of that paragraph says "addm3 is used if
addptrm3 is not defined."
I didn't read that as ambiguous; I read it as addm3 is assumed to work
fine when addptr is not defined.
I don't know of any change in this area
> On Sep 13, 2018, at 10:39 AM, Andrew Stubbs wrote:
>
> On 13/09/18 15:16, Paul Koning wrote:
>> If you don't have machine operations that add without messing with
>> condition codes, wouldn't it make sense to omit the definition of the
>> add-pointer patterns? GCC will build things out of n
On 13/09/18 15:16, Paul Koning wrote:
If you don't have machine operations that add without messing with
condition codes, wouldn't it make sense to omit the definition of the
add-pointer patterns? GCC will build things out of normal
(CC-clobbering) adds if there are no add-pointer operations, wh
> On Sep 13, 2018, at 10:08 AM, Andrew Stubbs wrote:
>
> On 13/09/18 11:01, Andrew Stubbs wrote:
>> The assert is caused because the def-use chains indicate that SCC conflicts
>> with itself. I suppose the question is why is it doing that, but it's
>> probably do do with that being a special
I'm using this PR as an excuse to put in the pending non-iteration
"iteration" rewrite. This ensures that we've at least visited one
predecessor of a block and re-instantiates only visiting reachable
blocks.
{O1,}-Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
It probably doesn'
On 13/09/18 11:01, Andrew Stubbs wrote:
The assert is caused because the def-use chains indicate that SCC
conflicts with itself. I suppose the question is why is it doing that,
but it's probably do do with that being a special register that gets
used in split2 (particularly by the addptrdi3 pat
A non-trivial amount of time is spent in ssa_conflicts_merge,
in particular the
/* Add a conflict between X and every one Y has. If the bitmap doesn't
exist, then it has already been coalesced, and we don't need to add a
conflict. */
EXECUTE_IF_SET_IN_BITMAP (by, 0, z, bi)
{
On 09/13/2018 03:33 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On 09/12/2018 12:57 PM, Richard Sandiford wrote:
Aldy Hernandez writes:
diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index 589fdea4df6..e9ee418e5b2 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-rang
The bug https://bugs.llvm.org/show_bug.cgi?id=33222 is now fixed on
Clang trunk, so the workaround won't be needed for Clang 8.0 and later.
* include/std/variant (variant) [__clang__]: Limit workaround to
Clang 7 and older.
Tested x86_64-linux, committed to trunk.
I hope somebod
Hi!
On Thu, Sep 13, 2018 at 04:41:25PM +0300, Ville Voutilainen wrote:
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -2046,7 +2046,7 @@ struct GTY(()) lang_type {
>unsigned lazy_copy_assign : 1;
>unsigned lazy_destructor : 1;
>unsigned has_const_copy_ctor : 1;
> - unsigned ha
On 13 September 2018 at 13:41, Ville Voutilainen
wrote:
>> How does this work when:
>> unsigned has_complex_copy_ctor : 1;
> It doesn't. I need more bits. Luckily, we have some available.
Here. I suppose this could theoretically be done in some later stage
of class completion,
but that would pr
On 08/31/18 19:45, Bernd Edlinger wrote:
> On 08/31/18 16:42, Jeff Law wrote:
>> On 08/31/2018 01:08 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>>
>>> when re-testing the new STRING_CST semantic patch here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01569.html
>>>
>>> I noticed that the (my) fix
2018-09-13 Ilya Leoshkevich
* MAINTAINERS: (write after approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c90437180d..f8838fa8e8c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -462,6 +462,7 @@ Georg-Johann Lay
Dimitar Dimitrov writes:
> +; Specialized IOR/AND patterns for matching setbit/clearbit instructions.
> +;
> +; TODO - allow clrbit and setbit to support (1 << REG) constructs
> +
> +(define_insn "clearbit__"
> + [(set (match_operand:EQD 0 "register_operand" "=r")
Nit: stray tab instead of
Hi all,
Ping? This new version changes both the middle-end and back-end part
so will need a review for both of those.
Best regards,
Thomas
On Wed, 29 Aug 2018 at 11:07, Thomas Preudhomme
wrote:
>
> Forgot another important change in ARM backend:
>
> The expander were causing one too many indire
On 8/17/18 6:29 AM, Omar Sandoval wrote:
> I don't have commit rights (first time contributor), so if this change is okay
> could it please be applied?
Hi,
thanks for the patch, I've committed the approved version.
[ In case you don't have one already ... ] if you want to continue
contributing,
On 13 September 2018 at 13:03, Jakub Jelinek wrote:
> On Thu, Sep 13, 2018 at 12:56:59PM +0300, Ville Voutilainen wrote:
>> + else if (!TYPE_HAS_CONST_COPY_CTOR (class_type))
>> + TYPE_HAS_COMPLEX_COPY_CTOR (class_type) += 2;
>> + }
>> + else if (ctor > 1 && TYP
On Thu, 13 Sep 2018, Tom de Vries wrote:
> On 9/4/18 5:59 PM, Tom de Vries wrote:
> > [ Adding Jason as addressee ]
> >
> > On 08/28/2018 08:20 PM, Omar Sandoval wrote:
> >> On Fri, Aug 17, 2018 at 12:16:07AM -0700, Omar Sandoval wrote:
> >>> On Thu, Aug 16, 2018 at 11:54:53PM -0700, Omar Sandova
On Thu, Sep 13, 2018 at 12:56:59PM +0300, Ville Voutilainen wrote:
> + else if (!TYPE_HAS_CONST_COPY_CTOR (class_type))
> + TYPE_HAS_COMPLEX_COPY_CTOR (class_type) += 2;
> + }
> + else if (ctor > 1 && TYPE_HAS_COMPLEX_COPY_CTOR (class_type) == 2)
> + TYPE
On 12/09/18 12:29, Andrew Stubbs wrote:
I'll report back when I've done more testing.
I reproduced the problem, in the latest sources, with the
SPECIAL_REGNO_P patch removed (and HARD_REGNO_RENAME_OK adjusted
accordingly).
Testcase: gcc.c-torture/compile/20020706-2.c -O3 -funroll-loops
du
On 9/4/18 5:59 PM, Tom de Vries wrote:
> [ Adding Jason as addressee ]
>
> On 08/28/2018 08:20 PM, Omar Sandoval wrote:
>> On Fri, Aug 17, 2018 at 12:16:07AM -0700, Omar Sandoval wrote:
>>> On Thu, Aug 16, 2018 at 11:54:53PM -0700, Omar Sandoval wrote:
On Thu, Aug 16, 2018 at 10:27:48PM -0700
On 13 September 2018 at 12:08, Ville Voutilainen
wrote:
> Curses.. the resetting is over-eager; we might have a non-trivial base
> or a member, and in those cases we shouldn't
> reset the triviality when we see a non-user-provided const copy. I
> think I'll hack around this with a non 0/1 value. :
On 13/09/18 10:25, Sam Tebbs wrote:
On 09/11/2018 04:20 PM, James Greenhalgh wrote:
> On Tue, Sep 04, 2018 at 10:13:43AM -0500, Sam Tebbs wrote:
>> Hi James,
>>
>> Thanks for the feedback. Here is an update with the changes you proposed
>> and an updated changelog.
>>
>> gcc/
>> 2018-09-04 Sa
On 09/11/2018 04:20 PM, James Greenhalgh wrote:
On Tue, Sep 04, 2018 at 10:13:43AM -0500, Sam Tebbs wrote:
Hi James,
Thanks for the feedback. Here is an update with the changes you proposed
and an updated changelog.
gcc/
2018-09-04 Sam Tebbs
PR target/85628
* config/aa
On Thu, 13 Sep 2018, Richard Biener wrote:
> On Thu, 13 Sep 2018, Richard Biener wrote:
>
> > On Thu, 13 Sep 2018, Gerald Pfeifer wrote:
> >
> > > On Mon, 10 Sep 2018, Martin Liška wrote:
> > > > Works for me! One needed to add --wrapper gdb81,--args. So now
> > > > I see a nice back-trace.
> >
On 13 September 2018 at 10:38, Ville Voutilainen
wrote:
> Howdy! The tricky details of copy constructors, part 76.
> In this approach, I let the const-copy "dominate"; that is, if
> a const-copy was found, a non-const-copy will not turn off triviality
> of the copy constructor, and a const-copy wi
Committed as r264202.
gcov-8 still fails at r264226 according to
https://gcc.gnu.org/ml/gcc-testresults/2018-09/msg01478.html
So it is confirmed that this patch doesn't resolve PR85871, as Mike hoped.
Thanks,
Joey
On Mon, Sep 10, 2018 at 3:04 PM Martin Liška wrote:
>
> On 09/05/2018 03:29 PM, J
On Thu, 13 Sep 2018, Richard Biener wrote:
> On Thu, 13 Sep 2018, Gerald Pfeifer wrote:
>
> > On Mon, 10 Sep 2018, Martin Liška wrote:
> > > Works for me! One needed to add --wrapper gdb81,--args. So now
> > > I see a nice back-trace.
> >
> > Great! This appears to be a tough one, though breaki
Hi Claus,
On Thu, 2018-09-13 at 09:59 +0200, Claudiu Zissulescu wrote:
> The patch is missing the entry change log. Otherwise is ok. I'll push it with
> the mentioned changes.
Thanks for taking care.
Also may we have it back-ported to 8.x branch so it will be a part of 8.3
release later?
-Ale
The patch is missing the entry change log. Otherwise is ok. I'll push it with
the mentioned changes.
Thank you,
Claudiu
> -Original Message-
> From: Alexey Brodkin [mailto:abrod...@synopsys.com]
> Sent: Thursday, September 13, 2018 9:41 AM
> To: gcc-patches@gcc.gnu.org
> Cc: linux-snps-.
With no trailing space in LINK_EH_SPEC linker spec gets generated as:
>8-
%{!r:--build-id} --eh-frame-hdr%{h*} ...
>8-
or even worse if hash style is added:
>8-
%{!r:
Howdy! The tricky details of copy constructors, part 76.
In this approach, I let the const-copy "dominate"; that is, if
a const-copy was found, a non-const-copy will not turn off triviality
of the copy constructor, and a const-copy will reinstate triviality
of the copy constructor even if a non-con
Aldy Hernandez writes:
> On 09/12/2018 12:57 PM, Richard Sandiford wrote:
>> Aldy Hernandez writes:
>>> diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
>>> index 589fdea4df6..e9ee418e5b2 100644
>>> --- a/gcc/wide-int-range.h
>>> +++ b/gcc/wide-int-range.h
>>> @@ -131,7 +131,7 @@ extern b
On Thu, 13 Sep 2018, Gerald Pfeifer wrote:
> On Mon, 10 Sep 2018, Martin Liška wrote:
> > Works for me! One needed to add --wrapper gdb81,--args. So now
> > I see a nice back-trace.
>
> Great! This appears to be a tough one, though breaking FreeBSD/i386
> with clang, GCC 6 and GCC 9 (two weeks o
On Mon, 10 Sep 2018, Martin Liška wrote:
> Works for me! One needed to add --wrapper gdb81,--args. So now
> I see a nice back-trace.
Great! This appears to be a tough one, though breaking FreeBSD/i386
with clang, GCC 6 and GCC 9 (two weeks old), Solaris, HP/UX, so looks
like something around glib
On Wed, 12 Sep 2018, Alexander Monakov wrote:
> On Wed, 12 Sep 2018, Richard Biener wrote:
> > With LTO "static" is too blurry - would -finline-only-hidden be OK
> > with you?
>
> This doesn't sound right - in non-pic, everything is hidden, effectively.
> And the intended use is with Linux kernel
On Wed, 12 Sep 2018, Jakub Jelinek wrote:
> Hi!
>
> This patch optimizes signed x % C1 == C2 expansion if it is beneficial.
> x % C1 == 0 should be handled unconditionally in match.pd (previous patch),
> this only handles the cases where C1 is positive power of two and abs (C2)
> is smaller than
70 matches
Mail list logo
