Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Serbian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/sr.po
(This file, 'cpplib-6.1-b20160131
cpplib-6.1-b20160131.sr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hi!
The r222470 commit changed =x into =v constraint in *truncdfsf_fast_mixed.
The problem is that for some tunings we have a splitter
/* For converting DF(xmm2) to SF(xmm1), use the following code instead of
cvtsd2ss:
unpcklpd xmm2,xmm2 ; packed conversion might crash on signaling NaNs
The test tree-ssa/pr69196-1.c is BRANCH_COST sensitive. This patch
limits it to the targets where it's actually been tested, reducing
unnecessary noise in the testsuite for other targets.
Installed on the trunk.
jeff
commit f37ecd860c899173c94689d6001730c1d750d860
Author: law
Date: Sat
On 03/04/2016 04:55 PM, Bernd Schmidt wrote:
This is a problem I ran into before, although I can't remember the
details. The problem here is that a user program requests an
unreasonably large vector, the default_vector_alignment returns an
unreasonably large alignment in a HOST_WIDE_INT, which th
On 03/04/2016 04:57 PM, Bernd Schmidt wrote:
This is a transformation which looks for
(set reg1 const)
(set reg2 (plus reg2 reg1))
and tries to replace all further uses of reg2 with (plus reg2 reg1). The
problem here is that one of the uses is in a narrower mode, inside a
zero_extend, so we pro
On 03/04/2016 05:08 PM, Joseph Myers wrote:
On Sat, 5 Mar 2016, Bernd Schmidt wrote:
This is a crash encountered with an implicit declaration inside an argument
list. In the PR, Jakub identified a place where we change the DECL_CONTEXT for
such decls, and I think I agree with him that this seem
As pointed out by Richi, the code did not precisely match the comment in
the case of two anonymous SSA_NAMEs.
In that case we don't have enough information to determine if the names
are associated. Until we do something like build partitions (similar to
what's done in tree-ssa-coalesce), it
On Sat, 5 Mar 2016, Bernd Schmidt wrote:
> This is a crash encountered with an implicit declaration inside an argument
> list. In the PR, Jakub identified a place where we change the DECL_CONTEXT for
> such decls, and I think I agree with him that this seems wrong. The following
> patch ensures th
This is a transformation which looks for
(set reg1 const)
(set reg2 (plus reg2 reg1))
and tries to replace all further uses of reg2 with (plus reg2 reg1). The
problem here is that one of the uses is in a narrower mode, inside a
zero_extend, so we produce wrong results.
The fix seems rather s
On Thu, 3 Mar 2016, Mike Stump wrote:
> On Mar 3, 2016, at 6:21 AM, Bernd Schmidt wrote:
> > What C standard can we assume for libiberty? I was looking at patching this
> > and discovered that SIZE_MAX is defined only for C99, so I'm leaning
> > towards retaining the ints and using INT_MAX.
>
This is a problem I ran into before, although I can't remember the
details. The problem here is that a user program requests an
unreasonably large vector, the default_vector_alignment returns an
unreasonably large alignment in a HOST_WIDE_INT, which then gets stored
int TYPE_ALIGN, which is an
This is a crash encountered with an implicit declaration inside an
argument list. In the PR, Jakub identified a place where we change the
DECL_CONTEXT for such decls, and I think I agree with him that this
seems wrong. The following patch ensures they aren't placed on the list
in the first plac
OK.
Jason
The representation of delete[] causes the constexpr machinery to ICE.
That's a separate bug worth fixing, but for GCC 6 it's simpler to stop
when we see the wrapper, and also gives a better diagnostic.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3cf04bc44a26e84e8c88231572baadb465c70ed
On 03/04/2016 01:37 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, on the following testcase we emit invalid
error on s390* in the va_arg ((ap), int) case, va_arg (ap, int) is fine
(and the former is fine in -std=c++11 or -std=c++98 too).
The bug only triggers in constructors (or destructo
I'm committing the attached patch to sync include/plugin-api.h with binutils.
-cary
2016-03-03 Than McIntosh
* plugin-api.h: Add new hooks to the plugin transfer vector to
to support querying section alignment and section size.
(ld_plugin_get_input_section_alignment):
On 03/03/2016 05:37 PM, Jason Merrill wrote:
On 02/25/2016 09:08 AM, Jason Merrill wrote:
We don't bother evaluating a store to an empty class member, and we
shouldn't complain about accesses either.
This needs to use really_empty_class, since that's what
expand_aggr_init_1 uses.
And even ca
This patch addresses a significant wrong-code issue with constexpr
loops: the value of a SAVE_EXPR was being cached across iterations, so
an increment would only happen once.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b4fbc938b1ce031d9b082f2d3e062976ac431977
Author: Jason Merrill
Da
OK.
Jason
OK.
Jason
Hi!
While working on PR70035, I've noticed that the clobbers at the start of
(certain) constructors are strangely emitted twice instead of just once.
The problem is that start_preparsed_function is first called on the
(abstract) constructor and then again on the cloned constructors (base or
comple
Hi!
As mentioned in the PR, on the following testcase we emit invalid
error on s390* in the va_arg ((ap), int) case, va_arg (ap, int) is fine
(and the former is fine in -std=c++11 or -std=c++98 too).
The bug only triggers in constructors (or destructors), and happens because
build_va_arg creates A
Hi!
-fsanitize=vptr library side of instrumentation assumes that the vtable
pointers in objects are either NULL, or some vtable pointer, if it is random
garbage, it might crash.
The following patch attempts to clear the vtable pointers in objects next to
the spot where -flifetime-dse=2 clobbers th
On Fri, Mar 4, 2016 at 12:49 PM, Bernd Schmidt wrote:
> On 03/04/2016 06:27 PM, Bernd Schmidt wrote:
>>
>> On 03/04/2016 06:14 PM, Patrick Palka wrote:
>>
>>> I just quickly tested building the generated insn-attrtab.c with and
>>> without the patch using my host gcc 5.3 compiler and the .s output
On Fri, Mar 4, 2016 at 11:47 AM, Jason Merrill wrote:
> c++98_only is wrong, we should just remove the target specifier.
>
> Jason
Tested with trunk and 5. Done.
--
H.J.
On Wed, Mar 02, 2016 at 12:03:12PM -0500, Tom de Vries wrote:
> 2015-10-16 Tom de Vries
Please adjust the date ;)
> * omp-low.c (check_omp_nesting_restrictions): Check for non-oacc
> construct in oacc routine. Check for oacc region in oacc routine.
>
> * c-c++-common/goacc/
c++98_only is wrong, we should just remove the target specifier.
Jason
On Fri, Mar 4, 2016 at 8:06 AM, Jason Merrill wrote:
> On this testcase, when strip_typedefs rebuilds a TYPENAME_TYPE to remove the
> typedef, in this case it looks up the same typedef and we then abort because
> we still have a typedef. In that case, strip the typedef explicitly.
>
> Tested x86_
On 02/24/2016 09:07 PM, Nathan Sidwell wrote:
this patch fixes the ICE reported in pr69916
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69916) The loop is
lowered at omp-lowering, but subsequently determined to be dead before
we get to oacc-target-lower. The loop CF is removed along with the
Hi,
a week has passed with PR 69920 fix in and it seems to have fixed all
issues caused by the fix to PR 69666, which I have reverted on the
gcc-5 branch.
So I am going to un-do that revert and backport the PR 69920 fix in
one commit to the branch, after final bootstrap and testing runs
finish (a
On Fri, Mar 04, 2016 at 07:03:09PM +0100, Marek Polacek wrote:
> Ok, version with dg-bogus:
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2016-03-04 Marek Polacek
>
> PR c/69407
> * c-common.c (resolve_overloaded_builtin): Set TREE_USED for the fetch
> operat
Hello!
> This is not a regression but I thought I'd post this anyway. Martin reported
> that we generate -Wunused-value warnings on the attached testcase, which
> arguable doesn't make sense. Setting TREE_USED suppresses the warning. Since
> we already compute 'fetch_op' I used that. (This war
On March 4, 2016 5:35:13 PM GMT+01:00, "Bin.Cheng"
wrote:
>On Fri, Mar 4, 2016 at 11:57 AM, Richard Biener
> wrote:
>> On Fri, Mar 4, 2016 at 12:07 PM, Bin Cheng wrote:
>>> Hi,
>>> A address canonicalization interface was introduced by my original
>patch to PR69052. The interface sorts sub-part
On Fri, Mar 04, 2016 at 06:41:26PM +0100, Jakub Jelinek wrote:
> I'm ok with it for gcc6.
Cool.
> But IMHO you should add dg-bogus directives here.
Ok, version with dg-bogus:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-03-04 Marek Polacek
PR c/69407
* c-commo
On Fri, Mar 04, 2016 at 07:01:10PM +0100, Bernd Schmidt wrote:
> On 03/04/2016 06:56 PM, Jakub Jelinek wrote:
> >I think we don't need to guarantee identical assembly, the reason I've
> >suggested that was if it passed, it would be much easier to verify.
> >Without that, I think it should be bootst
On 03/04/2016 06:56 PM, Jakub Jelinek wrote:
I think we don't need to guarantee identical assembly, the reason I've
suggested that was if it passed, it would be much easier to verify.
Without that, I think it should be bootstrapped at least on one other
target. Note the cases you remove the pare
On Fri, Mar 04, 2016 at 06:49:58PM +0100, Bernd Schmidt wrote:
> On 03/04/2016 06:27 PM, Bernd Schmidt wrote:
> >On 03/04/2016 06:14 PM, Patrick Palka wrote:
> >
> >>I just quickly tested building the generated insn-attrtab.c with and
> >>without the patch using my host gcc 5.3 compiler and the .s
On 03/04/2016 06:27 PM, Bernd Schmidt wrote:
On 03/04/2016 06:14 PM, Patrick Palka wrote:
I just quickly tested building the generated insn-attrtab.c with and
without the patch using my host gcc 5.3 compiler and the .s output is
not the same.
Hmm, looking at the 003t.original dump it looks li
On Fri, Mar 04, 2016 at 06:30:40PM +0100, Marek Polacek wrote:
> This is not a regression but I thought I'd post this anyway. Martin reported
> that we generate -Wunused-value warnings on the attached testcase, which
> arguable doesn't make sense. Setting TREE_USED suppresses the warning. Since
On Fri, Mar 04, 2016 at 06:12:09PM +0100, Martin Jambor wrote:
> > For the g*.dg/gomp/, if you'd only move -Wno-hsa into the last argument
> > next to -fopenmp, how many tests would be affected?
>
> Out of 287 files that have dg-options with them in the gomp
> directories, only 9 generate hsa warn
On 03/04/2016 03:54 PM, Alan Modra wrote:
This is a fix for two testcases that show reload replacing pseudos
that don't get hard regs, with their equivalent mem initialization,
but failing to address the mem properly. The short story is that ira
analysis creates reg equivalence info for use by r
On Fri, Mar 04, 2016 at 05:04:31PM +0100, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 05:01:34PM +0100, Martin Jambor wrote:
> > Not in the limited runs that I experimented with so far, but I
> > certainly kept this possibility in mind too. If so, I would either
> > set it back before invoking
This is not a regression but I thought I'd post this anyway. Martin reported
that we generate -Wunused-value warnings on the attached testcase, which
arguable doesn't make sense. Setting TREE_USED suppresses the warning. Since
we already compute 'fetch_op' I used that. (This warning doesn't tri
On 03/04/2016 05:03 PM, Jesper Broge Jørgensen wrote:
I can look into that if you deem it worth it, or would you rather just
go with Patriks suppressed parenthesis?
For the moment (in stage4) we'll at most go with Patrick's patch.
Whether we do anything beyond that depends on whether we can d
On 03/04/2016 06:14 PM, Patrick Palka wrote:
I just quickly tested building the generated insn-attrtab.c with and
without the patch using my host gcc 5.3 compiler and the .s output is
not the same.
Hmm, looking at the 003t.original dump it looks like there are
differences in SAVE_EXPRs. Indee
On 26/02/16 14:52, James Greenhalgh wrote:
gcc/ChangeLog:
* gcc/config/aarch64/aarch64.c (aarch64_function_arg_alignment):
Rewrite, looking one level down for records and arrays.
---
gcc/config/aarch64/aarch64.c | 31 ---
1 file changed, 16 inserti
On Fri, Mar 4, 2016 at 11:42 AM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 11:34:06AM -0500, Patrick Palka wrote:
>> * genattrtab.c (write_test_expr): New parameter EMIT_PARENS
>> which defaults to true. Emit an outer pair of parentheses only if
>> EMIT_PARENS. When contin
On Fri, Mar 04, 2016 at 11:34:06AM -0500, Patrick Palka wrote:
> * genattrtab.c (write_test_expr): New parameter EMIT_PARENS
> which defaults to true. Emit an outer pair of parentheses only if
> EMIT_PARENS. When continuing a chain of && or ||, don't emit
> parentheses for
Greetings,
Here I propose a patch to gfortran which allows initializing
components of derived type variables with a new compile flag.
Currently the options -finit-integer=, -finit-real=, -finit-logical=,
and -finit-character= are avaialable to initialize variables of each
respective type; however
On Fri, Mar 4, 2016 at 11:57 AM, Richard Biener
wrote:
> On Fri, Mar 4, 2016 at 12:07 PM, Bin Cheng wrote:
>> Hi,
>> A address canonicalization interface was introduced by my original patch to
>> PR69052. The interface sorts sub-parts in an address expression based on
>> precedences defined by
On Fri, 4 Mar 2016, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 04:13:41PM +0100, Bernd Schmidt wrote:
> > On 03/04/2016 03:27 PM, Patrick Palka wrote:
> > >>>I still suggest to try making write_test_expr() avoid emitting
> > >>>redundant parentheses for chains of || or &&, which would fix the
On this testcase, when strip_typedefs rebuilds a TYPENAME_TYPE to remove
the typedef, in this case it looks up the same typedef and we then abort
because we still have a typedef. In that case, strip the typedef
explicitly.
Tested x86_64-pc-linux-gnu, applying to trunk and 5.
commit 3f14013481
On Fri, Mar 04, 2016 at 05:01:34PM +0100, Martin Jambor wrote:
> Not in the limited runs that I experimented with so far, but I
> certainly kept this possibility in mind too. If so, I would either
> set it back before invoking dg-finish or dismiss the whole idea.
>
> > > However, the C++ and Fort
On 04/03/16 16:13, Bernd Schmidt wrote:
On 03/04/2016 03:27 PM, Patrick Palka wrote:
I still suggest to try making write_test_expr() avoid emitting
redundant parentheses for chains of || or &&, which would fix the
original issue all the same. Previously you claimed that such a
change would not
Hi,
On Fri, Mar 04, 2016 at 04:31:29PM +0100, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 04:27:11PM +0100, Martin Jambor wrote:
> > > Ah, ok; what about adding
> > > # Disable HSA warnings by default.
> > > lappend ALWAYS_CFLAGS "additional_flags=-Wno-hsa"
> > > in libgomp/testsuite/li
On Fri, Mar 04, 2016 at 04:13:41PM +0100, Bernd Schmidt wrote:
> On 03/04/2016 03:27 PM, Patrick Palka wrote:
> >>>I still suggest to try making write_test_expr() avoid emitting
> >>>redundant parentheses for chains of || or &&, which would fix the
> >>>original issue all the same. Previously you
On Fri, Mar 04, 2016 at 04:27:11PM +0100, Martin Jambor wrote:
> > Ah, ok; what about adding
> > # Disable HSA warnings by default.
> > lappend ALWAYS_CFLAGS "additional_flags=-Wno-hsa"
> > in libgomp/testsuite/lib/libgomp.exp (next to e.g.
> > -fno-diagnostics-show-caret)?
> >
>
> That w
On 02/03/16 09:38 -0800, Mike Stump wrote:
On Mar 2, 2016, at 2:08 AM, Maxim Kuvyrkov wrote:
PING ^ 2. The patch is sitting without comments for 4+ months.
So the libstdc++ people are usually pretty active and responsive, I usually let
them review these sorts of patches as domain experts.
Hi,
On Tue, Mar 01, 2016 at 11:06:43PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 01, 2016 at 10:47:46PM +0100, Martin Jambor wrote:
> > well, exactly what I wrote in the original email and what you have
> > quoted (and me as well) above. But let me quote the dejagnu source
> > comment of dg-runte
On 03/04/2016 03:27 PM, Patrick Palka wrote:
I still suggest to try making write_test_expr() avoid emitting
redundant parentheses for chains of || or &&, which would fix the
original issue all the same. Previously you claimed that such a
change would not be simpler than your current patch, but I
This is a fix for two testcases that show reload replacing pseudos
that don't get hard regs, with their equivalent mem initialization,
but failing to address the mem properly. The short story is that ira
analysis creates reg equivalence info for use by reload, based on
register lifetimes that are
On 03 Mar 21:17, Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 01:08:41PM +0100, Jakub Jelinek wrote:
> > Fixed thusly, unfortunately I don't have access to avx512f (and not even to
> > avx512dq) hw, so while I will bootstrap/regtest it on Haswell-E, can't test
> > the tests if they now work at ru
On Fri, 4 Mar 2016, David Malcolm wrote:
On Thu, 2016-03-03 at 17:36 -0500, Patrick Palka wrote:
On Thu, Mar 3, 2016 at 4:29 PM, Jesper Broge Jørgensen
wrote:
On 18/02/16 13:22, Bernd Schmidt wrote:
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
T
Hi Nick,
On 04/03/16 13:44, Nick Clifton wrote:
Hi Markus, Hi Richard,
PR 70044 reports a problem with the AArch64 backend. With LTO enabled
the function aarch64_override_options_after_change can be called more
than once for the same function. If only leaf frame pointers were
bein
Hi Markus, Hi Richard,
PR 70044 reports a problem with the AArch64 backend. With LTO enabled
the function aarch64_override_options_after_change can be called more
than once for the same function. If only leaf frame pointers were
being omitted originally, then the first call will set
fl
On Thu, 2016-03-03 at 17:36 -0500, Patrick Palka wrote:
> On Thu, Mar 3, 2016 at 4:29 PM, Jesper Broge Jørgensen
> wrote:
> >
> > On 18/02/16 13:22, Bernd Schmidt wrote:
> > >
> > > On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
> > > >
> > > > Here is the reformatted patch:
> > >
> > >
On Fri, Mar 04, 2016 at 02:27:46PM +0100, Richard Biener wrote:
> > +funknown-commons
> > +Common Var(flag_unknown_commons)
> > +Assume common declarations may be overridden with unknown larger sizes
>
> I think to make it work with LTO you need to mark it 'Optimization'.
> Also it's about
> array
On Thu, Feb 25, 2016 at 7:00 PM, Alan Lawrence wrote:
> On 22/02/16 12:03, Jakub Jelinek wrote:
>> (f) A global command-line option, which we check alongside DECL_COMMON and
>> further tests (basically, we want only DECL_COMMON decls that either have
>> ARRAY_TYPE, or some other aggregate type wit
Add support for nps400 bit operation instructions. There's a new flag
-mbitops that turns this feature on. There are new instructions, some
changes to existing instructions, a new register class to support the
new instructions, and some new expand and peephole optimisations.
gcc/ChangeLog:
Arrange to have the define __NPS400__ defined when compiling code for
Mellanox NPS400 ARC variant.
gcc/ChangeLog:
* conig/arc/arc.h (TARGET_CPU_CPP_BUILTINS): Add __NPS400__.
---
gcc/ChangeLog.NPS400 | 4
gcc/config/arc/arc.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/gc
This commit adds support for NPS400 cmem memory sections. Data to be
placed into cmem memory is placed into a section ".cmem",
".cmem_shared", or ".cmem_private".
There are restrictions on how instructions can be used to operate on
data held in cmem memory, this is reflected by the introduction o
When formatting 'L' operands (least significant word) only print
32-bits, don't sign extend to 64-bits.
This commit could really be applied directly to the current GCC trunk,
however, the only test I have for this issue right now relies on the
nps400 bitops support.
gcc/ChangeLog:
* conf
This test case triggered a bug caused by VOIDmode not being handled in
proper_comparison_operator, this problem was fixed with a commit on
2016-01-27 by Claudiu Zissulescu, adding this test case for coverage.
gcc/testsuite/ChangeLog:
* gcc.target/arc/nps400-1.c: New file.
---
gcc/testsui
New option for nps400 arc (-munaligned-access) that allows GCC to
generate unaligned accesses, the option is off by default. Turning this
option on will update the value for STRICT_ALIGNMENT.
gcc/ChangeLog:
* config/arc/arc.h (ARC_NPS400): Define if not already defined.
(UNALIGNE
The NPS400 is an ARC700 variant from Mellanox (formally EZChip).
This patch series adds a new GCC build target with the mellanox vendor
string, that configures the ARC backend to support NPS400.
This patch series is intended for GCC 7, Stage 1, once it reopens. I
am posting early in the hope tha
The define_memory_constraint allows for the address operand to be
reloaded into a base register. However, for the constraints 'Us<' and
'Us>', which are used for matching 'push' and 'pop' instructions moving
the address into a base register is not helpful. The constraints then
should be define_co
In the load*_update instructions the constraint 'rI' was being used,
which would accept either a register or a signed 12 bit constant. The
problem is that the 32-bit form of ld with update only takes a signed
9-bit immediate. As such, some ld instructions could be generated that
would, when assem
When code runs from section loaded into fast memory we do not want it to
use rodata section from a slow memory for any jump tables. This commit
turns on CASE_VECTOR_PC_RELATIVE by default for NPS400 targets, which in
turn turns on JUMP_TABLES_IN_TEXT_SECTION, which will place the jump
tables into
This commit adds support for the mellanox nps400 arc variant. Nothing
much actually changes with this commit other than adding support for
'arc*-mellanox-*' targets at configuration time.
I've added a new makefile fragment for the mellanox variant, right now
there's not much in here, I'll be addi
On Fri, Mar 04, 2016 at 02:12:33PM +0100, Marek Polacek wrote:
> Okay, so the following is the latest version. I extended the tests and I also
> changed the case for consecutive _Cilk_spawn keywords. And some whitespace
> fixes while at it.
>
> Bootstrapped/regtested on x86_64-linux, ok for trun
On Fri, Mar 04, 2016 at 07:41:10AM +0100, Jakub Jelinek wrote:
> On Thu, Mar 03, 2016 at 11:31:08PM -0700, Jeff Law wrote:
> > >2016-03-03 Marek Polacek
> > >
> > > PR c/69798
> > > * c-parser.c (c_parser_postfix_expression): Call
> > > c_parser_cast_expression instead of c_parser_postfix_
On Fri, Mar 04, 2016 at 01:53:20PM +0100, Bernd Schmidt wrote:
> On 03/03/2016 06:15 PM, Patrick Palka wrote:
> >Cool, this also fixes the false-positives seen in bdwgc, whose coding
> >style suggests indenting things inside an #ifdef as if it were an
> >if(), e.g.:
> >
> > if (a)
> > foo
On Thu, Mar 03, 2016 at 10:51:14PM -0700, Jeff Law wrote:
> On 03/03/2016 07:15 AM, Marek Polacek wrote:
> >This is ICE on invalid Cilk+ code. cilk_spawn expects a function call, so
> >e.g.
> >_Cilk_spawn (void) is invalid. The function call after the cilk_spawn
> >keyword
> >is parsed using re
On 03/03/2016 06:15 PM, Patrick Palka wrote:
Cool, this also fixes the false-positives seen in bdwgc, whose coding
style suggests indenting things inside an #ifdef as if it were an
if(), e.g.:
if (a)
foo ();
# ifndef A
bar ();
# endif
...
Once again I find myself th
On Thu, Mar 03, 2016 at 11:31:08PM -0700, Jeff Law wrote:
> Do we need to do anything for the call into c_parser_postfix_expression that
> occurs between the two you changed in this patch.
>
> I think you can get into that code with something like
>
> _Cilk_spawn _Cilk_spawn ());
Absolutely. Du
On Fri, Mar 4, 2016 at 12:07 PM, Bin Cheng wrote:
> Hi,
> A address canonicalization interface was introduced by my original patch to
> PR69052. The interface sorts sub-parts in an address expression based on
> precedences defined by function commutative_operand_precedence. It also
> assumes
On Wed, Mar 2, 2016 at 5:14 PM, Ilya Enkovich wrote:
> Hi,
>
> This patch fixes mask type determination for boolean values comparison. That
> avoid incorrect application of masks conversion pattern. Bootstrapped and
> tested on x86_64-pc-linux-gnu. OK for trunk?
Ok.
Richard.
> Thanks,
> Il
On Fri, Mar 04, 2016 at 07:27:51AM +0100, Jakub Jelinek wrote:
> The difference is that c_parser_cast_expression can parse (type)...,
> ++..., --..., &..., +..., -..., *..., ~..., !..., &&...,
> sizeof/alignof/__extension__/__real/__imag/__transaction_{atomic,relaxed}...
> Perhaps even safer versio
On Fri, Mar 4, 2016 at 12:11 PM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 11:42:34AM +0100, Uros Bizjak wrote:
>> On Fri, Mar 4, 2016 at 11:34 AM, Jakub Jelinek wrote:
>> > On Fri, Mar 04, 2016 at 11:16:44AM +0100, Uros Bizjak wrote:
>> >> On Fri, Mar 4, 2016 at 11:06 AM, Jakub Jelinek wro
On Fri, Mar 04, 2016 at 11:42:34AM +0100, Uros Bizjak wrote:
> On Fri, Mar 4, 2016 at 11:34 AM, Jakub Jelinek wrote:
> > On Fri, Mar 04, 2016 at 11:16:44AM +0100, Uros Bizjak wrote:
> >> On Fri, Mar 4, 2016 at 11:06 AM, Jakub Jelinek wrote:
> >> > On Fri, Mar 04, 2016 at 10:59:48AM +0100, Uros Bi
Hi,
A address canonicalization interface was introduced by my original patch to
PR69052. The interface sorts sub-parts in an address expression based on
precedences defined by function commutative_operand_precedence. It also
assumes that all CONST_INT sub-parts are at the end of vector after s
On Fri, Mar 04, 2016 at 12:02:59PM +0100, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 10:41:04AM +, Kyrill Tkachov wrote:
> > Can do. I've moved the dodgy functions into their own separate compile test.
> > The test passes.
> > Ok?
>
> LGTM.
OK from me too.
James
On Fri, Mar 04, 2016 at 10:41:04AM +, Kyrill Tkachov wrote:
> Can do. I've moved the dodgy functions into their own separate compile test.
> The test passes.
> Ok?
LGTM.
Jakub
On Fri, Mar 4, 2016 at 11:34 AM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 11:16:44AM +0100, Uros Bizjak wrote:
>> On Fri, Mar 4, 2016 at 11:06 AM, Jakub Jelinek wrote:
>> > On Fri, Mar 04, 2016 at 10:59:48AM +0100, Uros Bizjak wrote:
>> >> I don't like the fact that *dynamic_check is set to
On 02/03/16 16:17, Jakub Jelinek wrote:
On Tue, Mar 01, 2016 at 02:29:19PM +, Kyrill Tkachov wrote:
This test was reported as starting to fail a scan-assembler check with
-mtune=thunderx.
The compiler decided to move the result back into the integer registers and
perform the shift there
r
On Fri, Mar 04, 2016 at 11:16:44AM +0100, Uros Bizjak wrote:
> On Fri, Mar 4, 2016 at 11:06 AM, Jakub Jelinek wrote:
> > On Fri, Mar 04, 2016 at 10:59:48AM +0100, Uros Bizjak wrote:
> >> I don't like the fact that *dynamic_check is set to max (which is 0
> >> with your testcase) when recursion avo
On Fri, Mar 4, 2016 at 11:06 AM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 10:59:48AM +0100, Uros Bizjak wrote:
>> I don't like the fact that *dynamic_check is set to max (which is 0
>> with your testcase) when recursion avoidance code already set it to
>> "something reasonable", together wit
On Fri, Mar 04, 2016 at 10:59:48AM +0100, Uros Bizjak wrote:
> I don't like the fact that *dynamic_check is set to max (which is 0
> with your testcase) when recursion avoidance code already set it to
> "something reasonable", together with loop_1_byte alg. What do you
> think about attached (light
On Thu, Mar 3, 2016 at 9:16 PM, Jakub Jelinek wrote:
> Hi!
>
> Before my recent decide_alg change, *dynamic_check == -1 was indeed
> guaranteed, because any_alg_usable_p doesn't depend on the arguments of
> decide_alg that might change during recursive call, so we'd only recurse if
> it wouldn't s
1 - 100 of 104 matches
Mail list logo
