Howdy.
Am I missing something or are these two sets identical?
/* Get the lower and upper bounds of the type. */
if (TYPE_OVERFLOW_WRAPS (expr_type))
{
type_min = wi::min_value (prec, sgn);
type_max = wi::max_value (prec, sgn);
is the patch already integrated into mainline?
is this the most recent development place?
https://github.com/tkchia/gcc-ia16
On Jun 07 2018, Paul Koning wrote:
> None of these seem to use that loop optimization, with -O2 or -Os. Did I
> miss some magic switch to turn on something else that isn't on by default?
> Or is this a feature that was broken long ago and not noticed? If so, any
> hints where I might look for a
Hi Dennis,
On 08/06/2018 11:37, Dennis Luehring wrote:
is the patch already integrated into mainline?
No, it's not.
is this the most recent development place?
https://github.com/tkchia/gcc-ia16
Yes, that's the right place.
Andrew
is the patch already integrated into mainline?
No, it's not.
will that ever happen?
is this the most recent development place?
https://github.com/tkchia/gcc-ia16
Yes, that's the right place.
thx
Am 08.06.2018 um 12:59 schrieb Andrew Jenner:
Hi Dennis,
On 08/06/2018 11:37, Dennis Luehri
On 08/06/2018 12:43, Dennis Luehring wrote:
is the patch already integrated into mainline?
No, it's not.
will that ever happen?
Hard to say. There's no reason in principle why it couldn't happen, but
there's not a big demand for it, so it would require someone taking the
time and trouble t
> On Jun 8, 2018, at 6:59 AM, Andreas Schwab wrote:
>
> On Jun 07 2018, Paul Koning wrote:
>
>> None of these seem to use that loop optimization, with -O2 or -Os. Did I
>> miss some magic switch to turn on something else that isn't on by default?
>> Or is this a feature that was broken long
Hi,
As I reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
GCC for aarch64*-none-elf fails when configuring libstdc++ since
r261034 (a week ago).
The root cause is PR66203 which I reported quite some time ago, which
points to a newlib problem: on aarch64 there is no
Hi,
Linking is not taking place as the debug_function() being used is in
tree-cfg.c. How should I go about on adding in make-file considering
the dependencies?
Please find the diff file attached herewith.
Regards,
Hrishikesh
On Tue, Jun 5, 2018 at 12:38 AM, Martin Liška wrote:
> On 06/04/2018
On 06/08/2018 03:27 PM, Hrishikesh Kulkarni wrote:
> Hi,
>
> Linking is not taking place as the debug_function() being used is in
> tree-cfg.c. How should I go about on adding in make-file considering
> the dependencies?
Hi.
There's wrong declaration of the function in header file. I'll fix it s
On 06/08/2018 03:40 PM, Martin Liška wrote:
> There's wrong declaration of the function in header file. I'll fix it soon
> on trunk. Please carry on with following patch:
Fixed in r261327.
Martin
On 8 June 2018 at 14:22, Christophe Lyon wrote:
> Hi,
>
> As I reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
> GCC for aarch64*-none-elf fails when configuring libstdc++ since
> r261034 (a week ago).
Sorry for not trying to fix it, I'm travelling and not been a
On 8 June 2018 at 16:41, Jonathan Wakely wrote:
> On 8 June 2018 at 14:22, Christophe Lyon wrote:
>> Hi,
>>
>> As I reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
>> GCC for aarch64*-none-elf fails when configuring libstdc++ since
>> r261034 (a week ago).
>
> S
On Fri, 8 Jun 2018, Jonathan Wakely wrote:
> > The root cause is PR66203 which I reported quite some time ago, which
> > points to a newlib problem: on aarch64 there is no default rom
> > monitor, one has to explicitly use a --specs flag for the link to
> > succeed.
>
> I have no idea why this ca
On 8 June 2018 at 16:11, Joseph Myers wrote:
> On Fri, 8 Jun 2018, Jonathan Wakely wrote:
>
>> > The root cause is PR66203 which I reported quite some time ago, which
>> > points to a newlib problem: on aarch64 there is no default rom
>> > monitor, one has to explicitly use a --specs flag for the l
Hi,
-fdump-lto-body=foo
will dump gimple body of the function foo
foo (int a, int b)
{
[local count: 1073741825]:
_3 = a_1(D) + b_2(D);
return _3;
}
Please find the diff file attached herewith.
Regards,
Hrishikesh
On Fri, Jun 8, 2018 at 7:15 PM, Martin Liška wrote:
> On 06/08/2018 03:
On 06/08/2018 06:21 AM, Paul Koning wrote:
Interesting. The ChangeLog doesn't give any background. I suppose I should
plan to approximate the effect of this pattern with a define-peephole2 ?
The old RTL loop optimizer was replaced with a new RTL loop optimizer.
When the old one was written,
> On Jun 8, 2018, at 2:29 PM, Jim Wilson wrote:
>
> On 06/08/2018 06:21 AM, Paul Koning wrote:
>> Interesting. The ChangeLog doesn't give any background. I suppose I should
>> plan to approximate the effect of this pattern with a define-peephole2 ?
>
> The old RTL loop optimizer was replac
On 8 June 2018 at 22:46, Hrishikesh Kulkarni wrote:
> Hi,
>
> -fdump-lto-body=foo
> will dump gimple body of the function foo
>
> foo (int a, int b)
> {
>[local count: 1073741825]:
> _3 = a_1(D) + b_2(D);
> return _3;
>
> }
>
> Please find the diff file attached herewith.
@@ -53,10 +55,14
I have a question about the Aarch64 simd instructions and builtins.
I want to unpack a __Float32x4 (V4SF) variable into two __Float64x2
variables. I can get the upper part with:
__Float64x2_t a = __builtin_aarch64_vec_unpacks_hi_v4sf (x);
But I can't seem to find a builtin that would get me the
On Fri, Jun 08, 2018 at 04:01:14PM -0500, Steve Ellcey wrote:
> I have a question about the Aarch64 simd instructions and builtins.
>
> I want to unpack a __Float32x4 (V4SF) variable into two __Float64x2
> variables. I can get the upper part with:
>
> __Float64x2_t a = __builtin_aarch64_vec_unpa
On Thu, 2018-06-07 at 12:01 +0200, Richard Biener wrote:
>
> When we do our own comparisons of GCC vs. ICC on benchmarks
> like SPEC CPU 2006/2017 ICC doesn't have a big lead over GCC
> (in fact it even trails in some benchmarks) unless you get to
> "SPEC tricks" like data structure re-organizatio
On Fri, 2018-06-08 at 22:34 +0100, James Greenhalgh wrote:
>
> Are you in an environment where you can use arm_neon.h ? If so, that
> would
> be the best approach:
>
> float32x4_t in;
> float64x2_t low = vcvt_f64_f32 (vget_low_f64 (in));
> float64x2_t high = vcvt_high_f64_f32 (in);
>
> If
On Fri, Jun 8, 2018 at 1:12 PM, Paul Koning wrote:
> Thanks. I saw those sections and interpreted them as support for signal
> processor style fast hardware loops. If they can be adapted for dbra type
> looping, great. I'll give that a try.
The rs6000 port uses it for bdnz (branch decrement
Snapshot gcc-8-20180608 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On Fri, 8 Jun 2018, Steve Ellcey wrote:
On Thu, 2018-06-07 at 12:01 +0200, Richard Biener wrote:
When we do our own comparisons of GCC vs. ICC on benchmarks
like SPEC CPU 2006/2017 ICC doesn't have a big lead over GCC
(in fact it even trails in some benchmarks) unless you get to
"SPEC tricks"
26 matches
Mail list logo
