On Wed, Apr 05, 2017 at 05:17:24PM -0600, Sandra Loosemore wrote:
> > > Yes, exactly. I really want to reach the deadline for gcc-7.
> > > Fixing the name is certainly the most important first step,
> > > and if everybody agrees on "typeless_storage", for the name
> > > I can start with adjusting
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-7.1-b20170226.fr.po', h
On Wed, Apr 05, 2017 at 09:37:04AM -0600, Sandra Loosemore wrote:
> On 04/04/2017 06:14 AM, Alan Modra wrote:
> >Revised patch.
> >
> >[snip]
> >+@smallexample
> >+static void
> >+dgemv_kernel_4x4 (long n, const double *ap, long lda,
> >+ const double *x, double *y, double alpha)
>
On 04/05/2017 03:02 PM, Bernd Edlinger wrote:
On 04/05/17 19:22, Bernd Edlinger wrote:
On 04/05/17 18:08, Jakub Jelinek wrote:
Yes, exactly. I really want to reach the deadline for gcc-7.
Fixing the name is certainly the most important first step,
and if everybody agrees on "typeless_storage",
On 04/05/2017 09:46 PM, Bernd Edlinger wrote:
> It does the same as may_alias but additionally objects
> declared with that type have alias set 0, I just don't
> know if I have yet found the right words so that it can
> be understood. Based on the feedback I have now written:
>
> +@item typeless
On 04/05/2017 12:35 PM, Mike Stump wrote:
libffi/ChangeLog:
2017-04-03 Daniel Santos
PR testsuite/79867
* testsuite/lib/target-libpath.exp: Remove.
* testsuite/Makefile.in: Remove target-libpath.exp.
* testsuite/Makefile.am: Regenerated.
I don't think the libff
We crashed on this testcase because UNDERLYING_TYPE, a C++-specific code,
got into layout_type. It wound up there via strip_typedefs -> ... ->
build_type_attribute_qual_variant and that calls type_hash_canon which
has
7129 /* The TYPE_ALIGN field of a type is set by layout_type(), so we
7130
On 04/05/17 19:22, Bernd Edlinger wrote:
> On 04/05/17 18:08, Jakub Jelinek wrote:
>
> Yes, exactly. I really want to reach the deadline for gcc-7.
> Fixing the name is certainly the most important first step,
> and if everybody agrees on "typeless_storage", for the name
> I can start with adjusti
On 04/05/17 22:17, Jason Merrill wrote:
> On Wed, Apr 5, 2017 at 1:41 PM, Bernd Edlinger
> wrote:
>> On 04/05/17 17:20, Richard Biener wrote:
Also, wonder if you need to mark all types containing such arrays,
if you couldn't just set that flag in C++ on unsigned char/std::byte
array
On 04/05/2017 01:22 PM, Thomas Schwinge wrote:
>> --- a/gcc/gimplify.c
>> +++ b/gcc/gimplify.c
>> @@ -6102,14 +6102,19 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx,
>> tree decl, unsigned flags)
>> {
>>const char *rkind;
>>bool on_device = false;
>> + bool is_private = false;
>
On 4/5/17 9:14 AM, Nathan Sidwell wrote:
>
>> Thanks for the patch! Looks like there are some compile problems. I
>> can fix "resut", but not sure what the intent is for "canonical":
>
> I'm a dumbass. I built the x86_64 compiler :(
> try this.
>
> nathan
Thanks! Regtest showed that this blows
Hi Cesar!
Can you please help me understand/verify a part of your patch:
On Thu, 15 Sep 2016 07:56:58 -0700, Cesar Philippidis
wrote:
> Currently gfortran largely lacks support for fortran common blocks in
> OpenACC. The notable exception is acc declare link which does support
> common block ar
On Wed, Apr 5, 2017 at 1:41 PM, Bernd Edlinger
wrote:
> On 04/05/17 17:20, Richard Biener wrote:
>>> Also, wonder if you need to mark all types containing such arrays,
>>> if you couldn't just set that flag in C++ on unsigned char/std::byte
>>> arrays (and on anything with that attribute), have th
I have checked it in as obvious.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
OK.
On Wed, Apr 5, 2017 at 2:48 PM, Jakub Jelinek wrote:
> Hi!
>
> The testcase in the PR (GC related, so not easily reduceable) ICEs
> because two TEMPLATE_TYPE_PARMs that comptypes returns true on have
> different TYPE_CANONICAL (each has itself).
> The problem is that
> comptypes->structural_
Hi!
The testcase in the PR (GC related, so not easily reduceable) ICEs
because two TEMPLATE_TYPE_PARMs that comptypes returns true on have
different TYPE_CANONICAL (each has itself).
The problem is that
comptypes->structural_comptypes->comp_template_parms_position
compares not just idx and level,
- Sebastian Huber schrieb:
> Allow targets to define the default for the short enums option.
>
> v2: Move ARM_DEFAULT_SHORT_ENUMS to arm.h.
>
> gcc/
>
> * config/arm/arm.h: (ARM_DEFAULT_SHORT_ENUMS): Provide default
> definition.
> * config/arm/arm.c: (arm_default_short_en
On 04/05/17 17:20, Richard Biener wrote:
>> Also, wonder if you need to mark all types containing such arrays,
>> if you couldn't just set that flag in C++ on unsigned char/std::byte
>> arrays (and on anything with that attribute), have that imply alias set
>> 0 on it and then let the rest of alias
Copyright notices should now use a single range of years (e.g. 2005-2017).
--
Joseph S. Myers
jos...@codesourcery.com
On Apr 3, 2017, at 4:14 PM, Daniel Santos wrote:
>
> We currently have two copies of target-libpath.exp in the tree under
> gcc/testsuite/lib and libffi/testsuite/lib. It was originally pulled
> into the libffi project from downstream gcc in 2009
> (https://github.com/libffi/libffi/commit/5cbe20
On 04/05/17 18:08, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 05:03:33PM +0100, Jonathan Wakely wrote:
>>> I wanted to say it behaves mostly like __attribute__((may_alias))
>>> except that may_alias only has an effect on pointers and references
>>> but not when accessing an object directly, (I
On Wed, Apr 5, 2017 at 5:38 AM, Wilco Dijkstra wrote:
> Many supported cores use the AUTOPREFETCHER_WEAK setting which tries
> to order loads and stores to improve streaming performance. Since significant
> gains were reported in http://patchwork.ozlabs.org/patch/534469/ it seems
> like a good id
On 04/05/2017 12:07 PM, Vladimir Makarov wrote:
I'll correct the patch.
Here is the patch I've committed.
2017-04-05 Vladimir Makarov
PR rtl-optimization/70703
* ira-color.c (update_conflict_hard_regno_costs): Use
HOST_WIDE_INT instead of long.
Index: ira-color
On Wed, Apr 5, 2017 at 5:38 AM, Wilco Dijkstra wrote:
> Many supported cores use the AUTOPREFETCHER_WEAK setting which tries
> to order loads and stores to improve streaming performance. Since significant
> gains were reported in http://patchwork.ozlabs.org/patch/534469/ it seems
> like a good id
On Wed, Apr 05, 2017 at 05:03:33PM +0100, Jonathan Wakely wrote:
> > I wanted to say it behaves mostly like __attribute__((may_alias))
> > except that may_alias only has an effect on pointers and references
> > but not when accessing an object directly, (I hope you know what
> > I mean).
>
> And m
On 04/05/2017 11:25 AM, Jakub Jelinek wrote:
On Wed, Apr 05, 2017 at 11:11:54AM -0400, Vladimir Makarov wrote:
--- ira-color.c (revision 246536)
+++ ira-color.c (working copy)
@@ -1367,6 +1367,16 @@ update_costs_from_allocno (ira_allocno_t
|| ALLOCNO_ASSIGNED_P (another_allocno))
On 05/04/17 15:38 +, Bernd Edlinger wrote:
On 04/05/17 17:23, Richard Biener wrote:
On April 5, 2017 4:50:32 PM GMT+02:00, Florian Weimer
wrote:
On 04/05/2017 11:46 AM, Bernd Edlinger wrote:
+@item always_alias
+@cindex @code{always_alias} type attribute
+Same as @code{may_alias}, but ad
On 04/04/2017 06:14 AM, Alan Modra wrote:
Revised patch.
[snip]
+@smallexample
+static void
+dgemv_kernel_4x4 (long n, const double *ap, long lda,
+ const double *x, double *y, double alpha)
+@{
+ double *a0;
+ double *a1;
+ double *a2;
+ double *a3;
+
+ __asm__
+(
+
On 04/05/17 17:23, Richard Biener wrote:
> On April 5, 2017 4:50:32 PM GMT+02:00, Florian Weimer
> wrote:
>> On 04/05/2017 11:46 AM, Bernd Edlinger wrote:
>>> +@item always_alias
>>> +@cindex @code{always_alias} type attribute
>>> +Same as @code{may_alias}, but additionally applies to instances o
On Wed, Apr 5, 2017 at 10:29 AM, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 10:26:47AM +0200, Uros Bizjak wrote:
>> On Wed, Apr 5, 2017 at 10:20 AM, Jakub Jelinek wrote:
>> > On Wed, Apr 05, 2017 at 10:12:02AM +0200, Uros Bizjak wrote:
>> >> Oh, I forgot to point out that on x86_64 ABI specif
On Wed, Apr 05, 2017 at 03:27:20PM +, Bernd Edlinger wrote:
> Yes, but it is not clear if it will be available in LTO, for instance
> we used to stream TYPE_ALIAS_SET == 0 information to let frontends mark
> types that are opaque for TBAA. This however did not work as intended,
> because TYPE_
On 04/05/17 15:28, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 09:46:09AM +, Bernd Edlinger wrote:
>> this is related to the P1 codegen bug PR79671:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>>
>> Therefore I would like to add this now although
>> the trunk is already at in stage
On Wed, Apr 05, 2017 at 11:11:54AM -0400, Vladimir Makarov wrote:
> --- ira-color.c (revision 246536)
> +++ ira-color.c (working copy)
> @@ -1367,6 +1367,16 @@ update_costs_from_allocno (ira_allocno_t
> || ALLOCNO_ASSIGNED_P (another_allocno))
> continue;
>
> +
Dominik Vogt wrote:
> On Mon, Mar 27, 2017 at 09:27:35PM +0100, Dominik Vogt wrote:
> > The attached patch optimizes the atomic_exchange and
> > atomic_compare patterns on s390 and s390x (mostly limited to
> > SImode and DImode). Among general optimizaation, the changes fix
> > most of the problem
This patch implements the OpenACC 2.5 behavior of fortran allocate on
variables marked with declare create as defined in Section 2.13.2 in the
OpenACC spec. To do so, I've added two new data mappings,
GOMP_MAP_DECLARE_ALLOCATE and GOMP_MAP_DECLARE_DEALLOCATE.
While working on adding support for al
On April 5, 2017 4:50:32 PM GMT+02:00, Florian Weimer
wrote:
>On 04/05/2017 11:46 AM, Bernd Edlinger wrote:
>> +@item always_alias
>> +@cindex @code{always_alias} type attribute
>> +Same as @code{may_alias}, but additionally applies to instances of
>> +types with this attribute.
>
>As a GCC user,
On April 5, 2017 3:28:32 PM GMT+02:00, Jakub Jelinek wrote:
>On Wed, Apr 05, 2017 at 09:46:09AM +, Bernd Edlinger wrote:
>> this is related to the P1 codegen bug PR79671:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>>
>> Therefore I would like to add this now although
>> the trunk i
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 246707
Index: ChangeLog
===
--- ChangeLog (revision 246706)
+++ Change
On 04/05/2017 11:46 AM, Bernd Edlinger wrote:
+@item always_alias
+@cindex @code{always_alias} type attribute
+Same as @code{may_alias}, but additionally applies to instances of
+types with this attribute.
As a GCC user, I have to say that this doesn't really explain what the
attribute does.
Thanks for the patch! Looks like there are some compile problems. I can fix "resut",
but not sure what the intent is for "canonical":
I'm a dumbass. I built the x86_64 compiler :(
try this.
nathan
--
Nathan Sidwell
2017-04-05 Nathan Sidwell
PR target/79905
* config/rs6000/rs6000.c (
On 03/16/2017 07:13 AM, Thomas Schwinge wrote:
>> --- a/gcc/gimplify.c
>> +++ b/gcc/gimplify.c
>
>> @@ -6636,9 +6596,9 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq
>> *pre_p,
>>ctx = new_omp_context (region_type);
>>ctx->clauses = *list_p;
>>outer_ctx = ctx->outer_context;
On Mon, Mar 27, 2017 at 09:27:35PM +0100, Dominik Vogt wrote:
> The attached patch optimizes the atomic_exchange and
> atomic_compare patterns on s390 and s390x (mostly limited to
> SImode and DImode). Among general optimizaation, the changes fix
> most of the problems reported in PR 80080:
> http
Hi Nathan,
> On Apr 5, 2017, at 8:18 AM, Nathan Sidwell wrote:
>
> Here's a completed patch. Bill, if you could regression test it, that'd be
> great! (feel free to augment the testcase)
Thanks for the patch! Looks like there are some compile problems. I can fix
"resut", but not sure what
On Wed, Apr 05, 2017 at 09:46:09AM +, Bernd Edlinger wrote:
> this is related to the P1 codegen bug PR79671:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>
> Therefore I would like to add this now although
> the trunk is already at in stage 4.
>
> I propose to add a new type attribute
Here's a completed patch. Bill, if you could regression test it, that'd
be great! (feel free to augment the testcase)
Richard, rather than copy set_underlying_type's type cloning I added a
check in it for error_mark_node as the existing name. If you'd prefer
that remain unchanged, I can dupl
Many supported cores use the AUTOPREFETCHER_WEAK setting which tries
to order loads and stores to improve streaming performance. Since significant
gains were reported in http://patchwork.ozlabs.org/patch/534469/ it seems
like a good idea to enable this setting too for -mcpu=generic. Since the
wea
Code scheduling for Cortex-A53 isn't as good as it could be. It turns out
code runs faster overall if we place loads and stores with a dependency
closer together. To achieve this effect, this patch adds a bypass between
cortex_a53_load1 and cortex_a53_load*/cortex_a53_store* if the result of an
e
On 5 April 2017 at 13:41, Bin.Cheng wrote:
> On Wed, Apr 5, 2017 at 12:38 PM, Markus Trippelsdorf
> wrote:
>> On 2017.04.03 at 15:20 +0200, Richard Biener wrote:
>>> I'm re-testing the following variant.
>>>
>>> Richard.
>>>
>>> 2017-04-03 Richard Biener
>>>
>>> PR middle-end/80281
>>>
On Wed, Apr 5, 2017 at 12:38 PM, Markus Trippelsdorf
wrote:
> On 2017.04.03 at 15:20 +0200, Richard Biener wrote:
>> I'm re-testing the following variant.
>>
>> Richard.
>>
>> 2017-04-03 Richard Biener
>>
>> PR middle-end/80281
>> * match.pd (A + (-B) -> A - B): Make sure to preserv
On 2017.04.03 at 15:20 +0200, Richard Biener wrote:
> I'm re-testing the following variant.
>
> Richard.
>
> 2017-04-03 Richard Biener
>
> PR middle-end/80281
> * match.pd (A + (-B) -> A - B): Make sure to preserve unsigned
> arithmetic done for the negate or the plus. Simp
On April 5, 2017 12:01:37 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>When asan unpoisons variables that don't have byte sizes that are
>multiples
>of 8, it on big endian stores the last chunk size value into the first
>byte
>rather than last byte, so e.g. for the variable of size 12 bytes in the
>
Hi!
I'd like to ping 2 patches:
P1 PR debug/80234
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01489.html
Fix dwarf2out ICE with C++17 inline static data members with redundant
redeclaration
PR c/80163
http://gcc.gnu.org/ml/gcc-patches/2017-03/msg01324.html
Fix EXPAND_INITIALIZER expan
On 03/04/17 09:25, Eric Botcazou wrote:
> Hi,
>
> this fixes the ICE that has been introduced by the new implementation of
> stack
> checking in ILP32 mode, hence a regression present on mainline and 6 branch.
> I'd also like to mention that the patch only restores the implementation that
> was
Hi!
When asan unpoisons variables that don't have byte sizes that are multiples
of 8, it on big endian stores the last chunk size value into the first byte
rather than last byte, so e.g. for the variable of size 12 bytes in the
testcase it stores half-word 0x0400 into the shadow memory, which is f
Ping.
On Thu, Mar 30, 2017 at 08:26:55PM +0200, Marek Polacek wrote:
> This fix is similar to c++/79653: if something went wrong during
> make_pack_expansion, return error_mark instead of building up the attribute
> otherwise we end up with "gnu aligned <<>>" and that would mean
> crashing
> late
Ping.
On Wed, Mar 29, 2017 at 11:32:39PM +0200, Marek Polacek wrote:
> On Wed, Mar 29, 2017 at 02:56:51PM -0400, Jason Merrill wrote:
> > On Wed, Mar 29, 2017 at 12:38 PM, Marek Polacek wrote:
> > > Here we have a reference initialization with NSDMI and *this. We are
> > > crashing
> > > becaus
Hi,
this is related to the P1 codegen bug PR79671:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
Therefore I would like to add this now although
the trunk is already at in stage 4.
I propose to add a new type attribute always_alias that
works like may_alias but unlike may_alias it should
al
On Wed, Apr 05, 2017 at 10:26:47AM +0200, Uros Bizjak wrote:
> On Wed, Apr 5, 2017 at 10:20 AM, Jakub Jelinek wrote:
> > On Wed, Apr 05, 2017 at 10:12:02AM +0200, Uros Bizjak wrote:
> >> Oh, I forgot to point out that on x86_64 ABI specifies MMX values in
> >> SSE registers.
> >
> > I know it does
On 04/05/2017 12:08 AM, Dominik Vogt wrote:
> The attached patch fixes PR 79890. Bootstrapped and regression
> tested on s390x biarch and s390.
Applied. Thanks!
-Andreas-
On Wed, Apr 5, 2017 at 10:20 AM, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 10:12:02AM +0200, Uros Bizjak wrote:
>> Oh, I forgot to point out that on x86_64 ABI specifies MMX values in
>> SSE registers.
>
> I know it does. And if people have their own function that returns
> __m64 or takes su
On Wed, Apr 05, 2017 at 10:12:02AM +0200, Uros Bizjak wrote:
> Oh, I forgot to point out that on x86_64 ABI specifies MMX values in
> SSE registers.
I know it does. And if people have their own function that returns
__m64 or takes such arguments, they surely have to.
The question is only about th
On Wed, Apr 5, 2017 at 10:00 AM, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 09:42:31AM +0200, Uros Bizjak wrote:
>> On Tue, Apr 4, 2017 at 9:24 PM, Jakub Jelinek wrote:
>> > Hi!
>> >
>> > aggregate_value_p is called often very early during compilation, e.g.
>> > from allocate_function or duri
Hi!
On Tue, 19 Apr 2016 10:24:36 +0200, Martin Liška wrote:
> After brief discussions about packaging of an HSA runtime, we've decided to
> load
> an HSA runtime via dlopen mechanism. Following patch introduces necessary
> header
> files and all functions within the HSA plug-in are loaded via d
On Wed, Apr 05, 2017 at 09:42:31AM +0200, Uros Bizjak wrote:
> On Tue, Apr 4, 2017 at 9:24 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > aggregate_value_p is called often very early during compilation, e.g.
> > from allocate_function or during gimplification of a call with lhs.
> > The problem with tha
On Tue, Apr 4, 2017 at 9:24 PM, Jakub Jelinek wrote:
> Hi!
>
> aggregate_value_p is called often very early during compilation, e.g.
> from allocate_function or during gimplification of a call with lhs.
> The problem with that is e.g. that on x86_64 -m64 -mno-sse we can't
> include , because the a
Hi!
On Tue, 9 Jun 2015 16:43:57 +0200, Martin Jambor wrote:
> [hsa libgomp plugin]
> I'm looking forward to any comments and suggestions, meanwhile I have
> committed the patch to the branch as r224284.
Commenting better late than never? ;-)
Is there a specific reason why you're not using the
And the patch..
On Wed, Apr 5, 2017 at 8:25 AM, Bin.Cheng wrote:
> On Thu, Mar 30, 2017 at 2:34 PM, Richard Biener
> wrote:
>> On Thu, Mar 30, 2017 at 3:20 PM, Bin.Cheng wrote:
>>> On Thu, Mar 30, 2017 at 2:18 PM, Bin.Cheng wrote:
On Thu, Mar 30, 2017 at 1:44 PM, Richard Biener
wr
On Thu, Mar 30, 2017 at 2:34 PM, Richard Biener
wrote:
> On Thu, Mar 30, 2017 at 3:20 PM, Bin.Cheng wrote:
>> On Thu, Mar 30, 2017 at 2:18 PM, Bin.Cheng wrote:
>>> On Thu, Mar 30, 2017 at 1:44 PM, Richard Biener
>>> wrote:
On Thu, Mar 30, 2017 at 2:03 PM, Bin.Cheng wrote:
> On Thu, Ma
68 matches
Mail list logo
