Request for compiler option to disable multiple declarations in a single statement
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 this: int *p1, *p2; If anything, this leads to bizarre statements - very misleading for those trying to understand pointer usage in C or just read code: int i; int *j = &i; // impression: *j is being assigned &i char *k = "Text"; // impression: *k is "Text" void *fx(char *z); // impression: *fx is will accept char & return void Each of these idiosyncrasies is best avoided by retaining the space after the asterisk (and removing the one before) in a pointer declaration. This really ought to be the standard coding guideline. As for the problem of multiple declarations fraught in the suggestion above, I would like gcc developers to please consider a compiler option (--single-declarations perhaps) under which the programmer can only introduce one declaration in one statement. If such an option could be made available, it takes care of all declaration woes and lets declared types bear close resemblance to what they appear to be from signatures. Would my idea have takers on this list ? -- Thank you & Regards, Manish Jain
Re: How to get best AVX2 performance from gfortran?
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
>> boring (and all flags, not just the optimization ones):
>
>
> [Various options elided, the best was]:
>
>> GNU Haswell NoFMA Repack:
>> C_SW2.4350
>> D_SW9.7109
>> PG_D0.7869
>> TRACER_2D 163.6474
>> REMAPPING 100.6820
>>
>> So, my questions to you gurus are: Is there something I could try adding
>> to my gfortran options that might help with this discrepancy between Intel
>> AVX2 and GCC? Or perhaps I need to *remove* something (some flag kills the
>> vectorizer)?
>
> The gcc 8 release is just around the corner, and a lot of improvements
> have been made to code generation, also for AVX2. You might want to give
> the current trunk (or the soon-to-be-released) release candidate, or the
> then newly released gcc8 a spin.
>
> Second, this performance gap with respect to Intel (a factor of 6.6 for
> your TRACER_2D routine) is dramatic. If anything like this persists in gcc8,
> the only way to get this fixed is to submit a bug report.
> Profile the code, try to reduce the code to something that shows
> the the problem (and that you can put in a bug report).
Dependent on what those routines do (do they call math intrinsics like
sin or cos?) ICC has an advantage with a highly optimized vectorized
math library. You can use that from gfortran as well by using
-mveclibabi=svml and linking against libsvml.{a,so} which comes with ICC.
Unfortunately gfortran cannot exercise glibcs libmvec at the moment.
Richard.
> Regards
>
> Thomas
Re: Request for compiler option to disable multiple declarations in a single statement
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 not, standard coding > guidelines recommend declaring like this: > > int *p1, *p2; > > If anything, this leads to bizarre statements - very misleading for > those trying to understand pointer usage in C or just read code: > > int i; > int *j = &i; // impression: *j is being assigned &i > > char *k = "Text"; // impression: *k is "Text" > > void *fx(char *z); // impression: *fx is will accept char & return void > > > Each of these idiosyncrasies is best avoided by retaining the space > after the asterisk (and removing the one before) in a pointer > declaration. This really ought to be the standard coding guideline. > > As for the problem of multiple declarations fraught in the suggestion > above, I would like gcc developers to please consider a compiler option > (--single-declarations perhaps) under which the programmer can only > introduce one declaration in one statement. If such an option could be > made available, it takes care of all declaration woes and lets declared > types bear close resemblance to what they appear to be from signatures. > > Would my idea have takers on this list ? > This is something that will cause a lot of mixed feelings. Some people see it as a very good thing that you can have multiple declarations of connected types in the same declaration - others see it as a very bad idea. Certainly it is heavily used in existing code - making an option to disable it would be impractical. What I would suggest as a better compromise would be a warning, with different levels: -Wmulti-declaration=0 (the default): int a, b, c;// OK int a, *b, c; // OK int *a, *b, *c; // OK int a[10], b[10]; // OK -Wmulti-declaration=1 (Allow declarations of the same type only): int a, b, c;// OK int a, *b, c; // Warn int *a, *b, *c; // OK int a[10], b[10]; // OK -Wmulti-declaration=2 (Disallow multiple declarations) int a, b, c;// Warn int a, *b, c; // Warn int *a, *b, *c; // Warn int a[10], b[10]; // Warn A warning can always be turned into an error if you want. Personally, I would use such a warning option at level 1, but not at level 2. I know others would use more or less. (I have no idea if this is something that would be practical or easy to implement in gcc, or if there is anyone who would be willing to do the job. I am just trying to refine the suggestion into something that could have a wider appeal.)
Re: Request for compiler option to disable multiple declarations in a single statement
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 is not, standard coding > guidelines recommend declaring like this: > > int *p1, *p2; > > If anything, this leads to bizarre statements - very misleading for > those trying to understand pointer usage in C or just read code: > > int i; > int *j = &i; // impression: *j is being assigned &i > > char *k = "Text"; // impression: *k is "Text" > > void *fx(char *z); // impression: *fx is will accept char & return void I don't think these are such common misconceptions that a new compiler flag would help, especially since that new flag would not be the default so most beginners would not use it. > Each of these idiosyncrasies is best avoided by retaining the space > after the asterisk (and removing the one before) in a pointer > declaration. This really ought to be the standard coding guideline. Wars have been fought over less. > As for the problem of multiple declarations fraught in the suggestion > above, I would like gcc developers to please consider a compiler option > (--single-declarations perhaps) under which the programmer can only > introduce one declaration in one statement. If such an option could be > made available, it takes care of all declaration woes and lets declared > types bear close resemblance to what they appear to be from signatures. It might be appropriate as a warning option, for those who choose to enforce that style. And of course there are cases where avoiding multiple declarations changes the meaning of the code, such as this idiomatic C++: for (auto first = c.begin(), last = c.end(); first != last; ++first)
Re: Request for compiler option to disable multiple declarations in a single statement
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 compile with the switch enabled (as per user discretion, of course - no compulsion either way anywhere). If the option garners wide recognition / usage, over a period of time the standard pointer declaration could be fixed to everyone's happiness: int* p; // which really is what it should be in all propriety The current declaration style really sickens me, particularly when trying to explain C pointers to others. Manish Jain
Re: Request for compiler option to disable multiple declarations in a single statement
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 > compile without the option, and fresh code to compile with the switch > enabled (as per user discretion, of course - no compulsion either way > anywhere). If it were an option for what code is acceptable, rather than a warning, you would have trouble with header files that had multiple declarations - it would quickly become unusable. A warning is much friendlier in such contexts. (In particular, warnings like that are by default disabled for system headers.) > > If the option garners wide recognition / usage, over a period of time > the standard pointer declaration could be fixed to everyone's happiness: > > int* p; // which really is what it should be in all propriety That is a /highly/ subjective view. I too prefer one declaration per line in most cases, but I am not the only C programmer around - you can't consider your personal opinion to be the only right one. > > The current declaration style really sickens me, particularly when > trying to explain C pointers to others. > There is nothing to stop you using the style you want in the code you write yourself. This warning would simply be a way to mark breaking a code style guiderule. It may be better implemented in a plugin, rather than in gcc itself.
Re: Request for compiler option to disable multiple declarations in a single statement
> 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-declarations perhaps) under which the programmer can only >> introduce one declaration in one statement. If such an option could be >> made available, it takes care of all declaration woes and lets declared >> types bear close resemblance to what they appear to be from signatures. > > It might be appropriate as a warning option, for those who choose to > enforce that style. Fine - if anyone could create a warning specifically for multiple declarations (and which can be turned into Werror such that it breaks code for multiple declarations -- and absolutely nothing else), that serves the purpose as well as an option like --single-declarations. I don't even mind if programmers have to use pragma directives. The end result I want is the programmer to have some way of getting the compiler break code rather than compile the code at all. Right now, it is a real mess that just builds on a simple oversight on the part of Dennis Ritchie decades back. The most maddening way to address that mess is drop the space between the asterisk and the pointer variable in a declaration. Every single thing about pointer usage goes downhill from that clumsy fix. > And of course there are cases where avoiding multiple declarations > changes the meaning of the code, such as this idiomatic C++: > > for (auto first = c.begin(), last = c.end(); first != last; ++first) > 'idiomatic C++' looks more like 'idiotic C++' ever since v11/v14 came out. Does Stroustroupe have nothing better to do these days than to make a mockery of the once acceptable language ? I like C++ these days just as a seafarer likes a close encounter with a shark.
Re: Register conflicts between output memory address and output register
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 does not seem to acknowledge > any conflict with the output register (bar) it can therefore end up > using the same register for the output memory address as the output registe= > r. > This leads to the obvious problem if the ASM updates %1 before %0 as it will > corrupt the address. > > This can of course be worked around by making (bar) an early clobber or an > in/out but this does seem unnecessary. > > The question is... Should LRA recognise a conflict between the registers > involved in the address portion of an output memory operand and any output > register operands or is this a case where you strictly have to use early > clobber. Usually, the constraints are interpreted under the assumption that inputs and output are used atomically, as if by a single target instruction. If you consider an instruction that both updates memory and sets a register, then most architectures will indeed allow for the output register to be the same as one of the address registers for the memory operand, and therefore GCC should allow this allocation. In those cases where this is not true, e.g. because your inline asm does in fact use multiple instructions which set the two outputs at different times, then you should indeed use the earlyclobber flag -- that is exactly what this flag is intended for. The GCC documentation of the earlyclobber flag says: Means (in a particular alternative) that this operand is an earlyclobber operand, which is written before the instruction is finished using the input operands. Therefore, this operand may not lie in a register that is read by the instruction or as part of any memory address. Note in particular "... as part of any memory address." Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: Request for compiler option to disable multiple declarations in a single statement
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.
Stack protector: leak of guard's address on stack
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 computing the address of the guard is done using standard movsi pattern and can thus be spilled (see PR85434). I'm reaching out to the community for ideas on how to avoid this. Spilling is more likely in the context of PIC where the address is loaded from the GOT and is thus not rematerialized. Likewise CSE make things worse by reusing the address computed in the prologue to set the canari later in the epilogue when performing the check, thereby being sensitive to peak register pressure in the function. Aarch64 and I believe x86 backends don't have the CSE issue for PIC because the GOT access is represented by an outer UNSPEC whereas arm backend represent it by a MEM of an UNSPEC. I think all targets are prone to issues in theory because the scheduler could reorder the GOT access away from the guard/canari comparison which would make a spill possible. So far my feeling is that we would need new patterns that also cover the guard's address computation but that would make such a pattern quite complex to cover all the possible address. Thoughts? Best regards, Thomas
Re: Request for compiler option to disable multiple declarations in a single statement
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, standard coding > guidelines recommend declaring like this: > > int *p1, *p2; > > If anything, this leads to bizarre statements - very misleading for > those trying to understand pointer usage in C or just read code: > > int i; > int *j = &i; // impression: *j is being assigned &i > > char *k = "Text"; // impression: *k is "Text" > > void *fx(char *z); // impression: *fx is will accept char & return void > > > Each of these idiosyncrasies is best avoided by retaining the space > after the asterisk (and removing the one before) in a pointer > declaration. This really ought to be the standard coding guideline. > > As for the problem of multiple declarations fraught in the suggestion > above, I would like gcc developers to please consider a compiler option > (--single-declarations perhaps) under which the programmer can only > introduce one declaration in one statement. If such an option could be > made available, it takes care of all declaration woes and lets declared > types bear close resemblance to what they appear to be from signatures. > > Would my idea have takers on this list ? > > -- > Thank you & Regards, > Manish Jain > Clang has a warning flag called -Wcomma to warn about code like this; perhaps GCC could add it as well.
GCC-8 branching
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
gcc-7-20180419 is now available
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-branch revision 259512 You'll find: gcc-7-20180419.tar.xzComplete GCC SHA256=6df4a47efdc14d88c8a9e96b104aba3ce5a9c2b176d1997468129f32710eda55 SHA1=2e5dcccb08409a1950d95f3784d87881bfbaf462 Diffs from 7-20180412 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC-8 branching
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 branching, but it should be soon. New features can't be added until after the branch has been created. Release managers may also ask for a short delay for large scale changes that adversely affect their ability to backport fixes from the trunk to the release branch. jeff
