On 4/22/19 6:39 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
>
> [...]
>
> + "#"
> + "&& 1"
> + [(const_int 0)]
> + "{
> + /* If we do not have an RMW operand, then copy the input
> + to the output before this insn. Also modify the existing
> + insn in-place so we can have
Hi Jeff,
[...]
+ "#"
+ "&& 1"
+ [(const_int 0)]
+ "{
+ /* If we do not have an RMW operand, then copy the input
+ to the output before this insn. Also modify the existing
+ insn in-place so we can have make_field_assignment actually
+ generate a suitable extraction. */
+ if
With this testcase the code in template_args_equal to treat aliases as
distinct wasn't sufficient, because it only looked at the top level, whereas
here we have a reference to the alias. So let's also handle treating them
as distinct in structural_comptypes. For GCC 10 I have a more
As a freshly appointed maintainer I’m ready to commit my own
modulo-sched patches, but decide to ask here if there are any
objections. Maybe I should ask any additional approval at this stage?
If no, I’ll start tomorrow with committing patches 1/4 and 2/4 which are
well-formed regression
> > This issue unfortunately was not solved correctly. In that example we
> > don’t have -fmodulo-sched-allow-regmoves enabled and we should not
> > create any register moves at all.
>
> Yes, but if we do for whatever reason, we should never create register
> moves of hard registers. Because
Hello!
> I am pleased to announce that the GCC Steering Committee has
> appointed Roman Zhuykov as Modulo Scheduler maintainer.
Thanks to David and SC for the trust! I'm pleased to become SMS maintainer.
> Please join me in congratulating Roman on his new role.
> Roman, please update your
This is a generalized version of the patch I sent last week. This
variant fixes the remainder of the insv_1 and insv_2 failures on
aarch64. In combination with an updated patch from Steve this should
be enough to fix 87763.
A couple notes.
First, it re-uses combine's make_field_assignment
On Thu, 18 Apr 2019 at 16:55, Robin Dapp wrote:
>
> Hi Rainer,
>
> > I noticed you missed one piece of Iain's typeinfo.cc patch, btw.:
> >
> > diff --git a/gcc/d/typeinfo.cc b/gcc/d/typeinfo.cc
> > --- a/gcc/d/typeinfo.cc
> > +++ b/gcc/d/typeinfo.cc
> > @@ -886,7 +886,7 @@ public:
> > if
Hi,
This patch merges the libphobos library with upstream phobos b538f758a.
Fixes endian bugs in std.uni, and corrects unit-tests that failed on
version(BigEndian) targets, with good results on s390-linux-gnu.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as
Hi,
This patch merges the libdruntime sub-directory with upstream druntime 109f0f2e.
Includes more backports for extern(C) bindings, notably for DragonFly
and FreeBSD platforms. After adding the relevant compiler parts, it
should now be possible to turn on libphobos for x86_64 and i?38
> Le 21 avr. 2019 à 18:02, Steve Kargl a
> écrit :
>
> On Sat, Apr 20, 2019 at 09:51:11PM +0200, Dominique d'Humières wrote:
>> OK I missed the previous error. However I am still puzzled by (2):
>>
>> +
>> +found outside of a module
>>
>
> Why are you puzzled? Did you read the patch?
On Mon, 22 Apr 2019 at 11:15, Jakub Jelinek wrote:
>
> Not sure about libphobos D stuff, does it need to go through upstream and
> is libdruntime/gcc/deh.d compiled by compilers other than GDC?
>
It is not part of upstream, I could make that clearer in
libphobos/README.gcc if there's
Hi!
As detailed in the PR, unlike most other targets, on ARM EABI the floating
point registers are saved lazily, when EH personality routine calls
__gnu_unwind_frame (usually in the CONTINUE_UNWINDING macro).
That means the unwinder itself and the personality routines (and whatever
other
Thanks, Steve.
Committed as revision 270489.
Paul
On Fri, 19 Apr 2019 at 18:28, Steve Kargl
wrote:
>
> On Fri, Apr 19, 2019 at 06:19:00PM +0100, Paul Richard Thomas wrote:
> > The part of this patch in resolve.c had essentially already been
> > sorted out by Tobias Burnus in comment #2 of the
14 matches
Mail list logo
