Somehow removal of the Java frontend is a little more involved than
the original pass apparently has aimed for.
Applied.
Gerald
2017-01-14 Gerald Pfeifer
* doc/frontends.texi (G++ and GCC): Remove references to Java.
Index: doc/frontends.texi
On Sun, Jan 8, 2017 at 4:29 PM, Dominique d'Humières wrote:
>> r244027 reverts r244011. Sorry for the breakage. It seems to affect
>> all i686 as well in addition to power, maybe all 32-bit hosts.
>
> For the record, I see the following failures with an instrumented r244026 (as
> in pr78672)
>
>
On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>> wrote:
>>> On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
> I was finally able to get a 32-bit i686 compiler going (my attempts to
>
On Fri, Jan 13, 2017 at 11:36 PM, Richard Biener
wrote:
> Ah, with fibers fixed there's only the fp16.c part left. Presumably LGPL
> overall is OK as well (but I'm not a lawyer either).
Seems fp16.c has the GPL3 runtime exception in place, so I believe we
are good here license-wise:
"Under Sec
On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> Bootstrapped and regression tested powerpc64-linux biarch. elf_high
> has said "Elf specific ways of loading addresses for non-PIC code"
> ^^^
> right from the inital V4 support i
On Fri, Jan 13, 2017 at 10:20:58PM +1030, Alan Modra wrote:
> Rather than using unspecs in doloop insns to stop combine creating
> these insns, use legitimate_combined_insn.
>
> I'm not sure why the original patch implementing
> legitimate_combined_insn did not store the result of recog to the ins
Palmer Dabbelt wrote:
> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> new file mode 100644
> index 000..045f6cc
> --- /dev/null
> +++ b/gcc/config/riscv/linux.h
> [...]
> +#define GLIBC_DYNAMIC_LINKER "/lib" XLEN_SPEC "/" ABI_SPEC "/ld.so.1"
[with XLEN_SPEC being either
Hi Bill,
On Fri, Jan 13, 2017 at 10:28:33AM -0600, Bill Schmidt wrote:
> There is a gap in swap optimization that does not properly handle code
> generated by __builtin_vsx_xxspltd. This is expanded into an
> UNSPEC_VSX_XXSPLTD, which is currently treated as ok to swap. It should
> instead be t
On Fri, Jan 13, 2017 at 4:58 PM, Uros Bizjak wrote:
> On Fri, Jan 13, 2017 at 12:50 PM, Alan Modra wrote:
>> Rather than using unspecs in doloop insns to stop combine creating
>> these insns, use legitimate_combined_insn.
>>
>> I'm not sure why the original patch implementing
>> legitimate_combin
On Sat, Jan 14, 2017 at 11:19 AM, Uros Bizjak wrote:
> On Fri, Jan 13, 2017 at 4:58 PM, Uros Bizjak wrote:
>> On Fri, Jan 13, 2017 at 12:50 PM, Alan Modra wrote:
>>> Rather than using unspecs in doloop insns to stop combine creating
>>> these insns, use legitimate_combined_insn.
>>>
>>> I'm not
Hi Carl,
On Fri, Jan 13, 2017 at 10:27:59AM -0800, Carl E. Love wrote:
> * config/rs6000/altivec.md: Add define to expand nabs2 types
* config/rs6000/altivec.md (nabs2): New define_expand.
> * doc/extend.texi (section 6.60.22 PowerPC AltiVec Built-in Functions):
> Update the do
On Fri, Jan 13, 2017 at 02:58:23PM -0800, Carl E. Love wrote:
> The following patch fixes an issue with the builtin test test_ne_long().
> The issue is the arguments need to be "bool long long" not "bool long"
> to get the correct 64-bit value when running in 32-bit mode.
>
> The patch has been te
This fixes all failures for 'make check-profile', which are either due
to tests that use Debug Mode (which can't be combined with Profile
Mode) or which rely on new C++17 features that the Profile Mode
containers don't support. As Profile Mode has been deprecated for GCC
7 we're unlikely to add th
On Sat, Jan 14, 2017 at 03:51:27AM -0600, Segher Boessenkool wrote:
> It also prevents combine from combining any instruction into an existing
> doloop insn (resulting in a doloop insn again). This isn't too serious,
> almost always this is just a register copy that will be optimised away
> some o
Hi!
The force_operand on complex count expression in doloop_modify can invoke
various expander routines that are assuming there is rtl unsharing after
them (which is the case for expansion). When later optimizations invoke
the expander (e.g. expand_mult in this case), they use
unshare_all_rtl_in_
On Sat, Jan 14, 2017 at 03:28:51AM -0600, Segher Boessenkool wrote:
> On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> > Bootstrapped and regression tested powerpc64-linux biarch. elf_high
> > has said "Elf specific ways of loading addresses for non-PIC code"
> >
On Sun, Jan 15, 2017 at 12:08:39AM +1030, Alan Modra wrote:
> On Sat, Jan 14, 2017 at 03:28:51AM -0600, Segher Boessenkool wrote:
> > On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> > > Bootstrapped and regression tested powerpc64-linux biarch. elf_high
> > > has said "Elf specific w
On Sat, Jan 14, 2017 at 02:46:11PM +0100, Jakub Jelinek wrote:
> See Uros' comment about the INSN_CODE (insn) = insn_code_number;.
Later email retracted the one about a crash.
> Also, I'm worried about it for another reason, after the
> if (!targetm.legitimate_combined_insn (insn))
> call the PAT
On Sun, Jan 15, 2017 at 12:37:19AM +1030, Alan Modra wrote:
> On Sat, Jan 14, 2017 at 02:46:11PM +0100, Jakub Jelinek wrote:
> > See Uros' comment about the INSN_CODE (insn) = insn_code_number;.
>
> Later email retracted the one about a crash.
>
> > Also, I'm worried about it for another reason,
OK.
On Fri, Jan 13, 2017 at 5:58 PM, Paolo Carlini wrote:
> Hi,
>
> On 13/01/2017 18:33, Jason Merrill wrote:
>>
>> On Fri, Jan 13, 2017 at 11:42 AM, Paolo Carlini
>> wrote:
>>>
>>> Hi,
>>>
>>> On 13/01/2017 15:51, Nathan Sidwell wrote:
On 01/13/2017 09:45 AM, Paolo Carlini wrote:
On Fri, Jan 13, 2017 at 5:05 PM, David Malcolm wrote:
> On Wed, 2017-01-04 at 14:58 -0500, Jason Merrill wrote:
>> On Tue, Jan 3, 2017 at 8:28 PM, David Malcolm
>> wrote:
>> > PR c++/77829 and PR c++/78656 identify an issue within the C++
>> > frontend
>> > where it issues nonsensical fix-it hint
On Sun, Jan 15, 2017 at 12:08:39AM +1030, Alan Modra wrote:
> > Have you checked if/what this changes for some bigger code?
>
> Well, the bootstrap was all langs (minus ada due to not having ada
> installed) and ppc32 multilibs were built. Plus the testsuite run
> with RUNTESTFLAGS="--target_boar
Jeff,
The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:
internal compiler error: in fill_vec_av_set, at sel-sched.c:3712
I rolled back the earlier version of DSE patch and the failures were
resolved, so it defin
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-b20170101.fr.po', h
On 01/14/2017 08:49 AM, David Edelsohn wrote:
Jeff,
The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:
internal compiler error: in fill_vec_av_set, at sel-sched.c:3712
I rolled back the earlier version of DSE p
On 12/14/2016 08:46 AM, Bernd Schmidt wrote:
On 12/12/2016 03:21 PM, Bernd Schmidt wrote:
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer
> The following patch fixes these issues for me, does it work for you?
Yes, it does!
Dominique
> Janne Blomqvist
On Sat, Jan 14, 2017 at 11:46 AM, Jeff Law wrote:
> On 01/14/2017 08:49 AM, David Edelsohn wrote:
>>
>> Jeff,
>>
>> The ppc64le bootstrap comparison may have been fixed, but I continue
>> to see the additional testsuite failures on AIX, all of the form:
>>
>> internal compiler error: in fill_vec_a
On 01/14/2017 10:03 AM, David Edelsohn wrote:
On Sat, Jan 14, 2017 at 11:46 AM, Jeff Law wrote:
On 01/14/2017 08:49 AM, David Edelsohn wrote:
Jeff,
The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:
internal
If a jump always falls through but that cannot be optimised away, like
is the case with the PowerPC bdnz insn if its jump target is the same as
the fallthrough, sched gets confused if it schedules some instructions
from before that jump instruction to behind it: it splits the
fallthrough branch, bu
On Sat, Jan 14, 2017 at 05:55:48PM +, Segher Boessenkool wrote:
> - && extract_asm_operands (PATTERN (last)) != NULL_RTX
> + && (extract_asm_operands (last) || JUMP_LABEL (last) == before)
Somehow I removed the PATTERN there; retesting with it. I'll test it
on x86 as well,
On Sat, Jan 14, 2017 at 10:46 AM, Janne Blomqvist
wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>> wrote:
On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
>> I was finall
On 01/14/2017 12:46 AM, Janne Blomqvist wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>> wrote:
On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
>> I was finally able to g
On Sat, Jan 14, 2017 at 01:09:14PM -0600, Segher Boessenkool wrote:
> On Sat, Jan 14, 2017 at 05:55:48PM +, Segher Boessenkool wrote:
> > - && extract_asm_operands (PATTERN (last)) != NULL_RTX
> > + && (extract_asm_operands (last) || JUMP_LABEL (last) == before)
>
> Somehow I r
On Fri, Jan 13, 2017 at 10:24 PM, Jeff Law wrote:
>
>
> Given a block with more than one dead store, one of which is the last
> statement in the block, the existence debugging statements can change the
> generated code which is of course bad.
>
> The problem is when I moved the code to delete the
On Sat, 14 Jan 2017, Karsten Merker wrote:
> So the actual ld.so binary should be called something like
> "ld-linux-rv.so.1" instead of just "ld.so.1". With everything
> else staying the same, that would give us a dynamic linker path
> along the lines of "/lib64/lp64f/ld-linux-rv.so.1" for an RV64
As shown in the PR, ifcvt will happily make invalid insns when given the
chance. This patch teaches it some manners.
Bootstrapped and tested on powerpc64-linux. Is this okay for trunk?
Segher
2017-01-15 Segher Boessenkool
PR rtl-optimization/78751
* ifcvt.c (find_cond_tra
On 01/14/2017 10:03 AM, David Edelsohn wrote:
On Sat, Jan 14, 2017 at 11:46 AM, Jeff Law wrote:
On 01/14/2017 08:49 AM, David Edelsohn wrote:
Jeff,
The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:
internal
On 01/14/2017 06:36 AM, Jakub Jelinek wrote:
Hi!
The force_operand on complex count expression in doloop_modify can invoke
various expander routines that are assuming there is rtl unsharing after
them (which is the case for expansion). When later optimizations invoke
the expander (e.g. expand_m
On 01/14/2017 06:55 PM, Segher Boessenkool wrote:
As shown in the PR, ifcvt will happily make invalid insns when given the
chance. This patch teaches it some manners.
Bootstrapped and tested on powerpc64-linux. Is this okay for trunk?
Segher
2017-01-15 Segher Boessenkool
PR rtl
On 01/14/2017 10:55 AM, Segher Boessenkool wrote:
If a jump always falls through but that cannot be optimised away, like
is the case with the PowerPC bdnz insn if its jump target is the same as
the fallthrough, sched gets confused if it schedules some instructions
from before that jump instructio
On Sat, Jan 14, 2017 at 09:23:45PM -0700, Jeff Law wrote:
> But isn't this a backend failing? ISTM that gen_cond_trap just calls
> standard expansion routines and they should either have generated a
> valid sequence or NULL.
>
> What in particular generated insn 64 and shouldn't it instead have
On Sat, Jan 14, 2017 at 09:47:41PM -0700, Jeff Law wrote:
> > PR target/72749
> > * cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
> > fallthrough.
> > * haifa-sched.c (dump_insn_stream): Don't crash if there is a label
> > in the currently scheduled RTL fragm
On 01/14/2017 10:27 PM, Segher Boessenkool wrote:
On Sat, Jan 14, 2017 at 09:47:41PM -0700, Jeff Law wrote:
PR target/72749
* cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
fallthrough.
* haifa-sched.c (dump_insn_stream): Don't crash if there is
On 01/14/2017 10:11 PM, Segher Boessenkool wrote:
On Sat, Jan 14, 2017 at 09:23:45PM -0700, Jeff Law wrote:
But isn't this a backend failing? ISTM that gen_cond_trap just calls
standard expansion routines and they should either have generated a
valid sequence or NULL.
What in particular genera
On Sat, Jan 14, 2017 at 10:52:04PM -0700, Jeff Law wrote:
> >>In this case is the edge a fallthru or branch edge?
> >
> >Both! You get only one edge if both jump targets are the same.
> Right. To be more precise, my question was does it have EDGE_FALLTHRU
> set?
Yes:
succ: 6 [92.5%] (
46 matches
Mail list logo
