On Apr 18, 2018, Jason Merrill wrote:
> Ok, thanks.
Thanks, here's the consolidated patch I installed.
tinst_level objects are created during template instantiation, and
they're most often quite short-lived, but since there's no intervening
garbage collection, they accumulate throughout the pa
I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
On Tue, Apr 17, 2018, 9:45 PM Alexandre Oliva wrote:
>
> A static_cast of a pointer to data member used to wrap the PTRMEM_CST
> in a NOP_EXPR, but the NOP_EXPR is taken, in constexpr, as evidence
> that there was a reinterpret_
Ok, thanks.
On Tue, Apr 17, 2018, 9:29 PM Alexandre Oliva wrote:
> On Apr 17, 2018, Jason Merrill wrote:
>
> >> Any objections to making dec_refcount_use a friend of tinst_level's?
> >> Otherwise, I'd rather add a free() member function (or maybe static
> >> member function) to free both the TR
A static_cast of a pointer to data member used to wrap the PTRMEM_CST
in a NOP_EXPR, but the NOP_EXPR is taken, in constexpr, as evidence
that there was a reinterpret_cast in the expression. While
reinterpret_casts are to be rejected in constexprs, static_casts are
ok.
Thus, avoid introducing th
On Apr 17, 2018, Jason Merrill wrote:
>> Any objections to making dec_refcount_use a friend of tinst_level's?
>> Otherwise, I'd rather add a free() member function (or maybe static
>> member function) to free both the TREE_LIST and the tinst_level objects.
> Either of those sounds fine.
Here's
Hi,
The new tests g++.dg/ext/undef-bool-1.C and gcc.target/powerpc/undef-bool-2.c
fail on big-endian systems not configured to use VSX instructions by default.
This patch allows them to run correctly on such systems by adding the -mvsx
option.
Tested on a Power7 configured with the default (same
Ok.
On Tue, Apr 17, 2018, 1:59 PM Paolo Carlini
wrote:
> Hi,
>
> this one seems easy: just check the return value of begin_lambda_type
> for error_mark_node - exactly like we do in the parser - and avoid
> ICEing immediately after for the submitted snippet. Tested x86_64-linux.
>
> Thanks, Paolo
Ok.
On Tue, Apr 17, 2018, 10:28 AM Jakub Jelinek wrote:
> On Mon, Apr 16, 2018 at 10:55:34PM +, Jason Merrill wrote:
> > On Mon, Apr 16, 2018, 1:31 PM Jakub Jelinek wrote:
> >
> > > On Mon, Apr 16, 2018 at 09:28:43PM +0200, Jakub Jelinek wrote:
> > > > On the following new testcase we emit
On Tue, Apr 17, 2018, 10:25 AM Alexandre Oliva wrote:
> On Apr 17, 2018, Jason Merrill wrote:
>
> > I was thinking maybe_get_node
>
> 'k
>
> > I suppose better would be for
>
> > + if (obj->list_p () && obj->get_decl_maybe ())
> > + tree_list_freelist ().free (obj->get_node ());
>
> >
On Wed, Apr 4, 2018 at 6:03 AM, Andreas Schwab wrote:
>
> For some reason signal_cgo_test.go needs to run an interactive shell,
> but suppresses reading the startup files. This causes the shell history
> file to be clobbered, by using different history settings than usual.
> Avoid that by setting
Hi!
On Wed, Apr 18, 2018 at 12:20:50AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 05:15:06PM -0500, Bill Seurer wrote:
> > This patch fixes problems that asan has on powerpc64 running on some old
> > kernels and also very new kernels.
> >
> > See https://gcc.gnu.org/bugzilla/show_bug.c
On Tue, Apr 17, 2018 at 05:15:06PM -0500, Bill Seurer wrote:
> [PATCH, rs6000] Fix address sanitizer for powerpc64.
>
> This patch fixes problems that asan has on powerpc64 running on some old
> kernels and also very new kernels.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 and
> ht
[PATCH, rs6000] Fix address sanitizer for powerpc64.
This patch fixes problems that asan has on powerpc64 running on some old
kernels and also very new kernels.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 and
https://github.com/google/sanitizers/issues/933 for more information.
Bootst
On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
> On 04/17/2018 06:24 PM, Joshua Watt wrote:
> > Ping? I'd really like to get this in binutils, which apparently
> > requires getting it here first.
>
> I think it would help if you mentioned what this is and
> what is the intended use case.
A
On Tue, 2018-04-17 at 22:54 +0200, Jakub Jelinek wrote:
> PR debug/84637
> * dbxout.c (dbxout_int): Perform negation in unsigned int type.
> (stabstr_D): Change type of unum from unsigned int to
> unsigned HOST_WIDE_INT. Perform negation in unsigned
> HOST_WIDE_INT
>
On 04/17/2018 06:24 PM, Joshua Watt wrote:
> Ping? I'd really like to get this in binutils, which apparently
> requires getting it here first.
I think it would help if you mentioned what this is and
what is the intended use case.
Was this discussed on the binutils or gdb lists?
Thanks,
Pedro Alv
This fixes the problem that Kito Cheng just reported, where the stack doesn't
have ABI required alignment for 32-bit targets. This was an unintended side
effect of my previous change to fix a gcc bootstrap build failure.
This was tested with riscv{32,64}-{elf,linux} cross compilers and testsuite
> Fixed by just ignoring them. Bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk?
>
> 2018-04-17 Jakub Jelinek
>
> PR rtl-optimization/85431
> * dse.c (record_store): Ignore zero width stores.
OK, thanks.
--
Eric Botcazou
Hi!
As mentioned, for BLKmode stores with MEM_SIZE of 0 we invoke UB,
lowpart_bitmask (0) is called and that shifts an UHWI by 64.
Zero size MEMs should only appear in inline asm and shouldn't be interesting
to DSE at all, they can't make other stores dead, nor can be removed as dead
themselves.
Hi!
The first hunk is I think rather obvious, -2147483648 should be printed
as -2147483648 and doesn't need to introduce UB in the compiler while doing
so. The changes to stabstr_D are analogous, but in addition to that I don't
see why we should just strip away the upper bits, it is again just a
On Tue, Apr 17, 2018 at 04:36:54PM +0100, Kyrill Tkachov wrote:
> This patch makes the arm and aarch64 testsuite safe for when a C++ compiler
> is not present.
> This involves moving .C files into g++.dg/other/ and guarding them with the
> appropriate target check.
>
> For others it just means r
This patch by Tony Reix fixes invocations of ar and ld on AIX.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 259359)
Hi,
this one seems easy: just check the return value of begin_lambda_type
for error_mark_node - exactly like we do in the parser - and avoid
ICEing immediately after for the submitted snippet. Tested x86_64-linux.
Thanks, Paolo.
//
/cp
2018-04-17 Paolo Carlini
Hi!
With the PR85430 fix, I used some scripting to look for insns with
n_operands 2 and types like alu, sselog etc. (those that have 1 suffixed
variants).
The vec_extract_* patterns are one big category that have been detected by
this; some of the patterns used sselog1 type, but others used sselo
On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu wrote:
> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak wrote:
>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu wrote:
>>> -fcf-protection -mcet can't be used with IFUNC features, like symbol
>>> multiversioning or target clone, since IBT/SHSTK are applied to
On Tue, Apr 17, 2018 at 12:25 PM, H.J. Lu wrote:
> On Tue, Apr 17, 2018 at 12:03 PM, H.J. Lu wrote:
>> On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak wrote:
>>> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu wrote:
-fcf-protection -mcet can't be used with IFUNC features, like symbol
multiver
On Tue, Apr 17, 2018 at 11:55 AM, Uros Bizjak wrote:
> On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu wrote:
>> -fcf-protection -mcet can't be used with IFUNC features, like symbol
>> multiversioning or target clone, since IBT/SHSTK are applied to the whole
>> program and they may be disabled in some f
On Tue, Apr 17, 2018 at 8:42 PM, H.J. Lu wrote:
> -fcf-protection -mcet can't be used with IFUNC features, like symbol
> multiversioning or target clone, since IBT/SHSTK are applied to the whole
> program and they may be disabled in some functions. But -fcf-protection
> is implemented with multi-
-fcf-protection -mcet can't be used with IFUNC features, like symbol
multiversioning or target clone, since IBT/SHSTK are applied to the whole
program and they may be disabled in some functions. But -fcf-protection
is implemented with multi-byte NOPs on all 64-bit processors as well as
32-bit proc
CANNABINOID THERAPEUTICS SYMPOSIUM
June 6 - 7, 2018 | Crowne Plaza Redondo Beach & Marina Hotel | Redondo Beach, CA
---
SIGN UP TODAY:
http://links.infocastevents.mkt8115.com/ctt?kn=5&ms=MzM5MjIyMDkS1&r=NjkyMTk1NzM3MTk0S0&b=2&j=MTI2MjA1ODQyNAS2&mt=1&rt=0
---
Don't miss your last chance to get
On Tue, Apr 17, 2018 at 10:29 AM, Ian Lance Taylor wrote:
> On Tue, Apr 17, 2018 at 10:21 AM, Tom de Vries wrote:
>> On 04/17/2018 03:59 PM, Ian Lance Taylor wrote:
>>>
>>> The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
>>> points out that when backtrace_full checks wheth
On 04/12/2018 04:16 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, we need to unpoison the red zones when leaving a
> scope with VLA variable(s); this is done through __asan_allocas_unpoison
> call, unfortunately it is called after the __builtin_stack_restore which
> restores the stack
On Tue, Apr 17, 2018 at 04:36:54PM +0100, Kyrill Tkachov wrote:
> This patch makes the arm and aarch64 testsuite safe for when a C++ compiler
> is not present.
> This involves moving .C files into g++.dg/other/ and guarding them with the
> appropriate target check.
>
> For others it just means r
On Tue, Apr 17, 2018 at 10:21 AM, Tom de Vries wrote:
> On 04/17/2018 03:59 PM, Ian Lance Taylor wrote:
>>
>> The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
>> points out that when backtrace_full checks whether memory is
>> available, it doesn't necessarily release that me
On Apr 17, 2018, Jason Merrill wrote:
> I was thinking maybe_get_node
'k
> I suppose better would be for
> + if (obj->list_p () && obj->get_decl_maybe ())
> + tree_list_freelist ().free (obj->get_node ());
> to be e.g.
> obj-> maybe_free_list();
Any objections to making dec_refco
On Thu, 2018-03-22 at 21:45 -0500, Joshua Watt wrote:
> config/
> * ax_pthread.m4: Add file
> ---
> config/ax_pthread.m4 | 485
> +++
> 1 file changed, 485 insertions(+)
> create mode 100644 config/ax_pthread.m4
>
> diff --git a/config/ax_pth
On Tue, Apr 17, 2018 at 12:51:17PM -0400, Michael Meissner wrote:
> On Mon, Apr 16, 2018 at 02:53:35PM -0500, Segher Boessenkool wrote:
> > Can't you just set up things such that GET_MODE_WIDER_TYPE does not
> > return ieee128 for ibm128? With maybe a new hook yes, if that is
> > necessary.
>
> T
On 04/17/2018 03:59 PM, Ian Lance Taylor wrote:
The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
points out that when backtrace_full checks whether memory is
available, it doesn't necessarily release that memory. It will stay
on the free list, so libbacktrace will use more
On Tue, Apr 17, 2018 at 6:53 PM, Jakub Jelinek wrote:
> Hi!
>
> With the PR85430 fix, I used some scripting to look for insns with
> n_operands 2 and types like alu, sselog etc. (those that have 1 suffixed
> variants).
>
> The vec_extract_* patterns are one big category that have been detected by
On Tue, Apr 17, 2018 at 6:58 PM, Jakub Jelinek wrote:
> Hi!
>
> The search for patterns with n_operands 2 and TYPE_ALU revealed also these
> 3 patterns, which also have just 2 operands, yet use "alu".
>
> I think "alu1" is the right type for these, but given that they had explicit
> "memory" and "
Hi!
The search for patterns with n_operands 2 and TYPE_ALU revealed also these
3 patterns, which also have just 2 operands, yet use "alu".
I think "alu1" is the right type for these, but given that they had explicit
"memory" and "imm_disp" attributes, it probably isn't that big deal.
Bootstrappe
On Mon, Apr 16, 2018 at 02:53:35PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Apr 16, 2018 at 01:41:29PM -0400, Michael Meissner wrote:
> > As I was working on PR target/85075 (to flesh some bugs with IEEE 128-bit
> > support on the PowerPC, particularly with switching the default of long
On Tue, Apr 17, 2018 at 6:39 PM, Jakub Jelinek wrote:
> Hi!
>
> This define_insn has just 2 match_operands, so using alu type for it without
> defining memory attr is incorrect and can result in ICEs.
> My understanding is that alu1 is exactly what we want here.
>
> Bootstrapped/regtested on x86_6
Hi!
This define_insn has just 2 match_operands, so using alu type for it without
defining memory attr is incorrect and can result in ICEs.
My understanding is that alu1 is exactly what we want here.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-04-17 Jakub Jelinek
On Tue, Apr 17, 2018 at 12:29:31PM -0400, Michael Meissner wrote:
> On Tue, Apr 17, 2018 at 09:57:52AM -0500, Segher Boessenkool wrote:
> > On Mon, Apr 16, 2018 at 03:22:16PM -0400, Michael Meissner wrote:
> > > Here is the PR 85075 patch without the rs6000.md bits:
> >
> > This fails on powerpc64
Hi!
In the http://gcc.gnu.org/ml/gcc/2017-02/msg00041.html
thread it has been proposed that powerpc*-*-*spe* would be obsoleted in
GCC 7, which didn't happen and the rs6000 backend has been split into two,
one actively maintained where the SPE support has been removed, and the
other one which unfo
On Mon, Apr 16, 2018 at 10:55:34PM +, Jason Merrill wrote:
> On Mon, Apr 16, 2018, 1:31 PM Jakub Jelinek wrote:
>
> > On Mon, Apr 16, 2018 at 09:28:43PM +0200, Jakub Jelinek wrote:
> > > On the following new testcase we emit 2 different constexpr errors
> > > because of premature folding, whe
On Tue, Apr 17, 2018 at 09:57:52AM -0500, Segher Boessenkool wrote:
> On Mon, Apr 16, 2018 at 03:22:16PM -0400, Michael Meissner wrote:
> > Here is the PR 85075 patch without the rs6000.md bits:
>
> This fails on powerpc64-linux bootstrap (w/ --with-cpu=power7 if that
> matters):
>
> /home/segher
On Wed, Mar 14, 2018 at 05:35:21PM +0100, Borislav Petkov wrote:
> Hi,
>
> here's an attempt to document some of the inline asm operand modifiers
> which make sense and which get used so that people can find what they
> mean in the docs.
>
> This is my first gcc patch so there might be clumsiness
Hi all,
This patch makes the arm and aarch64 testsuite safe for when a C++ compiler is
not present.
This involves moving .C files into g++.dg/other/ and guarding them with the
appropriate target check.
For others it just means renaming them from .C to .c.
For gcc.target/aarch64/simd/pr67896.C
On Mon, Apr 16, 2018 at 03:22:16PM -0400, Michael Meissner wrote:
> Here is the PR 85075 patch without the rs6000.md bits:
This fails on powerpc64-linux bootstrap (w/ --with-cpu=power7 if that
matters):
/home/segher/src/gcc/libgcc/config/rs6000/ibm-ldouble.c: In function '__gcc_qadd
':
/home/segh
The bug report https://github.com/ianlancetaylor/libbacktrace/issues/13
points out that when backtrace_full checks whether memory is
available, it doesn't necessarily release that memory. It will stay
on the free list, so libbacktrace will use more and more memory over
time. This patch fixes that
On Tue, Apr 17, 2018 at 11:00:35AM +0200, Eric Botcazou wrote:
> Right, they were originally alike, but someone you know very well changed it:
>
> 2013-12-17 Jakub Jelinek
>
> * expr.c (convert_modes): For SUBREG_PROMOTED_VAR_P use SUBREG_REG (x)
> instead of x as last gen_lowpart
On Wed, 11 Apr 2018, Jason Merrill wrote:
> On Tue, Apr 10, 2018 at 1:12 PM, Jason Merrill wrote:
> > But really this is beside the point: the x86 ABI says that the
> > alignment of double is 4, so alignof(double) should be 4 regardless of
> > what GCC wants to do internally. And I think the sam
On Tue, 10 Apr 2018, Jason Merrill wrote:
> But really this is beside the point: the x86 ABI says that the
> alignment of double is 4, so alignof(double) should be 4 regardless of
> what GCC wants to do internally. And I think the same is true of
> __alignof__.
__alignof__ needs to stay reflecti
On 04/17/2018 10:33 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 10:29:35AM +0200, Martin Liška wrote:
>> On 04/17/2018 10:28 AM, Martin Liška wrote:
>>> I'm sending patch candidate.
>>
>> This one is the right one.
>
> Ok for stage1 with appropriate ChangeLog entries.
>
> Jakub
>
G
On Tue, Apr 17, 2018 at 09:32:31AM +0200, Eric Botcazou wrote:
> > The following testcase FAILs, because cse_local sees
> > (zero_extend:TI (subreg/s/v:DI (reg:TI ...) 0))
> > inside of REG_EQUAL note, and simplify-rtx.c attempts to optimize it.
> > case ZERO_EXTEND:
> > /* Check for a ze
> Yes, convert_modes does this, on the other side e.g. convert_move a few
> hundred lines above it doesn't:
> if (GET_CODE (from) == SUBREG
> && SUBREG_PROMOTED_VAR_P (from)
> && is_a (to_mode, &to_int_mode)
> && (GET_MODE_PRECISION (subreg_promoted_mode (from))
>
>
On Tue, Apr 17, 2018 at 10:17:15AM +0200, Martin Liška wrote:
> Sure. I see other format violations, should I fix that in follow up patch:
>
> gcc/c-family/c-warn.c: ? G_ ("floating point overflow in expression
> %qE "
> gcc/c-family/c-warn.c: : G_ ("floating point overflow in
On Tue, Apr 17, 2018 at 10:29:35AM +0200, Martin Liška wrote:
> On 04/17/2018 10:28 AM, Martin Liška wrote:
> > I'm sending patch candidate.
>
> This one is the right one.
Ok for stage1 with appropriate ChangeLog entries.
Jakub
On 04/17/2018 10:28 AM, Martin Liška wrote:
> I'm sending patch candidate.
This one is the right one.
Martin
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index d0d9c7894a8..2614eb58f14 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -98,10 +98,10 @@ overflow_warnin
On 04/17/2018 10:21 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 10:17:15AM +0200, Martin Liška wrote:
>> Sure. I see other format violations, should I fix that in follow up patch:
>>
>> gcc/c-family/c-warn.c: ? G_ ("floating point overflow in
>> expression %qE "
>> gcc/c-family/c-
> On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
> > On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
> >> + if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
> >> +{
> >> + warn_odr (t1, t2, f1, f2, warn, warned,
> >> +G_ ("one fie
On 04/17/2018 08:58 AM, Jakub Jelinek wrote:
> On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
>> +if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
>> + {
>> +warn_odr (t1, t2, f1, f2, warn, warned,
>> + G_ ("one field i
On Tue, Apr 17, 2018 at 07:39:20AM +0200, Martin Liška wrote:
> + if (DECL_BIT_FIELD (f1) != DECL_BIT_FIELD (f2))
> + {
> + warn_odr (t1, t2, f1, f2, warn, warned,
> + G_ ("one field is bitfield while other is not "));
I think all
> The following testcase FAILs, because cse_local sees
> (zero_extend:TI (subreg/s/v:DI (reg:TI ...) 0))
> inside of REG_EQUAL note, and simplify-rtx.c attempts to optimize it.
> case ZERO_EXTEND:
> /* Check for a zero extension of a subreg of a promoted
> variable, where the pro
On Tue, Apr 17, 2018 at 08:55:09AM +0200, Martin Jambor wrote:
> Hi,
>
> my fix from last week caused an ICE described in PR 85421 because I did
> not read my own comment and forgot that after calls to
> redirect_callee_duplicating_thunks, one must finish the work by calling
> expand_all_artificia
67 matches
Mail list logo
