Hi all,
One of the historical artefacts of the C language has been the burden of
lugging around multiple declarations in a single statement, with some
well-known pitfalls:
int* ptr1, ptr2;
Since ptr2 looks like a pointer but actually is not, standard coding
guidelines recommend declaring like
On Thu, Apr 19, 2018 at 8:33 AM, Thomas Koenig wrote:
> Hi Matt,
> [timings]
>
>> Intel AVX2:
>>
>> C_SW 1.4931
>> D_SW 5.4254
>> PG_D 1.0878
>> TRACER_2D 24.7418
>> REMAPPING 27.2644
>
>
>> Now I looked at GNU Fortran (7.3.0). Here my "stock" flags are quite
On 19/04/18 10:09, Manish Jain wrote:
> Hi all,
>
> One of the historical artefacts of the C language has been the burden of
> lugging around multiple declarations in a single statement, with some
> well-known pitfalls:
>
> int* ptr1, ptr2;
>
> Since ptr2 looks like a pointer but actually is n
On 19 April 2018 at 09:09, Manish Jain wrote:
> Hi all,
>
> One of the historical artefacts of the C language has been the burden of
> lugging around multiple declarations in a single statement, with some
> well-known pitfalls:
>
> int* ptr1, ptr2;
>
> Since ptr2 looks like a pointer but actually i
On 04/19/18 14:46, David Brown wrote:
> Certainly it is heavily used in existing code - making an option
> to disable it would be impractical.
Thanks for replying, Mr. Brown.
What I meant was if an option could be provided, existing code could
compile without the option, and fresh code to compi
On 19/04/18 11:27, Manish Jain wrote:
>
> On 04/19/18 14:46, David Brown wrote:
>> Certainly it is heavily used in existing code - making an option
>> to disable it would be impractical.
>
> Thanks for replying, Mr. Brown.
>
> What I meant was if an option could be provided, existing code could
> Wars have been fought over less.
I joined the list to make the request. So I just hope my war is not in a
lonely one-man army.
>> As for the problem of multiple declarations fraught in the suggestion
>> above, I would like gcc developers to please consider a compiler option
>> (--single-declar
Matthew Fortune wrote:
> If however the address of my_mem is lowered after IRA i.e. when validating
> constraints in LRA then IRA has nothing to do as the address is just a
> symbol_ref. When LRA resolves the constraint for the address it introduces
> a register for the output memory address but d
Insulting people and insisting your preferred coding style (which is
not the one used by GCC's own code, by the way) is definitely a good
way to get people interested in your proposal.
Hi,
For stack protector to be robust, at no point in time the guard against
which the canari is compared must be spilled to the stack. This is achieved
by having dedicated insn pattern for setting the canari and comparing it
against the guard which doesn't reflect at RTL what is happening. However
On 4/19/18, Manish Jain wrote:
> Hi all,
>
> One of the historical artefacts of the C language has been the burden of
> lugging around multiple declarations in a single statement, with some
> well-known pitfalls:
>
> int* ptr1, ptr2;
>
> Since ptr2 looks like a pointer but actually is not, standar
Hi,
I'd like to ask what is the expected date for GCC branching to GCC-8 release
version?
I'm mostly interested because I'd like to know when it'll be ok again to add
new features?
Or are we still able to add them?
Thanks,
Sebastian
Snapshot gcc-7-20180419 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180419/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On 04/19/2018 04:07 PM, Peryt, Sebastian wrote:
> Hi,
>
> I'd like to ask what is the expected date for GCC branching to GCC-8 release
> version?
> I'm mostly interested because I'd like to know when it'll be ok again to add
> new features?
> Or are we still able to add them?
No exact date for b
14 matches
Mail list logo
