On Tue, 27 Mar 2018, Steve Ellcey wrote:
> Here is another libmvec question. While testing on x86 I could easily make
> a loop with calls to sin, cos, log, exp, or pow and see them vectorized when
> I compile with -Ofast. But if I try making a loop with sincos, it does not
> get vectorized. Is
Hi,
Here's a report of a successful build and install of GCC:
$ gcc-7.3.0/config.guess
x86_64-pc-linux-gnu
$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/lto-wrapper
Targ
Here is another libmvec question. While testing on x86 I could easily make
a loop with calls to sin, cos, log, exp, or pow and see them vectorized when
I compile with -Ofast. But if I try making a loop with sincos, it does not
get vectorized. Is that to be expected?
I compiled:
#define _GNU_SO
Hi,
Here's a report of a successful build and install of GCC:
$ gcc-7.3.0/config.guess
armv4tl-unknown-linux-gnueabi
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-linux-gnueabi/7.3.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with: /home/aaro/los/w
On Tue, 2018-03-27 at 08:12 +, ??? ??? wrote:
> Hello,
>
> My name is Avi Owshanko.
>
> I'm an experienced programmer (worked for IBM-HRL GC group, and EMC-
> Recoverpoint), and I wish to join in the development of GCC.
Hi Avi, welcome to GCC development!
As initial projects, I consider
Hi,
I want to add run-time support for checking for equality of
the size expressions where pointers to variable-length arrays
are required to be compatible.
I wonder if you could give some advise on how to approach
this. One general question is where this should be added.
For example, I think it
On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>
>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>> in libgcc counts how many stack frame it has to unwind and uses INCSSP
>> to pop shadow stack. This can't unwind the orig
On 03/27/2018 01:26 PM, H.J. Lu wrote:
2. Since shadow stack is never saved and restored by compiler, unwinder
in libgcc counts how many stack frame it has to unwind and uses INCSSP
to pop shadow stack. This can't unwind the original shadow stack when
the alternate shadow stack is used. _URC_N
On Tue, Mar 27, 2018 at 6:32 AM, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 8 trunk is open for regression and documentation fixes. Following
> past releases we are aiming at a first release candidate mid April though
> if you look at the quality data below that looks ambitious.
>
> So
Status
==
The GCC 8 trunk is open for regression and documentation fixes. Following
past releases we are aiming at a first release candidate mid April though
if you look at the quality data below that looks ambitious.
So please help tackling (and confirming, bisecting, reducing, etc.)
regre
On Mon, Mar 26, 2018 at 11:31 PM, Florian Weimer wrote:
> On 03/27/2018 12:43 AM, H.J. Lu wrote:
>>
>> On Linux, when alternate signal stack is used with thread cancellation,
>> _Unwind_Resume fails when it tries to unwind shadow stack from signal
>> handler on alternate signal stack. The issue i
Hello,
My name is Avi Owshanko.
I'm an experienced programmer (worked for IBM-HRL GC group, and
EMC-Recoverpoint), and I wish to join in the development of GCC.
As initial projects, I consider:
1. Adding a virtual interface for the 'toplev' class, so no file would
include 'toplev.h' (movi
12 matches
Mail list logo
