One small comment.
On Tue, Nov 20, 2018 at 10:01 AM Christoph Muellner
wrote:
>
> Tested with "make check" and no regressions found.
>
> This patch depends on the struct xgene1_prefetch_tune,
> which has been acknowledged already:
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00985.html
>
>
Jakub,
Thanks for the comments!
I have addressed them as attached.
Wei
gcc/
* common/config/i386/i386-common.c (processor_names): Add cascadelake.
(processor_alias_table): Add cascadelake.
* config.gcc: Add -march=cascadelake.
* config/i386/driver-i386.c
On Sat, 17 Nov 2018 at 16:07, Johannes Pfau wrote:
>
> Hi,
>
> the loadDR test in the libphobos.shared testsuite tries to dynamically load
> the phobos library. The path for the library currently points to the main
> multilib variant phobos library, causing other multilib variants to fail the
On Tue, Nov 20, 2018 at 04:59:46PM -0500, Jason Merrill wrote:
> On 11/19/18 5:12 PM, Marek Polacek wrote:
> > On Mon, Nov 19, 2018 at 10:33:17PM +0100, Jakub Jelinek wrote:
> > > On Mon, Nov 19, 2018 at 04:21:19PM -0500, Marek Polacek wrote:
> > > > 2018-11-19 Marek Polacek
> > > >
> > > >
On 21-11-18 02:03, Ian Lance Taylor wrote:
> On Wed, Nov 14, 2018 at 6:45 AM, Tom de Vries wrote:
>> On 14-11-18 14:25, Jakub Jelinek wrote:
>>> On Wed, Nov 14, 2018 at 02:08:05PM +0100, Tom de Vries wrote:
> +btest_dwz_CFLAGS = $(AM_CFLAGS) -g -O0
Hmm, I already discovered that
... in fact I'm thinking that the below - which directly checks for
unqualified_id to be non-null in both places - may be a better variant:
among other things it means that for related testcases like:
typedef void a();
struct A
{ a a1: 1; };
we get the location of a1 right (we could also change
Tom de Vries writes:
> [libbacktrace] Factor out read_initial_length
>
> 2018-11-22 Tom de Vries
>
> * dwarf.c (read_initial_length): Factor out of ...
> (build_address_map, read_line_info): ... here.
This is OK.
Thanks.
Ian
Hi,
this patch factors out new function read_initial_length in dwarf.c.
Bootstrapped and reg-tested on x86_64.
OK for trunk?
Thanks,
- Tom
[libbacktrace] Factor out read_initial_length
2018-11-22 Tom de Vries
* dwarf.c (read_initial_length): Factor out of ...
On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz wrote:
> Patch 7 fixes tests for msp430-elf in the large memory model.
Added missing documentation for new check_effective target procs in attached
patch.
>From 4cfb2ecd0e0580f69790fadd68b77e8a82992ef4 Mon Sep 17 00:00:00 2001
From: Jozef
On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz wrote:
> Patch 6 fixes tests expecting printf float support for targets which have been
> configured with "newlib-nano-formatted-io". When newlib is configured in this
> way, float printf is enabled at build time by registering _printf_float
On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz wrote:
> Patch 3 sets up require-effective-target directives for tests which
> require the compilation of large arrays.
> Targets which have 16-bit or 20-bit size_t fail to compile tests with large
> arrays designed to test 32-bit or 64-bit
On 11/21/18 5:16 PM, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE in maybe_explain_implicit_delete, because
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL - there are no user parameters
and ...
From what I understood, const_p is used only in certain cases like const vs.
non-const
On 11/21/18 5:10 PM, Jakub Jelinek wrote:
On Wed, Nov 21, 2018 at 07:49:48PM +0100, Jakub Jelinek wrote:
So, do you suggest we should instead return
operator new
^~~~
operator delete []
^~
operator ==
^~~
operator "" _foo
^~~~
?
That would mean
On 11/21/18 1:49 PM, Jakub Jelinek wrote:
On Wed, Nov 21, 2018 at 01:29:15PM -0500, Jason Merrill wrote:
similarly for operator"" _F the column is under _ rather than first o.
I disagree with this one: the name of the declaration is operator""_F, so I
think the caret should go at the first o.
On Wed, Nov 21, 2018 at 11:21:18PM +0100, Jakub Jelinek wrote:
> As I wrote in the PR, before PR81708 commits,
Note, e.g. in 4.8, the stack_protector_* patterns weren't guarded with
something like TARGET_SSP_TLS_GUARD but with !TARGET_HAS_BIONIC,
which just means it was incorrectly implemented
Hi!
As I wrote in the PR, before PR81708 commits,
while i386 defaulted to SSP_TLS rather than SSP_GLOBAL on everything but
Android, the -mstack-protector-guard= switch controlled pretty much
whether the i386.md special stack protector patterns are used (if tls)
or whether generic code is used
Hi!
On the following testcase we ICE in maybe_explain_implicit_delete, because
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL - there are no user parameters
and ...
>From what I understood, const_p is used only in certain cases like const vs.
non-const copy constructor or assignment operator, if the
On Wed, Nov 21, 2018 at 07:49:48PM +0100, Jakub Jelinek wrote:
> So, do you suggest we should instead return
> operator new
> ^~~~
> operator delete []
> ^~
> operator ==
> ^~~
> operator "" _foo
> ^~~~
> ?
> That would mean
On 11/21/2018 02:33 PM, Uros Bizjak wrote:
Hello!
Before the recent patch to post-reload mode switching, vzeroupper
insertion depended on the existence of the return copy instructions
pair in functions that return a value. The first instruction in the
pair represents a move to a function
Andi Kleen writes:
Ping^3!
> Andi Kleen writes:
>
> Ping!^2
>
>> Andi Kleen writes:
>>
>> Ping!
>>
>>> From: Andi Kleen
>>>
>>> When instrumenting programs using __fentry__ it is often useful
>>> to instrument the function return too. Traditionally this
>>> has been done by patching the
On Wed, 21 Nov 2018 20:19:29 +0100
Rainer Orth wrote:
> new effective-target keywords always need documenting in
> gcc/doc/sourcebuild.texi.
>
> Rainer
>
Whoops, thanks for the heads up, fixed in attached.
I'll add documentation for the keywords added in the other patches as well.
On Wed, Nov 21, 2018 at 08:12:44PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 21, 2018 at 12:07:51PM -0600, Segher Boessenkool wrote:
> > > Admittedly, it might be better if the initializer was 0x1010101 or say
> > > 0x4030201 because on big endian in particular 0x10101 has the top 15 bits
> > >
> We don't have the commit access ,can someone please commit for us ?
>
> ~Umesh
>
> On Wed, Nov 21, 2018, 18:37 Jakub Jelinek
> > On Wed, Nov 21, 2018 at 06:06:41PM +0530, Umesh Kalappa wrote:
> > > Thank you for the inputs and please find the attachment for the update
> > patch.
> >
> > LGTM.
On November 21, 2018 8:44:46 PM GMT+01:00, Uros Bizjak
wrote:
>Hello!
>
>Attached patch removes extra blockage insn generation. For the
>software archaeology, please see the PR [1], where it was determined,
>that the removed part is probably a dataflow branch to trunk merge
>oversight.
>
Hello!
Attached patch removes extra blockage insn generation. For the
software archaeology, please see the PR [1], where it was determined,
that the removed part is probably a dataflow branch to trunk merge
oversight.
2018-11-21 Uros Bizjak
PR middle-end/88129
* function.c
ping?
On Fri, 26 Oct 2018, Marc Glisse wrote:
Hello,
here are some tweaks so that I can usefully mark deque as trivially
relocatable. It includes more noexcept(auto) madness. For __relocate_a_1, I
should also test if copying, ++ and != are noexcept, but I wanted to ask
first because there
Hello!
Before the recent patch to post-reload mode switching, vzeroupper
insertion depended on the existence of the return copy instructions
pair in functions that return a value. The first instruction in the
pair represents a move to a function return hard register, and the
second was a USE of
Hi Jakub,
Before 9.0 is released, we should also document the flag
(and the extension it supports) in the manual, and note it
in changes.html and on the Wiki. Would you also do that?
Like this? Ok for trunk/wwwdocs?
OK for trunk (and I don't think you need my OK for wwwdocs, but
you have
Hi Janne,
PING!
OK.
Thanks for the patch!
Regards
Thomas
Hi Jozef,
> On Wed, 14 Nov 2018 15:41:00 +
> Jozef Lawrynowicz wrote:
>
>> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
>> these are extensions to existing target selectors in dg directives.
>
> Made some modifications to patch 1 based on suggestions.
> Added
Hi!
On Wed, Nov 21, 2018 at 12:07:51PM -0600, Segher Boessenkool wrote:
> > Admittedly, it might be better if the initializer was 0x1010101 or say
> > 0x4030201 because on big endian in particular 0x10101 has the top 15 bits
> > all zero and thus that is what is in u.f1, so if the bug can be
On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz wrote:
> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
> these are extensions to existing target selectors in dg directives.
Made some modifications to patch 1 based on suggestions.
Added int_eq_float and ptr_eq_long
On Wed, Nov 21, 2018 at 01:29:15PM -0500, Jason Merrill wrote:
> > similarly for operator"" _F the column is under _ rather than first o.
>
> I disagree with this one: the name of the declaration is operator""_F, so I
> think the caret should go at the first o.
Right now when
On 11/21/18 8:35 AM, David Malcolm wrote:
Consider this test case:
namespace json
{
enum { JSON_OBJECT };
}
void test ()
{
JSON_OBJECT;
}
which erroneously accesses an enum value in another namespace without
qualifying the access.
GCC 6 through 8 issue a suggestion that doesn't mention
Two patches to fix the build on msp430-elf which has 16-bit or 20-bit
pointers.
The patch for 88111 also affects other targets, by changing the
default values that are used when pool_options members are zero. The
new default values depend on the number of bits in size_t.
Bootstrapped on
On 11/21/18 10:59 AM, Jakub Jelinek wrote:
Hi!
David's r251026 change added a weird trailing ->location.
It doesn't seem to be useful for anything, matching_braces has its own code
to track locations, so no need to do anything in the caller (and no other
spot does something like that).
On 11/21/18 10:55 AM, Jakub Jelinek wrote:
Hi!
On Tue, Nov 20, 2018 at 04:32:26PM -0500, David Malcolm wrote:
This makes the fix-it hint wrong: after the fix-it is applied, it will
become
return color;
(which won't compile), rather than
return O::color;
which will.
Here is an updated
>
> OK if you put a comment ...
I have adde comments to both free_lang_data referring that some fields
are freed late and comment to the new freeing pass.
While testing I noticed stupid bug in need_assembler_name_p which in
case TYPE_DECL does not satisfy the elaborate conditional for type to be
On Wed, Nov 21, 2018 at 06:31:43PM +0100, Jakub Jelinek wrote:
> > > As mentioned in the PR, the testcase fails on big-endian targets.
> > > The following patch tweaks it so that it does not fail there and still
> > > checks for the original bug.
> >
> > It relies on a certain bitfield layout,
On Fri, Nov 16, 2018 at 02:56:46PM +, Thomas Preudhomme wrote:
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus allowing an attacker to control what the canary would be compared
> against. ARM
On Wed, Nov 21, 2018 at 11:23:38AM -0600, Segher Boessenkool wrote:
> Hi,
>
> On Wed, Nov 21, 2018 at 02:13:55PM +0100, Jakub Jelinek wrote:
> > As mentioned in the PR, the testcase fails on big-endian targets.
> > The following patch tweaks it so that it does not fail there and still
> > checks
Hi,
On Wed, Nov 21, 2018 at 02:13:55PM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, the testcase fails on big-endian targets.
> The following patch tweaks it so that it does not fail there and still
> checks for the original bug.
It relies on a certain bitfield layout, not just on LE.
On 11/21/18 6:08 AM, Rainer Orth wrote:
Hi Martin,
By calling builtin_decl_explicit rather than builtin_decl_implicit
the updated patch in the attachment avoids test failures due to
missing warnings on targets with support for long double but whose
libc doesn't support C99 functions like fabsl
On 20/11/2018 18:00, Christoph Muellner wrote:
> Tested with "make check" and no regressions found.
>
> This patch depends on the struct xgene1_prefetch_tune,
> which has been acknowledged already:
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00985.html
>
> *** gcc/ChangeLog ***
>
>
On 11/2/18 6:07 PM, Sam Tebbs wrote:
> On 11/02/2018 05:28 PM, Sam Tebbs wrote:
>
>> Hi all,
>>
>> This patch adds a new target hook called "asm_post_cfi_startproc". This hook
>> is
>> intended to be used by the aarch64 backend to emit a directive that enables
>> support for unwinding frames
On Wed, 2018-11-21 at 16:59 +0100, Jakub Jelinek wrote:
> Hi!
>
> David's r251026 change added a weird trailing ->location.
> It doesn't seem to be useful for anything, matching_braces has its
> own code
> to track locations, so no need to do anything in the caller (and no
> other
> spot does
On Tue, Nov 20, 2018 at 11:04:46AM -0600, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Nov 13, 2018 at 10:28:16AM +0100, Jakub Jelinek wrote:
> > 2018-11-13 Jakub Jelinek
> >
> > PR target/87839
> > * config/aarch64/atomics.md (@aarch64_compare_and_swap): Use
> > rIJ constraint for
Hi Thomas,
Sorry for the delay.
On 16/11/18 14:56, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On Sat, 10 Nov 2018 at 15:07, Thomas Preudhomme
wrote:
Thanks Kyrill.
Updated patch in attachment. Best regards,
Thomas
On Thu, 8 Nov 2018 at 15:53, Kyrill Tkachov wrote:
Hi Thomas,
Hi!
David's r251026 change added a weird trailing ->location.
It doesn't seem to be useful for anything, matching_braces has its own code
to track locations, so no need to do anything in the caller (and no other
spot does something like that).
Bootstrapped/regtested on x86_64-linux and
Hi!
On Tue, Nov 20, 2018 at 04:32:26PM -0500, David Malcolm wrote:
> This makes the fix-it hint wrong: after the fix-it is applied, it will
> become
> return color;
> (which won't compile), rather than
> return O::color;
> which will.
Here is an updated version of the patch, which still uses
On Wed, Nov 21, 2018 at 6:48 AM Richard Biener
wrote:
>
> On Tue, Nov 20, 2018 at 7:36 PM Andi Kleen wrote:
> >
> > On Tue, Nov 20, 2018 at 11:53:15AM +0100, Richard Biener wrote:
> > > On Fri, Nov 16, 2018 at 8:07 AM Uros Bizjak wrote:
> > > >
> > > > On Fri, Nov 16, 2018 at 4:57 AM Andi Kleen
On Tue, Nov 20, 2018 at 7:36 PM Andi Kleen wrote:
>
> On Tue, Nov 20, 2018 at 11:53:15AM +0100, Richard Biener wrote:
> > On Fri, Nov 16, 2018 at 8:07 AM Uros Bizjak wrote:
> > >
> > > On Fri, Nov 16, 2018 at 4:57 AM Andi Kleen wrote:
> > > >
> > > > From: Andi Kleen
> > > >
> > > > The
On Wed, Nov 21, 2018 at 3:23 PM Jeff Law wrote:
>
> On 11/21/18 7:21 AM, Richard Biener wrote:
> > On Wed, Nov 21, 2018 at 3:28 AM Jeff Law wrote:
> >>
> >> Richi's recent change to fix 88069 is causing various targets to fail
> >> tree-ssa/20030711-2.c. That test is verifying a variety of
> >>
My previous fix for PR87229 was too aggressive. The following
simply teaches the LTO streamer to deal with CALL_EXPRs, support
for which was already in place. I've amended it with two
missing pieces, streaming of CALL_EXPR_BY_DESCRIPTOR and CALL_EXPR_IFN.
LTO bootstrapped and tested on
On Wed, Nov 21, 2018 at 3:16 PM Jeff Law wrote:
>
> On 11/21/18 7:13 AM, Richard Biener wrote:
> > On Wed, Nov 21, 2018 at 1:12 AM Jeff Law wrote:
> >>
> >> On 11/20/18 6:42 AM, Michael Matz wrote:
> >>> Hi,
> >>>
> >>> this bug report is about cris generating worse code since tree-ssa. The
>
On 11/21/18 7:21 AM, Richard Biener wrote:
> On Wed, Nov 21, 2018 at 3:28 AM Jeff Law wrote:
>>
>> Richi's recent change to fix 88069 is causing various targets to fail
>> tree-ssa/20030711-2.c. That test is verifying a variety of
>> optimizations occur during the first DOM pass.
>>
>> Prior to
On Wed, Nov 21, 2018 at 3:28 AM Jeff Law wrote:
>
> Richi's recent change to fix 88069 is causing various targets to fail
> tree-ssa/20030711-2.c. That test is verifying a variety of
> optimizations occur during the first DOM pass.
>
> Prior to Richi's change FRE1 would do some significant
This fixes a bogus warning in bitmap.c by avoiding the problematic
transform of cunrolli, thereby eliding the elt->bits[0] test for
--disable-checking.
Bootstrapped (with and without --disable-checking) and tested on
x86_64-unknown-linux-gnu, applied.
Richard.
2018-11-21 Richard Biener
On Wed, Nov 21, 2018 at 2:06 AM Alexandre Oliva wrote:
>
> In some cases of overriding or resetting locations, we might retain
> discriminator info from earlier locations, when we should take
> discriminator information from the overriding location or reset it.
>
> Regstrapped on
On 11/21/18 7:13 AM, Richard Biener wrote:
> On Wed, Nov 21, 2018 at 1:12 AM Jeff Law wrote:
>>
>> On 11/20/18 6:42 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> this bug report is about cris generating worse code since tree-ssa. The
>>> effect is also visible on x86-64. The symptom is that the work
On Wed, Nov 21, 2018 at 1:12 AM Jeff Law wrote:
>
> On 11/20/18 6:42 AM, Michael Matz wrote:
> > Hi,
> >
> > this bug report is about cris generating worse code since tree-ssa. The
> > effect is also visible on x86-64. The symptom is that the work horse of
> > adler32.c (from zlib) needs spills
On Tue, Nov 20, 2018 at 8:37 PM David Malcolm wrote:
>
> The dump_* API attempts to capture emission location metadata for the
> various dump messages, but looking in -fsave-optimization-record shows
> that many dump messages are lacking useful impl_location values, instead
> having this location
Consider this test case:
namespace json
{
enum { JSON_OBJECT };
}
void test ()
{
JSON_OBJECT;
}
which erroneously accesses an enum value in another namespace without
qualifying the access.
GCC 6 through 8 issue a suggestion that doesn't mention the namespace:
: In function 'void test()':
Hi Jakub and All,
We don't have the commit access ,can someone please commit for us ?
~Umesh
On Wed, Nov 21, 2018, 18:37 Jakub Jelinek On Wed, Nov 21, 2018 at 06:06:41PM +0530, Umesh Kalappa wrote:
> > Thank you for the inputs and please find the attachment for the update
> patch.
>
> LGTM.
>
Hi!
As mentioned in the PR, the testcase fails on big-endian targets.
The following patch tweaks it so that it does not fail there and still
checks for the original bug.
Tested on x86_64-linux and i686-linux, ok for trunk and release branches?
2018-11-21 Jakub Jelinek
PR
Hi Martin,
> By calling builtin_decl_explicit rather than builtin_decl_implicit
> the updated patch in the attachment avoids test failures due to
> missing warnings on targets with support for long double but whose
> libc doesn't support C99 functions like fabsl (such as apparently
>
On Wed, Nov 21, 2018 at 06:06:41PM +0530, Umesh Kalappa wrote:
> Thank you for the inputs and please find the attachment for the update patch.
LGTM.
Jakub
Thank you for the inputs and please find the attachment for the update patch.
Do please let us know your comments on the same
~Umesh
On Tue, Nov 20, 2018 at 3:03 PM Jakub Jelinek wrote:
On Mon, Nov 19, 2018 at 04:08:29PM +0530, Lokesh Janghel wrote:
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
This is currently slowed down by the speed of subversion (as my subversion tree
was outdated). So it should only be a matter of days ... ;-)
> On 21.11.2018, at 12:15, Christoph Müllner
> wrote:
>
>>
>> On 21.11.2018, at 11:26, Kyrill Tkachov wrote:
>>
>> Hi Christoph,
>>
>> On 20/11/18
Hello all,
if a class contains any 'virtual ... = 0', it's an abstract class and for an
abstract class, the destructor not added to the vtable.
For a normal
virtual ~class() { }
that's not a problem as the class::~class() destructor will be generated during
the parsing of the function.
But
Hi Eric,
On Wed, Nov 21, 2018 at 09:35:03AM +0100, Eric Botcazou wrote:
> > This is saying that *every* op except those very few works on the full
> > register. And that for every architecture that has W_R_O.
>
> That's still a progress over the previous situation.
Yes. But it feels more than
On 21/11/2018 00:47, Jeff Law wrote:
This seems like a really gross hack and sets an expectation that
generating registers in the target after IRA has started is OK. It is
not OK. THe fact that this works is, IMHO, likely an accident.
What's the proper test for this? Neither lra_in_progress
> On 21.11.2018, at 11:26, Kyrill Tkachov wrote:
>
> Hi Christoph,
>
> On 20/11/18 18:00, Christoph Muellner wrote:
>> Tested with "make check" and no regressions found.
>>
>> This patch depends on the struct xgene1_prefetch_tune,
>> which has been acknowledged already:
>>
On Wed, Nov 21, 2018 at 06:23:41PM +0800, Wei Xiao wrote:
> The attached patch added -march=cascadelake for x86.
> Tested with bootstrap and regression tests on x86_64. No regressions.
> Is it ok for trunk?
Not a real review, just nits:
index bff4dfb..f7c1c98 100644
--- a/gcc/ChangeLog
+++
Yes you did indeed which is why I didn't include you in to To list.
I've reworked the Arm part significantly since it was last approved,
the ping is meant for the Arm maintainers.
Thanks for enquiring about it. Best regards,
Thomas
On Wed, 21 Nov 2018 at 00:32, Jeff Law wrote:
>
> On 11/16/18
On Wed, Nov 21, 2018 at 11:20 AM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Nov 14, 2018 at 12:37:02AM +0100, Jakub Jelinek wrote:
> > 2018-11-13 Jakub Jelinek
> >
> > PR rtl-optimization/87817
> > * config/i386/i386.md (nmi2_bzhi_3, *bmi2_bzhi_3,
> > *bmi2_bzhi_3_1,
Hi Christoph,
On 20/11/18 18:00, Christoph Muellner wrote:
Tested with "make check" and no regressions found.
This patch depends on the struct xgene1_prefetch_tune,
which has been acknowledged already:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00985.html
*** gcc/ChangeLog ***
2018-xx-xx
Hi,
The attached patch added -march=cascadelake for x86.
Tested with bootstrap and regression tests on x86_64. No regressions.
Is it ok for trunk?
Wei
gcc/
* common/config/i386/i386-common.c (processor_names): Add cascadelake.
(processor_alias_table): Add cascadelake.
Hi!
On Wed, Nov 14, 2018 at 12:37:02AM +0100, Jakub Jelinek wrote:
> 2018-11-13 Jakub Jelinek
>
> PR rtl-optimization/87817
> * config/i386/i386.md (nmi2_bzhi_3, *bmi2_bzhi_3,
> *bmi2_bzhi_3_1, *bmi2_bzhi_3_1_ccz): Use IF_THEN_ELSE
> in the pattern to avoid triggering
On Tue, Nov 20, 2018 at 12:39:44AM +0100, Jakub Jelinek wrote:
> On Mon, Nov 19, 2018 at 04:10:09PM -0700, Jeff Law wrote:
> > > PR c/88065 - ICE in -Wsizeof-pointer-memaccess on an invalid strncpy
> > >
> > > gcc/c-family/ChangeLog:
> > >
> > > PR c/88065
Please also add
PR c/87297
On Wed, Nov 21, 2018 at 10:48 AM Uros Bizjak wrote:
>
> On Wed, Nov 21, 2018 at 12:46 AM Jeff Law wrote:
> >
> > On 11/19/18 12:58 PM, Uros Bizjak wrote:
> > > Hello!
> > >
> > > The assert in create_pre_exit at mode-switching.c expects return copy
> > > pair with nothing in between. However,
On Wed, Nov 21, 2018 at 12:46 AM Jeff Law wrote:
>
> On 11/19/18 12:58 PM, Uros Bizjak wrote:
> > Hello!
> >
> > The assert in create_pre_exit at mode-switching.c expects return copy
> > pair with nothing in between. However, the compiler starts mode
> > switching pass with the following
On Fri, Oct 26, 2018 at 9:44 AM H.J. Lu wrote:
>
> On 10/25/18, Uros Bizjak wrote:
> > On Fri, Oct 26, 2018 at 8:48 AM H.J. Lu wrote:
> >>
> >> On 10/25/18, Uros Bizjak wrote:
> >> > On Fri, Oct 26, 2018 at 8:07 AM H.J. Lu wrote:
> >> >>
> >> >> * read-rtl.c (apply_subst_iterator):
On Wed, 21 Nov 2018, Jan Hubicka wrote:
> Hi,
> this patch recovers location infomration in the ODR warnings.
> Because location info is not attached to types but corresponding
> TYPE_DECLs, we need to prevent TYPE_DECLs to be merged when
> corresponding types are not merged.
>
> To achieve this
> This is saying that *every* op except those very few works on the full
> register. And that for every architecture that has W_R_O.
That's still a progress over the previous situation.
> It also only looks at the top code in the RTL, so it will say for example
> a rotate-and-mask is just fine,
Hello!
Before vzeroupper gets emitted before function call, the compiler
checks if if there are live call-saved SSE registers at the insertion
point. This functionality is intended to handle Windows ABI, so we
don't clear upper parts of the XMM registers that live across the
call.
However, the
On Wed, Nov 21, 2018 at 08:31:17AM +0100, Thomas Koenig wrote:
> > I'd like to ping this patch, ok for trunk?
>
> OK. Thanks for the patch!
Thanks.
> Before 9.0 is released, we should also document the flag
> (and the extension it supports) in the manual, and note it
> in changes.html and on
87 matches
Mail list logo
