Hi Julian!
On Thu, 7 May 2015 16:56:11 +0100, Julian Brown wrote:
> On Tue, 5 May 2015 16:09:18 +0200
> Thomas Schwinge wrote:
> > On Tue, 5 May 2015 08:43:48 -0400, John David Anglin
> > wrote:
> > > On 2015-05-05 5:43 AM, Thomas Schwinge wrote:
> > > >> FAIL: libgomp.oacc-c/../libgomp.oacc-c-
Hi,
On 8 May 2015 at 00:07, Joseph Myers wrote:
> On Mon, 20 Apr 2015, Pavel Kopyl wrote:
>
>> Hi all,
>>
>>
>> To build a GCC-4.9.2 ARM cross-compiler for my setting I need to configure it
>> with "--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.9.2".
>> But I found that gcc driver r
On May 21, 2015 12:13:19 AM GMT+02:00, Jan Hubicka wrote:
>Hi,
>this patch extends statistics from tree-ssa-alias to also cover TBAA
>oracle.
>This is useful to keep track of aliasing effectivity. For example the
>hack
>in alias.c putting globbing all pointers to one costs about 20% of all
>answe
This is another patch aimed at fixing bugs relating to trying to execute
NEON code on a target that doesn't support it revealed by my
arm-none-eabi testing on a gazillion different multilibs. Inspired by
what vect.exp does and my other patch in this group to fix
advsimd-intrinsics.exp, I've ha
On 05/20/2015 08:09 PM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* final.c (final_scan_insn): Don't check HAVE_peephole with the
preprocessor.
* output.h: Likewise.
* genconfig.c (main): Alwways define
find_split_point will tend to favor splitting complex insns in such a
way as to encourage multiply-add insns. It does this by splitting an
unrecognizable insn at the (plus (mult)).
Now that many MULTs are canonicalized as ASHIFT, that code to prefer the
multiply-add is no longer triggering
ARM testing shares the AArch64 advsimd-intrinsics execution tests. On
ARM, though, the NEON support being tested is optional -- some arches
are compatible with the NEON compilation options but hardware available
for testing might or might not be able to execute those instructions.
In arm-none-
On targets such as ARM, some arches are compatible with options needed
to enable compilation with vectorization, but the specific hardware (or
simulator or BSP) available for execution tests may not implement or
enable those features. The vect.exp test harness already includes some
magic to de
From: Trevor Saunders
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* final.c (final_scan_insn): Don't check HAVE_peephole with the
preprocessor.
* output.h: Likewise.
* genconfig.c (main): Alwways define HAVE_peephole.
* genpeep.c: Don't emit checks of HA
From: Trevor Saunders
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* *.c, *.h: DOn't check HAVE_conditional_move with the preprocessor.
---
gcc/ChangeLog | 4
gcc/combine.c | 5 ++---
gcc/expmed.c | 13 +
gcc/expr.c| 10 ++
gcc/optabs.c | 30 +++
From: Trevor Saunders
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* genconfig.c (main): Always define HAVE_conditional_move.
* *.c: Don't check if HAVE_conditional_move is defined.
---
gcc/ChangeLog | 4
gcc/combine.c | 2 +-
gcc/expmed.c | 4 ++--
gcc
From: Trevor Saunders
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* *.c: Remove comparison of ARG_FRAME_POINTER_REGNUM and
FRAME_POINTER_REGNUM with the preprocessor.
---
gcc/ChangeLog | 5 +
gcc/combine.c | 18 +++---
gcc/df-problems.c | 5 ++---
gcc
From: Trevor Saunders
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* defaults.h: Add default for STACK_PUSH_CODE.
* expr.c: Don't redefine STACK_PUSH_CODE.
* recog.c: Likewise.
---
gcc/ChangeLog | 6 ++
gcc/defaults.h | 8
gcc/expr.c | 8
gcc/
From: Trevor Saunders
gcc/c-family/ChangeLog:
2015-05-20 Trevor Saunders
* c-cppbuiltin.c (c_cpp_builtins): Check the value of
STACK_GROWS_DOWNWARD rather than if it is defined.
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* *.c: Check the value of STACK_GROWS_DOWN
From: Trevor Saunders
gcc/c-family/ChangeLog:
2015-05-20 Trevor Saunders
* c-cppbuiltin.c (c_cpp_builtins): Use if instead of #if with
STACK_GROWS_DOWNWARD.
gcc/ChangeLog:
2015-05-20 Trevor Saunders
* *.c: Use if instead of preprocessor checks with
STACK
From: Trevor Saunders
Hi,
Another week and more patches to remove conditional compilation ;-)
each patch individually bootstrapped + regtested on x86_64-unknown-linux-gnu,
and run through config-list.mk with a couple more patches I'll commit when I
finish writing ChangeLogs. Committing to trun
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > From: Steven Bosscher [mailto:stevenb@gmail.com]
> > Sent: Tuesday, May 19, 2015 7:21 PM
> >
> > Not OK.
> > This will break in move_invariants() when it looks at REGNO (inv->reg)
Older assemblers don't understand .abiversion, so I'm committing the
following as obvious to fix a problem Michael Meissner found when
building gcc for powerpc64-linux.
PR libgcc/66225
* config/rs6000/morestack.S: Remove ".abiversion 1".
Index: libgcc/config/rs6000/morestack.S
===
OK.
Jason
On Wed, May 20, 2015 at 3:53 PM, Hans-Peter Nilsson
wrote:
>> From: "H.J. Lu"
>> Date: Tue, 19 May 2015 21:20:46 +0200
>
>> This patch affects your target. Can you verify if it is OK on
>> your target?
>
> If you mean philosophically, it's ok when the general bits and
> direction are ok, but for
On 05/20/2015 07:32 AM, Jakub Jelinek wrote:
> For OpenMP/OpenACC, there is still lots of diagnostics emitted during
> gimplification and at the start of the omp lowering phases, so for
> diagnostics purposes you can consider them as part of a common layer for all
> the 3 FEs.
Thanks, that makes
Now that I know a bit more from Jakub & Yuri's comments, I don't think
we should be turning that flag on for all the targets in the testsuite.
I was primarily trying to avoid someone else having to go through the
same analysis and reach the same conclusion for another port. But I'm
less concern
GCC bootstraps with this patch.
On Wed, May 20, 2015 at 12:54 PM, Ian Lance Taylor wrote:
> This is OK if GCC bootstraps.
>
> Thanks.
>
> Ian
>
> On Wed, May 20, 2015 at 11:25 AM, Yunlian Jiang wrote:
>> I have the following change to make libiberty compile with _GNU_SOURCE
>> defined
>> and re
> From: "H.J. Lu"
> Date: Tue, 19 May 2015 21:20:46 +0200
> This patch affects your target. Can you verify if it is OK on
> your target?
If you mean philosophically, it's ok when the general bits and
direction are ok, but for the practical part of checking
e.g. for typos through compilation, pl
Perhaps I should've sent this to the java-patches list.
PING.
gcc/java/
* class.c: Remove pending_static_fields.
(add_field): Remove use of pending_static_fields.
(java_write_globals): Remove.
* decl.c (java_mark_class_local): Remove use of
pending_static_fields.
* java-tree.h: Remove pen
On 05/20/2015 06:16 PM, Joseph Myers wrote:
On Wed, 20 May 2015, Aldy Hernandez wrote:
Update for the c-family bits removing the flag_syntax_only part Jason
requested.
And BTW, ping for you C front-end maintainers (unless Jason is reviewing the C
bits, in which case the rest of you can sit bac
On Wed, 20 May 2015, Aldy Hernandez wrote:
> Update for the c-family bits removing the flag_syntax_only part Jason
> requested.
>
> And BTW, ping for you C front-end maintainers (unless Jason is reviewing the C
> bits, in which case the rest of you can sit back and look pretty).
The C front-end
Hi,
this patch extends statistics from tree-ssa-alias to also cover TBAA oracle.
This is useful to keep track of aliasing effectivity. For example the hack
in alias.c putting globbing all pointers to one costs about 20% of all
answers on firefox. I.e. from 15500978 disambiguations/23744267 querrie
On May 20, 2015, Jason Merrill wrote:
> I want to explicitly pass -std=c++98 to the compiler used in building
> stage 1. Does this seem like the right way to do that?
It certainly works, but I'm a bit concerned about its overriding the
earlier choices of STAGE1_CXXFLAGS, that use CXXFLAGS or ST
As described in PR target/63810, this addresses several problems with
the validation and encoding of deployment target version strings for the
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro. There are
currently four testcases exercising inputs to -mmacosx-version-min
(gcc/testsuite/gcc.dg/da
On 05/20/2015 05:01 PM, Jan Hubicka wrote:
commit 8824b5ecba26cef065e47b34609c72677c3c36fc
Author: Aldy Hernandez
Date: Wed May 20 16:31:14 2015 -0400
Set DECL_IGNORED_P on temporary arrays created in the switch
conversion pass.
diff --git a/gcc/tree-switch-conversion.c b/gcc/tree
Update for the c-family bits removing the flag_syntax_only part Jason
requested.
And BTW, ping for you C front-end maintainers (unless Jason is reviewing
the C bits, in which case the rest of you can sit back and look pretty).
Aldy
gcc/c-family/
* c-common.h (c_parse_final_cleanups): New pr
On 05/20/2015 03:18 PM, Jason Merrill wrote:
On 05/08/2015 09:14 PM, Aldy Hernandez wrote:
+ if (!flag_syntax_only)
+c_parse_final_cleanups ();
The condition is a significant change of behavior for the C++ front end;
doing final instantiation and such even with -fsyntax-only was a
deliber
register_specialization complains about a specialization in a different
namespace from the main template; we shouldn't give that error about an
instantiation of a partial specialization. And we were about to
SET_DECL_IMPLICIT_INSTANTIATION anyway, so let's just do that before we
call register_
I noticed that -Wc++14-compat was warning about headers that had been
updated to include a declaration of a global sized operator delete.
This was intended to catch problematic placement deletes, but now I
think that C++14 headers that just don't bother to guard the declaration
with a C++14 #if
This is the first in a series of patches to fix the fallout from recent
combiner changes in how shift-add style insns are canonicalized.
This patch effectively just adds a new shift-add insn to the PA port.
The old shift-add insn stays for now, but will be removed in a follow-up
once I'm con
On Tue, 19 May 2015, H.J. Lu wrote:
> Here is the complete patch. Tested on Linux/x86-64. It is also
> available on hjl/pie/master branch in git mirror.
OK a week after you CC all relevant target maintainers on the patch, in
the absence of objections from those target maintainers.
--
Joseph
>
> commit 8824b5ecba26cef065e47b34609c72677c3c36fc
> Author: Aldy Hernandez
> Date: Wed May 20 16:31:14 2015 -0400
>
> Set DECL_IGNORED_P on temporary arrays created in the switch
> conversion pass.
>
> diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
> index
How does this version, which has been committed to the debug-early
branch, look?
One more thing Richi. I merged trunk into the branch once again, and Go
broke. I tracked it down to a temporary that was being created late
that IMO shouldn't even get debug info.
The fact that it gets creat
On 05/20/2015 11:05 AM, David Malcolm wrote:
This patch fixes the false positive seen from -Wmisleading-indentation
on this code:
if (v == 2)
{
res = 27;
} else
{
res = 18;
}
return res;
^ FALSE POSITIVE HERE
along with similar code seen when
On 05/20/2015 11:04 AM, Andreas Tobler wrote:
Hi,
the attached patch enables some PIE tests on FreeBSD.
Ok for trunk?
Thanks,
Andreas
2015-05-20 Andreas Tobler
* gcc.target/i386/pr32219-1.c: Enable test on FreeBSD.
* gcc.target/i386/pr32219-2.c: Likewise.
* gcc.target/i386/
On 20.05.15 21:49, John Marino wrote:
I have maintained unwind support for FreeBSD i386 and x86_64 in my
"gnat-aux" repository for many years (I created it). I've always
intended on contributing it back to GCC, but I never got around to
"proving" it worked until now.
The version I've been using
On Wed, 20 May 2015, Alex Velenko wrote:
> Hi,
>
> This patch limits testcase split-live-ranges-for-shrink-wrap.c runs to
> supported achitecture versions.
> Object size with -march=armv4t check fails because pop pc is not interworking
> safe on armv4t.
> This test is not supported for -march=arm
On Wed, 20 May 2015, Alex Velenko wrote:
> Hi,
>
> This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c
> testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed.
arm_thumb1_ok means "this is an ARM target where -mthumb causes Thumb-1 to
be used". It only eve
This is OK if GCC bootstraps.
Thanks.
Ian
On Wed, May 20, 2015 at 11:25 AM, Yunlian Jiang wrote:
> I have the following change to make libiberty compile with _GNU_SOURCE defined
> and remove the declaration of asprintf in libiberty.h if
> HAVE_DECL_ASPRINTF is not
> defined.
>
> diff --git a/in
I have maintained unwind support for FreeBSD i386 and x86_64 in my
"gnat-aux" repository for many years (I created it). I've always
intended on contributing it back to GCC, but I never got around to
"proving" it worked until now.
The version I've been using actually has two flavors: FreeBSD 8 and
On 05/20/2015 12:28 AM, Jeff Law wrote:
> Yes, this is OK for the trunk. Please commit.
>
> jeff
Applied to trunk (revision 223454).
--
Regards,
Mikhail Maltsev
On 20/05/2015 12:19, Jonathan Wakely wrote:
On 20/05/15 11:17 +0100, Jonathan Wakely wrote:
On 04/05/15 22:31 +0200, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/h
On 05/08/2015 09:14 PM, Aldy Hernandez wrote:
+ if (!flag_syntax_only)
+c_parse_final_cleanups ();
The condition is a significant change of behavior for the C++ front end;
doing final instantiation and such even with -fsyntax-only was a
deliberate choice. Can we drop the condition?
+
On Wed, May 20, 2015 at 7:36 PM, augustine.sterl...@gmail.com
wrote:
> On Tue, May 19, 2015 at 8:31 PM, Max Filippov wrote:
>> 2015-05-20 Max Filippov
>> gcc/
>> * config/xtensa/xtensa.c (init_alignment_context): Replace MULT
>> by BITS_PER_UNIT with ASHIFT by exact_log2 (BITS_
The current definition of _GLIBC_READ_MEM_BARRIER in libstdc++ is too
weak for an ACQUIRE FENCE, which is what it is intended to be. The
original code emitted an "isync" instead of "lwsync".
All of the guard acquire and set code needs to be cleaned up to use
GCC atomic intrinsics, but this is nece
Hi,
This patch limits testcase split-live-ranges-for-shrink-wrap.c runs to
supported achitecture versions.
Object size with -march=armv4t check fails because pop pc is not interworking
safe on armv4t.
This test is not supported for -march=armv7 as this test is for thumb1.
Is patch ok?
gcc/testsu
I have the following change to make libiberty compile with _GNU_SOURCE defined
and remove the declaration of asprintf in libiberty.h if
HAVE_DECL_ASPRINTF is not
defined.
diff --git a/include/libiberty.h b/include/libiberty.h
index b33dd65..8e096a0 100644
--- a/include/libiberty.h
+++ b/include/li
Hi,
This patch prevents arm_thumb1_ok XPASS in sibcall-3.c and sibcall-4.c
testcases. Sibcalls are not ok for Thumb1 and testcases need to be fixed.
Is patch ok?
gcc/testsuite
2015-05-20 Alex Velenko
* gcc.dg/sibcall-3.c (dg-skip-if): Skip if arm_thumb1_ok.
* gcc.dg/sibcall-
On 15/05/15 19:37 +0100, Jonathan Wakely wrote:
Testing revealed a few bugs in how I handled paths that don't exist.
The new __gnu_test::nonexistent_path() function is a bit hacky but
should be good enough for the testsuite.
This makes it even hackier but avoids linker warnings for using the
ev
On 05/20/2015 09:21 AM, Jeff Law wrote:
> What I don't see is any way to know if the target supports asm flag outputs.
> Are we expecting the kernel folks to do some kind of test then enable/disable
> based on the result?
I'd forgotten that we'd talked about a cpp symbol.
I'll add that.
r~
I want to explicitly pass -std=c++98 to the compiler used in building
stage 1. Does this seem like the right way to do that?
Tested x86_64-pc-linux-gnu.
commit 97e77ef17e558cdb6d26d440e691fea710e2a2dc
Author: Jason Merrill
Date: Mon May 18 23:58:41 2015 -0400
* configure.ac: Add -std=c
As discussed in the thread starting at
https://gcc.gnu.org/ml/libstdc++/2014-05/msg00027.html when
__make_move_if_noexcept_iterator decides not to move it returns a
mutable iterator, which can then result in the wrong constructor being
used. This ensures that when not moving we will get a pointer-
Hi,
the attached patch enables some PIE tests on FreeBSD.
Ok for trunk?
Thanks,
Andreas
2015-05-20 Andreas Tobler
* gcc.target/i386/pr32219-1.c: Enable test on FreeBSD.
* gcc.target/i386/pr32219-2.c: Likewise.
* gcc.target/i386/pr32219-3.c: Likewise.
* gcc.t
This patch fixes the false positive seen from -Wmisleading-indentation
on this code:
if (v == 2)
{
res = 27;
} else
{
res = 18;
}
return res;
^ FALSE POSITIVE HERE
along with similar code seen when I tested it with linux-4.0.3.
The patch adds a reject
On Wed, May 20, 2015 at 10:36:25AM -0600, Jeff Law wrote:
>
> These fix the remaining leaks in the threader that I'm aware of. We failed
> to properly clean-up when we had to cancel certain jump threading
> opportunities. So thankfully this wasn't a big leak.
>
> Bootstrapped and regression tes
These fix the remaining leaks in the threader that I'm aware of. We
failed to properly clean-up when we had to cancel certain jump threading
opportunities. So thankfully this wasn't a big leak.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on the trunk.
Jeff
d
On Tue, May 19, 2015 at 8:31 PM, Max Filippov wrote:
> 2015-05-20 Max Filippov
> gcc/
> * config/xtensa/xtensa.c (init_alignment_context): Replace MULT
> by BITS_PER_UNIT with ASHIFT by exact_log2 (BITS_PER_UNIT).
Approved, please apply.
Well, these kinds of asm are inherently target specific, but I did already ask
for a cpp symbol to indicate this faculty us available.
On May 20, 2015 9:21:07 AM PDT, Jeff Law wrote:
>On 05/15/2015 09:37 AM, Richard Henderson wrote:
>> Version 2 includes proper test cases and documentation.
>> H
On 05/15/2015 09:37 AM, Richard Henderson wrote:
Version 2 includes proper test cases and documentation.
Hopefully the documentation even makes sense. Suggestions
and improvements there gratefully appreciated.
r~
---
gcc/config/i386/constraints.md | 5 ++
gcc/config/i386/i386.
On 05/20/2015 10:08 AM, Manuel López-Ibáñez wrote:
I don't particularly like file scoped "offset_is_invalid" variable. It
appears that it's only set within check_format_arg, but it's used from a
variety of other locations via location_from_offset. Given the current
structure of the code, alte
On 20 May 2015 at 15:33, Jeff Law wrote:
> So if I'm understanding the situation correctly, with this new version
> behaviour for non-concatenated tokens is preserved which was the only
> behaviour regression in the prior patch, right?
The new version will also handle most escape sequences correc
On 04/20/2015 04:32 PM, Martin Sebor wrote:
I also wonder if other targets need -fasynchronous-unwind-tables and
whether or not we should just add it unconditionally.
I initially only tested powerpc64* and x86_64. I had tried s370
but asan doesn't appear to be built there (is it not supported?)
It seems I made an off-by-one error in my last patch for multiple
locations. This only affected the position of the caret character,
which we don't test (since the testsuite uses
-fno-diagnostics-show-caret). Fixed thusly and added a comment to
remind me and others that locations start at 1, but we
Anytime go code built with gccgo is linked against libraries
built with gcc (without split stack) there could be mixing of split stack
and non split stack code. I think that will be a common case.
My understanding is that if you don't use the gold linker in these
cases, it is possible that the a
On 05/20/2015 09:43 AM, David Malcolm wrote:
Add various new tests to Wmisleading-indentation.c:
* Ensure that users can use pragma to turn off
-Wmisleading-indentation for a range of code.
* Add functions demonstrating a variety of indentation styles
seen:
(a) on http:/
Add various new tests to Wmisleading-indentation.c:
* Ensure that users can use pragma to turn off
-Wmisleading-indentation for a range of code.
* Add functions demonstrating a variety of indentation styles
seen:
(a) on http://en.wikipedia.org/wiki/Indent_style
(b) via t
On 05/02/2015 04:16 PM, Ed Smith-Rowland wrote:
This extends' static assert to not require a message string.
I elected to make this work also for C++11 and C++14 and warn only with
-pedantic.
I think many people just write
static_assert(thing, "");
.
I took the path of building an empty strin
Hi all,
Mikael, thanks for the review. Committed as r223445 (without the else-branch).
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 22
On 05/11/2015 02:01 PM, Jason Merrill wrote:
On 05/11/2015 12:57 PM, Jason Merrill wrote:
On 05/11/2015 08:03 AM, Manuel López-Ibáñez wrote:
My preference would be to replace the static with a pointer and
placement-new with proper new and delete
Actually, on second thought, there really doesn
> > I bootstrapped/regtested on x86_64-linux the patch bellow. If it will work
> > for Firefox and Chrome I will go ahead with it at least temporarily.
>
> Really? This introduced a LTO failure in the gnat.dg testsuite:
>
> FAIL: gnat.dg/lto8.adb (internal compiler error)
> FAIL: gnat.dg/lto8.ad
On Wed, May 20, 2015 at 07:17:35AM -0700, Cesar Philippidis wrote:
> > ..., and this: why not do such nesting checking in
> > gcc/omp-low.c:check_omp_nesting_restrictions? Currently (changed by
> > Bernd in internal r442824, 2014-11-29) we're allowing all
> > OpenACC-inside-OpenACC nesting -- shou
Hi,
On Wed, 20 May 2015, Rich Felker wrote:
> > of a win that often, outside toy examples. Sure, the compiler can hoist
> > function addresses trivially, but I think it will lead to spilling more
> > often than not, or alternatively the hoisting will be undone by the
> > register allocators r
On 05/20/2015 01:23 AM, Thomas Schwinge wrote:
>> I included two new test cases in this patch. They are mostly identical
>> but, unfortunately, the c and c++ front ends emit slightly different
>> error messages.
>
> The preference is to keep these as single files (so that C and C++ can
> easily b
On Wed, May 20, 2015 at 02:10:41PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Richard Henderson wrote:
>
> > It is. The relaxation that HJ is working on requires that the reads
> > from the got not be hoisted. I'm not especially convinced that what
> > he's working on is a win.
Hi,
Someone privately pointed out that the ARM and AArch64 ports do not
define TARGET_RELAXED_ORDERING given that the architecture(s) mandates a
weak memory model. This patch fixes it for AArch64, the ARM patch
follows in due course after appropriate testing.
I will also note that we can de
Hi All,
Here is updated patch to optimize mask stores. The main goal of it is
to avoid execution of mask store if its mask is zero vector since
loads that follow it can be blocked.
The following changes were done:
1. A test on sink legality was added - it simply prohibits to cross
statements wi
On 05/20/2015 02:39 PM, Jakub Jelinek wrote:
On Wed, May 20, 2015 at 02:01:44PM +0200, Bernd Schmidt wrote:
To implement OpenACC vector-single mode, we need to ensure that only one
thread out of the group representing a worker executes. The others skip
computations but follow along the CFG, so t
On 18/05/15 11:32, Richard Biener wrote:
On Wed, May 13, 2015 at 5:33 PM, Kyrill Tkachov
wrote:
Hi Richard,
On 13/05/15 12:27, Richard Biener wrote:
I notice that we don't have a testuite check that the target has
a hw sqrt instructions. Would you like me to add one? Or can I make
the testc
On 05/20/2015 02:15 AM, Manuel López-Ibáñez wrote:
This is a new version of the patch submitted here:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html
but handling (some) escape sequences.
I could not figure out a way to re-use the code from libcpp for this,
thus I implemented a simple
> Date: Wed, 20 May 2015 11:11:52 +0200
> Subject: Re: Refactor gimple_expr_type
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tbsau...@tbsaunde.org; gcc-patches@gcc.gnu.org
>
> On Tue, May 19, 2015 at 6:50 PM, Aditya K wrote:
>>
>>
>>
On Wed, May 20, 2015 at 09:02:40AM -0400, David Edelsohn wrote:
> On Tue, May 19, 2015 at 9:09 PM, Alan Modra wrote:
> > On Mon, May 18, 2015 at 02:05:59PM -0400, David Edelsohn wrote:
> >> On Sun, May 17, 2015 at 10:54 PM, Alan Modra wrote:
> >> > This patch changes rs6000_stack_info to keep sav
Le 20/05/2015 10:24, Andre Vehreschild a écrit :
> Hi Mikael,
>
> when I got you right on IRC, then you proposed this change about the pointer
> attribute:
>
> diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
> index 6d565ae..545f778 100644
> --- a/gcc/fortran/trans-stmt.c
> +++ b
On 20 May 2015 at 18:18, Richard Biener wrote:
> On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
>
>> On 20 May 2015 at 17:01, Richard Biener wrote:
>> > On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
>> >
>> >> On 20 May 2015 at 16:17, Prathamesh Kulkarni
>> >> wrote:
>> >> > Hi,
>> >> > This
On 05/20/2015 01:19 AM, Christian Bruel wrote:
Hi,
Could a global reviewer have a look at the c-family part ?, this is
blocking for the TARGET_CPU_CPP_BUILTINS macro redefinition in C (arm
but probably others)
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01185.html
The c-family bits are OK. S
On Tue, May 19, 2015 at 9:09 PM, Alan Modra wrote:
> On Mon, May 18, 2015 at 02:05:59PM -0400, David Edelsohn wrote:
>> On Sun, May 17, 2015 at 10:54 PM, Alan Modra wrote:
>> > This patch changes rs6000_stack_info to keep save areas offsets even
>> > when not used. I need lr_save_offset valid fo
Current IRA still use both target macros in a few places.
Tell IRA to use the order we defined rather than with it's own cost
calculation. Allocate caller saved first, then callee saved.
This is especially useful for LR/x30, as it's free to allocate and is
pure caller saved when used in leaf func
On Wed, May 20, 2015 at 8:13 AM, Lynn A. Boger
wrote:
>
>
> On 05/19/2015 07:52 PM, Alan Modra wrote:
>>
>> On Tue, May 19, 2015 at 07:40:15AM -0500, Lynn A. Boger wrote:
>>>
>>> Questions on the use of the options for split stack:
>>>
>>> - The way this is implemented, split stack is generated if
On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
> On 20 May 2015 at 17:01, Richard Biener wrote:
> > On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
> >
> >> On 20 May 2015 at 16:17, Prathamesh Kulkarni
> >> wrote:
> >> > Hi,
> >> > This patch rejects expanding operator-list to implicit 'for'.
>
On Wed, May 20, 2015 at 02:01:44PM +0200, Bernd Schmidt wrote:
> To implement OpenACC vector-single mode, we need to ensure that only one
> thread out of the group representing a worker executes. The others skip
> computations but follow along the CFG, so the results of conditional branch
> decisio
On Wed, May 20, 2015 at 5:10 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Richard Henderson wrote:
>
>> It is. The relaxation that HJ is working on requires that the reads
>> from the got not be hoisted. I'm not especially convinced that what
>> he's working on is a win.
>>
>> With LTO
This adds functionality to the nvptx backend to emit uni-directional
branches. The idea is to recognize the previously introduced
warp-broadcast pattern; we know that its result is constant across an
entire warp of threads, so any value based on that result has the same
property. If a jump cond
On 05/19/2015 07:52 PM, Alan Modra wrote:
On Tue, May 19, 2015 at 07:40:15AM -0500, Lynn A. Boger wrote:
Questions on the use of the options for split stack:
- The way this is implemented, split stack is generated if the
target platform supports split stack, on ppc64/ppc64le as well
as on x86
Hi,
On Tue, 19 May 2015, Richard Henderson wrote:
> It is. The relaxation that HJ is working on requires that the reads
> from the got not be hoisted. I'm not especially convinced that what
> he's working on is a win.
>
> With LTO, the compiler can do the same job that he's attempting in the
On 20 May 2015 at 17:01, Richard Biener wrote:
> On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
>
>> On 20 May 2015 at 16:17, Prathamesh Kulkarni
>> wrote:
>> > Hi,
>> > This patch rejects expanding operator-list to implicit 'for'.
>> On second thoughts, should we reject expansion of operator-li
1 - 100 of 136 matches
Mail list logo
