>@@ -605,14 +605,21 @@ c_strlen (tree src, int only_value)
>
> /* Set MAXELTS to sizeof (SRC) / sizeof (*SRC) - 1, the maximum possible
> length of SRC. Prefer TYPE_SIZE() to TREE_STRING_LENGTH() if possible
>- in case the latter is less than the size of the array. */
>- HOST_WIDE_IN
On Fri, Jun 29, 2018 at 9:54 PM, Martin Liška wrote:
> On 06/22/2018 10:35 PM, Jeff Law wrote:
>> On 05/16/2018 05:53 AM, Martin Liška wrote:
>>> On 12/21/2017 10:13 AM, Martin Liška wrote:
On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
> Another thing is that the "/" in there is wrong, so
On 2018-07-17 04:25 PM, Michael Ploujnikov wrote:
> On 2018-07-17 06:02 AM, Richard Biener wrote:
>> On Tue, Jul 17, 2018 at 8:10 AM Bernhard Reutner-Fischer
>> wrote:
>>>
>>> On 16 July 2018 21:38:36 CEST, Michael Ploujnikov
>>> wrote:
Hi,
>>>
+clone_fn_ids = hash_map::create
On събота, 23 юни 2018 г. 20:35:23 EEST Jakub Jelinek wrote:
> On Sat, Jun 23, 2018 at 03:26:50PM +0300, Dimitar Dimitrov wrote:
> > I took arm/ldmstm.md as an inspiration. See attached machine description
> > for PRU that requires the increase. I omitted this machine-generated MD
> > file from my
This has been a long time coming, but as most of you know I've changed
groups at Red Hat and my new duties don't give me the time or focus I
used to have for all my various upstream maintainerships. To be fair
to the community, I'm making this change official by stepping down
from the ones I can
clang (including trunk and many older versions) incorrectly marks static local
variables (__tag) hidden when -fvisibility-inlines-hidden is used.
% cat b.cc
#include
std::shared_ptr foo(int x) {
return std::make_shared(x);
}
% g++-8 -fvisibility-inlines-hidden -fno-rtti -c b.cc
% readelf -s b.
On 07/19/2018 03:51 PM, Jeff Law wrote:
On 07/13/2018 05:45 PM, Martin Sebor wrote:
+ offset_int ofr[] = {
+ wi::to_offset (fold_convert (ptrdiff_type_node, vr->min)),
+ wi::to_offset (fold_convert (ptrdiff_type_node, vr->max))
+ };
huh. Do you maybe want to use widest_i
On 07/19/2018 02:45 PM, Bernd Edlinger wrote:
@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
const char a[4] = "abc\000\000";
The excess elements contribute to TREE_STRING_LENGTH()
but not to strlen(). */
- unsigned HOST_WIDE_INT length
-= strnlen (TREE
Here's one more update with tweaks addressing a couple more
of Bernd's comments:
1) correct the use of TREE_STRING_LENGTH() where a number of
array elements is expected and not bytes
2) set CHARTYPE as soon as it's first determined rather than
trying to extract it again later
On 07/19/2018 01:49
On 06/24/2018 03:05 PM, Martin Sebor wrote:
> Storing integer command line option arguments in type int
> limits options such as -Wlarger-than= or -Walloca-larger-than
> to at most INT_MAX (see bug 71905). Larger values wrap around
> zero. The value zero is considered to disable the option,
> mak
I've checked in the patch below as r262892 to avoid the many
warnings the new code was causing with GCC 6:
/ssd/src/gcc/svn/gcc/align.h:53:32: warning: extended initializer lists
only available with -std=c++11 or -std=gnu++11
Martin
Index: gcc/ChangeLog
===
On 07/13/2018 05:45 PM, Martin Sebor wrote:
>>
>> + offset_int ofr[] = {
>> + wi::to_offset (fold_convert (ptrdiff_type_node, vr->min)),
>> + wi::to_offset (fold_convert (ptrdiff_type_node, vr->max))
>> + };
>>
>> huh. Do you maybe want to use widest_int for ofr[]? What's
>>
On Thu, 2018-07-19 at 08:31 +0100, Richard Sandiford wrote:
>
> > @@ -4706,8 +4730,11 @@ aarch64_process_components (sbitmap
> > components, bool prologue_p)
> > while (regno != last_regno)
> > {
> > /* AAPCS64 section 5.1.2 requires only the bottom 64 bits to be saved
> > - so
> On Jul 19, 2018, at 2:24 PM, Jakub Jelinek wrote:
>
> On Thu, Jul 19, 2018 at 02:06:16PM -0500, Qing Zhao wrote:
>>> If you expand it as (int) ((unsigned char *)p)[n] - (int) ((unsigned char
>>> *)q)[n]
>>> then aren't you relying on int type to have wider precision than unsigned
>>> char
>
>@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
> const char a[4] = "abc\000\000";
> The excess elements contribute to TREE_STRING_LENGTH()
> but not to strlen(). */
>- unsigned HOST_WIDE_INT length
>-= strnlen (TREE_STRING_POINTER (init), TREE_STRING_LEN
On 07/19/18 22:03, Martin Sebor wrote:
> On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
>>> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
>>> return ssize_int (0);
>>>
>>> /* We don't know the starting offset, but we do know that the string
>>> - has no internal zero byte
In the discussion of my patch for pr86532 Bernd noted that
GCC silently accepts constant character arrays with no
terminating nul as arguments to strlen (and other string
functions).
The attached patch is a first step in detecting these kinds
of bugs in strlen calls by issuing -Wstringop-overflow
On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
@@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
return ssize_int (0);
/* We don't know the starting offset, but we do know that the string
-has no internal zero bytes. We can assume that the offset falls
-wit
On 07/19/2018 12:19 AM, Bernd Edlinger wrote:
if (TREE_CODE (idx) != INTEGER_CST
&& TREE_CODE (argtype) == POINTER_TYPE)
{
/* From a pointer (but not array) argument extract the variable
index to prevent get_addr_base_and_unit_off
On 07/19/2018 01:17 AM, Richard Biener wrote:
On Wed, 18 Jul 2018, Martin Sebor wrote:
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
going to be an INTEGER_TYPE? And under what c
Hi,
Hope you having a great day!
I just wanted to be aware if you looking to acquire NetApp Users Contact List
for your marketing efforts?
We also have Users information of companies using: Dell EMC, VMware, CISCO,
Citrix, IBM, Oracle, Brocade Communications Systems, Symantec, Veeam, Nut
On 07/19/2018 12:04 PM, Bernd Edlinger wrote:
Hi,
this fixes a few minor nits, which I spotted while
looking at the string folding functions:
Please hold off until the patch for bug 86532 has been reviewed,
approved, and committed. I'm making changes in this area,
partly to address some of y
On 07/19/18 20:11, Jeff Law wrote:
> On 07/19/2018 12:04 PM, Bernd Edlinger wrote:
>> Hi,
>>
>>
>> this fixes a few minor nits, which I spotted while
>> looking at the string folding functions:
>>
>> string_constant: Remove impossible check: TREE_CODE (arg)
>> can't be COMPONENT_REF and MEM_REF at
On Thu, Jul 19, 2018 at 02:06:16PM -0500, Qing Zhao wrote:
> > If you expand it as (int) ((unsigned char *)p)[n] - (int) ((unsigned char
> > *)q)[n]
> > then aren't you relying on int type to have wider precision than unsigned
> > char
> > (or unit_mode being narrower than mode)?
>
> do you impl
On 19/07/18 21:40 +0300, Ville Voutilainen wrote:
On 19 July 2018 at 20:18, Jonathan Wakely wrote:
This removes some seemingly redundant conditions from a few traits. If
__is_trivially_assignable correctly checks the assignable condition as
well as triviality, then we don't need is_assignable e
Jakub,
thanks a lot for you review and comments.
> On Jul 19, 2018, at 12:31 PM, Jakub Jelinek wrote:
>
> On Thu, Jul 19, 2018 at 11:49:16AM -0500, Qing Zhao wrote:
>> As Wilco mentioned in PR78809 after I checked in the last part of
>> implementation of inline strcmp:
>>
>> See http://www.i
On 19/07/18 11:04 -0400, Glen Fernandes wrote:
On Thu, Jul 19, 2018 at 10:40 AM Jonathan Wakely wrote:
On 19/07/18 10:32 -0400, Glen Fernandes wrote:
>Attached: patch.txt
>Use __builtin_memmove for trivially copyable types
>2018-07-19 Glen Joseph Fernandes
>* include/bits/stl_algobase.h
On 19 July 2018 at 20:18, Jonathan Wakely wrote:
> This removes some seemingly redundant conditions from a few traits. If
> __is_trivially_assignable correctly checks the assignable condition as
> well as triviality, then we don't need is_assignable explicitly. Does
> anybody see a problem with t
On 07/19/2018 12:04 PM, Bernd Edlinger wrote:
> Hi,
>
>
> this fixes a few minor nits, which I spotted while
> looking at the string folding functions:
>
> string_constant: Remove impossible check: TREE_CODE (arg)
> can't be COMPONENT_REF and MEM_REF at the same time.
Shouldn't they all be != te
Hi,
this fixes a few minor nits, which I spotted while
looking at the string folding functions:
string_constant: Remove impossible check: TREE_CODE (arg)
can't be COMPONENT_REF and MEM_REF at the same time.
c_strlen: maxelts is (signed) HOST_WIDE_INT, therefore
use tree_to_shwi.
c_getstr: tree
On 07/19/2018 06:55 AM, Tamar Christina wrote:
>>>
>>> What's the purpose of including auto-host in params-list and
>>> params-options? It seems like you're putting a property of the target
>>> (guard size) into the wrong place (auto-host.h).
>>>
>>
>> The reason for this is because there's a test
On Thu, Jul 19, 2018 at 11:49:16AM -0500, Qing Zhao wrote:
> As Wilco mentioned in PR78809 after I checked in the last part of
> implementation of inline strcmp:
>
> See http://www.iso-9899.info/n1570.html
> section 7.24.4:
>
> "The sign of a nonzero value returned by the comparison functions
This removes some seemingly redundant conditions from a few traits. If
__is_trivially_assignable correctly checks the assignable condition as
well as triviality, then we don't need is_assignable explicitly. Does
anybody see a problem with that
I added some extra tests for cases that had been pro
Hi,
As Wilco mentioned in PR78809 after I checked in the last part of
implementation of inline strcmp:
See http://www.iso-9899.info/n1570.html
section 7.24.4:
"The sign of a nonzero value returned by the comparison functions memcmp,
strcmp, and strncmp is determined
by the sign of the diff
[Dropping Jeff Law from the list since he already commented on the
middle end parts]
Hi Kyrill,
On Thu, 19 Jul 2018 at 12:02, Kyrill Tkachov
wrote:
>
> Hi Thomas,
>
> On 17/07/18 12:02, Thomas Preudhomme wrote:
> > Fixed in attached patch. ChangeLog entries are unchanged:
> >
> > *** gcc/ChangeL
On Wed, Jun 13, 2018 at 02:57:45AM -0500, Michael Collison wrote:
> Updated with Richard's style and mismatched mode comments.
>
> Okay for trunk?
OK.
Thanks,
James
On Wed, Jun 13, 2018 at 03:06:05AM -0500, Michael Collison wrote:
> Updated previous patch:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00508.html
>
> With coding style feedback from Richard Sandiford: (that also apply to this
> patch)
>
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00
On 17/07/18 16:23, James Greenhalgh wrote:
> On Mon, Jul 09, 2018 at 08:20:53AM -0500, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch adds support for the Statistical Profiling Extension (SPE) on
>> AArch64. Even though the compiler will not generate code any differently
>> given this extensio
On 07/19/2018 08:39 AM, Jonathan Wakely wrote:
> On 19/07/18 10:01 -0400, Glen Fernandes wrote:
>> On Thu, Jul 19, 2018 at 9:25 AM Jonathan Wakely
>> wrote:
>>> Sorry for the delay in reviewing this properly, as I've only just
>>> realised that this introduces undefined behaviour, doesn't it?
>>>
On Thu, Jul 19, 2018 at 10:40 AM Jonathan Wakely wrote:
> On 19/07/18 10:32 -0400, Glen Fernandes wrote:
> >Attached: patch.txt
> >Use __builtin_memmove for trivially copyable types
> >2018-07-19 Glen Joseph Fernandes
> >* include/bits/stl_algobase.h
> >(__copy_move_a): Used __is_trivia
On Thu, Jul 19, 2018 at 10:40 AM Jonathan Wakely wrote:
> On 19/07/18 10:32 -0400, Glen Fernandes wrote:
> >Attached: patch.txt
> >Use __builtin_memmove for trivially copyable types
> >2018-07-19 Glen Joseph Fernandes
> >* include/bits/stl_algobase.h
> >(__copy_move_a): Used __is_trivia
On 07/19/2018 03:06 AM, Aldy Hernandez wrote:
>
>
> On 07/19/2018 04:18 AM, Richard Biener wrote:
>> On Wed, Jul 18, 2018 at 2:05 PM Aldy Hernandez wrote:
>>>
>>> Hi again!
>>>
>>> Well, since this hasn't been reviewed and I'm about to overhaul the
>>> TYPE_OVERFLOW_WRAPS code anyhow, might as w
On 19/07/18 10:32 -0400, Glen Fernandes wrote:
On Thu, Jul 19, 2018 at 10:01 AM Glen Fernandes wrote:
I was still unclear about that, but I forwarded you an e-mail from
Marshall with his answer when I asked whether libc++'s use of
TriviallyCopyAssignable here was incorrect. Let me know if it ap
On 19/07/18 10:01 -0400, Glen Fernandes wrote:
On Thu, Jul 19, 2018 at 9:25 AM Jonathan Wakely wrote:
Sorry for the delay in reviewing this properly, as I've only just
realised that this introduces undefined behaviour, doesn't it?
It's undefined to use memmove for a type that is not trivially
On Thu, Jul 19, 2018 at 10:01 AM Glen Fernandes wrote:
>
> I was still unclear about that, but I forwarded you an e-mail from
> Marshall with his answer when I asked whether libc++'s use of
> TriviallyCopyAssignable here was incorrect. Let me know if it applies
> here, and if not (and that interpre
Hi Steve,
> This patch checks for SIMD functions and saves the extra registers when
> needed. It does not change the caller behavour, so with just this patch
> there may be values saved by both the caller and callee. This is not
> efficient, but it is correct code.
I tried a few simple test cas
On Thu, Jul 19, 2018 at 04:16:10PM +0200, Martin Liška wrote:
> I must admit that was my intention :) In my eyes it makes it more consistent
> and
> it gives consumers feedback about usage of an option that does nothing.
> For x86_64 there's list of options that are Ignore and don't produce a
> w
On 07/19/2018 03:47 PM, Jakub Jelinek wrote:
> On Thu, Jul 19, 2018 at 03:25:15PM +0200, Martin Liška wrote:
>> Few weeks ago I added new Deprecated flag for options. Apparently, there's
>> one similar called Ignore. Thus I moved all Deprecated to Ignore and for
>> all Ignored I do a warning of fol
On 17/07/18 15:52, James Greenhalgh wrote:
> On Mon, Jun 25, 2018 at 03:48:13AM -0500, Andre Simoes Dias Vieira wrote:
>> On 18/06/18 09:08, Andre Simoes Dias Vieira wrote:
>>> Hi Richard,
>>>
>>> Sorry for the delay I have been on holidays. I had a look and I think you
>>> are right. With these
> Cc: d...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> From: Pedro Alves
> Date: Thu, 19 Jul 2018 14:41:13 +0100
>
> On 07/19/2018 02:06 PM, Eli Zaretskii wrote:
> >> From: Richard Biener
> >> Date: Thu, 19 Jul 2018 10:46:01 +0200
> >> Cc: DJ Delorie , GCC Patches ,
> >> g
On Thu, Jul 19, 2018 at 9:25 AM Jonathan Wakely wrote:
> Sorry for the delay in reviewing this properly, as I've only just
> realised that this introduces undefined behaviour, doesn't it?
>
> It's undefined to use memmove for a type that is not trivially
> copyable. All trivial types are trivially
On Thu, Jul 19, 2018 at 03:25:15PM +0200, Martin Liška wrote:
> Few weeks ago I added new Deprecated flag for options. Apparently, there's
> one similar called Ignore. Thus I moved all Deprecated to Ignore and for
> all Ignored I do a warning of following format:
>
> $ xgcc: warning: switch ‘-mmpx
On 07/19/2018 02:06 PM, Eli Zaretskii wrote:
>> From: Richard Biener
>> Date: Thu, 19 Jul 2018 10:46:01 +0200
>> Cc: DJ Delorie , GCC Patches ,
>> gdb-patc...@sourceware.org
>>
>>> *err = ENOTSUP;
>>>^~~
>>> ./simple-object-elf.c:1284:14: note: each undecl
On 19/07/18 07:59 -0400, Glen Fernandes wrote:
Updated patch to simplify the helper trait, and to include
instead of in the unit test for copy_uninitialized:
Use __builtin_memmove for trivially copy assignable types
2018-07-19 Glen Joseph Fernandes
* include/bits/stl_algobase.h
(__i
Hi.
Few weeks ago I added new Deprecated flag for options. Apparently, there's
one similar called Ignore. Thus I moved all Deprecated to Ignore and for
all Ignored I do a warning of following format:
$ xgcc: warning: switch ‘-mmpx’ is no longer supported
After that there were quite some usages f
> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
> return ssize_int (0);
>
>/* We don't know the starting offset, but we do know that the string
> - has no internal zero bytes. We can assume that the offset falls
> - within the bounds of the string; otherwise,
> From: Richard Biener
> Date: Thu, 19 Jul 2018 10:46:01 +0200
> Cc: DJ Delorie , GCC Patches ,
> gdb-patc...@sourceware.org
>
> > *err = ENOTSUP;
> >^~~
> > ./simple-object-elf.c:1284:14: note: each undeclared identifier is
> > reported only once for ea
Hi Richard,
Thanks for the feedback. I find that using "is_left_consecutive" is more
descriptive than checking for it being a power of 2 - 1, since it
describes the requirement (having consecutive ones from the MSB) more
explicitly. I would be happy to change it though if that is the consensus
Hi Jeff,
> -Original Message-
> From: Tamar Christina
> Sent: Thursday, July 12, 2018 18:45
> To: Jeff Law
> Cc: gcc-patches@gcc.gnu.org; nd ;
> jos...@codesourcery.com; bonz...@gnu.org; d...@redhat.com;
> nero...@gcc.gnu.org; aol...@redhat.com; ralf.wildenh...@gmx.de
> Subject: Re: [PAT
On 07/19/2018 12:31 PM, Richard Earnshaw (lists) wrote:
> On 19/07/18 11:22, Martin Liška wrote:
>> On 07/19/2018 12:01 PM, Richard Earnshaw (lists) wrote:
>>> On 19/07/18 10:56, Martin Liška wrote:
On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
> On 19/07/18 08:30, Martin Liška w
On Wed, Jul 18, 2018 at 12:34:28PM -0700, Kostya Serebryany wrote:
> On Wed, Jul 18, 2018 at 12:29 PM H.J. Lu wrote:
> >
> > On Wed, Jul 18, 2018 at 11:45 AM, Kostya Serebryany wrote:
> > > On Wed, Jul 18, 2018 at 11:40 AM H.J. Lu wrote:
> > >>
> > >> On Wed, Jul 18, 2018 at 11:18 AM, Kostya Ser
On Wed, Jul 11, 2018 at 12:53 PM David Malcolm wrote:
>
> This patch implements a -fsave-optimization-record option, which
> leads to a JSON file being written out, recording the dump_* calls
> made (via the optinfo infrastructure in the previous patch).
>
> The patch includes a minimal version of
Hi again.
Providing an updated patch to include the formatting suggestions.
Thanks,
Matthew
On 12/07/18 11:39, Sudakshina Das wrote:
Hi Matthew
On 12/07/18 11:18, Richard Sandiford wrote:
Looks good to me FWIW (not a maintainer), just a minor formatting thing:
Matthew Malcomson writes:
d
On Wed, Jul 11, 2018 at 12:53 PM David Malcolm wrote:
>
> Changes relative to v4:
> * eliminated optinfo subclasses as discussed
> * eliminated optinfo-internal.h, moving what remained into optinfo.h
> * added support for dump_gimple_expr_loc and dump_gimple_expr
> * more selftests
>
> This patch
On 07/19/2018 01:56 PM, Jakub Jelinek wrote:
On Thu, Jul 19, 2018 at 01:54:46PM +0200, Florian Weimer wrote:
On 07/19/2018 01:48 PM, H.J. Lu wrote:
Both __has_attribute (indirect_return) and __has_attribute (__indirect_return__)
work here.
Applications can have
#define indirect_return
so th
The following does away with copying hashtable elements when moving them
from the optimistic hashtable to the valid one. It does that by
keeping only a single global obstack for all phi, ref and nary
elements and freeing things between iterations by unwinding that obstack.
In this process phis a
Updated patch to simplify the helper trait, and to include
instead of in the unit test for copy_uninitialized:
Use __builtin_memmove for trivially copy assignable types
2018-07-19 Glen Joseph Fernandes
* include/bits/stl_algobase.h
(__is_simple_copy_move): Defined helper.
(__cop
On Thu, Jul 19, 2018 at 4:56 AM, Jakub Jelinek wrote:
> On Thu, Jul 19, 2018 at 01:54:46PM +0200, Florian Weimer wrote:
>> On 07/19/2018 01:48 PM, H.J. Lu wrote:
>> > Both __has_attribute (indirect_return) and __has_attribute
>> > (__indirect_return__)
>> > work here.
>>
>> Applications can have
On Thu, Jul 19, 2018 at 01:54:46PM +0200, Florian Weimer wrote:
> On 07/19/2018 01:48 PM, H.J. Lu wrote:
> > Both __has_attribute (indirect_return) and __has_attribute
> > (__indirect_return__)
> > work here.
>
> Applications can have
>
> #define indirect_return
>
> so the variant without under
On Thu, Jul 19, 2018 at 01:39:04PM +0200, Florian Weimer wrote:
> On 07/19/2018 01:33 PM, Jakub Jelinek wrote:
> > On Thu, Jul 19, 2018 at 04:21:26AM -0700, H.J. Lu wrote:
> > > The new indirect_return attribute is intended to mark swapcontext in
> > > . This patch defines __HAVE_INDIRECT_RETURN_A
On 07/19/2018 01:48 PM, H.J. Lu wrote:
Both __has_attribute (indirect_return) and __has_attribute (__indirect_return__)
work here.
Applications can have
#define indirect_return
so the variant without underscore mangling is definitely not correct.
Thanks,
Florian
On Thu, Jul 19, 2018 at 01:39:04PM +0200, Florian Weimer wrote:
> On 07/19/2018 01:33 PM, Jakub Jelinek wrote:
> > On Thu, Jul 19, 2018 at 04:21:26AM -0700, H.J. Lu wrote:
> > > The new indirect_return attribute is intended to mark swapcontext in
> > > . This patch defines __HAVE_INDIRECT_RETURN_A
On 07/19/2018 01:33 PM, Jakub Jelinek wrote:
On Thu, Jul 19, 2018 at 04:21:26AM -0700, H.J. Lu wrote:
The new indirect_return attribute is intended to mark swapcontext in
. This patch defines __HAVE_INDIRECT_RETURN_ATTRIBUTE__
so that it can be used checked before using indirect_return attribut
On Thu, Jul 19, 2018 at 04:21:26AM -0700, H.J. Lu wrote:
> The new indirect_return attribute is intended to mark swapcontext in
> . This patch defines __HAVE_INDIRECT_RETURN_ATTRIBUTE__
> so that it can be used checked before using indirect_return attribute
> in . It works when the indirect_retur
On Thu, Jul 19, 2018 at 10:35:27AM +0200, Richard Biener wrote:
> On Wed, Jul 18, 2018 at 5:33 PM H.J. Lu wrote:
> >
> > In
> >
> > struct ucontext;
> > typedef struct ucontext ucontext_t;
> >
> > extern int (*bar) (ucontext_t *__restrict __oucp,
> >const ucontext_t *__restrict
Hi Thomas,
On 17/07/18 12:02, Thomas Preudhomme wrote:
Fixed in attached patch. ChangeLog entries are unchanged:
*** gcc/ChangeLog ***
2018-07-05 Thomas Preud'homme
PR target/85434
* target-insns.def (stack_protect_combined_set): Define new standard
pattern name.
(stack_prot
On 19/07/18 11:22, Martin Liška wrote:
> On 07/19/2018 12:01 PM, Richard Earnshaw (lists) wrote:
>> On 19/07/18 10:56, Martin Liška wrote:
>>> On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
On 19/07/18 08:30, Martin Liška wrote:
> This is correct version of the patch. Anyway, I'm
On 07/19/2018 12:01 PM, Richard Earnshaw (lists) wrote:
> On 19/07/18 10:56, Martin Liška wrote:
>> On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
>>> On 19/07/18 08:30, Martin Liška wrote:
This is correct version of the patch. Anyway, I'm thinking about the
ForceHelp
attri
Richard Biener writes:
> On Wed, Jul 18, 2018 at 8:08 PM Richard Sandiford
> wrote:
>>
>> This patch adds the target framework for handling the SVE ACLE,
>> starting with four functions: svadd, svptrue, svsub and svsubr.
>>
>> The ACLE has both overloaded and non-overloaded names. Without
>> the
Hi Richard,
On 07/12/2018 05:35 PM, Richard Earnshaw (lists) wrote:
On 11/07/18 17:48, Jackson Woodruff wrote:
Hi Sudi,
On 07/10/2018 02:29 PM, Sudakshina Das wrote:
Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch resolves PR86014. It does so by n
On 19/07/18 10:56, Martin Liška wrote:
> On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
>> On 19/07/18 08:30, Martin Liška wrote:
>>> This is correct version of the patch. Anyway, I'm thinking about the
>>> ForceHelp
>>> attribute. I may do it in a bit different version. Let me come up wi
On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
> On 19/07/18 08:30, Martin Liška wrote:
>> This is correct version of the patch. Anyway, I'm thinking about the
>> ForceHelp
>> attribute. I may do it in a bit different version. Let me come up with one
>> another
>> version of the patch.
>
Hi,
since we now mention the problem with Intel tuning, I tought we also may mention
the LTO link-time issue that was fixed. It was mentioned by several folks at
the phoronix forum. (Basicaly sometimes the partition size has overlfown which
made partitioner to put every symbol into separate pariti
Hi,
On 19/07/2018 10:43, Rainer Orth wrote:
Hi Paolo,
the below resolves the bug report and its duplicates by implementing -
in a rather straightforward way, I believe - the resolution of DR 136,
which also made into C++17. Note that in the patch I used permerror instead
of a plain error for c
On 19/07/18 08:30, Martin Liška wrote:
> This is correct version of the patch. Anyway, I'm thinking about the ForceHelp
> attribute. I may do it in a bit different version. Let me come up with one
> another
> version of the patch.
>
> Martin
>
I don't understand how this is supposed to work. -
Status
==
The GCC 8 branch is frozen for preparation of the GCC 8.2 release.
All changes to the branch now require release manager approval.
Previous Report
===
https://gcc.gnu.org/ml/gcc/2018-07/msg00194.html
On 07/19/2018 04:18 AM, Richard Biener wrote:
On Wed, Jul 18, 2018 at 2:05 PM Aldy Hernandez wrote:
Hi again!
Well, since this hasn't been reviewed and I'm about to overhaul the
TYPE_OVERFLOW_WRAPS code anyhow, might as well lump it all in one patch.
On 07/16/2018 09:19 AM, Aldy Hernandez
On Thu, Jul 19, 2018 at 9:21 AM Alexandre Oliva wrote:
>
> On Jul 18, 2018, Richard Biener wrote:
>
> > On Wed, Jul 18, 2018 at 8:53 AM Alexandre Oliva wrote:
> >> Instance discriminators are not compatible with LTO, in that the
> >> instance mapping is not preserved in LTO dumps. There are no
On Thu, Jul 19, 2018 at 8:31 AM, Richard Sandiford
wrote:
> Hi,
>
> Thanks for doing this.
>
> Steve Ellcey writes:
>> This is a patch to support the Aarch64 SIMD ABI [1] in GCC. I intend
>> to eventually follow this up with two more patches; one to define the
>> TARGET_SIMD_CLONE* macros and on
On Wed, Jul 18, 2018 at 8:08 PM Richard Sandiford
wrote:
>
> This patch adds the target framework for handling the SVE ACLE,
> starting with four functions: svadd, svptrue, svsub and svsubr.
>
> The ACLE has both overloaded and non-overloaded names. Without
> the equivalent of clang's __attribute
On Wed, Jul 18, 2018 at 6:18 PM Eli Zaretskii wrote:
>
> Hi,
>
> I've built the pretest of GDB 8.2 with MinGW today, and bumped into a
> compilation error in libiberty:
>
> if [ x"" != x ]; then \
>gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
> -I./../include
Hi Paolo,
> the below resolves the bug report and its duplicates by implementing -
> in a rather straightforward way, I believe - the resolution of DR 136,
> which also made into C++17. Note that in the patch I used permerror instead
> of a plain error for consistency with the other check
> (chec
On Wed, Jul 18, 2018 at 5:33 PM H.J. Lu wrote:
>
> In
>
> struct ucontext;
> typedef struct ucontext ucontext_t;
>
> extern int (*bar) (ucontext_t *__restrict __oucp,
>const ucontext_t *__restrict __ucp)
> __attribute__((__indirect_return__));
>
> extern int res;
>
> void
> f
On Wed, Jul 18, 2018 at 3:42 PM Tom de Vries wrote:
>
> On 07/06/2018 12:28 PM, Richard Biener wrote:
> > On Thu, Jul 5, 2018 at 4:12 PM Tom de Vries wrote:
> >>
> >> On 07/05/2018 01:39 PM, Richard Biener wrote:
> >>> On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries wrote:
>
> [ was: Re: [
On Wed, Jul 18, 2018 at 2:05 PM Aldy Hernandez wrote:
>
> Hi again!
>
> Well, since this hasn't been reviewed and I'm about to overhaul the
> TYPE_OVERFLOW_WRAPS code anyhow, might as well lump it all in one patch.
>
> On 07/16/2018 09:19 AM, Aldy Hernandez wrote:
> > Howdy!
> >
> > I've abstracte
Hi,
Thanks for doing this.
Steve Ellcey writes:
> This is a patch to support the Aarch64 SIMD ABI [1] in GCC. I intend
> to eventually follow this up with two more patches; one to define the
> TARGET_SIMD_CLONE* macros and one to improve the GCC register
> allocation/usage when calling SIMD fun
This is correct version of the patch. Anyway, I'm thinking about the ForceHelp
attribute. I may do it in a bit different version. Let me come up with one
another
version of the patch.
Martin
>From 9bfc1400213911b4508e90198df7b2dd11efc85c Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 20 Feb 2
On Jul 18, 2018, Richard Biener wrote:
> On Wed, Jul 18, 2018 at 8:53 AM Alexandre Oliva wrote:
>> Instance discriminators are not compatible with LTO, in that the
>> instance mapping is not preserved in LTO dumps. There are no plans to
>> preserve discriminators in them.
> Because...
... it
On 07/18/2018 06:28 PM, Thomas Preudhomme wrote:
> Hi Martin,
>
> Why is this needed when -mfpu does not seem to need it for instance?
Because the mfpu is an enum option type:
mfpu=
Target RejectNegative Joined Enum(arm_fpu) Var(arm_fpu_index)
Init(TARGET_FPU_auto) Save
Specify the name of the
On Wed, 18 Jul 2018, Martin Sebor wrote:
> > > > + while (TREE_CODE (chartype) != INTEGER_TYPE)
> > > > +chartype = TREE_TYPE (chartype);
> > > This is a bit concerning. First under what conditions is chartype not
> > > going to be an INTEGER_TYPE? And under what conditions will extract
100 matches
Mail list logo
