On Tue, Feb 02, 2016 at 12:50:39AM +0100, Bernd Schmidt wrote:
> On 02/01/2016 09:34 PM, Jakub Jelinek wrote:
> >On the following testcase we completely uselessly consume about 5.5GB
> >of RAM and lots of compile time. The problem is the code to avoid
> >exponential behavior of nonzero_bits/num_si
Hi All,
Ping for following thread :
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01968.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01969.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01970.html
Thanks
Mickael
On Tue, Jan 26, 2016 at 05:39:24PM +, Wilco Dijkstra wrote:
> ping (note the regressions discussed below are addressed by
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01761.html)
OK, but please be extra vigilant for any fallout on AArch64 after this
and the follow-up linked above is applie
On 01/02/16 19:27, Mike Stump wrote:
On Jan 29, 2016, at 8:10 AM, Sebastian Pop wrote:
>diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>index 062f42c..3df7974 100644
>--- a/gcc/doc/install.texi
>+++ b/gcc/doc/install.texi
>@@ -383,7 +383,7 @@ installed but it is not in your default li
On Wed, Jan 20, 2016 at 03:22:11PM +, James Greenhalgh wrote:
>
> Hi,
>
> In a number of cases where we try to create vectors we end up spilling to the
> stack and then filling. This is one example distilled from a couple of
> micro-benchmrks where the issue shows up. The reason for the extra
On Sun, Jan 24, 2016 at 02:54:32AM -0800, Richard Henderson wrote:
> This looks to be an incomplete transition of the aarch64 backend to
> CONST_WIDE_INT. I haven't checked to see if it's a regression from
> gcc5, but I suspect not, since there should have been similar checks
> for CONST_DOUBLE.
>
The following is the minimal approach to fix this -Warray-bound at
this stage. We're pretty bad at optimizing range tests that
get optimizable during GIMPLE only (fold can handle quite some cases).
Too bad to optimize this before VRP gets to warn about out-of-bound
array accesses. Later reassoc
As it happens the patch I did over a year ago for PR64682 isn't quite
correct. This is PR69567. This fixes it.
Tested on the separate testcases; also did bootstrap + testsuite on
powerpc64-linux and x86_64-linux. I'll commit this tomorrow or so if
no one sees something wrong with it.
Segher
On Thu, Jan 28, 2016 at 04:42:02AM -0800, H.J. Lu wrote:
> >> 2016-01-27 Jakub Jelinek
> >> Ilya Enkovich
> >>
> >> PR target/69454
> >> * config/i386/i386.c (convert_scalars_to_vector): Remove
> >> stack alignment fixes.
> >>
On 01/29/2016 02:25 AM, Martin Sebor wrote:
What seems to happen is that the call to __builtin_alloca_with_align
uses the stdu (store with update) instruction to store and bump down
the stack pointer (SP) at the same time (standard for powerpc63le)
to make room for the VLA. The subsequent code t
On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek wrote:
>> The bottom line is ix86_minimum_alignment must return the correct
>> number for DImode or you can just turn off STV. My suggestion is
>> to use my patch.
>
> Uros, any preferences here? I mean, it is possible to use
> e.g. the ix86_opti
On 01/25/2016 05:55 PM, Martin Sebor wrote:
The downside of this approach is that it prevents everything but
the front end from distinguishing flexible array members from
arrays of unspecified or unknown bounds. The immediate impact
is that prevents us from maintaining ABI compatibility with GCC
On Tue, Feb 2, 2016 at 4:24 AM, Uros Bizjak wrote:
> On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek wrote:
>
>>> The bottom line is ix86_minimum_alignment must return the correct
>>> number for DImode or you can just turn off STV. My suggestion is
>>> to use my patch.
>>
>> Uros, any preferenc
On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote:
> On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek wrote:
>
> >> The bottom line is ix86_minimum_alignment must return the correct
> >> number for DImode or you can just turn off STV. My suggestion is
> >> to use my patch.
> >
> > Uros
On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wrote:
> On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote:
>> On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek wrote:
>>
>> >> The bottom line is ix86_minimum_alignment must return the correct
>> >> number for DImode or you can just turn off
The following fixes yet another bogus range info case.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-02-02 Richard Biener
PR tree-optimization/69606
* tree-ssa-math-opts.c (bswap_replace): Clear flow sensitive
info on the result before m
On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
> On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wrote:
>> On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote:
>>> On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek wrote:
>>>
>>> >> The bottom line is ix86_minimum_alignment must return the co
Hi!
On Wed, 13 Jan 2016 18:39:26 +0100, Martin Jambor wrote:
> this patch contains changes to the configuration mechanism and offload
> bits, so that users can build compilers with HSA support.
>
> It is a re-post of
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00714.html, which, has
> alread
2016-02-02 15:46 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
>> On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wrote:
>>> On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote:
On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek wrote:
>> The bottom line i
On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich wrote:
> 2016-02-02 15:46 GMT+03:00 H.J. Lu :
>> On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
>>> On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wrote:
On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote:
> On Tue, Feb 2, 2016 at 12
On Tue, Feb 2, 2016 at 2:06 PM, H.J. Lu wrote:
> On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich wrote:
>> 2016-02-02 15:46 GMT+03:00 H.J. Lu :
>>> On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wrote:
> On Tue, Feb 02, 2016 at 01:24:26PM +01
On Tue, Feb 02, 2016 at 04:46:26AM -0800, H.J. Lu wrote:
> >> So, is http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02129.html
> >> ok for trunk then (alone or with additional sorry, incremental or not?)?
> >> I believe it does just that.
> >
> > This patch is WRONG.
> >
> > --
> > H.J.
>
> You will
2016-02-02 16:06 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich wrote:
>> 2016-02-02 15:46 GMT+03:00 H.J. Lu :
>>> On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wrote:
> On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bi
On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich wrote:
> 2016-02-02 16:06 GMT+03:00 H.J. Lu :
>> On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich wrote:
>>> 2016-02-02 15:46 GMT+03:00 H.J. Lu :
On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
> On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek wr
On Tue, Feb 2, 2016 at 5:09 AM, Jakub Jelinek wrote:
> On Tue, Feb 02, 2016 at 04:46:26AM -0800, H.J. Lu wrote:
>> >> So, is http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02129.html
>> >> ok for trunk then (alone or with additional sorry, incremental or not?)?
>> >> I believe it does just that.
>>
2016-02-02 16:14 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich wrote:
>> 2016-02-02 16:06 GMT+03:00 H.J. Lu :
>>> On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich
>>> wrote:
2016-02-02 15:46 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu wrote:
>>
On Tue, Feb 2, 2016 at 5:21 AM, Ilya Enkovich wrote:
> 2016-02-02 16:14 GMT+03:00 H.J. Lu :
>> On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich wrote:
>>> 2016-02-02 16:06 GMT+03:00 H.J. Lu :
On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich
wrote:
> 2016-02-02 15:46 GMT+03:00 H.J. Lu :
2016-02-02 16:25 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 5:21 AM, Ilya Enkovich wrote:
>> 2016-02-02 16:14 GMT+03:00 H.J. Lu :
>>> On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich
>>> wrote:
2016-02-02 16:06 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich
> w
Hi!
On Wed, 2 Dec 2015 16:58:45 +0100, I wrote:
> On Mon, 30 Nov 2015 19:30:34 +, Julian Brown
> wrote:
> > --- a/libgomp/oacc-parallel.c
> > +++ b/libgomp/oacc-parallel.c
>
> > +void
> > +GOACC_host_data (int device, size_t mapnum,
> > +void **hostaddrs, size_t *sizes, unsigned
On Tue, Feb 2, 2016 at 5:55 AM, Ilya Enkovich wrote:
> 2016-02-02 16:25 GMT+03:00 H.J. Lu :
>> On Tue, Feb 2, 2016 at 5:21 AM, Ilya Enkovich wrote:
>>> 2016-02-02 16:14 GMT+03:00 H.J. Lu :
On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich
wrote:
> 2016-02-02 16:06 GMT+03:00 H.J. Lu :
2016-02-02 17:03 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 5:55 AM, Ilya Enkovich wrote:
>> 2016-02-02 16:25 GMT+03:00 H.J. Lu :
>>> On Tue, Feb 2, 2016 at 5:21 AM, Ilya Enkovich
>>> wrote:
2016-02-02 16:14 GMT+03:00 H.J. Lu :
> On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich
> w
Hi,
On Thu, Jan 28, 2016 at 08:18:27AM -0700, Gerald Pfeifer wrote:
>
> This is okay with the changes/considering the questions above.
>
thanks for the feedback. I have committed the following after
incorporating the comments.
Martin
Index: changes.html
==
Hi!
On 02/01/2016 02:03 PM, Jakub Jelinek wrote:
On Mon, Feb 01, 2016 at 01:41:50PM -0600, James Norris wrote:
The attached patch resolves c/PR64748. The patch
adds the use of parm's with the deviceptr clause.
[snip snip]
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10760,7 +10760,7 @@
libgcc/ChangeLog:
* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.
gcc/ChangeLog:
* common/config/s3
In PR 69577 we have:
A: (set (reg:V2TI X) ...)
B: (set (subreg:TI (reg:V2TI X) 0) ...)
X gets allocated to an AVX register, as usual for V2TI. The problem is
that the movti for B doesn't then preserve the other half of X, even
though the subreg semantics are supposed to guarantee that.
If i
On 02/02/2016 03:52 PM, Marcin Kościelnicki wrote:
> libgcc/ChangeLog:
>
> * config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
> * config/s390/morestack.S: New file.
> * config/s390/t-stack-s390: New file.
> * generic-morestack.c (__splitstack_find): Add s390-spe
From: claziss
Adding my self.
2016-02-02 Claudiu Zissulescu
* MAINTAINERS (Write After Approval): Add myself.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@233077
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog | 4
MAINTAINERS | 1 +
2 files changed, 5 insertions(+)
libgcc/ChangeLog:
* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.
gcc/ChangeLog:
* common/config/s3
Jakub Jelinek writes:
> On Sat, Jan 30, 2016 at 02:04:45PM +, Richard Sandiford wrote:
>> Not sure what to call it. Maybe canonize_uhwi? Like canonize, except
>> that it takes a uhwi instead of a length.
>>
>> > Can that be done as a follow-up? Certainly it would need
>> > to take the uhwi
2016-02-01 16:56 GMT+03:00 Senthil Kumar Selvaraj
:
>
> Hi,
>
> This patch sets PARAM_ALLOW_STORE_DATA_RACES to 1 (the default until
> a year back), to avoid code size regressions in trunk (and probably
> 5.x )for the AVR target.
>
> Consider the following piece of code
>
> volatile int z;
Hello!
The problem, exposed by the testcase in the PR, was with the
generation of unwanted MMX registers. Instructions that touch %mm
registers switch x87 register stack to MMX mode and this way clobber
all x87 registers in the register stack.
The core of the problem was in totally bogus cost val
On Tue, Jan 26, 2016 at 11:31 AM, Patrick Palka wrote:
> This patch makes the parser more robust in determining whether an 'auto'
> specifier that appears in a parameter declaration corresponds to a
> placeholder for a late return type, or corresponds to an implicit
> template parameter as for an
Hi Richard,
On 02/02/16 14:56, Richard Sandiford wrote:
In PR 69577 we have:
A: (set (reg:V2TI X) ...)
B: (set (subreg:TI (reg:V2TI X) 0) ...)
X gets allocated to an AVX register, as usual for V2TI. The problem is
that the movti for B doesn't then preserve the other half of X, even
thou
On Tue, Feb 2, 2016 at 5:54 PM, Kyrill Tkachov
wrote:
> Hi Richard,
>
>
> On 02/02/16 14:56, Richard Sandiford wrote:
>>
>> In PR 69577 we have:
>>
>>A: (set (reg:V2TI X) ...)
>>B: (set (subreg:TI (reg:V2TI X) 0) ...)
>>
>> X gets allocated to an AVX register, as usual for V2TI. The probl
Hi all,
the attached patch fixes a regression that was most likely introduced
by one of my former patches, when in an associate() the rank of the
associated variable could not be determined at parse time correctly.
The patch now adds a flag to the association list indicating, that the
rank of the
Hi,
with HSA merged, the hsa branch can be used for development of new
features again. Thus, I have committed there a patch which I finished
after the merge proposal and thus I kept in a private branch so far,
which allows collapse(2) and collapse(3) clauses to be gridified and
the individual loo
[Resending without disclaimer, sorry]
Uros Bizjak writes:
> On Tue, Feb 2, 2016 at 5:54 PM, Kyrill Tkachov
> wrote:
>> Hi Richard,
>>
>>
>> On 02/02/16 14:56, Richard Sandiford wrote:
>>>
>>> In PR 69577 we have:
>>>
>>>A: (set (reg:V2TI X) ...)
>>>B: (set (subreg:TI (reg:V2TI X) 0) ...)
On Feb 2, 2016, at 2:23 AM, Sebastian Huber
wrote:
> It would be good to have a recommended version as well (similar for cloog,
> gmp, mpc and mpfr). If you present me three versions which one should I
> choose as a naive user?
The latest release, or the one on your system. This is so basic t
Hi Andre,
This looks to be OK for trunk.
I'll move to the 5-branch patch right away.
Thanks
Paul
On 29 January 2016 at 19:17, Andre Vehreschild wrote:
> Hi all,
>
> attached is a patch to fix a regression in current gfortran when a
> coarray is used in the source=-expression of an allocate().
Marcin KoÅcielnicki wrote:
> Here we go. I've also removed the "see below", since I don't really
> see anything below...
The "see below" refers to this code (which I agree isn't really obvious):
if (TARGET_TPF_PROFILING)
{
/* Generate a BAS instruction to serve as a function
Hi Andre,
This one looks good too. As every day goes by, I see more and more why
Tobias was so keen to incorporate all objects into a single descriptor
type :-)
OK for 5-branch.
Thanks for both the patches
Paul
On 1 February 2016 at 13:34, Andre Vehreschild wrote:
> Oh, well, now with attachm
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 8277dff..afe4720 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2016-02-02 H.J. Lu
+
+ * gcc.target/i386/iamcu/test_empty_structs_and_unions.c: New test.
+
2016-02-02 James Norris
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/c
On 02/02/2016 02:06 AM, mickael guene wrote:
Hi All,
Ping for following thread :
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01968.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01969.html
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01970.html
Two comments:
(1) MIPS has had a simil
On 02/02/16 19:33, Ulrich Weigand wrote:
Marcin Kościelnicki wrote:
Here we go. I've also removed the "see below", since I don't really
see anything below...
The "see below" refers to this code (which I agree isn't really obvious):
if (TARGET_TPF_PROFILING)
{
/* Generate a B
On 01/30/2016 10:33 AM, Arkadiusz Drabczyk wrote:
* doc/invoke.texi: update documentation WRT .so libraries in -l
---
gcc/ChangeLog | 4
gcc/doc/invoke.texi | 8 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1d60690..0a6
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
Hi all,
here is a diagnostics patch, which makes sure that the responsible
flag is printed in several warning messages (for which this was still
missing).
The only case that I'm not completely sure about is the hunk in
intrinsic.c. In particular I was not able to trigger this warning and
found n
Hi Maintainers,
This patch disables prefetching for -march=znver1 which is turned on by default.
gcc/ChangeLog:
2016-02-02 Victoria Stepanyan
* gcc/config/i386/x86-tune.def: Disable default prefetching for
-march=znver1
Ok for trunk?
Victoria
--- a/gcc/config/i386/x86-tune.def
+++
This testcase fails on 32-bit powerpc-linux with
Excess errors:
/home/segher/src/gcc/gcc/testsuite/c-c++-common/vector-compare-4.c:31:1:
warning: GCC vector returned by reference: non-standard ABI extension with no
compatibility guarantee
Fix this as in vector-compare-2.c .
Tested on powerpc64
This documents the most likely problems for C++ programs using GCC 6.
Committed to CVS.
Index: htdocs/gcc-6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.2
diff -u -r1.2 porting_
On 2016-02-02, Sandra Loosemore wrote:
> I see that the documentation of -l does need to be updated to mention
> .so files, but I think your patch doesn't go far enough. It's already
> confusing because that sentence says "The only difference is...", and
> then mentions *two* things it does di
On Tue, Feb 2, 2016 at 9:28 PM, Stepanyan, Victoria
wrote:
> Hi Maintainers,
>
> This patch disables prefetching for -march=znver1 which is turned on by
> default.
>
> gcc/ChangeLog:
>
> 2016-02-02 Victoria Stepanyan
>
> * gcc/config/i386/x86-tune.def: Disable default prefetching for
>
On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant wrote:
>> include/plugin-api.h defines an ABI between linker and compiler,
>> which can be used to implement linker plug-in by any compilers.
>> I'd like to add GCC Runtime Library Exception to include/plugin-api.h
>> so that the linker plug-in can have
On 01/02/16 13:57, Claudiu Zissulescu wrote:
In this patch, we add support for the new FPU instructions available with
ARC V2 processors. The new FPU instructions covers both single and
double precision IEEE formats. While the single precision is available
for both ARC EM and ARC HS processors
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Brazilian Portuguese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/pt_BR.po
(This file, 'cppl
On Sat, 2016-01-30 at 11:06 +, Richard Sandiford wrote:
> We need to be careful of examples like:
>
> struct __attribute__ ((aligned (8))) s { _Complex float x; };
> void foo (struct s *ptr, struct s val) { *ptr = val; }
>
> "x" gets SCmode, which has an alignment of 4. And it's OK for
libgcc/ChangeLog:
* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.
gcc/ChangeLog:
* common/config/s3
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/vi.po
(This file, 'cpplib-6.1-b20160
On 02/02/2016 05:28 AM, Jason Merrill wrote:
On 01/25/2016 05:55 PM, Martin Sebor wrote:
The downside of this approach is that it prevents everything but
the front end from distinguishing flexible array members from
arrays of unspecified or unknown bounds. The immediate impact
is that prevents
On 1 February 2016 at 17:14, Kyrill Tkachov wrote:
> Indeed I see the new passes on armeb-none-eabi.
> However, the new FAILs that I see are ICEs, not just vectorisation failures,
> so they need to be looked at.
>
> The ICEs that I see are:
> FAIL: gcc.dg/torture/vshuf-v4hi.c -O2 (internal com
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Ukrainian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/uk.po
(This file, 'cpplib-6.1-b201601
When using type reflection, you occasionally need to know the order of
a type's methods. The order is simply an alphabetical sort.
Unfortunately, gccgo was not unpacking names before sorting them,
meaning that a type with a combination of exported and unexported
methods would have them in the wron
In gimple_fold_indirect_ref, we STRIP_NOPS, find the ADDR_EXPR, and fold
everything away.
I can't imagine it ever being correct to drop an address space change between
pointers, so I've modified tree_nop_conversion_p. Anything else seems to
require more checks every places we use STRIP_NOPS.
On 02/02/16 19:00, Mike Stump wrote:
On Feb 2, 2016, at 2:23 AM, Sebastian Huber
wrote:
>It would be good to have a recommended version as well (similar for cloog,
gmp, mpc and mpfr). If you present me three versions which one should I choose as
a naive user?
The latest release, or the on
On 03/02/16 07:29, Sebastian Huber wrote:
On 02/02/16 19:00, Mike Stump wrote:
On Feb 2, 2016, at 2:23 AM, Sebastian
Huber wrote:
>It would be good to have a recommended version as well (similar for
cloog, gmp, mpc and mpfr). If you present me three versions which
one should I choose as a
It's been a long-standing problem in gccgo that the testing package
does not report the correct file/line information when using a method
like t.Error. This is because the testing type uses an embedded type,
and methods like t.Error are actually inherited from the embedded
type. This means that t
On February 3, 2016 7:03:54 AM GMT+01:00, Richard Henderson
wrote:
>In gimple_fold_indirect_ref, we STRIP_NOPS, find the ADDR_EXPR, and
>fold
>everything away.
>
>I can't imagine it ever being correct to drop an address space change
>between
>pointers, so I've modified tree_nop_conversion_p. A
On 02/03/2016 06:05 PM, Richard Biener wrote:
I wasn't aware that STRIP_NOPS strips ADDR_SPACE_CONVERT_EXPR.
Isn't this maybe failing to use that (unable to look at the attachment from my
phone).
The test case does fail to use ADDR_SPACE_CONVERT_EXPR.
Perhaps it's because of the intermediate
79 matches
Mail list logo
