-Wmissing-field-initializers says «missing initializer for member» when it obviously isn't.
Below is a sample code to test. GCC with the option allegedly says
that the line «obj = {0};» isn't initializes «mystruct::b» member to
anything, although it really is.
struct mystruct{
int a;
int b[2];
};
int main(){
mystruct obj = {1,{2,3}};
printf("%i\n", obj.b[1]);
obj = {0};
printf("%i\n", obj.b[1]);
return 0;
}
A bug?
Version: gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Re: GCC missing -flto optimizations? SPEC lbm benchmark
I never could understand, why field reordering was removed from GCC? I mean, I know that it's prohibited in C and C++, but, sure, GCC can detect whether it possibly can influence application behavior, and if not, just do the reorder. The veto is important to C/C++ as programming languages, but not to machine code that is being generated from them. As long as app can't detect that its fields were reordered through means defined by C/C++, field reordering by compiler is fine, isn't it? On Fri, 15 Feb 2019 at 12:49, Jun Ma wrote: > > Bin.Cheng 于2019年2月15日周五 下午5:12写道： > > > On Fri, Feb 15, 2019 at 3:30 AM Steve Ellcey wrote: > > > > > > I have a question about SPEC CPU 2017 and what GCC can and cannot do > > > with -flto. As part of some SPEC analysis I am doing I found that with > > > -Ofast, ICC and GCC were not that far apart (especially spec int rate, > > > spec fp rate was a slightly larger difference). > > > > > > But when I added -ipo to the ICC command and -flto to the GCC command, > > > the difference got larger. In particular the 519.lbm_r was more than > > > twice as fast with ICC and -ipo, but -flto did not help GCC at all. > > > > > > There are other tests that also show this type of improvement with -ipo > > > like 538.imagick_r, 544.nab_r, 525.x264_r, 531.deepsjeng_r, and > > > 548.exchange2_r, but none are as dramatic as 519.lbm_r. Anyone have > > > any idea on what ICC is doing that GCC is missing? Is GCC just not > > > agressive enough with its inlining? > > > > IIRC Jun did some investigation before? CCing. > > > > Thanks, > > bin > > > > > > Steve Ellcey > > > sell...@marvell.com > > ICC is doing much more than GCC in ipo, especially memory layout > optimizations. See https://software.intel.com/en-us/node/522667. > ICC is more aggressive in array transposition/structure splitting > /field reordering. However, these optimizations have been removed > from GCC long time ago. > As for case lbm_r, IIRC a loop with memory access which stride is 20 is > most time-consuming. ICC will optimize the array(maybe structure?) > and vectorize the loop under ipo. > > Thanks > Jun
Re: Enabling Ctags Tree Wide for GCC
On Wed, 11 Sep 2019 at 09:55, Nicholas Krause wrote: > > > On 9/11/19 2:30 AM, Andreas Schwab wrote: > > On Sep 11 2019, Nicholas Krause wrote: > > > >> I was wondering what is the easiest way to allow source tree wide > >> ctags. > > There is make TAGS, which uses etags. Note: over time on the internet appeared quite a few different "ctags" projects (exuberant ctags universal ctags, anjuta-ctags, you named it), AFAIK the currently maintained and developed project with the most number of supported languages is universal ctags, so I recommend using it. > Is there no way to build it for vim as thats what I would prefer to stay > with. (disclaimer: I'm just a random reader of the ML) Using ctags with any project is as simple as `ctags -R` in base directory of sources (add -e option if you use Emacs). There's no need for any complex setup, because the "tags" format is very dumb. It's just "tag name" (e.g. name of a function, struct, macro), line number, and the whole line where that name is defined. So, in particular, if you have 2 functions foo() defined, and you jump to a tag "foo()", there's no way a text editor can figure out which one "foo()" is that you wanted, so it would either jump to the first occurrence (vim does that, you need to use :tn :tp to navigate further) or present you with a list of occurences (Emacs does this). So, I doubt there's a "make tags" command, because it's one symbol bigger than "ctags -R" ;-)
Re: Enabling Ctags Tree Wide for GCC
On Wed, 11 Sep 2019 at 12:50, Hi-Angel wrote: > > On Wed, 11 Sep 2019 at 09:55, Nicholas Krause wrote: > > > > > > On 9/11/19 2:30 AM, Andreas Schwab wrote: > > > On Sep 11 2019, Nicholas Krause wrote: > > > > > >> I was wondering what is the easiest way to allow source tree wide > > >> ctags. > > > There is make TAGS, which uses etags. > > Note: over time on the internet appeared quite a few different "ctags" > projects (exuberant ctags universal ctags, anjuta-ctags, you named > it), AFAIK the currently maintained and developed project with the > most number of supported languages is universal ctags, so I recommend > using it. > > > Is there no way to build it for vim as thats what I would prefer to stay > > with. > > (disclaimer: I'm just a random reader of the ML) > > Using ctags with any project is as simple as `ctags -R` in base > directory of sources (add -e option if you use Emacs). > > There's no need for any complex setup, because the "tags" format is > very dumb. It's just "tag name" (e.g. name of a function, struct, > macro), line number, and the whole line where that name is defined. > So, in particular, if you have 2 functions foo() defined, and you jump > to a tag "foo()", there's no way a text editor can figure out which > one "foo()" is that you wanted, so it would either jump to the first > occurrence (vim does that, you need to use :tn :tp to navigate > further) or present you with a list of occurences (Emacs does this). > > So, I doubt there's a "make tags" command, because it's one symbol > bigger than "ctags -R" ;-) Worth noting btw, that ctags are a great thing if you want to quickly dive in to a project, and you're okay with their downsides, such as not being able to resolve foo() as in example. This even especially emphasized by the fact my local Universal Ctags support 100 (!!!) languages (`ctags --list-languages | wc -l`) But in the long run, if you work with a project a lot, I'd recommend looking at setting up an LSP server. All modern editors support it, including vim and emacs (some natively, some through extensions). It doesn't have the downsides of tags format, and can also provide you with things like completion or error highlighting as you type.
Re: -ffunction-sections and -fdata-sections documentation
On 13 October 2017 at 17:02, David Edelsohn wrote: > On Fri, Oct 13, 2017 at 3:06 AM, Sebastian Huber > wrote: >> Hello, >> >> I would like to update the documentation of these compiler flags and have >> some questions. The -ffunction-sections and -fdata-sections documentation >> is currently: >> >> "Place each function or data item into its own section in the output file if >> the target supports arbitrary sections. The name of the function or the name >> of the data item determines the section’s name in the output file. >> >> Use these options on systems where the linker can perform optimizations to >> improve locality of reference in the instruction space. Most systems using >> the ELF object format and SPARC processors running Solaris 2 have linkers >> with such optimizations. AIX may have these optimizations in the future. >> >> Only use these options when there are significant benefits from doing so. >> When you specify these options, the assembler and linker create larger >> object and executable files and are also slower. You cannot use |gprof| on >> all systems if you specify this option, and you may have problems with >> debugging if you specify both this option and -g." >> >> The end-of-life of Solaris 2.6 was 2006. Is it worth to mention this here? >> >> This "AIX may have these optimizations in the future." is there since at >> least 1996. What is the current AIX status? >> >> Is the "Only use these options when there are significant benefits from >> doing so. When you specify these options, the assembler and linker create >> larger object and executable files and are also slower. You cannot use >> |gprof| on all systems if you specify this option, and you may have problems >> with debugging if you specify both this option and -g." still correct on the >> systems of today? >> >> Do these options affect the code generation? > > Out of date documentation in GCC? What a surprise! > > -ffunction-sections and -fdata-sections are available on AIX. The AIX > linker rearranges sections (CSECTs) based on the call graph. The > performance impact varies. > > I'm not certain what the central question of the email message is. > > Thanks, David I think they're asking: 1. Is it worth removing the note about Solaris, given it get EOLed in 2006. 2. Does AIX's linker perform optimization "to improve locality of reference in the instruction space" 3. Does options still cause problems with debugging(when used with -g) and with gprof?
Re: Remove RMS from the GCC Steering Committee
Hello! I don't know all the details, and it surprises me nobody is asking for them. Let me be the first. On Fri, 26 Mar 2021 at 23:03, Nathan Sidwell wrote: > I’m a white dude with a British accent. > /Of course/ I have white male privilege. So, this text makes me feel sorry for the author, but at the same time makes it clear he is writing under some emotional burnout that he unambiguously shown he is experiencing. I think before making any kind of decision it would be fair to ask the author to provide references to the points he has written below. Because someone's career is at stake, so that kind of decision shouldn't be done that easily, just because someone wrote that on the internet, right? And yes, I realize that "someone" is or was a prolific developer, but so was RMS whom we are discussing here. We all do code-review to look for developer's mistakes, and I think it's useful to do the same here. So, Nathan Sidwell, could you please provide references for the problems you mentioned below? > In the before-time, I had heard that RMS was ‘difficult’, or ‘socially > awkward’. > I had ignored the true toxicity he engenders. I’m sure you have too. It > didn’t > directly affect me. I didn’t need to interact with him. I’m not a woman. It > diminishes all of us to ignore it. > Let me list a few of the cases I have found. Warning, this are extremely > offensive repugnant opinions. Mostly referenced via geekfeminism.wikia.org. > It > didn’t take me long to find them – I should have done so sooner and for that I > am sorry. > 1. 'skeptical that voluntarily pedophilia harms children.’ stallman's > own > archives 2006-mar-jun I note that children are *incapable* of consenting. > That’s what the age of consent means. > 2. 'end censorship of “child pornography”’. Stallman's archives > 2012-jul-oct.html Notice use of “quotes” to down play what is actually being > requested. > 3. 'gentle expressions of attraction’ Stallman's archives > 2012-jul-oct.html > Condoning a variant of the wolf-whistle. Unless one’s talking to one’s lover, > ‘gentle invitations for sex’ by a stranger is *grooming* (be it child or > of-age). > 4. Defends someone charged with ‘"sexual assault" on a "child" after a > session with a sex worker of age 16.’ stallman's archives 2018-jul-oct Notice > the quoting here, implying the *child* is not a child. ‘The article refers to > the sex worker as a "child", but that is not so. Elsewhere it has been > published > that she is 16 years old. That is late adolescence, not childhood.’ No, they > are > a child, that’s what the ages of majority and consent mean. > 5. The ‘St Ignatius’ ‘EMACS virgins’ non-joke. ‘The commenter writes > about > seeing the routine when she was only 15, and how RMS singled her out several > times during that performance: > He actually pointed to me in the back and proclaimed, into the mic, "A > GIRL!" causing the audience to turn and look. Mortifying. Then he proceeded to > gesture toward me every time he referred to "EMACS Virgins." (I cannot believe > that he is still doing the same talk 10+ years later.)’ > No wonder women want nothing to do with him. > 6. A business card that is completely repelling image on oreilly > 7. He knows those cards are inappropriate. He broke the code of conduct > he > helped author. wiredferret's twitter feed. > 8. I understand he’s tried to circumvent such codes of conduct by asking > women to meet him outside of the conference venue. _sagesharp_'s twitter feed. > 9. He doesn’t acknowledge the few women he has worked with ‘I don’t have > any experience working with women in programming projects; I don’t think that > any volunteered to work on Emacs or GCC.’ Completely ignoring Sandra > Loosemore, > who is a coauthor, with him, of the Glibc manual. Sandra was involved with > LISP > standardization, so I would be surprised if he was unaware of her involvement > there. As you well know, she has worked significantly on GCC, GCC has several > other women contributors, but too few for complacency. > 10. ‘My first interaction with RMS was at a hacker con at 19. He asked my > name, I gave it, whether I went to MIT (I had an MIT shirt on), and after > confirmation I did, asked me on a date. I said no. That was our entire > conversation.’ corbett's twitter feed. This is but one of many reports of > utterly inappropriate social interactions. > That list is no where near exhaustive, nor is it prioritized. As a personal > anecdote, an acquaintance of mine who was at MIT, related that she was warned > about RMS’s behaviour, and to never be alone with him. It wasn’t an isolated > warning.
Re: Please, really, make `-masm=intel` the default for x86
On Fri, 25 Nov 2022 at 09:40, LIU Hao via Gcc wrote: > One annoying thing about GCC is that, for x86 if I need to write I piece of > inline assembly then I > have to do it twice: one in AT&T syntax and one in Intel syntax. Why? A default is merely a default. I don't really see why changing that should help you specifically. A decision "which assembly syntax to use" is one that makes a project like ones you're contributing to, not GCC. If they decided to use AT&T syntax, they won't switch to Intel just because a compiler toolchain has changed their default. If you care specifically about the projects you are contributing to, then those are the ones whom you need to convince to switch to "intel" assembly syntax, not the GCC developers. Because as I said, changing a default in GCC will hardly make any change to those other projects.
