Here is the current patch (passed regtest), after moving defer/undefer
from forwprop to fold_stmt_1. I am not sure if checking no_warning at the
end of fold_stmt_1 is safe, or if I should save its value at the beginning
of the function, in case some of the transformations clear it.
On Tue, 26
On 04/26/2016 04:05 PM, Tom Tromey wrote:
Hi. I've been working on Rust support for gdb, and I needed this patch
as a prerequisite.
DW_LANG_Rust is only defined in DWARF 5, which isn't released yet.
However, the value is mentioned in the DWARF issue requesting the
addition; and similar DWARF-5-
On 03/15/2016 08:46 AM, Andreas Schwab wrote:
* include/private/gcconfig.h [AARCH64] (ALIGNMENT, CPP_WORDSZ):
Define for __ILP32__.
---
boehm-gc/include/private/gcconfig.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Similarly, this should be going to upstream
On 03/15/2016 08:18 AM, Andreas Schwab wrote:
Like x32, aarch64 ILP32 needs to define FFI_SIZEOF_JAVA_RAW. This fixes
the java interpreter.
Andreas.
* src/aarch64/ffitarget.h (FFI_SIZEOF_JAVA_RAW) [__ILP32__]:
Define.
Doesn't libffi come from an upstream project? If so, should
On 04/24/2016 11:40 PM, Sebastian Huber wrote:
Ok, what about the GCC trunk?
On 20/04/16 14:35, Sebastian Huber wrote:
Hello,
I know that I am pretty late, but is there a chance to get this into
the GCC 6.1 release?
On 19/04/16 14:56, Sebastian Huber wrote:
v2: Do not use architecture config
On 04/25/2016 03:11 AM, Bernd Schmidt wrote:
On 03/02/2016 10:53 PM, Vladimir Makarov wrote:
The patch is ok for me. But I'd wait for GCC7. People are sensitive to
their code performance degradation. Even in most cases the patch
improves performance, in some case it can worsen code and peop
On 03/02/2016 02:53 PM, Vladimir Makarov wrote:
The overall effect of this patch seems to be fairly minimal in
practice, which is slightly disappointing. On the whole, it seems to
be a very slight net positive, with few instances where we generate
additional instructions.
I am just speculating
On Mon, Apr 25, 2016 at 04:25:27PM +0200, Bernd Schmidt wrote:
> On 04/25/2016 04:21 PM, Bernd Schmidt wrote:
> >On 04/25/2016 03:30 PM, Trevor Saunders wrote:
> >>On Mon, Apr 25, 2016 at 02:28:51PM +0200, Bernd Schmidt wrote:
> >>>On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
> From
On 27/04/16 00:14, Richard Biener wrote:
On Fri, Apr 15, 2016 at 12:44 PM, kugan
wrote:
As pointed out by Richard, for signed & sign-bit-CST value range should be
[-INF, 0] range, not a [-INF, INF] range as happens now.
This patch fixes this. I bootstrapped and regression tested for
x86-64-l
On Tue, Apr 26, 2016 at 09:03:03AM -0600, Jeff Law wrote:
> On 04/26/2016 07:08 AM, Jakub Jelinek wrote:
> >Hi!
> >
> >I've noticed a warning during bootstrap:
> >../../gcc/reorg.c: In function ‘void try_merge_delay_insns(rtx_insn*,
> >rtx_insn*)’:
> >../../gcc/reorg.c:1431:12: warning: name looku
On Tue, Apr 26, 2016 at 3:11 PM, Bernd Schmidt wrote:
> On 04/26/2016 09:39 PM, H.J. Lu wrote:
>>
>> make check-gcc RUNTESTFLAGS="--target_board='unix{-mx32}'
>> i386.exp=avx512vl-vmovdqa64-1.c"
>
>
> Unfortunately, that doesn't work:
>
> /usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.
PR c++/66639 asked to declare __func__ , __FUNCTION__ and
__PRETTY_FUNCTION__ as constexpr. With the request fulfilled
sometime in the 6.0 time frame (possibly as a result of fixing
c++/70353), the attached patch implements the corresponding
change suggested in c++/66561 - __builtin_LINE at al.
On 04/26/2016 11:28 PM, Dhole wrote:
I've fixed all the spaces issues. I've also changed the "unsigned long long"
to "time_t" as you suggested. Also, to improve reliability I'm now
using strtoll rather than strtoull, so that negative values can be
detected in SOURCE_DATE_EPOCH, which are treate
On Tue, Apr 26, 2016 at 03:02:38PM +0200, Jakub Jelinek wrote:
> I've been using the attached hack; without this patch during x86_64-linux
> and i686-linux yes,extra,rtl checking bootstraps there were 66931
> notes (surprisingly only from the ivopts and gimple-ssa-strength-reduction
> hash tables,
On Tue, Apr 26, 2016 at 03:02:38PM +0200, Jakub Jelinek wrote:
> The debugging hack is too ugly and slows down the compiler (by artificially
> increasing number of collisions), so it is not appropriate, but perhaps we
> can add some internal only use OEP_* flag, pass it to the recursive calls
> of
On 04/26/2016 09:39 PM, H.J. Lu wrote:
make check-gcc RUNTESTFLAGS="--target_board='unix{-mx32}'
i386.exp=avx512vl-vmovdqa64-1.c"
Unfortunately, that doesn't work:
/usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such
file or directory
compilation terminated.
Trying to follo
Hi. I've been working on Rust support for gdb, and I needed this patch
as a prerequisite.
DW_LANG_Rust is only defined in DWARF 5, which isn't released yet.
However, the value is mentioned in the DWARF issue requesting the
addition; and similar DWARF-5-only constants have already been added to
dw
On 02/17/2016 07:24 AM, Nick Clifton wrote:
Hi Guys,
Redefining a previously defined static function as both public and
weak triggers an ICE in ipa-visibility.c:
internal compiler error: in function_and_variable_visibility, at
ipa-visibility.c:518
This bug has been discussed and patch p
On 12/15/2015 10:25 AM, Kyrill Tkachov wrote:
Hi all,
This converts the preprocessor check for WORD_REGISTER_OPERATIONS into a
runtime one
in rtlanal.c.
Since this one was in combination with an "#if defined" and used to
guard an if-statement
I'd appreciate it if someone gave it a double-check
Hi Bernd,
On 16-04-25 12:15:50, Bernd Schmidt wrote:
> On 04/18/2016 02:26 PM, Dhole wrote:
> >A few months ago I submited a patch to allow the embedded timestamps by
> >C/C++ macros to be set externally [2], which was already an improvement
> >over [1]. I was told to wait until the GCC 7 stage 1
On 04/25/2016 03:07 AM, Bernd Schmidt wrote:
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
That would be this patch. Also passes testing on x86_64-linux.
Hi Bernd,
I like the idea behind the patch! So much so
This patch by Chris Manghane adds Enclosed_var_expression to the Go
frontend. This represents a reference from a function literal to a
variable defined in the enclosing function. This simplifies the
existing code, and provides a base for future work. Bootstrapped and
ran Go testsuite on x86_64-p
On 01/31/2016 03:16 PM, Alan Modra wrote:
The comment says this test is supposed to prevent "a narrower
operation than requested", but it actually only allows a larger
subreg, not one the same size. Fix that.
Bootstrapped and regression tested powerpc64-linux. OK for stage1?
Note that this bu
On 04/04/2016 06:00 AM, Senthil Kumar Selvaraj wrote:
2016-04-04 Senthil Kumar Selvaraj
* gcc.c-torture/compile/pr69102.c: Require scheduling support.
* gcc.c-torture/compile/pr37669.c: Require >=32 bit integers.
* gcc.c-torture/execute/bitfld-6.c: Likewise.
* gcc.c-torture/ex
On 04/11/2016 08:10 PM, Vladimir Makarov wrote:
On 04/10/2016 11:24 PM, Zhouyi Zhou wrote:
save a function call to init_reload when using lra, also remove the a
type error in reload1.c
because init_reload is called only once when compile process, the
performance reduction may not be significant
On 04/26/2016 08:04 AM, Rainer Orth wrote:
When working on a couple of Cilk Plus issues lately (PRs target/60290,
target/68945), I noticed that you have to modify the libcilkplus sources
to enable various debugging output. This seems silly, and the following
patch allows defining them from the c
On 26 April 2016 at 16:31, Richard Biener wrote:
> On Mon, 25 Apr 2016, Prathamesh Kulkarni wrote:
>
>> On 6 April 2016 at 14:54, Richard Biener wrote:
>> > On Wed, 6 Apr 2016, Richard Biener wrote:
>> >
>> >> On Wed, 6 Apr 2016, Prathamesh Kulkarni wrote:
>> >>
>> >> > On 6 April 2016 at 13:44,
On 03/26/2016 08:38 AM, Jake Hamby wrote:
Unfortunately, my previous patch that included a change to gcc/config/vax/vax.h
that increased FIRST_PSEUDO_REGISTER from 16 to 17 breaks the C++ exception
handling that I’d worked so hard to get right with the rest of the patch. I
believe I need to de
On 04/01/2016 01:06 PM, Jake Hamby wrote:
My theory is that it has to do with liveness detection and a write
into the stack frame being incorrectly seen as updating a local
variable, but that could be completely wrong. I was hoping that by
cc'ing gcc-patches that somebody more familiar with why
On 03/31/2016 02:29 PM, Jake Hamby wrote:
The failures all seem to be related to trying to read a value from an
array of 64-bit values and loading it into a 32-bit register. It
seems like there should be a special insn defined for this sort of
array access, since VAX has mova* and pusha* variant
On Tue, 26 Apr 2016, Richard Biener wrote:
On Sun, Apr 24, 2016 at 7:14 PM, Marc Glisse wrote:
Hello,
trying to move a first pattern from fold_comparison.
I first tried without single_use. It brought the number of 'free' in
g++.dg/tree-ssa/pr61034.C down to 11, changed gcc.dg/sms-6.c to only
On 03/26/2016 05:56 AM, Jake Hamby wrote:
On Mar 23, 2016, at 05:56, Christos Zoulas
wrote:
In article , Jake
Hamby wrote:
Hi,
Thanks a lot for your patch. I applied it to our gcc-5 in the
tree. Unfortunately gcc-5 seems that it was never tested to even
compile. I fixed the simple compilati
On Tue, 26 Apr 2016, Bernd Edlinger wrote:
> Hi,
>
> as we all know, it's high time now to adjust the minimum supported
> gmp/mpfr/mpc versions for gcc-7.
I think updating the minimum versions (when using previously built
libraries, not in-tree) is only appropriate when it allows some cleanup i
On Tue, Apr 26, 2016 at 11:42 AM, H.J. Lu wrote:
> On Tue, Apr 26, 2016 at 9:33 AM, H.J. Lu wrote:
>> On Tue, Apr 26, 2016 at 9:27 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-26 19:20 GMT+03:00 Ilya Enkovich :
2016-04-26 19:12 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enk
On Tue, Apr 26, 2016 at 12:32 PM, Bernd Schmidt wrote:
> On 04/26/2016 08:35 PM, H.J. Lu wrote:
>>
>> This
>>
>> /* { dg-final { scan-assembler-times "vmovdqa64\[
>> \\t\]+\[^\{\n\]*%ymm\[0-9\]+\[^\nxy\]*\\(.{5}(?:\n|\[ \\t\]+#)" 1 {
>> target nonpic } } } */
>>
>> fails on x32 since x32 with 32-b
On 04/26/2016 08:35 PM, H.J. Lu wrote:
This
/* { dg-final { scan-assembler-times "vmovdqa64\[
\\t\]+\[^\{\n\]*%ymm\[0-9\]+\[^\nxy\]*\\(.{5}(?:\n|\[ \\t\]+#)" 1 {
target nonpic } } } */
fails on x32 since x32 with 32-bit pointers has (%r10d) instead of
(%r10). .{5} doesn't match.
What is this
On Tue, 26 Apr 2016, Bernd Edlinger wrote:
For instance PR libstdc++/69881: gmp.h did this:
#define __need_size_t /* tell gcc stddef.h we only want size_t */
#include /* for size_t */
I've persuaded Jonathan to work around that in libstdc++.
Of course the in-tree build does work with le
OK.
Jason
On 26.04.2016 20:39, Marc Glisse wrote:
> On Tue, 26 Apr 2016, Bernd Edlinger wrote:
>
>> as we all know, it's high time now to adjust the minimum supported
>> gmp/mpfr/mpc versions for gcc-7.
>>
>> So this attached patch is now targeting at only supporting the currently
>> latest relased gmp-6.1.0
On April 26, 2016 8:39:28 PM GMT+02:00, Marc Glisse
wrote:
>On Tue, 26 Apr 2016, Bernd Edlinger wrote:
>
>> as we all know, it's high time now to adjust the minimum supported
>> gmp/mpfr/mpc versions for gcc-7.
>>
>> So this attached patch is now targeting at only supporting the
>currently
>> lat
On Tue, Apr 26, 2016 at 9:33 AM, H.J. Lu wrote:
> On Tue, Apr 26, 2016 at 9:27 AM, Ilya Enkovich wrote:
>> 2016-04-26 19:20 GMT+03:00 Ilya Enkovich :
>>> 2016-04-26 19:12 GMT+03:00 H.J. Lu :
On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enkovich
wrote:
> 2016-04-26 18:39 GMT+03:00 H.J. Lu
On 26.04.2016 20:29, Jakub Jelinek wrote:
> On Tue, Apr 26, 2016 at 06:23:17PM +, Bernd Edlinger wrote:
>> as we all know, it's high time now to adjust the minimum supported
>> gmp/mpfr/mpc versions for gcc-7.
>
> I'm not saying we shouldn't bump the minimum supported versions, but bumping
> th
On Tue, Apr 26, 2016 at 11:31 AM, Bernd Schmidt wrote:
> On 04/26/2016 08:21 PM, Richard Sandiford wrote:
>>
>> "H.J. Lu" writes:
>>>
>>> I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset
>>> optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128
>>> to keep the OI
On Tue, 26 Apr 2016, Bernd Edlinger wrote:
as we all know, it's high time now to adjust the minimum supported
gmp/mpfr/mpc versions for gcc-7.
So this attached patch is now targeting at only supporting the currently
latest relased gmp-6.1.0, mpfr-3.1.4 and mpc-1.0.3, instead of trying
to suppor
On Tue, Apr 26, 2016 at 5:26 AM, Bernd Schmidt wrote:
> On 01/29/2016 01:19 PM, Uros Bizjak wrote:
>>>
>>> * gcc.target/i386/avx512bw-vptestmb-1.c: Correct [xyz]mm register
>>> number scans.
>>> * gcc.target/i386/avx512bw-vptestmw-1.c: Likewise.
>>> * gcc.target/i386/avx512bw-vptestnmb-1.c: Likewi
Another style nit on top of the ones already posted, sorry:
tbsaunde+...@tbsaunde.org writes:
> +void
> +print_rtx_insn_vec (FILE *file, const vec &vec)
> +{
> + fputc('{', file);
missing space before '('.
Richard
On 04/26/2016 08:21 PM, Richard Sandiford wrote:
"H.J. Lu" writes:
I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset
optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128
to keep the OI and XI modes from confusing the compiler into thinking
that these modes could
On Tue, Apr 26, 2016 at 06:23:17PM +, Bernd Edlinger wrote:
> as we all know, it's high time now to adjust the minimum supported
> gmp/mpfr/mpc versions for gcc-7.
I'm not saying we shouldn't bump the minimum supported versions, but bumping
them immediately to the latest releases is IMHO undes
Hi,
as we all know, it's high time now to adjust the minimum supported
gmp/mpfr/mpc versions for gcc-7.
So this attached patch is now targeting at only supporting the currently
latest relased gmp-6.1.0, mpfr-3.1.4 and mpc-1.0.3, instead of trying
to support all previous versions, especially in-tr
"H.J. Lu" writes:
> I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset
> optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128
> to keep the OI and XI modes from confusing the compiler into thinking
> that these modes could actually be used for computation. But the
Bernd Schmidt writes:
> On 01/01/2016 07:02 PM, Hans-Peter Nilsson wrote:
>> On Tue, 1 Dec 2015, Bernd Schmidt wrote:
>
>>> The automatic Makefile approach might look something like this. The effect
>>> is
>>> similar to what happens when you edit tm.texi.in, except the build would not
>>> be int
Jason.
we currently clone constexpr function bodies when evaluating them (via the reuse
cache that caused such fun). The cloning is necessary so decls in different
(recursive) evaluations are distinct. We only need to clone for recursive
evaluations though -- the outermost evaluation could u
On Tue, Apr 26, 2016 at 9:27 AM, Ilya Enkovich wrote:
> 2016-04-26 19:20 GMT+03:00 Ilya Enkovich :
>> 2016-04-26 19:12 GMT+03:00 H.J. Lu :
>>> On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enkovich
>>> wrote:
2016-04-26 18:39 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich
On Tue, Apr 26, 2016 at 9:20 AM, Ilya Enkovich wrote:
> 2016-04-26 19:12 GMT+03:00 H.J. Lu :
>> On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-26 18:39 GMT+03:00 H.J. Lu :
On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich
wrote:
> 2016-04-26 18:12 GMT+03:00 H.J
On 04/01/2016 05:37 AM, Bernd Schmidt wrote:
Cc'ing Matt Thomas who is listed as the vax maintainer; most of the
patch should be reviewed by him IMO. If he is no longer active I'd
frankly rather deprecate the port rather than invest effort in keeping
it running.
Index: gcc/except.c
2016-04-26 19:20 GMT+03:00 Ilya Enkovich :
> 2016-04-26 19:12 GMT+03:00 H.J. Lu :
>> On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-26 18:39 GMT+03:00 H.J. Lu :
On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich
wrote:
> 2016-04-26 18:12 GMT+03:00 H.J. Lu :
>
On 04/04/2016 08:51 AM, Maciej W. Rozycki wrote:
On Thu, 31 Mar 2016, Jake Hamby wrote:
There's one more thing that's broken in the VAX backend which I'd
*really* like to fix: GCC can't compile many of its own files at -O2, as
well as a few other .c files in the NetBSD tree, because it can't ex
2016-04-26 19:12 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enkovich wrote:
>> 2016-04-26 18:39 GMT+03:00 H.J. Lu :
>>> On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich
>>> wrote:
2016-04-26 18:12 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 8:05 AM, Ilya Enkovich
On 04/26/16 11:14, Wilco Dijkstra wrote:
Evandro Menezes wrote:
True, but the results when running on A53 could be quite different.
GCC is ~1.2% faster on Cortex-A53 built for generic, but there is no
difference in perlbench.
Looks good, then. Fine by me.
Thanks for your patience,
--
Evand
Evandro Menezes wrote:
>
> True, but the results when running on A53 could be quite different.
GCC is ~1.2% faster on Cortex-A53 built for generic, but there is no
difference in perlbench.
Wilco
On Tue, Apr 26, 2016 at 9:07 AM, Ilya Enkovich wrote:
> 2016-04-26 18:39 GMT+03:00 H.J. Lu :
>> On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-26 18:12 GMT+03:00 H.J. Lu :
On Tue, Apr 26, 2016 at 8:05 AM, Ilya Enkovich
wrote:
> 2016-04-26 17:55 GMT+03:00 H.J
2016-04-26 18:39 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich wrote:
>> 2016-04-26 18:12 GMT+03:00 H.J. Lu :
>>> On Tue, Apr 26, 2016 at 8:05 AM, Ilya Enkovich
>>> wrote:
2016-04-26 17:55 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 7:15 AM, Ilya Enkovich
On 03/27/2016 04:09 PM, Jake Hamby wrote:
Thank you for the offer. I already tested it on an Amiga 3000 w/
68040 card when I made the fix. The bug manifested as the
cross-compiler crashing with a failure to find a suitable insn,
because it couldn’t find the correct FP instruction to expand to. I
On Tue, Apr 26, 2016 at 9:04 AM, Bernd Schmidt wrote:
> On 04/25/2016 07:55 PM, Jason Merrill wrote:
>>
>> On 04/25/2016 05:07 AM, Bernd Schmidt wrote:
>>>
>>> +if (TREE_CODE (arg2) == CONST_DECL)
>>> + arg2 = DECL_INITIAL (arg2);
>>> +int literal_mask = ((!!integer_zerop
On Tue, 26 Apr 2016, Richard Biener wrote:
On Sun, Apr 24, 2016 at 7:42 PM, Marc Glisse wrote:
Hello,
the first part is something that was discussed last stage3, and Jakub argued
in favor of single_use. The second part is probably less useful, it notices
that if we manually check for overflow
Fixed.
Jason
On Tue, Apr 26, 2016 at 5:46 AM, Andreas Schwab wrote:
> /usr/local/gcc/gcc-20160426/gcc/testsuite/c-c++-common/cpp/pr63831-1.c:5:14:
> error: size of array 'T1' is negative
> /usr/local/gcc/gcc-20160426/gcc/testsuite/c-c++-common/cpp/pr63831-1.c:13:14:
>
On 04/26/2016 05:41 PM, Jakub Jelinek wrote:
On Tue, Apr 26, 2016 at 03:13:32PM +0200, Bernd Schmidt wrote:
On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
^
../../gcc/reorg.c:1413:25: warning: matches this ‘i’ under old rules
for (unsigned int i = len - 1; i < len; i--)
On 03/28/2016 04:29 PM, Jake Hamby wrote:
I have some bad news and some good news. The bad news is that there
has been a nasty optimizer bug lurking in the VAX backend for GCC for
many years, which has to do with over-optimistic removal of necessary
tst/cmp instructions under certain circumstance
On Tue, Apr 26, 2016 at 03:13:32PM +0200, Bernd Schmidt wrote:
> On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
> >^
> >../../gcc/reorg.c:1413:25: warning: matches this ‘i’ under old rules
> >for (unsigned int i = len - 1; i < len; i--)
> > ^
>
> Oh, and al
On Tue, Apr 26, 2016 at 8:21 AM, Ilya Enkovich wrote:
> 2016-04-26 18:12 GMT+03:00 H.J. Lu :
>> On Tue, Apr 26, 2016 at 8:05 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-26 17:55 GMT+03:00 H.J. Lu :
On Tue, Apr 26, 2016 at 7:15 AM, Ilya Enkovich
wrote:
> 2016-04-26 17:07 GMT+03:00 H.J
I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset
optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128
to keep the OI and XI modes from confusing the compiler into thinking
that these modes could actually be used for computation. But the OI
and XI modes can be used
On 03/26/2016 06:02 AM, Jake Hamby wrote:
As an added bonus, I see that my patch set also included an old m68k
patch that had been sitting in my tree, which fixes a crash when
-m68040 is defined. I may have submitted it to port-m68k before. It
hasn’t been tested with the new compiler either. Here
On Tue, Apr 26, 2016 at 2:35 AM, Richard Biener wrote:
> On Tue, 26 Apr 2016, Uros Bizjak wrote:
>
>> On Tue, Apr 26, 2016 at 11:17 AM, Richard Biener wrote:
>> > On Mon, 25 Apr 2016, Uros Bizjak wrote:
>> >
>> >> On Mon, Apr 25, 2016 at 4:47 PM, H.J. Lu wrote:
>> >> > On Mon, Apr 25, 2016 at 7:
2016-04-26 18:12 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 8:05 AM, Ilya Enkovich wrote:
>> 2016-04-26 17:55 GMT+03:00 H.J. Lu :
>>> On Tue, Apr 26, 2016 at 7:15 AM, Ilya Enkovich
>>> wrote:
2016-04-26 17:07 GMT+03:00 H.J. Lu :
> On Mon, Apr 25, 2016 at 9:13 AM, Ilya Enkovich
On 04/26/2016 03:17 AM, Richard Biener wrote:
On Mon, 25 Apr 2016, Uros Bizjak wrote:
On Mon, Apr 25, 2016 at 4:47 PM, H.J. Lu wrote:
On Mon, Apr 25, 2016 at 7:18 AM, Uros Bizjak wrote:
On Mon, Apr 25, 2016 at 2:51 PM, H.J. Lu wrote:
Tested on Linux/x86-64. OK for trunk?
+ /* FIXME:
On 04/19/2016 01:24 AM, Sebastian Huber wrote:
gcc/
* config/rtems.h (LIB_SPEC): Add -latomic.
libatomic/
* configure.tgt (*-*-rtems*): New supported target.
* config/rtems/host-config.h: New file.
* config/rtems/lock.c: Likewise.
IMHO, as the rtems port maintai
On Tue, Apr 26, 2016 at 8:05 AM, Ilya Enkovich wrote:
> 2016-04-26 17:55 GMT+03:00 H.J. Lu :
>> On Tue, Apr 26, 2016 at 7:15 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-26 17:07 GMT+03:00 H.J. Lu :
On Mon, Apr 25, 2016 at 9:13 AM, Ilya Enkovich
wrote:
> 2016-04-25 18:27 GMT+03:00 H.J
2016-04-26 17:55 GMT+03:00 H.J. Lu :
> On Tue, Apr 26, 2016 at 7:15 AM, Ilya Enkovich wrote:
>> 2016-04-26 17:07 GMT+03:00 H.J. Lu :
>>> On Mon, Apr 25, 2016 at 9:13 AM, Ilya Enkovich
>>> wrote:
2016-04-25 18:27 GMT+03:00 H.J. Lu :
>
> Ilya, can you take a look?
>
> Thanks.
On 04/26/2016 07:08 AM, Jakub Jelinek wrote:
Hi!
I've noticed a warning during bootstrap:
../../gcc/reorg.c: In function ‘void try_merge_delay_insns(rtx_insn*,
rtx_insn*)’:
../../gcc/reorg.c:1431:12: warning: name lookup of ‘i’ changed
for (i = 0; i < XVECLEN (PATTERN (insn), 0); i++)
This patch improves the location info for -Wnested-externs.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2016-04-26 Marek Polacek
PR c/70791
* c-decl.c (pushdecl): Pass LOCUS down to warning.
* gcc.dg/Wnested-externs-2.c: New test.
diff --git gcc/c/c-de
On Tue, Apr 26, 2016 at 7:15 AM, Ilya Enkovich wrote:
> 2016-04-26 17:07 GMT+03:00 H.J. Lu :
>> On Mon, Apr 25, 2016 at 9:13 AM, Ilya Enkovich
>> wrote:
>>> 2016-04-25 18:27 GMT+03:00 H.J. Lu :
Ilya, can you take a look?
Thanks.
--
H.J.
>>>
>>> Hi,
>>>
>>> Algo
On Tue, 26 Apr 2016, Marek Polacek wrote:
> Ah, right, that revealed two more places that were missing the
> c_parser_maybe_reclassify_token call.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
> On 04/25/2016 09:01 PM, Matthias Klose wrote:
> > please could you make the shebang python3? Not sure if it's good to replace
> > one old implementation with a soon to become old implementation.
> >
> > Matthias
>
> Sure, thanks for pointing out.
>
> Attaching v2, where I changed:
> + switche
2016-04-26 17:07 GMT+03:00 H.J. Lu :
> On Mon, Apr 25, 2016 at 9:13 AM, Ilya Enkovich wrote:
>> 2016-04-25 18:27 GMT+03:00 H.J. Lu :
>>>
>>> Ilya, can you take a look?
>>>
>>> Thanks.
>>>
>>> --
>>> H.J.
>>
>> Hi,
>>
>> Algorithmic part of the patch looks OK to me except the following piece of
>>
On Fri, Apr 15, 2016 at 12:44 PM, kugan
wrote:
> As pointed out by Richard, for signed & sign-bit-CST value range should be
> [-INF, 0] range, not a [-INF, INF] range as happens now.
>
> This patch fixes this. I bootstrapped and regression tested for
> x86-64-linux-gnu with no new regression. Is t
On Mon, Apr 25, 2016 at 9:13 AM, Ilya Enkovich wrote:
> 2016-04-25 18:27 GMT+03:00 H.J. Lu :
>>
>> Ilya, can you take a look?
>>
>> Thanks.
>>
>> --
>> H.J.
>
> Hi,
>
> Algorithmic part of the patch looks OK to me except the following piece of
> code.
>
> +/* Check REF's chain to add new insns in
When working on a couple of Cilk Plus issues lately (PRs target/60290,
target/68945), I noticed that you have to modify the libcilkplus sources
to enable various debugging output. This seems silly, and the following
patch allows defining them from the command line.
Tested on i386-pc-solaris2.12 a
On 04/25/2016 09:01 PM, Matthias Klose wrote:
> please could you make the shebang python3? Not sure if it's good to replace
> one old implementation with a soon to become old implementation.
>
> Matthias
Sure, thanks for pointing out.
Attaching v2, where I changed:
+ switched from python2 to py
Hi, thanks for answering,
2016-04-25 16:21 GMT-03:00 Jason Merrill :
> Let's create a constexpr.h rather than expose constexpr internals to all of
> the front end. Really, I'd prefer to avoid exposing them at all. Why does
> what you want to do require all this implementation detail?
Ok, you are
Evandro Menezes wrote:
>On 03/10/16 10:37, James Greenhalgh wrote:
>> Thanks for sticking with it. This is OK for GCC 7 when development
>> opens.
>>
>> Remember to mention the most recent changes in your Changelog entry
>> (Remove "fp" attribute from *movhf_aarch64 and *movtf_aarch64).
>
>
> OK to
As $SUBJECT. The reason this caught my eye on aarch64 is because
the return value register (x0) is not identical to the register in which
the hidden parameter for AArch64 is set (x8). Thus setting this to true
seems to be quite reasonable and shaves off 100 odd mov x0, x8's from
cc1 in a bootstrap
On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
^
../../gcc/reorg.c:1413:25: warning: matches this ‘i’ under old rules
for (unsigned int i = len - 1; i < len; i--)
^
Oh, and also - I flagged this while reviewing other parts of Trevor's
changes, this pat
On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
It is not fatal, but still ugly. The problem is that the function has
int i;
...
for (i = 0; ...)
...
for (unsigned int i = ... )
...
for (i = 0; ...)
This patch just declares the var in the only affected loop, so that the warning
is not e
On Tue, Apr 26, 2016 at 03:06:16PM +0200, Marek Polacek wrote:
> On Tue, Apr 26, 2016 at 11:44:52AM +, Joseph Myers wrote:
> > On Tue, 26 Apr 2016, Marek Polacek wrote:
> >
> > > This PR was reopened, because the exact same problem with treating a
> > > TYPENAME
> > > wrongly as an ID was fou
Hi!
I've noticed a warning during bootstrap:
../../gcc/reorg.c: In function ‘void try_merge_delay_insns(rtx_insn*,
rtx_insn*)’:
../../gcc/reorg.c:1431:12: warning: name lookup of ‘i’ changed
for (i = 0; i < XVECLEN (PATTERN (insn), 0); i++)
^
../../gcc/reorg.c:1263:7: warning:
On 04/25/16 13:49, Alexander Monakov wrote:
On Mon, 25 Apr 2016, Nathan Sidwell wrote:
acceptable?
No, that really doesn't sound viable. You'd need to somehow take into account
every instance where the compiler attempts to switch sections internally
(.text/.data/.bss, -ffunction-sections/-fda
On Tue, Apr 26, 2016 at 11:44:52AM +, Joseph Myers wrote:
> On Tue, 26 Apr 2016, Marek Polacek wrote:
>
> > This PR was reopened, because the exact same problem with treating a
> > TYPENAME
> > wrongly as an ID was found when using just if-clause, without an enclosing
> > for
> > loop. More
On 04/25/2016 07:55 PM, Jason Merrill wrote:
On 04/25/2016 05:07 AM, Bernd Schmidt wrote:
+if (TREE_CODE (arg2) == CONST_DECL)
+ arg2 = DECL_INITIAL (arg2);
+int literal_mask = ((!!integer_zerop (arg1) << 1)
+| (!!integer_zerop (arg2) << 2));
Are yo
On 04/26/2016 02:39 PM, Jakub Jelinek wrote:
I support that change, and -Wparentheses will still enable this, it just
gives more fine-grained control and be in line with what clang does.
Bernd, how much are you against this change?
Don't really care that much, I just don't quite see the point.
Hi!
As mentioned in the PR, the bug that has been eventually worked around
by making the C++ constexpr hash tables non-deletable is that
operand_equal_p, which is used in lots of hash tables as the equal function
(with last argument 0), may return true, i.e. a match, even for trees that
have diffe
1 - 100 of 138 matches
Mail list logo
