Hi,
what aout this?
Index: tree.c
===
--- tree.c (revision 230924)
+++ tree.c (working copy)
@@ -13424,6 +13424,12 @@ gimple_canonical_types_compatible_p (con
{
tree f1, f2;
+ /* Don't try to compare v
> > Actually I think it is harder than that, because we need to strip LTO data
> > from the object files, so we do not end up with duplicated LTO if the object
> > file was already having both LTO and non-LTO stuff in it.
>
> When I started with LTO I was looking into that, and that is why I origi
On Thu, Nov 26, 2015 at 02:55:04AM +0100, Jan Hubicka wrote:
> >
> > > I suppose we could play a games here with slim LTO: claim the file, see if
> > > there are any symbols defined in the non-LTO symbol table and if so,
> > > interpret
> > > read the symbol table and tell linker about the symbol
> > > In theory we could change the build system to avoid that case though, but
> > > it would need some changes.
> > >
> > > It would be better if that could be handled somehow.
> >
> > How does this work with your patchset? Ideally we should have way to claim
> > only portions of object files,
> > In theory we could change the build system to avoid that case though, but
> > it would need some changes.
> >
> > It would be better if that could be handled somehow.
>
> How does this work with your patchset? Ideally we should have way to claim
> only portions of object files, but we don't
> > Moreover we do have all infrastructure ready to implement 3). Our tree
> > merging
> > and symbol table handling is fuly incremental and I think made a patch to
> > implement it today. The scheme is easy:
>
> What happens when .S (assembler) files are part of the incremential object?
> Th
On systems that use select (basically, Solaris), the netpoll code in
libgo could sometimes fail to free an fd_set that it allocated. Over
time, this could cause the program to run out of memory. This patch
fixes that problem. It also skips an unnecessary call to read.
Bootstrapped and ran Go tes
> Moreover we do have all infrastructure ready to implement 3). Our tree
> merging
> and symbol table handling is fuly incremental and I think made a patch to
> implement it today. The scheme is easy:
What happens when .S (assembler) files are part of the incremential object?
The kernel does
> Your patch means that Andis/HJs work is no longer needed and we can
> drop the section suffixes again?
Doing that would break existing setups that do ld -r instead of gcc -r
Maybe longer term.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
Hi,
here is the patch that implement incremental LTO linking. I will wait few days
for feedback. gcc -r now does LTO IL linking only. To force codegen, one can
use -Wl,-rnolto which I found no right place to document. We may want -rnolto
flag uspported by GCC driver, so the testsuite can be upd
The patch adds close phi nodes to every outer loop exit, and to every loop
guard. For loop guards it computes an initial value that determines where we
stop inserting phi nodes. When the initial value is a constant, the initial
value is considered to be defined in the entry of the code gen region
Hi,
this is the first part of patch that adds -flinker-output flags and gets symbol
visibility right. It makes the testcase in the PR to pass, but I do not know
how to turn it into a testsuite ready version.
I remember there was other PRs related to incremental linking and symbol
visibility,
I wi
Paul
I've bootstrap and regression tested the patch on x86_64-*-freebsd.
I intend to do the same tonight on i386-*-freebsd. After that, I'll
go over the patch as you have done and then intend to commit it.
AFAICT, Tobias is busy with Real-Life (tm) (or taking a much
needed rest from gfortran hack
On Wed, 2015-11-25 at 11:55 +0100, Bernd Schmidt wrote:
> On 11/25/2015 03:26 AM, David Malcolm wrote:
> > Consider the case where an assumption that the host is little-endian
> > assumption creeps into one of the bitmap functions. Some time later,
> > another developer updates their working copy
On Thu, 2015-11-19 at 19:44 +0100, Bernd Schmidt wrote:
> On 11/19/2015 07:08 PM, David Malcolm wrote:
> > gcc_assert terminates the process and no further testing is done,
> > whereas the approach the kit tries to run as much of the testsuite as
> > possible, and then fail if any errors occurred.
Dear Alessandro and Tobias,
I have been through the patch to check for obvious bloopers but can
find none, as expected given the author :-)
I would dearly like to see the testcases at the same time as the patch
but I think that the commit should be made sooner, rather than
later. Given its na
PR 66147 points out that it doesn't work to build the gotools with a
cross-compiler. This patch improves matters. I added a new host
export to the top level Makefile. Build maintainers, does this change
seem OK?
Ian
./ChangeLog:
2015-11-25 Ian Lance Taylor
PR go/66147
* Makefile.tpl (HOST
> On 11/25/2015 02:10 PM, Jan Hubicka wrote:
> >>The problem here is that we're trying to compare the TYPE_FIELDS of
> >>two variants of an incomplete type, which doesn't make sense; we
> >>shouldn't expect TYPE_FIELDS of an incomplete type to be meaningful.
> >>
> >>Tested x86_64-pc-linux-gnu. OK
On 11/23/2015 02:23 AM, Thomas Schwinge wrote:
Would be nice to get rid of the two following UNRESOLVEDs:
{+PASS: g++.dg/init/self1.C -std=c++11 convert (test for errors, line
13)+}
[-PASS:-]{+UNRESOLVED:+} g++.dg/init/self1.C -std=c++11 [-execution
test-]{+compilation failed to pr
On 11/25/2015 02:10 PM, Jan Hubicka wrote:
The problem here is that we're trying to compare the TYPE_FIELDS of
two variants of an incomplete type, which doesn't make sense; we
shouldn't expect TYPE_FIELDS of an incomplete type to be meaningful.
Tested x86_64-pc-linux-gnu. OK for trunk?
commi
OK.
Jason
On 11/25/2015 02:21 PM, Jakub Jelinek wrote:
Thanks. Though, perhaps we could guard those new two stmts with
if (flag_sanitize & SANITIZE_UNDEFINED)
? No need to generate a useless attribute in the common case.
OK, sure.
commit 1c63a34b1d44cb6eb29e38c49660cb66c175c72b
Author: Jason Merri
It's not clear to me whether I should be passing in UNKNOWN_LOCATION
or input_location to the various functions.
cp_build_unary_op used input_location in various places internally,
so I've passed that in wherever there isn't a better value.
Rather than try to get this right now I'm inclined to
On Wed, 25 Nov 2015, Jakub Jelinek wrote:
The same is true whether we write it b > a or (a - b) > a (I don't think PRE
+ SCCVN avoid increasing register pressure).
So, I'd really prefer doing x-y>x to y>x only for single use.
Ok (for now).
Do you plan to work on that (my match.pd experienc
> The DWARF change is OK if the tree-nested.c changes make sense to Eric.
As discussed in the audit trail of the PR, I'd rather have avoided the
additional indirection, but the DWARF requirement seems to force it if we base
the computation on the static chain and I don't see another approach.
A
Changes from previous version:
- all new calls to protected_set_expr_location removed; instead
the location is passed into a tree-building function, using
the preceding patch.
- removal of #if 0 code
- generates meaningful ranges for new expressions, using
cp_lexer_previous_token.
- share
On Sat, 2015-11-21 at 02:16 -0500, Jason Merrill wrote:
> On 11/19/2015 03:46 PM, Jason Merrill wrote:
> > On 11/15/2015 12:01 AM, David Malcolm wrote:
> >> As with the C frontend, there's an issue with tree nodes that
> >> don't have locations: VAR_DECL, INTEGER_CST, etc:
> >>
> >>int test (in
This patch avoids the need for calls to protected_set_expr_location
in the followup patch by adding location_t params to the following
functions:
- build_new
- cp_build_indirect_ref
- cp_build_unary_op
- cp_build_c_cast
- cp_build_modify_expr
It's not clear to me whether I should be pass
On Wed, Nov 25, 2015 at 09:45:46AM -0500, Jason Merrill wrote:
> On 11/24/2015 04:01 PM, Jakub Jelinek wrote:
> >2) the downcast check is just DERIVED_FROM_P check, but my undestanding
> >of that is that DERIVED_FROM_P (x, x) is true too
>
> Yes, but you can use is_properly_derived_from instead.
>
Hi!
This patch adds a quick optimization for what I believe quite common case,
people mistakenly (because of laziness, lack of knowledge, ...) not using
firstprivate clauses for scalars not written in the body of omp
parallel/task regions. It handles only the easy cases, i.e. non-addressable
scal
Thank you for the feedback, PFA fixed patch.
Victoria
-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com]
Sent: Wednesday, November 25, 2015 11:32
To: gcc-patches@gcc.gnu.org
Cc: Stepanyan, Victoria; Kumar, Venkataramanan
Subject: Re: Add support for CLZERO ISA
Hello!
> 20
On Wed, Nov 25, 2015 at 2:31 AM, James Greenhalgh
wrote:
> On Tue, Nov 17, 2015 at 02:10:35PM -0800, Andrew Pinski wrote:
>>
>> Because the imp and parts are really integer rather than strings, this patch
>> moves the comparisons to be integer. Also allows saving around integers are
>> easier tha
On 25 November 2015 at 17:29, Alan Lawrence wrote:
> On 16/11/15 21:04, Doug Evans wrote:
>>
>> Hi.
>>
>> Apologies for the delay.
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440
>>
>> Tested with current trunk.
>>
>> 2015-11-16 Doug Evans
>>
>> PR libstdc++/67440
>> * python/li
On Wed, Nov 25, 2015 at 01:57:13PM -0500, Jason Merrill wrote:
> The _FUN function returned by the lambda conversion operator calls the op()
> with a null object argument, which would be undefined behavior for user
> code, but we can get away with it internally since it isn't observable.
> Tell UBs
> >
> > Your patch means that Andis/HJs work is no longer needed and we can
> > drop the section suffixes again?
> >
> >
>
> There is a difference between "ld -r " and "gcc -r". "ld -r" may not
> perform any LTO.
Theoretically ld -r may look up for the linker plugin on it search path that
will
i
> On Nov 25, 2015, at 9:24 AM, Alessandro Fanfarillo
> wrote:
>
> Dear all,
>
> in attachment the previous patch compatible with the current trunk.
> The patch also includes the changes introduced in the latest TS 18508.
>
> Built and regtested on x86_64-pc-linux-gnu.
>
> PS: I will add the
On November 25, 2015 3:33:47 PM GMT+01:00, Cesar Philippidis
wrote:
>On 10/20/2015 02:37 AM, Jakub Jelinek wrote:
>> On Fri, Oct 09, 2015 at 12:15:24PM +0200, Thomas Schwinge wrote:
>>> diff --git gcc/fortran/scanner.c gcc/fortran/scanner.c
>>> index bfb7d45..1e1ea84 100644
>>> --- gcc/fortran/sc
> The problem here is that we're trying to compare the TYPE_FIELDS of
> two variants of an incomplete type, which doesn't make sense; we
> shouldn't expect TYPE_FIELDS of an incomplete type to be meaningful.
>
> Tested x86_64-pc-linux-gnu. OK for trunk?
> commit c6f5cd55d0bbebc2fa46628ebb8fdec2a
On Wed, Nov 25, 2015 at 11:57 AM, Paolo Bonzini wrote:
> Patch committed to upstream libtool, thanks for your understanding.
Great!
How can I have the patch backported to GCC trunk and 5-branch libtool,
and then rebuild configure with the appropriate versions of autoconf?
I have not been able t
The _FUN function returned by the lambda conversion operator calls the
op() with a null object argument, which would be undefined behavior for
user code, but we can get away with it internally since it isn't
observable. Tell UBsan to ignore it.
Tested x86_64-pc-linux-gnu, applying to trunk an
On Wed, Nov 25, 2015 at 9:29 AM, Alan Lawrence wrote:
> On 16/11/15 21:04, Doug Evans wrote:
>>
>> Hi.
>>
>> Apologies for the delay.
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440
>>
>> Tested with current trunk.
>>
>> 2015-11-16 Doug Evans
>>
>> PR libstdc++/67440
>> * python
> >
> > 1) linker plugin is modified to pass -flinker-output to lto wrapper
> > linker-output is either dyn (.so), pie or exec
> > for incremental linking I added .rel for 3) and noltorel for 1)
> >
> > currently it does rel because 3) (nor 2) can not be done when
> > incremnetal
>
On 11/24/2015 04:17 AM, Pierre-Marie de Rodat wrote:
On 11/23/2015 10:08 PM, Jason Merrill wrote:
On 11/23/2015 08:53 AM, Pierre-Marie de Rodat wrote:
Do you think the other patches could make it before the branch? (if
they could, I will rebase+retest them as quick as possible).
Probably, ye
>
> Might be a bit expensive though. It also reminds me of all the
> ICEs we have PRs for WRT the type verifier. Remember we are in stage3
> now so rather than introducing new issues you should spend some time
> fixing the existing ones you caused ;)) (just look for bugs
> CCed to hubi...@gcc.g
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67954
The patch was bootstrapped on x86/x86-64. The test is too big and was
not included to the patch.
Committed as rev. 230893 to gcc-5 branch and as rev. 230894 to trunk.
Index: ChangeLog
==
The DWARF change is OK if the tree-nested.c changes make sense to Eric.
Jason
On 14/11/15 13:19, David Edelsohn wrote:
The copy_ctor_neg testcase fails on AIX.
Also on ARM and AArch64 platforms (arm-none-linux-gnueabihf, arm-none-eabi,
aarch64-none-linux-gnu, aarch64-none-elf), with similar error messages.
Thanks,
Alan
On 16/11/15 21:04, Doug Evans wrote:
Hi.
Apologies for the delay.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440
Tested with current trunk.
2015-11-16 Doug Evans
PR libstdc++/67440
* python/libstdcxx/v6/printers.py (find_type): Handle "const" in
type name.
* testsui
The PTX backend needs to create names for incoming parameters etc. It was
numbering these from 1, which apart from being mentally jarring, turns out is a
little awkward.
Fixed thusly.
nathan
2015-11-25 Nathan Sidwell
* config/nvptx/nvptx.md (load_arg_reg): Arg number
constraint is 'n'.
Hello!
> 2015-11-25 Victoria Stepanyan
>
> * common/config/i386/i386-common.c
> (OPTION_MASK_ISA_CLZERO_SET): New.
> (ix86_handle_option): Handle clzero.
>* config.gcc (i[34567]86-*-*): Add clzerointrin.h,
> (x86_64-*-*): Likewise.
> * config/i386/
Dear all,
in attachment the previous patch compatible with the current trunk.
The patch also includes the changes introduced in the latest TS 18508.
Built and regtested on x86_64-pc-linux-gnu.
PS: I will add the test cases in a different patch.
2015-04-29 9:55 GMT+02:00 Tobias Burnus :
> Dear a
On Wed, 25 Nov 2015, Stepanyan, Victoria wrote:
> --- gcc_original/gcc/doc/invoke.texi 2015-10-28 09:11:35.755612785 -0500
> +++ gcc-10-27-15/gcc/doc/invoke.texi 2015-10-28 05:04:32.543441760 -0500
> @@ -310,7 +310,7 @@
> -fsanitize=@var{style} -fsanitize-recover -fsanitize-recover=@var{style}
On Tue, Oct 27, 2015 at 01:21:51PM -0700, Richard Henderson wrote:
> The problem in this PR is that a word-mode subreg is used to write to a
> multi-word pseudo, under the assumption that is the correct way to insert a
> value into the appropriate bits of the pseudo.
>
> Except that the pseudo the
On Wed, 25 Nov 2015, Paolo Bonzini wrote:
> * doc/implement-c.texi (Integers Implementation): Make GCC's promises
> about signed left shift stronger and clarify the cases when they're
> broken.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 24/11/2015 16:57, David Edelsohn wrote:
> > > We plan to do a GCC 5.3 release candidate at the end of next week
> > > followed by the actual release a week after that.
> > >
> > > So now is the time to look at your regression bugs in bugzilla and
> > > do some backporting for things already fi
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Friday, September 18, 2015 3:25 PM
> To: Moore, Catherine; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: Re: [RFA] Compact EH Patch
>
> > Index: libgcc/libgcc-std.ver.in
> >
> ===
On Nov 25, 2015, at 2:55 AM, Bernd Schmidt wrote:
>> That would be the ideal - though do we require randomization
> What do you hope to gain with randomization?
Please, no randomization.
Bernd Schmidt writes:
> On 11/25/2015 05:19 PM, Richard Sandiford wrote:
>> I guess not, but without it we have both local and global variables
>> called which_alternative.
>
> So call the local ones something else (alt_to_check, requested_alt or
> attr_alt)?
Well, having two names for the same
On 11/25/2015 05:19 PM, Richard Sandiford wrote:
I guess not, but without it we have both local and global variables
called which_alternative.
So call the local ones something else (alt_to_check, requested_alt or
attr_alt)?
Bernd
Hi Maintainers,
This patch adds support for CLZERO instruction.
The ISA is enabled by new -mclzero option and is available for AMD znver1
target (-march=znver1).
Bootstrapped and retested.
gcc/ChangeLog:
2015-11-25 Victoria Stepanyan
* common/config/i386/i386-common.c
(OP
Bernd Schmidt writes:
> On 11/25/2015 01:26 PM, Richard Sandiford wrote:
>> Later patches in the series add a new form of attribute that takes the
>> attribute number as an argument, rather than it being stored in the
>> global which_alternative variable.
>>
>> Having both a local alternative numb
I'm reading up on this stuff, but I'm probably still not the best person
to review the actual frequency manipulation parts in this. There are a
few things I can comment on, however.
The first question would be, have you looked at the rebuild_frequencies
code in predict.c, and whether you can r
On 17/09/15 15:56 +0100, Jonathan Wakely wrote:
When exceptions are disabled a failed allocation while trying to
shrink_to_fit() will abort the program. Since shrink_to_fit() is a
non-binding request we should just ignore it rather than risk taking
down the whole process.
Tested powerpc64le-linu
Both are OK.
Jason
Hi,
On 11/25/2015 04:59 PM, Markus Trippelsdorf wrote:
Index: cp/constexpr.c
===
--- cp/constexpr.c (revision 230865)
+++ cp/constexpr.c (working copy)
@@ -1799,8 +1799,8 @@ cxx_eval_array_reference (const constexpr_ctx *c
Bernd Schmidt writes:
> On 11/25/2015 01:35 PM, Richard Sandiford wrote:
>> The define_subst support made it syntactically possible to add
>> attributes to a define_expand, but until now they had been ignored
>> by genattrtab.c. This patch allows define_expands to have
>> "code,alternative" attri
On 11/25/2015 01:26 PM, Richard Sandiford wrote:
Later patches in the series add a new form of attribute that takes the
attribute number as an argument, rather than it being stored in the
global which_alternative variable.
Having both a local alternative number and a global alternative number
is
On 2015.11.25 at 16:43 +0100, Paolo Carlini wrote:
> Hi,
>
> for this small 5/6 regression (an ICE) Markus suggests in the audit trail to
> protect the tree_to_shwi call with tree_fits_shwi_p. I tweaked a bit his
> suggestion adopting a pattern already used, eg, in the parser, and
> successfully t
Hi,
the patch below makes libgomp/testsuite/libgomp.c/target-28.c pass on
HSA, where it previously did not like the two static variables with
the same name. Committed to the branch.
Thanks,
Martin
2015-11-25 Martin Jambor
* hsa.c (hsa_get_declaration_name): Return ASM name for gl
Hi,
when looking at why target-12.c and target-24.c in
libgomp/testsuite/libgomp.c/, I found two other places in libgomp's
target.c where shared-memory devices ought to be treated like the
host. Committed to the branch.
Thanks,
Martin
2015-11-25 Martin Jambor
libgomp/
* target.c (
On 11/25/2015 01:35 PM, Richard Sandiford wrote:
The define_subst support made it syntactically possible to add
attributes to a define_expand, but until now they had been ignored
by genattrtab.c. This patch allows define_expands to have
"code,alternative" attributes but raises an error for gener
The problem here is that we're trying to compare the TYPE_FIELDS of two
variants of an incomplete type, which doesn't make sense; we shouldn't
expect TYPE_FIELDS of an incomplete type to be meaningful.
Tested x86_64-pc-linux-gnu. OK for trunk?
commit c6f5cd55d0bbebc2fa46628ebb8fdec2a44abf3a
Au
Hi,
On Wed, 25 Nov 2015, Bernd Schmidt wrote:
> So here's a very basic version which I think is appropriate for the
> current stage, and can be extended later. Ok if it passes testing?
When we're improving that place, we should really only consider ASMs that
change memory state to be problemat
I ran make check (paseed) and spec 2000, where 1 extra test(255.vortex) failed.
On Wed, Nov 25, 2015 at 6:41 PM, Aleksandra Tsvetkova
wrote:
> gcc/testsuite/ChangeLog
> 2015-10-27 Tsvetkova Alexandra
>
> * gcc.target/i386/mpx/memmove.c: New test for __mpx_wrapper_memmove.
>
> libmpx/Change
On 11/25/2015 04:00 PM, Jakub Jelinek wrote:
nonfreeing_call_p is one necessary condition (if that is true, it means
the call could mean that the first access does not trap while the second one
does).
But I agree that we need a predicate for nonbarrier_call_p or similar.
Some atomic builtins are
On Wed, Nov 25, 2015 at 3:15 AM, Richard Biener wrote:
> On Wed, 25 Nov 2015, Jan Hubicka wrote:
>
>> Hi,
>> PR 67548 is about LTO not supporting incremental linking. I never really
>> considered our current incremental linking very useful, because it triggers
>> code generation at the incrementa
Hi,
for this small 5/6 regression (an ICE) Markus suggests in the audit
trail to protect the tree_to_shwi call with tree_fits_shwi_p. I tweaked
a bit his suggestion adopting a pattern already used, eg, in the parser,
and successfully tested it in trunk. I suppose it could make sense to
also f
gcc/testsuite/ChangeLog
2015-10-27 Tsvetkova Alexandra
* gcc.target/i386/mpx/memmove.c: New test for __mpx_wrapper_memmove.
libmpx/ChangeLog
2015-10-28 Tsvetkova Alexandra
* mpxrt/Makefile.am (libmpx_la_LDFLAGS): Add -version-info option.
* libmpxwrap/Makefile.am (libmpx_la_LDF
On Mon, Nov 23, 2015 at 03:16:42PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 23, 2015 at 03:12:05PM +0100, Martin Jambor wrote:
> > +/* Thread routine to run a kernel asynchronously. */
> > +
> > +static void *
> > +run_kernel_asynchronously (void *thread_arg)
> > +{
> > + struct async_run_info *
On Wed, 25 Nov 2015, Jakub Jelinek wrote:
> But finding out if you have an expression on which c_fully_fold has been
> already called or not is non-trivial too.
The rule is that if the C front end needs to fold early for any reason
(e.g. for warnings) then the result of folding gets wrapped in a
Hi,
On Wed, 25 Nov 2015, Jakub Jelinek wrote:
> > That looks bogus to me. It misses asm()s and at least today
> > nonfreeing_call_p too much checks what it sounds like it checks. In
> > practice it might work though. At least all the __sync_* and
> > __atomic_* calls are _not_ barriers this
On 11/25/2015 03:54 PM, Kyrill Tkachov wrote:
And here it is.
This fixes the bug on arm and tests on arm look ok.
I've kicked off bootstraps and tests on arm, aarch64 and x86_64.
Ok for trunk if they come back clean?
Sure. Thanks! (Backport too.)
Bernd
Committed to placate the masses.
2015-11-25 Steven G. Kargl
PR fortran/68227
* trans-stmt.c (gfc_do_allocate): Convert gcc_assert argument into
into part of conditional statement.
Index: gcc/gcc/gcc/fortran/trans-stmt.c
=
On Wed, 25 Nov 2015, Marek Polacek wrote:
> On Wed, Nov 25, 2015 at 03:45:08PM +0100, Richard Biener wrote:
> > But the whole point of the SAVE_EXPR is that it does _not_ "duplicate" it,
> > it just creates another use of the same value.
>
> Of course, but when 'x' in that pattern doesn't have si
On 11/25/2015 03:52 PM, Dominik Vogt wrote:
Without looking into the details, I believe it's an optimization
to have certain frequently used members of the struct always on
the same cache line.
Probably better to annotate the global vars then with an alignment,
rather than waste space on the s
On Wed, Nov 25, 2015 at 03:52:10PM +0100, Richard Biener wrote:
> On Wed, Nov 25, 2015 at 2:18 PM, Michael Matz wrote:
> > Hi,
> >
> > On Wed, 25 Nov 2015, Richard Biener wrote:
> >
> >> I don't think so. Btw, if you want to add this please add a new gimple
> >> predicate to identify "memory barr
On Wed, Nov 25, 2015 at 03:56:39PM +0100, Richard Biener wrote:
> > c_gimplify_expr and SAVE_EXPR_RESOLVED_P would work as well I guess?
>
> Or simply not call fold () from convert () -> convert_to_integer ().
I was thinking about calling convert_to_integer_nofold in convert; that
fixed the testc
On Wed, Nov 25, 2015 at 03:45:08PM +0100, Richard Biener wrote:
> But the whole point of the SAVE_EXPR is that it does _not_ "duplicate" it,
> it just creates another use of the same value.
Of course, but when 'x' in that pattern doesn't have side-effects, it's not
wrapped in SAVE_EXPR and gets du
On Wed, 25 Nov 2015, Richard Biener wrote:
> On Wed, 25 Nov 2015, Jakub Jelinek wrote:
>
> > On Wed, Nov 25, 2015 at 03:35:10PM +0100, Marek Polacek wrote:
> > > Look how 'x' is duplicated in the result of the pattern, and since
> > > (because of
> > > the volatile 'e') it has TREE_SIDE_EFFECTS,
On Wed, 25 Nov 2015, Jakub Jelinek wrote:
> On Wed, Nov 25, 2015 at 03:35:10PM +0100, Marek Polacek wrote:
> > Look how 'x' is duplicated in the result of the pattern, and since (because
> > of
> > the volatile 'e') it has TREE_SIDE_EFFECTS, we need to wrap it in a
> > SAVE_EXPR,
> > which means
On 25/11/15 14:14, Kyrill Tkachov wrote:
On 25/11/15 14:12, Bernd Schmidt wrote:
On 11/25/2015 03:10 PM, Kyrill Tkachov wrote:
What should we do when we don't have STACK_GROWS_DOWNWARD? Do we need to
write:
if (STACK_GROWS_DOWNWARD)
i -= crtl->args.pretend_args_size;
else
i += crtl->ar
On Wed, Nov 25, 2015 at 02:31:38PM +0100, Bernd Schmidt wrote:
> On 11/25/2015 01:56 PM, Dominik Vogt wrote:
> >The attached patch fixes a warning during Linux kernel compilation
> >on S/390 due to -mwarn-dynamicstack and runtime alignment of stack
> >variables with constant size causing cfun->call
On Wed, Nov 25, 2015 at 2:18 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 25 Nov 2015, Richard Biener wrote:
>
>> I don't think so. Btw, if you want to add this please add a new gimple
>> predicate to identify "memory barrier" (any call or asm with a VDEF).
>
> if (is_gimple_call (stmt) && !no
On Wed, Nov 25, 2015 at 03:35:10PM +0100, Marek Polacek wrote:
> Look how 'x' is duplicated in the result of the pattern, and since (because of
> the volatile 'e') it has TREE_SIDE_EFFECTS, we need to wrap it in a SAVE_EXPR,
> which means the convert() produces
>
> (short int) (((SAVE_EXPR != 0 ?
On 11/24/2015 04:01 PM, Jakub Jelinek wrote:
2) the downcast check is just DERIVED_FROM_P check, but my undestanding
of that is that DERIVED_FROM_P (x, x) is true too
Yes, but you can use is_properly_derived_from instead.
With that change the first cast is OK for trunk and branch.
Jason
On Wed, 25 Nov 2015, Marek Polacek wrote:
> This is a bit tangled and I don't know how to best fix this so let me explain
> in more detail.
>
> The gist is that a C_MAYBE_CONST_EXPR leaks into the gimplifier.
>
> In the testcase, we have
>
> (short) ((i ? *e : 0) & ~u | i & u);
>
> where 'e'
This is a bit tangled and I don't know how to best fix this so let me explain
in more detail.
The gist is that a C_MAYBE_CONST_EXPR leaks into the gimplifier.
In the testcase, we have
(short) ((i ? *e : 0) & ~u | i & u);
where 'e' is a pointer to volatile. During c_parser_conditional_express
On 10/20/2015 02:37 AM, Jakub Jelinek wrote:
> On Fri, Oct 09, 2015 at 12:15:24PM +0200, Thomas Schwinge wrote:
>> diff --git gcc/fortran/scanner.c gcc/fortran/scanner.c
>> index bfb7d45..1e1ea84 100644
>> --- gcc/fortran/scanner.c
>> +++ gcc/fortran/scanner.c
>> @@ -935,6 +935,63 @@ skip_free_comm
SLP in GCC 6 is now way more aggressive in exploring opportunities
involving random permutations. This can end up bad with the
cost model telling us this vectorization is not profitable
(both due to bugs in the accounting and due to reality). But in
some cases at least the interleaving path is a
2015-11-24 23:04 GMT+03:00 Jeff Law :
> On 11/19/2015 09:06 AM, Ilya Enkovich wrote:
>>
>> On 19 Nov 16:46, Bernd Schmidt wrote:
>>>
>>> On 11/19/2015 03:28 PM, Ilya Enkovich wrote:
This is a refactoring patch discussed in another thread [1]. It gets
rid of CODE_FOR_nothing usage in
1 - 100 of 193 matches
Mail list logo
