Hi,
Let me make some comments from the kernel side.
On Thu, Apr 28, 2016 at 11:58:25AM +0100, Szabolcs Nagy wrote:
> On 28/04/16 09:47, Maxim Kuvyrkov wrote:
> >> On Apr 27, 2016, at 7:26 PM, Szabolcs Nagy wrote:
> >>
> >> with -mfentry, by default the user only has to
> >> implement the fentry
Hi,
I've committed the attached obvious patch to fix some failures
Assembler messages:
Error: can't open :-isa=sh4-up for reading: No such file or directory
with testcases which specify -mrelax on sh4-unknown-linux-gnu.
Tested with "make -k check" on sh4-unknown-linux-gnu.
Regards,
On Fri, 6 May 2016, NOC wrote:
> We have changed our mirror server setup.
>
> Could you please update the mirror list and replace:
>
> France, Gravelines: http://mirror0.babylon.network/gcc/ |
> ftp://mirror0.babylon.network/gcc/ |
> rsync://mirror0.babylon.network/gcc/, thanks to Tim Semeijn
> (
On Sat, 23 Apr 2016, Tom G. Christensen wrote:
> Latest results for 5.x
That's quite a bit. Thanks for the patch, I applied this.
(And sorry for missing this versus the other which I applied
right away.)
Gerald
On Fri, 6 May 2016, Marc Glisse wrote:
2016-05-06 Marc Glisse
gcc/
* fold-const.c (fold_binary_loc) [(X ^ Y) & Y]: Remove and merge with...
* match.pd ((X & Y) ^ Y): ... this.
((X & Y) & Y, (X | Y) | Y, (X ^ Y) ^ Y, (X & Y) & (X & Z), (X | Y)
| (X | Z), (X ^ Y
On Sun, 8 May 2016, Mikhail Maltsev wrote:
Hi!
I decided to revive this patch:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00999.html.
I addressed review comments about sign conversions. Bootstrapped and regtested
on x86_64-linux-gnu {,-m32}. OK for trunk?
Hello,
are you sure that your tra
Hello!
As exposed by r235906 [1], we should not widen DFmode memory access to
V2DFmode in the splitter.
Attached patch introduces two new patterns that use correct mode of
memory operand. These two patterns are appropriate for the
TARGET_SSE_PARTIAL_REG_DEPENDENCY splitters, as they don't need to
Hi!
I decided to revive this patch:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00999.html.
I addressed review comments about sign conversions. Bootstrapped and regtested
on x86_64-linux-gnu {,-m32}. OK for trunk?
--
Regards,
Mikhail Maltsev
gcc/testsuite/ChangeLog:
2016-05-08 Mikhail M
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 Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-6.1.0.sv.po', has just
Hi,
The attached patch converts the GET_SH_ARG_CLASS macro into a function.
No functional change.
Tested on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed as r236009.
Cheers,
Oleg
gcc/ChangeLog:
*
Hi,
The attached patch performs various cleanups in the SH code. No
functional changes.
Tested on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed as r236008.
Cheers,
Oleg
gcc/ChangeLog:
* config/sh/
On 8 May 2016 at 14:51, Ville Voutilainen wrote:
> On 8 May 2016 at 14:48, Daniel Krügler wrote:
>> Have you considered to test against decay instead of
>> remove_reference/remove_const? That would be similar to other places
>> in the standard. (I also believe that your fix actually should be
>>
On 8 May 2016 at 14:48, Daniel Krügler wrote:
> Have you considered to test against decay instead of
> remove_reference/remove_const? That would be similar to other places
> in the standard. (I also believe that your fix actually should be
> submitted as an LWG issue)
STL is about to submit the
Have you considered to test against decay instead of
remove_reference/remove_const? That would be similar to other places
in the standard. (I also believe that your fix actually should be
submitted as an LWG issue)
- Daniel
2016-05-08 13:43 GMT+02:00 Ville Voutilainen :
> Tested on Linux-PPC64.
>
Tested on Linux-PPC64.
2016-05-08 Ville Voutilainen
Avoid endless run-time recursion for copying single-element
tuples where the element type is by-value constructible
from any type.
* include/std/tuple (_TC<>::_NotSameTuple): New.
* include/std/tuple (tuple(_UElements&&.
With the recent change not to install libvtv without
--enable-vtable-verify, I noticed that gcc/g++ would still accept
-fvtable-verify without errors, only to emit obscure link-time errors
about missing vtv_*.o (which hadn't been installed in that situation
before) and libvtv.
It seems to me a muc
Hi,
The attached patch adds some rudimentary support for atomic operations.
On the original RX there is one truly atomic insn "xchg". All other
operations have to implement atomicity in some other way. One straight
forward option which is already being done on SH is to disable
interrupts for th
17 matches
Mail list logo