This also fails on powerpc.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Fri, Jun 19, 2015 at 6:35 PM, Bill Schmidt
wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 demonstrates that we
> fail to match vector predicates with pseudos that are in the virtual
> stack register range. The reduced test case provided with the bug
> report, when compiled
On 19.06.2015 19:35, Jason Merrill wrote:
> OK, thanks.
>
> Sorry this took so long to review; please feel free to ping me every week.
>
> Jason
I added the testcase from PR66467, bootstrapped and regtested on
x86_64-linux. The final variant is attached. I applied it to trunk.
I see that versio
Hi.
In current implementation we avoid giving "logical and/or of equal
expressions" warning for literal constant operands. The attached patch
fixes the check to make it treat const-qualified VAR_DECLs with constant
initializers the same way.
Bootstrapped and regtested on x86_64-linux. OK for trunk
I've committed the attached patch to fix PR target/66591 which is
an ice-on-valid-code with -mlra.
SH has only one register in INDEX_REGISTER_CLASS and if the index
term of a memory address is a subreg of DImode register, LRA can't
find appropriate hardware registers in the problematic situation.
I
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 demonstrates that we
fail to match vector predicates with pseudos that are in the virtual
stack register range. The reduced test case provided with the bug
report, when compiled for the C++14 standard, demonstrates that we need
to be able to
Given that a mapped variable in 4.1 can have different kinds across nested data
regions, we need to store map-type not only for each var, but also for each
structured mapping. Here is my WIP patch, is it sane? :)
Attached testcase works OK on the device with non-shared memory.
diff --git a/inclu
> Yes, something like that.
Thanks, installed on the branch.
--
Eric Botcazou
After the merge of the debug-early branch, the Ada compiler now sets the
DECL_ARTIFICIAL and DECL_IGNORED_P flags too late for them to be taken into
account by the debug back-end.
Only for variables actually. In fact the current state of affairs is a bit
convoluted: for types, we set DECL_ARTI
After the merge of the debug-early branch, the Ada compiler now issues
warnings about unused global declarations (check_global_declaration is now
invoked in Ada too). That's undesirable, since the front-end proper already
does it and its messages are superior.
Tested on x86_64-suse-linux, appl
On Fri, 19 Jun 2015, Eric Botcazou wrote:
> This adjusts the type adjustment code for array components in the C and C++
> front-ends as per Joseph's remark, fixes a couple of documentation glitches
> and adds 3 more testcases following Richard's questions.
>
> Joseph, is that what you had in mi
Functions that return a discriminated record types with default discriminant
are handled specially, in the sense that the caller and the callee don't see
the same size for the return value (the former seeing the larger one). The
attached patch makes a couple of adjustments to this support.
Tes
When we set the size and precision of nullptr_t we forgot to set the
alignment, so we end up with unaligned accesses that cause problems on
some targets. The ABI has now been clarified to specify the alignment.
My question is what to do about this for GCC 5.2. This is currently
breaking thin
Hi,
hsa_spill_out appends two HSA instructions after another one and is
not the last function that is going to do that, so I factored that
code out. I also updated the comment to fit reality. Conversly for
hsa_insert_insn_before and hsa_spill_in.
Martin
2015-06-19 Martin Jambor
* h
Hi,
hsa_type_float_p is another function that we had implemented twice on
the HSA branch, unified thusly.
Martin
2015-06-19 Martin Jambor
* hsa-brig.c (float_type_p): Moved from here...
* hsa-gen.c (hsa_type_float_p): ...and here...
* hsa.c (hsa_type_float_p): ...to h
Hi,
I've run comments through spell-checker, added a few missing comments
and also fixed some other coding-style errors such as lines exceeding
80 characters.
Martin
2015-06-19 Martin Jambor
* hsa.h: Fixed spelling and coding style errors, added missing
comments.
* hs
Hi,
sanitize_hsa_name attracted my attention because it had no comment but
then I found out we had two copies of the function in two different
files. So I moved the definition to hsa.c.
Martin
2015-06-19 Martin Jambor
* hsa.c (hsa_sanitize_name): Moved here from...
* hsa-gen
Hi,
the following patch is a cleanup of hsa_get_segment_addr_type which
should not attempt to handle arrays in any way. While doing that, I
also bit the bullet and extended hsa_type_for_tree_type so that it is
able to create aggregate HSA symbols. Both records and arrays are
represented as array
Hi,
except for one use, from bittype_for_type was used as a poor-man's
type size function. That is confusing, so I added a real type size
function. The new implementation of hsa_bittype_for_type then uses
that as its basis too.
Martin
2015-06-18 Martin Jambor
* hsa.c (hsa_type_bit_
Hi,
Some functionality does not belong neither to hsa-gen.c not to
hsa-brig.c and there is enough of it to warrant a separate file. This
is the initial movement of such things to a new file hsa.c.
Martin
2015-06-18 Martin Jambor
* hsa.c: New file.
* Makefile.in (OBJS): Add h
When we're determining the exception-specification of a defaulted dtor,
we need to look at the NSDMIs. During this process we set
cp_unevaluated_operand. But having that set during instantiation of the
lambda breaks things. So let's clear it like we do in other places.
The one tricky bit is
On 18 June 2014 at 11:06, Ramana Radhakrishnan
wrote:
> On Tue, Jun 17, 2014 at 4:03 PM, Charles Baylis
> wrote:
>> Your mention of larger vector modes prompted me to check that the
>> patch has the desired result with them. In fact, the costs are
>> estimated incorrectly which means the post_mod
Here, in template substitution we were calling process_outer_var_ref for
both references to the outer variable without doing a name lookup to see
if there is a local binding. If we add the local capture to
local_specializations, we will find that when we come to the second
reference.
Tested
We need to deal with the case of an empty STATEMENT_LIST.
Tested x86_64-pc-linux-gnu, applying to trunk and 5.
commit 8d83ff350b98c5bce1ed99db7e9fcdd3aa818f08
Author: Jason Merrill
Date: Fri Jun 19 10:48:32 2015 -0400
PR c++/65973
* constexpr.c (build_constexpr_constructor_member_in
In this case merge_types was applying type quals to a POINTER_TYPE and
then build_ptrmemfunc_type stripped them. build_ptrmemfunc_type
shouldn't assume that DECL_LANG_SPECIFIC is different between
cv-variants of a type.
Tested x86_64-pc-linux-gnu, applying to trunk. Applying decl.c hunk to 5
Jeff Law wrote:
On 05/22/2015 09:42 AM, Alan Lawrence wrote:
This patch does so (and makes slightly less conservative, to tackle the
example above). I found I had to make this a separate pass, so that the
phi nodes were cleaned up at the end of the pass before running
tree_if_conversion.
What PH
Richard Biener wrote:
Apart from Jeffs comment - the usual fix for the undesired
vectorization is to put
a __asm__ volatile (""); in the loop.
In vect-strided-a-u16-i4.c, narrowing the scope of the declaration seemed to
preserve the original intent. I've been able to drop the other testsuite c
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02139.html .
Changes are:
* Separate the two passes by descending from a common base class, allowing
different predicates;
* Test flag_tree_vectorize, and loop->force_vectorize/dont_vectorize - this
fixes the test failing
This adjusts the type adjustment code for array components in the C and C++
front-ends as per Joseph's remark, fixes a couple of documentation glitches
and adds 3 more testcases following Richard's questions.
Joseph, is that what you had in mind?
Tested on x86_64-suse-linux.
* doc/ext
On Fri, Jun 19, 2015 at 05:43:01PM +0100, Jim Wilson wrote:
> This is a follow on to the long double 0.0 patch. The float and
> double support has similar problems and need similar fixes, though a
> little smaller in scope. Before the patch this testcase
> void sub1 (float *f) { *f = 0.0; }
> vo
This is a follow on to the long double 0.0 patch. The float and
double support has similar problems and need similar fixes, though a
little smaller in scope. Before the patch this testcase
void sub1 (float *f) { *f = 0.0; }
void sub2 (double *d) { *d = 0.0; }
gives assembly code
sub1:
fm
OK, thanks.
Sorry this took so long to review; please feel free to ping me every week.
Jason
> On Jun 19, 2015, at 8:51 AM, Jan-Benedict Glaw wrote:
>
> Hi James,
>
> On Tue, 2015-06-16 10:58:48 +0100, James Greenhalgh
> wrote:
>> The testcase in this patch, from libgcc, causes an ICE in the Vax
>> build.
> [...]
>> As far as I know, reload is going to get rid of these SUBREGs
>> for
On Fri, Jun 19, 2015 at 06:22:12PM +0200, Marek Polacek wrote:
> Using -fsanitize=undefined -fsanitize-undefined-trap-on-error when both
> compiling and linking results in libubsan.so in DT_NEEDED of the final
> executable. That's inconvenient since the latter flag ensures that
> __builtin_trap is
Using -fsanitize=undefined -fsanitize-undefined-trap-on-error when both
compiling and linking results in libubsan.so in DT_NEEDED of the final
executable. That's inconvenient since the latter flag ensures that
__builtin_trap is used instead of libubsan routines thus the libubsan
library shouldn't
On Fri, 19 Jun 2015, Marek Polacek wrote:
+/* x + y - (x | y) -> x & y */
+(simplify
+ (minus (plus @0 @1) (bit_ior @0 @1))
+ (if (!TYPE_OVERFLOW_SANITIZED (type) && !TYPE_SATURATING (type))
+ (bit_and @0 @1)))
+
+/* (x + y) - (x & y) -> x | y */
+(simplify
+ (minus (plus @0 @1) (bit_and @0 @1)
On Fri, 19 Jun 2015, Prathamesh Kulkarni wrote:
> Hi,
> C FE rejects incomplete type for expression in typeof.
>
> struct foo;
> struct foo *p;
> typeof (struct foo) *q; // accepted
> typeof (*p) *q; // error: dereferencing pointer to incomplete type.
>
> The attached patch tries to fix it.
>
On Thu, Jun 18, 2015 at 05:41:18PM +0200, Marek Polacek wrote:
> > Again for symmetry, it seems like this comes with
> > x + y - (x | y) -> x & y
> > x + y - (x & y) -> x | y
> > which seem fine when overflow is undefined or wraps, but not if for instance
> > it saturates.
>
> I'll leave this as a
As we have generalized TLS GD code for all memory model in patch 1,
support for tiny model is quite straightforward. We just need to output
different assembly according to memory model.
2015-06-19 Jiong Wang
gcc/
* config/aarch64/aarch64.md (tlsgd): Support tiny model constraint.
gcc/tests
Currently, there is only small model support for TLS GD on
AArch64. While TLS Global Dynamic (Traditional) is actually the same for
all memory mode.
For TLSGD, the code logic is always the following:
RegA = GOT descriptor address of tls variable.
call __tls_get_addr/
nop
Instruction sequences
Hi,
C FE rejects incomplete type for expression in typeof.
struct foo;
struct foo *p;
typeof (struct foo) *q; // accepted
typeof (*p) *q; // error: dereferencing pointer to incomplete type.
The attached patch tries to fix it.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
OK for
On 18 June 2015 at 21:17, Christophe Lyon wrote:
> Hi,
>
> I backported the fix for PR62308 to 4.9-branch. The original patch
> applies cleanly.
>
> Bootstrap + make check OK on x86_64 and aarch64.
>
> I'm also adding the testcase I've just sent separately for trunk.
>
> OK?
Committed as r224671
On 19 June 2015 at 14:32, Marcus Shawcroft wrote:
> On 18 June 2015 at 20:17, Christophe Lyon wrote:
>> Hi,
>>
>> While backporting the fix for PR62308 from trunk to 4.9-branch, it
>> appeared that a testcase would be useful.
>>
>> Here it is. I'll send another email to request the backport of th
Hi,
There was a set of stability fixes (mostly different ICEs) for Pointer Bounds
Checker done in GCC 6. But only few of them were approved to be ported to GCC
5. Will it be OK to port other chkp specific stability fixes to GCC 5? Here
is a list of patches:
https://gcc.gnu.org/ml/gcc-patch
On Fri, Jun 19, 2015 at 03:03:38PM +0200, Bernd Schmidt wrote:
> >they are also very much OpenMP or OpenACC specific, rather than representing
> >language neutral behavior, so there is a problem that you'd need M x N
> >different expansions of those constructs, which is not really maintainable
> >(
Hi,
This patch tries to improve 64bit integer computations on 32bit target. This
is achieved by an additional i386 target pass which searches for all conversion
candidates and tries to transform them into vector mode when profitable.
Initial problem discussion had several assumptions that this
A second release candidate for the last release from the GCC 4.8 branch,
GCC 4.8.5, is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.5-RC-20150619
and shortly its mirrors.
It has been generated from SVN revision 224647. I have sofar bootstrapped
the release candidate on
{x86_64
On 06/19/2015 02:25 PM, Jakub Jelinek wrote:
Emitting PTX specific code from current ompexp is highly undesirable of
course, but I must say I'm not a big fan of keeping the GOMP_* gimple trees
around for too long either, they've never meant to be used in low gimple,
and even all the early optimiz
> * go-lang.c (go_langhook_init_options_struct): Don't set
> x_flag_split_stack.
> (go_langhook_post_options): Set it here instead.
> ---
> gcc/go/go-lang.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/go/go-lang.c b/gcc/go/go-lang.c
> ind
On 18 June 2015 at 20:17, Christophe Lyon wrote:
> Hi,
>
> While backporting the fix for PR62308 from trunk to 4.9-branch, it
> appeared that a testcase would be useful.
>
> Here it is. I'll send another email to request the backport of the fix
> + testcase to the 4.9-branch.
>
> Christophe.
>
> 2
On Fri, Jun 19, 2015 at 11:53:14AM +0200, Bernd Schmidt wrote:
> On 05/28/2015 05:08 PM, Jakub Jelinek wrote:
>
> >I understand it is more work, I'd just like to ask that when designing stuff
> >for the OpenACC offloading you (plural) try to take the other offloading
> >devices and host fallback i
Hi all,
a ping on this patch. Rebased to current trunk.
Bootstraps and regtests fine on x86_64-linux-gnu/f21.
Ok for trunk?
- Andre
> On Mon, 4 May 2015 16:53:15 +0200
> Andre Vehreschild wrote:
>
> > Hi all,
> >
> > I like to present here a first patch for using class arrays in associate.
Hi all,
Bootstrapped and tested on x86_64-linx.
Will commit shortly as obvious.
Thanks,
Kyrill
2015-06-19 Kyrylo Tkachov
* config/i386/i386.c (ix86_function_versions): Use std::swap instead
of manually swapping.
(expand_vec_perm_interleave2): Likewise.
commit c4e17657d5557ec58e9
Ping.
On Fri, Jun 12, 2015 at 11:07:29AM +0200, Marek Polacek wrote:
> Ping.
>
> On Fri, Jun 05, 2015 at 10:55:08AM +0200, Marek Polacek wrote:
> > On Thu, Jun 04, 2015 at 09:04:19PM +, Joseph Myers wrote:
> > > The C changes are OK.
> >
> > Jason, do you want to approve the C++ parts?
On 05/28/2015 05:08 PM, Jakub Jelinek wrote:
I understand it is more work, I'd just like to ask that when designing stuff
for the OpenACC offloading you (plural) try to take the other offloading
devices and host fallback into account.
The problem is that many of the transformations we need to
Hi!
On Thu, 18 Jun 2015 11:20:54 -0500, James Norris
wrote:
> The attached patch adds additional tests for the
> OpenACC default clause.
Thanks!
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/goacc/default-1.c
> @@ -0,0 +1,57 @@
> +/* { dg-do run } */
> +
> +#include
> +
> +int
> +main (i
On 09/06/2015 16:22, Michael Haubenwallner wrote:
> Hi build machinery maintainers,
>
> since we always build the C++ compiler now, I fail to see the need to still
> use RAW_CXX_TARGET_EXPORTS for libvtv.
>
> The situation to expose the problem is:
> * Use a multilib-enabled x86_64-linux box.
>
> You appear to be duplicating the documentation of an unrelated attribute.
Merge glitch, now fixed, thanks.
> What happens when typeof is applied to a field with reversed storage
> order?
You mean a scalar field contained in an aggregate type with reverse SSO? Then
nothing, nothing is changed
Hi,
DEF_GOMP_BUILTIN tests for 'flag_parallelize_loops'. But if
flag_parallelize_loops is one (which is also the default), then
pass_parloops doesn't do anything, and won't generate any OMP constructs.
This patch makes DEF_GOMP_BUILTIN tests 'flag_parallelize_loops > 1',
just like all the ot
Rename test source from tlsle.c into tls.c for reuse purpose.
tls.c will be used as test source file for all TLS test, we just need to
specify different tls options in different testcases.
2015-06-19 Jiong Wang
gcc/testsuite/
* gcc.target/aarch64/tlsle.c: Rename to tls.c
* gcc.target/aar
Currently, TLS IE is supported on small model only. This patch implement
TLS Initial-exec model support for AArch64 tiny memory model.
Under tiny model, we only allow 1M loadable segment size, one single ldr
instruction is enough for addressing the got entry for TLS IE directly.
The code sequenc
> > Can I modify an existing struct to create an opposite endian variant?
> > Eg.
> >
> > struct bar
> > {
> >
> > int a;
> >
> > };
> >
> > struct wibble
> > {
> >
> > struct __attr_sso__ bar a;
> >
> > };
>
> The compiler accepts it, but apparently discards the attribute silently,
Hi,
This patch doesn't allow to reuse bounds created for abnormal ssa name to avoid
coalescing issues. Bootstrapped and regtested for x86_64-unknown-linux-gnu.
Applied to trunk. Is it OK for gcc-5-branch?
Thanks,
Ilya
--
gcc/
2015-06-19 Ilya Enkovich
* tree-chkp.c (chkp_compute_
On 08/06/15 09:25, Richard Biener wrote:
On Thu, 4 Jun 2015, Tom de Vries wrote:
{
gsi_next (&gsi);
continue;
diff --git gcc/tree-ssa-sccvn.c gcc/tree-ssa-sccvn.c
index e417a15..449a615 100644
--- gcc/tree-ssa-sccvn.c
+++ gcc/tree-ssa-sccvn.c
@@ -85,6 +85
Hi!
On Tue, 5 May 2015 16:09:18 +0200, I wrote:
> I don't know why libgomp.oacc-c-c++-common/lib-62.c contains this
> explicit acc_init call with acc_device_nvidia -- generally, the test
> cases should not contain such unconditional statements. So, let's then
> please remove this. See
> libgomp/
On 16/06/15 13:18, Richard Biener wrote:
On Mon, Jun 15, 2015 at 12:38 AM, Tom de Vries wrote:
On 14/06/15 23:49, Bernhard Reutner-Fischer wrote:
On June 14, 2015 10:55:59 AM GMT+02:00, Tom de Vries
wrote:
On 13/03/15 11:36, Richard Biener wrote:
On Fri, Mar 13, 2015 at 11:32 AM, Tom de
Hi!
On Tue, 5 May 2015 11:43:20 +0200, I wrote:
> On Mon, 4 May 2015 10:20:14 -0400, John David Anglin
> wrote:
> > FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-3.c
> > -DACC_DEVICE_TYPE_host
> > =1 -DACC_MEM_SHARED=1 output pattern test, is
> > libgomp: no device found
> > , should ma
67 matches
Mail list logo
