Re: On US corporate influence over Free Software and the GCC Steering Committee
> Here the relevant excerpt (but please go chech the quotation): > > "As an IBM employee, you are not allowed to use your gmail account to work > in any way on VNIC. You are not allowed to use your personal email account > as a "hobby". You are an IBM employee 100% of the time. > Please remove yourself completely from the maintainers file. I grant you a 1 > time exception on contributions to VNIC to make this change." > > > This is happened yesterday (literally). Troubling indeed, but this might just be an overzealous manager. IBM, like other corporations, has made significant technical contributions to GCC over the years, for example the scheduler and the vectorizer, and thus has assigned the copyright of these contributions to the FSF. -- Eric Botcazou
Re: removing toxic emailers
On Tue, 20 Apr 2021 at 04:47, Frosku wrote:
>
> On Mon Apr 19, 2021 at 4:06 PM BST, Thomas Rodgers wrote:
> > Google doesn't pay anybody to work on GCC all day. You know nothing
> > about
> > GCC or the "problems" you're complaining about. Your input to this
> > conversation is not constructive.
>
> This feels like that moment in 8Mile, "pay attention, you're saying the
> same shit that he said." The personal insults and technical semantic
> arguments are testament to the fact that you're not willing or not able
> to argue the points. It's quite incredible that two people have replied
> to the same multiple-hundred word e-mail about a broad issue of trying
> to gatekeep discussion and both have focused on semantics ("it's not
> *all* day"). I will remember not to use hyperbole in future for fear of
> it being taken literally and used as an excuse to dodge the point.
Check the git logs, Google employees are minor contributors these
days. The GPLv3 scared Google away from GCC years ago.
I've unsubscribed from this list now, so please stop CCing me. I'm not
interested in continuing this.
Re: On US corporate influence over Free Software and the GCC Steering Committee
Obviously the dude was not Eric Raymond, because he would have sent the IBM Fuckhead an appropriate reply. These are the developers at IBM, who after being watched by the IBM Panopticon, they obey! Now repeat after me, "Whenever I hear the voice say, 'Now, listen to me, ' I will obey." "When I hear the voice say, 'Now, listen to me, ' I will obey." > Sent: Tuesday, April 20, 2021 at 7:37 PM > From: "Eric Botcazou" > To: "Giacomo Tesio" > Cc: gcc@gcc.gnu.org > Subject: Re: On US corporate influence over Free Software and the GCC > Steering Committee > > > Here the relevant excerpt (but please go chech the quotation): > > > > "As an IBM employee, you are not allowed to use your gmail account to work > > in any way on VNIC. You are not allowed to use your personal email account > > as a "hobby". You are an IBM employee 100% of the time. > > Please remove yourself completely from the maintainers file. I grant you a 1 > > time exception on contributions to VNIC to make this change." > > > > > > This is happened yesterday (literally). > > Troubling indeed, but this might just be an overzealous manager. IBM, like > other corporations, has made significant technical contributions to GCC over > the years, for example the scheduler and the vectorizer, and thus has assigned > the copyright of these contributions to the FSF. > > -- > Eric Botcazou > > >
Re: On US corporate influence over Free Software and the GCC Steering Committee
On 20/04/2021 08:54, Giacomo Tesio wrote: > Hi GCC developers, > > just to further clarify why I think the current Steering Committee is highly > problematic, > I'd like you to give a look at this commit > message over Linux MAINTAINERS > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e > > Here the relevant excerpt (but please go chech the quotation): > > "As an IBM employee, you are not allowed to use your gmail account to work in > any way > on VNIC. You are not allowed to use your personal email account as a "hobby". > You > are an IBM employee 100% of the time. > Please remove yourself completely from the maintainers file. I grant you a 1 > time > exception on contributions to VNIC to make this change." > > > This is happened yesterday (literally). I know nothing of this case other than the link you sent. But it seems to me that the complaint from IBM is that the developer used his private gmail address here rather than his IBM address. It is normal practice in most countries that if you are employed full time to do a certain type of job, then you can't do the same kind of work outside of the job without prior arrangement with the employer. That applies whether it is extra paid work, or unpaid (hobby) work. This is partly because it can quickly become a conflict of interests, and partly because you are supposed to be refreshed and ready for work each day and not tired out from an all-night debugging session on a different project. Usually employers are quite flexible about these things unless there is a clear conflict of interests (like working on DB2 during the day, and Postgresql in the evening). Some employers prefer to keep things standardised and rigid. A company like IBM that is heavily involved in Linux kernel coding will want to keep their copyrights and attributions clear. So if they have an employee that is working on this code - whether it is part of their day job or not - it makes sense to insist that attributions, maintainer contact information and copyrights all make it clear that the work is done by an IBM employee. It is not only IBM's right to insist on this, it might also be a legal obligation. (It is quite possible that this guy's manager could have expressed things a bit better - we are not privy to the rest of the email or any other communication involved.) This is precisely why copyright assignment for the FSF can involve complicated forms and agreements from contributors' employers. > > And while this is IBM, the other US corporations with affiliations in > the Steering Committee are no better: > https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > I can't see any relevance in that post other than your "big corporations are completely evil because there are examples of them being bad" comments. > I can understand that some of you consider working for such corporations "a > joy". > But for the rest of us, and to most people outside the US, their influence > over the leadership of GCC is a threat. Please stop claiming to speak for anyone but yourself. You certainly do not speak for /me/. I don't work for "such corporations", I am outside the US, but I do not see IBM or others having noticeable influence over gcc and thus there is no threat. David
Re: On US corporate influence over Free Software and the GCC Steering Committee
You got to understand what an employee 100% of the time means. It means to be 100% Employer-Owned - It is the Culture of Ownership. But the tyrannical double standard do-gooders and the continued pretense that they're trying to help people in this society (e.g. women, minorities, free software, etc) is a lot more destructive. Am pleased to know you are allowed to do, say, think, etc. whatever you want to, without being controlled or limited. Have had developers here who have contacted me privately to tell me how amazed they are seeing me pushing my ideas about what software and project administration is. People who describe me as toxic, abusive, entitled, a jerk, a troll, a donkey and a twit... A very long list indeed. Because the only people they are willing to accept are people like themselves. My guess is that in their meetings, they sit around discussing who is worthy to join this wonderful group that they are. Sitting around trying to decide who would get to be allowed into this developer group. The whole thing is rotten because the purpose of the group is mostly centered on deciding who could have this honor. > Sent: Tuesday, April 20, 2021 at 9:42 PM > From: "David Brown" > To: "Giacomo Tesio" , gcc@gcc.gnu.org > Subject: Re: On US corporate influence over Free Software and the GCC > Steering Committee > > On 20/04/2021 08:54, Giacomo Tesio wrote: > > Hi GCC developers, > > > > just to further clarify why I think the current Steering Committee is > > highly problematic, > > I'd like you to give a look at this commit > > message over Linux MAINTAINERS > > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e > > > > Here the relevant excerpt (but please go chech the quotation): > > > > "As an IBM employee, you are not allowed to use your gmail account to work > > in any way > > on VNIC. You are not allowed to use your personal email account as a > > "hobby". You > > are an IBM employee 100% of the time. > > Please remove yourself completely from the maintainers file. I grant you a > > 1 time > > exception on contributions to VNIC to make this change." > > > > > > This is happened yesterday (literally). > > I know nothing of this case other than the link you sent. But it seems > to me that the complaint from IBM is that the developer used his private > gmail address here rather than his IBM address. > > It is normal practice in most countries that if you are employed full > time to do a certain type of job, then you can't do the same kind of > work outside of the job without prior arrangement with the employer. > That applies whether it is extra paid work, or unpaid (hobby) work. > This is partly because it can quickly become a conflict of interests, > and partly because you are supposed to be refreshed and ready for work > each day and not tired out from an all-night debugging session on a > different project. > > Usually employers are quite flexible about these things unless there is > a clear conflict of interests (like working on DB2 during the day, and > Postgresql in the evening). Some employers prefer to keep things > standardised and rigid. > > A company like IBM that is heavily involved in Linux kernel coding will > want to keep their copyrights and attributions clear. So if they have > an employee that is working on this code - whether it is part of their > day job or not - it makes sense to insist that attributions, maintainer > contact information and copyrights all make it clear that the work is > done by an IBM employee. It is not only IBM's right to insist on this, > it might also be a legal obligation. > > (It is quite possible that this guy's manager could have expressed > things a bit better - we are not privy to the rest of the email or any > other communication involved.) > > > This is precisely why copyright assignment for the FSF can involve > complicated forms and agreements from contributors' employers. > > > > > > And while this is IBM, the other US corporations with affiliations in > > the Steering Committee are no better: > > https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > > > > I can't see any relevance in that post other than your "big corporations > are completely evil because there are examples of them being bad" comments. > > > I can understand that some of you consider working for such corporations "a > > joy". > > But for the rest of us, and to most people outside the US, their influence > > over the leadership of GCC is a threat. > > Please stop claiming to speak for anyone but yourself. You certainly do > not speak for /me/. I don't work for "such corporations", I am outside > the US, but I do not see IBM or others having noticeable influence over > gcc and thus there is no threat. > > David >
Re: On US corporate influence over Free Software and the GCC Steering Committee
On Tue, 20 Apr 2021 at 11:21, David Brown wrote: > On 20/04/2021 08:54, Giacomo Tesio wrote: > > Hi GCC developers, > > > > just to further clarify why I think the current Steering Committee is > highly problematic, > > I'd like you to give a look at this commit > > message over Linux MAINTAINERS > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e > > > > Here the relevant excerpt (but please go chech the quotation): > > > > "As an IBM employee, you are not allowed to use your gmail account to > work in any way > > on VNIC. You are not allowed to use your personal email account as a > "hobby". You > > are an IBM employee 100% of the time. > > Please remove yourself completely from the maintainers file. I grant you > a 1 time > > exception on contributions to VNIC to make this change." > > > > > > This is happened yesterday (literally). > > I know nothing of this case other than the link you sent. But it seems > to me that the complaint from IBM is that the developer used his private > gmail address here rather than his IBM address. > > It is normal practice in most countries that if you are employed full > time to do a certain type of job, then you can't do the same kind of > work outside of the job without prior arrangement with the employer. > That applies whether it is extra paid work, or unpaid (hobby) work. > This is partly because it can quickly become a conflict of interests, > and partly because you are supposed to be refreshed and ready for work > each day and not tired out from an all-night debugging session on a > different project. > > Usually employers are quite flexible about these things unless there is > a clear conflict of interests (like working on DB2 during the day, and > Postgresql in the evening). Some employers prefer to keep things > standardised and rigid. > > A company like IBM that is heavily involved in Linux kernel coding will > want to keep their copyrights and attributions clear. So if they have > an employee that is working on this code - whether it is part of their > day job or not - it makes sense to insist that attributions, maintainer > contact information and copyrights all make it clear that the work is > done by an IBM employee. It is not only IBM's right to insist on this, > it might also be a legal obligation. > > (It is quite possible that this guy's manager could have expressed > things a bit better - we are not privy to the rest of the email or any > other communication involved.) > > > This is precisely why copyright assignment for the FSF can involve > complicated forms and agreements from contributors' employers. > > > > > > And while this is IBM, the other US corporations with affiliations in > > the Steering Committee are no better: > https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > > > > I can't see any relevance in that post other than your "big corporations > are completely evil because there are examples of them being bad" comments. > > > I can understand that some of you consider working for such corporations > "a joy". > > But for the rest of us, and to most people outside the US, their > influence > > over the leadership of GCC is a threat. > > Please stop claiming to speak for anyone but yourself. You certainly do > not speak for /me/. I don't work for "such corporations", I am outside > the US, but I do not see IBM or others having noticeable influence over > gcc and thus there is no threat. > > David > I have raised my concerns directly with the FSF, and GNU, about the behaviours and attitudes on here - I would suggest others do the same.
Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate a proper bug report yet. This is the compiler: [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 --enable-languages=c --disable-multilib --enable-checking=release --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.3.0 (GCC) This is the crash report from the console: Exception Type:EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x000c, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Illegal instruction: 4 Termination Reason:Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [98080] Application Specific Information: dyld2 mode Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libgambit.dylib 0x00010dfaf010 ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280) This is the disassembled code (arrow points to crash point): (lldb) di -s 0x000103d6 -c 10 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING: 0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at c_intf.c:3282:9 0x103d60002 <+1506>: orb%al, 0x31(%rbp) 0x103d60005 <+1509>: shlb %cl, 0x2e(%rsi) 0x103d60008 <+1512>: nopl (%rax,%rax) -> 0x103d60010 <+1520>: movl (%rbp,%r10,4), %esi 0x103d60015 <+1525>: callq 0x103fba9a0 ; symbol stub for: ___UTF_8_put 0x103d6001a <+1530>: movq %r10, %rax 0x103d6001d <+1533>: addq $0x1, %r10 0x103d60021 <+1537>: cmpq %r12, %rax 0x103d60024 <+1540>: jne0x103d60010 ; <+1520> at c_intf.c:3280:173 I don’t know why that particular instruction is “Illegal”. Can someone suggest a way forward? Thanks. Brad
Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
Lucier, Bradley J via Gcc wrote: I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate a proper bug report yet. This is the compiler: [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 --enable-languages=c --disable-multilib --enable-checking=release --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.3.0 (GCC) Can someone suggest a way forward? Please could you raise a PR (Bugzilla) - (https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc) .. the information here is enough to start - but it would help to know what you were compiling when this occurred .. adding ‘-save-temps’ to the compile line and adding the .i file to the BZ can be helfpul. .. I think this will take a little analysis (and isn’t something I've seen in testing on either i7 or xeon w hardware). thanks Iain
Re: On US corporate influence over Free Software and the GCC Steering Committee
> You are an IBM employee 100% of the time. For those who aren't aware of it, this has been IBM's position for many decades. It's not a new position. But they are unique in the extremeness of their position on this, so generalizing this would be a mistake.
Re: On US corporate influence over Free Software and the GCC Steering Committee
> Troubling indeed, but this might just be an overzealous manager. > IBM, like other corporations, has made significant technical > contributions to GCC over the years, for example the scheduler and > the vectorizer, and thus has assigned the copyright of these > contributions to the FSF. Yes, as long as the employee is doing it as part of their work for IBM, which was the case in your examples. What's never been OK for IBM are their employees doing software development "on their own time" because they've taken the position that such doesn't exist.
Re: On US corporate influence over Free Software and the GCC Steering Committee
Hi David, I'm amused to see how far you can go to rationalize such a clear statement: "You are an IBM employee 100% of the time." This is the kind of control these companies think they deserve over their employees. And when they refuse to obey, they are fired, like Timnit Gebru. To me, the members of the Steering Committee shouldn't be under such burden. Since the vast maiority of them are, this turns to be a risk for people relying on GCC. But let me clear about this: I do NOT speak for anybody who share your trust in the benevolence if US BigTech, wherever they live. Feel free to believe what makes you feel better. Giacomo On April 20, 2021 9:42:55 AM UTC, David Brown wrote: > On 20/04/2021 08:54, Giacomo Tesio wrote: > > Hi GCC developers, > > > > just to further clarify why I think the current Steering Committee > is highly problematic, > > I'd like you to give a look at this commit > > message over Linux MAINTAINERS > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e > > > > Here the relevant excerpt (but please go chech the quotation): > > > > "As an IBM employee, you are not allowed to use your gmail account > to work in any way > > on VNIC. You are not allowed to use your personal email account as a > "hobby". You > > are an IBM employee 100% of the time. > > Please remove yourself completely from the maintainers file. I grant > you a 1 time > > exception on contributions to VNIC to make this change." > > > > > > This is happened yesterday (literally). > > I know nothing of this case other than the link you sent. But it > seems > to me that the complaint from IBM is that the developer used his > private > gmail address here rather than his IBM address. > > It is normal practice in most countries that if you are employed full > time to do a certain type of job, then you can't do the same kind of > work outside of the job without prior arrangement with the employer. > That applies whether it is extra paid work, or unpaid (hobby) work. > This is partly because it can quickly become a conflict of interests, > and partly because you are supposed to be refreshed and ready for work > each day and not tired out from an all-night debugging session on a > different project. > > Usually employers are quite flexible about these things unless there > is > a clear conflict of interests (like working on DB2 during the day, and > Postgresql in the evening). Some employers prefer to keep things > standardised and rigid. > > A company like IBM that is heavily involved in Linux kernel coding > will > want to keep their copyrights and attributions clear. So if they have > an employee that is working on this code - whether it is part of their > day job or not - it makes sense to insist that attributions, > maintainer > contact information and copyrights all make it clear that the work is > done by an IBM employee. It is not only IBM's right to insist on > this, > it might also be a legal obligation. > > (It is quite possible that this guy's manager could have expressed > things a bit better - we are not privy to the rest of the email or any > other communication involved.) > > > This is precisely why copyright assignment for the FSF can involve > complicated forms and agreements from contributors' employers. > > > > > > And while this is IBM, the other US corporations with affiliations > in > > the Steering Committee are no better: > https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > > > > I can't see any relevance in that post other than your "big > corporations > are completely evil because there are examples of them being bad" > comments. > > > I can understand that some of you consider working for such > corporations "a joy". > > But for the rest of us, and to most people outside the US, their > influence > > over the leadership of GCC is a threat. > > Please stop claiming to speak for anyone but yourself. You certainly > do > not speak for /me/. I don't work for "such corporations", I am > outside > the US, but I do not see IBM or others having noticeable influence > over > gcc and thus there is no threat. > > David
Re: On US corporate influence over Free Software and the GCC Steering Committee
On 4/20/21 7:42 AM, Richard Kenner via Gcc wrote: Troubling indeed, but this might just be an overzealous manager. IBM, like other corporations, has made significant technical contributions to GCC over the years, for example the scheduler and the vectorizer, and thus has assigned the copyright of these contributions to the FSF. Yes, as long as the employee is doing it as part of their work for IBM, which was the case in your examples. What's never been OK for IBM are their employees doing software development "on their own time" because they've taken the position that such doesn't exist. It amazes me how many people who don't work for IBM want to assert IBM's policies. There is certainly ability to work on projects on your own time that don't conflict with IBM's business. You simply have to be open about it and make sure your management is aware. Bill
Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
On Tue, Apr 20, 2021 at 12:20:06PM +, Lucier, Bradley J via Gcc wrote: > I’m seeing an “Illegal Instruction” fault and don’t quite know how to > generate a proper bug report yet. > > This is the compiler: > > [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v > Using built-in specs. > COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc > COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper > Target: x86_64-apple-darwin19.6.0 > Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 > --enable-languages=c --disable-multilib --enable-checking=release > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk > Thread model: posix > Supported LTO compression algorithms: zlib > gcc version 10.3.0 (GCC) > > This is the crash report from the console: > > Exception Type:EXC_BAD_INSTRUCTION (SIGILL) > Exception Codes: 0x000c, 0x > Exception Note:EXC_CORPSE_NOTIFY > > Termination Signal:Illegal instruction: 4 > Termination Reason:Namespace SIGNAL, Code 0x4 > Terminating Process: exc handler [98080] > > Application Specific Information: > dyld2 mode > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libgambit.dylib 0x00010dfaf010 > ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280) > > This is the disassembled code (arrow points to crash point): > > (lldb) di -s 0x000103d6 -c 10 > libgambit.dylib`___SCMOBJ_to_NONNULLSTRING: > 0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at > c_intf.c:3282:9 > 0x103d60002 <+1506>: orb%al, 0x31(%rbp) > 0x103d60005 <+1509>: shlb %cl, 0x2e(%rsi) Does GCC ever generate this last instruction (a variable shift of a byte in memory!)? Even the next to last (register to memory) is only generated infrequently. First thing to do would be to start the disassembly earlier, or even at the beginning of the function, because I believe that the address you gave is not an instruction boundary, and in this case the output of the disassembler is nonsense until it resynchronizes on a real boundary. Regards, Gabriel > 0x103d60008 <+1512>: nopl (%rax,%rax) > -> 0x103d60010 <+1520>: movl (%rbp,%r10,4), %esi > 0x103d60015 <+1525>: callq 0x103fba9a0 ; symbol stub for: > ___UTF_8_put > 0x103d6001a <+1530>: movq %r10, %rax > 0x103d6001d <+1533>: addq $0x1, %r10 > 0x103d60021 <+1537>: cmpq %r12, %rax > 0x103d60024 <+1540>: jne0x103d60010 ; <+1520> at > c_intf.c:3280:173 > > I don’t know why that particular instruction is “Illegal”. > > Can someone suggest a way forward? > > Thanks. > > Brad
Re: On US corporate influence over Free Software and the GCC Steering Committee
Giacomo Tesio wrote: > And while this is IBM, the other US corporations with affiliations in the Steering Committee are no better: https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > I can understand that some of you consider working for such corporations "a > joy". > But for the rest of us, and to most people outside the US, their influence over the leadership of GCC is a threat. > Please, do not create a hostile environment for indipendent contributors. What do you mean by independent? If you're independently wealthy and don't need to work, you can avoid this. If you're a cashier or field laborer or in some other poorly paid job, then your employer probably doesn't care. Otherwise, if you work for a company that produces software, even just internally, or for a university, or a company where your name might be associated with the company, then your employer may demand that you cease publicly working on Free Software. I find it a bit hypocritical; there's no objection to the fact that GCC was developed using stuff bought with funds donated by these companies, their creators and their employees, to MIT, including people like Jeffery Epstein, one of the Koch brothers, and Bill Gates. But how dare IBM hire people to work on GCC! We need to preserve our independence! -- The standard is written in English . If you have trouble understanding a particular section, read it again and again and again . . . Sit up straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185 (1991)
Re: On US corporate influence over Free Software and the GCC Steering Committee
> On Apr 20, 2021, at 9:22 AM, David Starner via Gcc wrote: > > Giacomo Tesio wrote: >> ... >> Please, do not create a hostile environment for indipendent contributors. > > What do you mean by independent? If you're independently wealthy and > don't need to work, you can avoid this. If you're a cashier or field > laborer or in some other poorly paid job, then your employer probably > doesn't care. Otherwise, if you work for a company that produces > software, even just internally, or for a university, or a company > where your name might be associated with the company, then your > employer may demand that you cease publicly working on Free Software. Not necessarily. I'll offer you my own example. I'm the target maintainer for pdp11. It should be obvious that I'm doing this as an "independent contributor", not as part of my job, and indeed that work is for that reason spare time work done outside of business hours. I have a company copyright disclaimer in place, dating back to some years ago when the work I was doing on gcc did at times touch on (then) company business. As a legal matter it is doubtful that my current GCC involvement even needs that copyright disclaimer since the work is not on company time and not in the company's field of enterprise. In other words, we have jobs (unless we're retired or unemployed) as well as private time, and there are a number of GCC contributors who contribute their private time. I take Giacomo's comment to refer to that case. paul
Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
On Apr 20, 2021, at 9:11 AM, Gabriel Paubert mailto:paub...@iram.es>> wrote: (lldb) di -s 0x000103d6 -c 10 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING: 0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at c_intf.c:3282:9 0x103d60002 <+1506>: orb%al, 0x31(%rbp) 0x103d60005 <+1509>: shlb %cl, 0x2e(%rsi) Does GCC ever generate this last instruction (a variable shift of a byte in memory!)? Even the next to last (register to memory) is only generated infrequently. I submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 You may be correct, but it appears that the “offending" instruction is -> 0x103d60010 <+1520>: movl (%rbp,%r10,4), %esi Brad
Re: removing toxic emailers
On Tue, Apr 20, 2021, 12:54 AM Jonathan Wakely via Gcc wrote: > > Check the git logs, Google employees are minor contributors these > days. The GPLv3 scared Google away from GCC years ago. > Just for the record, Google has no problem with the GPLv3. Google stopped working on GCC because they made a company decision to use clang instead. That decision was made for technical reasons, not licensing reasons. Ian >
Re: removing toxic emailers
> Just for the record, Google has no problem with the GPLv3. Google stopped
> working on GCC because they made a company decision to use clang instead.
> That decision was made for technical reasons, not licensing reasons.
But note that some cellphone manufacturers (e.g, Samsung) have taken
steps to prevent non-signed binaries from being loaded in their phones.
This would have been problematic ("Tivoisation") if GPLv3 code was
included in Android.
Re: removing toxic emailers
On 20/04/2021 16:15, Richard Kenner via Gcc wrote:
>> Just for the record, Google has no problem with the GPLv3. Google stopped
>> working on GCC because they made a company decision to use clang instead.
>> That decision was made for technical reasons, not licensing reasons.
>
> But note that some cellphone manufacturers (e.g, Samsung) have taken
> steps to prevent non-signed binaries from being loaded in their phones.
> This would have been problematic ("Tivoisation") if GPLv3 code was
> included in Android.
>
That would surely only be relevant if people wanted to use their
telephones to compile code? The license of the compiler does not matter
(except for libraries or code snippets that are copied directly by the
compiler to the binaries, and gcc has permissive license exceptions for
these.)
Re: removing toxic emailers
> That would surely only be relevant if people wanted to use their > telephones to compile code? That's not completely clear. It would certainly be true if the compiler were included on the phone, whether or not the compiler was actually used. But I was more addressing the general comment that Google doesn't care about GPLv3 than the specific issue of GCC. If the kernel were GPLv3, for example, there would be an issue with what Samsung is doing.
GCC 11.1 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
GCC 11.0.1 Status Report (2021-04-20)
Status == We have reached zero P1 regressions today and releases/gcc-11 branch has been created; GCC 11.1-rc1 has been built and announced a few moments ago. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, we'd like to release 11.1 late next week, or soon after that, if any important issues are discovered and fixed, rc2 could be released this or next week. Quality Data Priority # Change from last report --- --- P10 - 8 P2 244 - 22 P3 32 + 1 P4 200 + 1 P5 25 + 1 --- --- Total P1-P3 276 - 29 Total 501 - 27 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-April/235384.html
GCC 12.0.0 Status Report (2021-04-20)
Status == The trunk has branched for the GCC 11 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 11 so it is possible to test important fixes for 11.1 on it. Quality Data Priority # Change from last report --- --- P10 - 8 P2 249 - 17 P3 34 + 3 P4 200 + 1 P5 25 + 1 --- --- Total P1-P3 283 - 22 Total 508 - 20 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-April/235384.html
help debug hash_map garbage collection issue
I have a static hash_map object that needs to persist across passes: static GTY(()) hash_map *map; I initialize the map like so: map = hash_map::create_ggc (4); But I see crashes when accessing the map after adding and removing some number of entries in a few passes. The crashes are due to the map having been garbage-collected and the memory allocated to it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see in GDD being written into the map by poison_pages()). I assumed marking the map pointer GTY(()) would keep the garbage collector from touching the map. Is there something else I need to do to keep it from doing that? Thanks Martin PS Just in case it matters, the bitmap in the table is allocated via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside the map.
Re: help debug hash_map garbage collection issue
On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: > I have a static hash_map object that needs to persist across passes: > > static GTY(()) hash_map *map; > > I initialize the map like so: > > map = hash_map::create_ggc (4); > > But I see crashes when accessing the map after adding and removing > some number of entries in a few passes. The crashes are due to > the map having been garbage-collected and the memory allocated to > it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see > in GDD being written into the map by poison_pages()). > > I assumed marking the map pointer GTY(()) would keep the garbage > collector from touching the map. Is there something else I need > to do to keep it from doing that? > > Thanks > Martin > > PS Just in case it matters, the bitmap in the table is allocated > via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside > the map. My sense is that this is the problem. What happens if you use BITMAP_GGC_ALLOC? Marek
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. I am seeing at least one compilation failure when building the RC. Note that trunk built fine for me yesterday morning. libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -o core/thread/.libs/osthread.o /tmp/cc8zG8DV.s: Assembler messages: /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15 /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16 /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17 /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18 /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19 /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20 /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21 /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22 /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23 /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24 /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25 /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26 /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27 /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28 /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29 /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30 /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
Re: help debug hash_map garbage collection issue
On 4/20/21 2:13 PM, Marek Polacek wrote: On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: I have a static hash_map object that needs to persist across passes: static GTY(()) hash_map *map; I initialize the map like so: map = hash_map::create_ggc (4); But I see crashes when accessing the map after adding and removing some number of entries in a few passes. The crashes are due to the map having been garbage-collected and the memory allocated to it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see in GDD being written into the map by poison_pages()). I assumed marking the map pointer GTY(()) would keep the garbage collector from touching the map. Is there something else I need to do to keep it from doing that? Thanks Martin PS Just in case it matters, the bitmap in the table is allocated via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside the map. My sense is that this is the problem. What happens if you use BITMAP_GGC_ALLOC? Same thing :( Martin Marek
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Apr 20 2021, William Seurer via Gcc wrote: > On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: >> The first release candidate for GCC 11.1 is available from >> >> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ >> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 >> >> and shortly its mirrors. It has been generated from git revision >> r11-8265-g246abba01f302eb453475b650ba839ec905be76d. >> >> I have so far bootstrapped and tested the release candidate on >> x86_64-linux and i686-linux. Please test it and report any issues to >> bugzilla. >> >> If all goes well, I'd like to release 11.1 on Tuesday, April 27th. >> > I am seeing at least one compilation failure when building the RC. Note > that trunk built fine for me yesterday morning. > > libtool: compile: > /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc > -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ > -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ > > -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ > -isystem > /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include > -isystem > /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include > -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections > -fdata-sections -O2 -g -nostdinc -I > /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c > /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d > -fPIC -fversion=Shared - > o core/thread/.libs/osthread.o > /tmp/cc8zG8DV.s: Assembler messages: > /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 > /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 > /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15 > /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16 > /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17 > /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18 > /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19 > /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20 > /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21 > /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22 > /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23 > /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24 > /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25 > /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26 > /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27 > /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28 > /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29 > /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30 > /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31 That comes from commit 6eae7549b8a. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>
> On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
> > The first release candidate for GCC 11.1 is available from
> >
> > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
> >
> > and shortly its mirrors. It has been generated from git revision
> > r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
> >
> > I have so far bootstrapped and tested the release candidate on
> > x86_64-linux and i686-linux. Please test it and report any issues to
> > bugzilla.
> >
> > If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
> >
> I am seeing at least one compilation failure when building the RC. Note
> that trunk built fine for me yesterday morning.
>
> libtool: compile:
> /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc
> -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/
> -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/
>
> -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/
> -isystem
> /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include
> -isystem
> /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include
> -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections
> -fdata-sections -O2 -g -nostdinc -I
> /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c
> /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d
> -fPIC -fversion=Shared -o core/thread/.libs/osthread.o
> /tmp/cc8zG8DV.s: Assembler messages:
> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15
> /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16
> /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17
> /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18
> /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19
> /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20
> /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21
> /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22
> /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23
> /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24
> /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25
> /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26
> /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27
> /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28
> /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29
> /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30
> /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
So do we need to change
+else version (PPC)
+{
+void*[19] regs = void;
+asm pure nothrow @nogc
+{
+"stw r13, %0" : "=m" (regs[ 0]);
+"stw r14, %0" : "=m" (regs[ 1]);
...
+else version (PPC64)
+{
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[snip]
> So do we need to change
> +else version (PPC)
>
>
> +{
>
>
> +void*[19] regs = void;
>
>
> +asm pure nothrow @nogc
>
>
> +{
>
>
> +"stw r13, %0" : "=m" (regs[ 0]);
>
>
> +"stw r14, %0" : "=m" (regs[ 1]);
>
>
> ...
> +else version (PPC64)
>
>
> +{
>
>
> +void*[19] regs = void;
>
>
> +asm pure nothrow @nogc
>
>
> +{
>
>
> +"std r13, %0" : "=m" (regs[ 0]);
>
>
> +"std r14, %0" : "=m" (regs[ 1]);
>
>
> ...
> to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> to "stw %%r13, %0" etc. under some conditions?
Yes, I think so. The "r13", etc. names are not accepted by gas unless you
use the -mregnames option. It's easier to just remove the 'r'.
Peter
Re: help debug hash_map garbage collection issue
On 4/20/21 2:36 PM, Martin Sebor wrote:
On 4/20/21 2:13 PM, Marek Polacek wrote:
On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote:
I have a static hash_map object that needs to persist across passes:
static GTY(()) hash_map *map;
I initialize the map like so:
map = hash_map::create_ggc (4);
But I see crashes when accessing the map after adding and removing
some number of entries in a few passes. The crashes are due to
the map having been garbage-collected and the memory allocated to
it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see
in GDD being written into the map by poison_pages()).
I assumed marking the map pointer GTY(()) would keep the garbage
collector from touching the map. Is there something else I need
to do to keep it from doing that?
Thanks
Martin
PS Just in case it matters, the bitmap in the table is allocated
via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
the map.
My sense is that this is the problem. What happens if you use
BITMAP_GGC_ALLOC?
Same thing :(
I reduced the problem to the following patch/test case no involving
a bitmap or other pointers. With it applied, GCC reliably crashes.
An example of a stack trace is below the patch. What am I missing?
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 87864f3d0dd..0e6cded166e 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -2749,11 +2749,21 @@ gimple_call_operator_delete_p (const gcall *stmt)
return false;
}
+typedef int_hash i_hash;
+
+static GTY(()) hash_map *ii_map;
+
/* Return true when STMT is builtins call. */
bool
gimple_call_builtin_p (const gimple *stmt)
{
+ if (!ii_map)
+ii_map = ii_map->create_ggc (4);
+
+ uintptr_t key = gimple_code (stmt);
+ ii_map->put (key, key);
+
tree fndecl;
if (is_gimple_call (stmt)
&& (fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
during GIMPLE pass: cplxlower0
/src/gcc/master/gcc/testsuite/gcc.dg/builtins-1.c:97:55: internal
compiler error: Segmentation fault
0x1308b30 crash_signal
/src/gcc/master/gcc/toplev.c:327
0xe7eaa0 bool simple_hashmap_traits2147483647> >, int>::is_empty,
int, simple_hashmap_traits2147483647> >, int> >::hash_entry>(hash_map2147483647>, int,
simple_hashmap_traits
>, int> >::hash_entry const&)
/src/gcc/master/gcc/hash-map-traits.h:75
0xe7e36a hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry::is_empty(hash_map,
int, simple_hashmap_traits2147483647> >, int> >::hash_entry const&)
/src/gcc/master/gcc/hash-map.h:71
0xe7ea32 hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false,
xcallocator>::is_empty(hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry&)
/src/gcc/master/gcc/hash-table.h:541
0xe7e89d hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false, xcallocator>::expand()
/src/gcc/master/gcc/hash-table.h:819
0xe7e155 hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false, xcallocator>::find_slot_with_hash(int
const&, unsigned int, insert_option)
/src/gcc/master/gcc/hash-table.h:964
0xe7d9b8 hash_map, int,
simple_hashmap_traits
>, int> >::put(int const&, int const&)
/src/gcc/master/gcc/hash-map.h:166
0xe7932f gimple_call_builtin_p(gimple const*)
/src/gcc/master/gcc/gimple.c:2766
0xece684 maybe_fold_stmt
/src/gcc/master/gcc/gimplify.c:3303
0xed888e gimplify_modify_expr
/src/gcc/master/gcc/gimplify.c:5994
0xf03d14 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/src/gcc/master/gcc/gimplify.c:14083
0xedbf17 gimplify_stmt(tree_node**, gimple**)
/src/gcc/master/gcc/gimplify.c:6877
0xec55f0 gimplify_and_add(tree_node*, gimple**)
/src/gcc/master/gcc/gimplify.c:489
0xec5d8f internal_get_tmp_var
/src/gcc/master/gcc/gimplify.c:642
0xec5dd6 get_formal_tmp_var(tree_node*, gimple**)
/src/gcc/master/gcc/gimplify.c:663
0xf07a6b gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/src/gcc/master/gcc/gimplify.c:15072
0xf0d30a force_gimple_operand_1(tree_node*, gimple**, bool
(*)(tree_node*), tree_node*)
/src/gcc/master/gcc/gimplify-me.c:78
0xf0d3d7 force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*,
bool (*)(tree_node*), tree_node*, bool, gsi_iterator_update)
/src/gcc/master/gcc/gimplify-me.c:115
0xf0d490 force_gimple_operand_gsi(gimple_stmt_iterator*, tree_node*,
bool, tree_node*, bool, gsi_iterator_update)
/src/gcc/master/gcc/gimplify-me.c:141
0x13791c5 gimplify_build1(gimple_stmt_iterator*, tree_code, tree_node*,
tree_node*)
/src/gcc/master/gcc/tree-cfg.c:9249
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > and shortly its mirrors. It has been generated from git revision > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
> On 21/04/2021 00:02 Peter Bergner wrote:
>
>
> On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> > On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
> >> /tmp/cc8zG8DV.s: Assembler messages:
> >> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> >> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> [snip]
> > So do we need to change
> > +else version (PPC)
> >
> >
> > +{
> >
> >
> > +void*[19] regs = void;
> >
> >
> > +asm pure nothrow @nogc
> >
> >
> > +{
> >
> >
> > +"stw r13, %0" : "=m" (regs[ 0]);
> >
> >
> > +"stw r14, %0" : "=m" (regs[ 1]);
> >
> >
> > ...
> > +else version (PPC64)
> >
> >
> > +{
> >
> >
> > +void*[19] regs = void;
> >
> >
> > +asm pure nothrow @nogc
> >
> >
> > +{
> >
> >
> > +"std r13, %0" : "=m" (regs[ 0]);
> >
> >
> > +"std r14, %0" : "=m" (regs[ 1]);
> >
> >
> > ...
> > to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> > to "stw %%r13, %0" etc. under some conditions?
>
> Yes, I think so. The "r13", etc. names are not accepted by gas unless you
> use the -mregnames option. It's easier to just remove the 'r'.
>
OK, unless told otherwise, I'll keep them in for darwin though.
--- a/libphobos/libdruntime/core/thread/osthread.d
+++ b/libphobos/libdruntime/core/thread/osthread.d
@@ -1444,55 +1444,35 @@ in (fn)
else version (PPC)
{
void*[19] regs = void;
-asm pure nothrow @nogc
-{
-"stw r13, %0" : "=m" (regs[ 0]);
-"stw r14, %0" : "=m" (regs[ 1]);
-"stw r15, %0" : "=m" (regs[ 2]);
-"stw r16, %0" : "=m" (regs[ 3]);
-"stw r17, %0" : "=m" (regs[ 4]);
-"stw r18, %0" : "=m" (regs[ 5]);
-"stw r19, %0" : "=m" (regs[ 6]);
-"stw r20, %0" : "=m" (regs[ 7]);
-"stw r21, %0" : "=m" (regs[ 9]);
-"stw r22, %0" : "=m" (regs[ 9]);
-"stw r23, %0" : "=m" (regs[10]);
-"stw r24, %0" : "=m" (regs[11]);
-"stw r25, %0" : "=m" (regs[12]);
-"stw r26, %0" : "=m" (regs[13]);
-"stw r27, %0" : "=m" (regs[14]);
-"stw r28, %0" : "=m" (regs[15]);
-"stw r29, %0" : "=m" (regs[16]);
-"stw r30, %0" : "=m" (regs[17]);
-"stw r31, %0" : "=m" (regs[18]);
-}
+version (Darwin)
+enum regname = "r";
+else
+enum regname = "";
+static foreach (i; 0 .. regs.length)
+{{
+enum int j = 13 + i; // source register
+asm pure nothrow
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
Peter Bergner via Gcc wrote:
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
/tmp/cc8zG8DV.s: Assembler messages:
/tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
/tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[snip]
So do we need to change
+else version (PPC)
+{
+void*[19] regs = void;
+asm pure nothrow @nogc
+{
+"stw r13, %0" : "=m" (regs[ 0]);
+"stw r14, %0" : "=m" (regs[ 1]);
...
+else version (PPC64)
+{
+void*[19] regs = void;
+asm pure nothrow @nogc
+{
+"std r13, %0" : "=m" (regs[ 0]);
+"std r14, %0" : "=m" (regs[ 1]);
...
to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
to "stw %%r13, %0" etc. under some conditions?
Yes, I think so. The "r13", etc. names are not accepted by gas unless you
use the -mregnames option. It's easier to just remove the 'r’.
which would break it on Darwin.
Either that section needs to be conditional on “version Darwin” and a
second one
general - or the existing fall-back can be used for Linux (but the comments
still stand
that there are disadvantages on PPC from using the fallback).
Iain (S)
Re: help debug hash_map garbage collection issue
On 4/20/21 4:15 PM, Martin Sebor wrote:
On 4/20/21 2:36 PM, Martin Sebor wrote:
On 4/20/21 2:13 PM, Marek Polacek wrote:
On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote:
I have a static hash_map object that needs to persist across passes:
static GTY(()) hash_map *map;
I initialize the map like so:
map = hash_map::create_ggc (4);
But I see crashes when accessing the map after adding and removing
some number of entries in a few passes. The crashes are due to
the map having been garbage-collected and the memory allocated to
it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see
in GDD being written into the map by poison_pages()).
I assumed marking the map pointer GTY(()) would keep the garbage
collector from touching the map. Is there something else I need
to do to keep it from doing that?
Thanks
Martin
PS Just in case it matters, the bitmap in the table is allocated
via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
the map.
My sense is that this is the problem. What happens if you use
BITMAP_GGC_ALLOC?
Same thing :(
I reduced the problem to the following patch/test case no involving
a bitmap or other pointers. With it applied, GCC reliably crashes.
An example of a stack trace is below the patch. What am I missing?
It seems that assigning the address of an object allocated by
ggc_alloc() (which presumably includes BITMAP_GGC_ALLOC()) to
a GTY-marked pointer "defeats" the purpose of the marker and
allows it to be garbage collected. I suppose it's the spirit
of "garbage in, garbage out" (pun intended). Since (if?)
the combination makes no sense I shouldn't be too surprised
that it results in a crash.
If it really doesn't make sense, it would be really nice if
the compiler warned about it. I suppose expanding the GTY marker
to some GCC-internal attribute would make it possible to detect.
Alternatively, it would be helpful if this "gotcha" was at
least documented, both in the code and in the manual. That
would have saved me a day's worth of frustrating debugging.
Let me put something together.
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 87864f3d0dd..0e6cded166e 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -2749,11 +2749,21 @@ gimple_call_operator_delete_p (const gcall *stmt)
return false;
}
+typedef int_hash i_hash;
+
+static GTY(()) hash_map *ii_map;
+
/* Return true when STMT is builtins call. */
bool
gimple_call_builtin_p (const gimple *stmt)
{
+ if (!ii_map)
+ ii_map = ii_map->create_ggc (4);
+
+ uintptr_t key = gimple_code (stmt);
+ ii_map->put (key, key);
+
tree fndecl;
if (is_gimple_call (stmt)
&& (fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
during GIMPLE pass: cplxlower0
/src/gcc/master/gcc/testsuite/gcc.dg/builtins-1.c:97:55: internal
compiler error: Segmentation fault
0x1308b30 crash_signal
/src/gcc/master/gcc/toplev.c:327
0xe7eaa0 bool simple_hashmap_traits2147483647> >, int>::is_empty,
int, simple_hashmap_traits2147483647> >, int> >::hash_entry>(hash_map2147483647>, int,
simple_hashmap_traits
>, int> >::hash_entry const&)
/src/gcc/master/gcc/hash-map-traits.h:75
0xe7e36a hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry::is_empty(hash_map,
int, simple_hashmap_traits2147483647> >, int> >::hash_entry const&)
/src/gcc/master/gcc/hash-map.h:71
0xe7ea32 hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false,
xcallocator>::is_empty(hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry&)
/src/gcc/master/gcc/hash-table.h:541
0xe7e89d hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false, xcallocator>::expand()
/src/gcc/master/gcc/hash-table.h:819
0xe7e155 hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false, xcallocator>::find_slot_with_hash(int
const&, unsigned int, insert_option)
/src/gcc/master/gcc/hash-table.h:964
0xe7d9b8 hash_map, int,
simple_hashmap_traits
>, int> >::put(int const&, int const&)
/src/gcc/master/gcc/hash-map.h:166
0xe7932f gimple_call_builtin_p(gimple const*)
/src/gcc/master/gcc/gimple.c:2766
0xece684 maybe_fold_stmt
/src/gcc/master/gcc/gimplify.c:3303
0xed888e gimplify_modify_expr
/src/gcc/master/gcc/gimplify.c:5994
0xf03d14 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/src/gcc/master/gcc/gimplify.c:14083
0xedbf17 gimplify_stmt(tree_node**, gimple**)
/src/gcc/master/gcc/gimplify.c:6877
0xec55f0 gimplify_and_add(tree_node*, gimple**)
/src/gcc/master/gcc/gimplify.c:489
0xec5d8f internal_get_tmp_var
/src/gcc/master/gcc/gimplify.c:642
0xec5dd6 get_formal_tmp_var(tree_node*, gimple**)
/src/gcc/master/gcc/gimplify.c:663
0xf07a6b gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/src/gcc/master/gcc/gimplify.c:15072
0xf0d30a force_gimple_operand_1(tree_node*, gimple**, bool
(*)(tree_node*), tree_node*)
/src/gcc/master/gcc/gi
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On 4/20/21 4:20 PM, Jakub Jelinek wrote:
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
The first release candidate for GCC 11.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
and shortly its mirrors. It has been generated from git revision
r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux. Please test it and report any issues to
bugzilla.
If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
I am seeing at least one compilation failure when building the RC. Note
that trunk built fine for me yesterday morning.
libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc
-B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/
-B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include
-fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections
-fdata-sections -O2 -g -nostdinc -I
/home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c
/home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d
-fPIC -fversion=Shared -o core/thread/.libs/osthread.o
/tmp/cc8zG8DV.s: Assembler messages:
/tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
/tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
/tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15
/tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16
/tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17
/tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18
/tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19
/tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20
/tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21
/tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22
/tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23
/tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24
/tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25
/tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26
/tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27
/tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28
/tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29
/tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30
/tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
So do we need to change
+else version (PPC)
+{
+void*[19] regs = void;
+asm pure nothrow @nogc
+{
+"stw r13, %0" : "=m" (regs[ 0]);
+"stw r14, %0" : "=m" (regs[ 1]);
...
+else version (PPC64)
+{
+void*[19] regs = void;
+asm pure nothrow @nogc
+{
+"std r13, %0" : "=m" (regs[ 0]);
+"std r14, %0" : "=m" (regs[ 1]);
...
to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
to "stw %%r13, %0" etc. under some conditions?
Jakub
I tried that and I did get a clean build. The only additional errors
seen when test were run (compared to a build yesterday) were:
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++2a (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++2a (test for excess errors)
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > wrote: > > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > and shortly its mirrors. It has been generated from git revision > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > As I have reported in Bugzilla, the last minute > > libstdc++: Refactor/cleanup of C++20 atomic wait implementation > > has severely regressed libstdc++ on AIX due to changes to > bits/semaphore_base.h header. > > - David > > > I posted a patch to BZ that should disable entirely for AIX (and > other targets where there's not a supported implementation strategy). > > This patch isn't the best way of addressing this for a variety of reasons, > but this support is intended as experimental for GCC11 anyway. Unfortunately > I can't test it on AIX because it would seem that my ssh keys never landed on > the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report.
Re: help debug hash_map garbage collection issue
On 4/20/21 5:03 PM, Martin Sebor wrote:
On 4/20/21 4:15 PM, Martin Sebor wrote:
On 4/20/21 2:36 PM, Martin Sebor wrote:
On 4/20/21 2:13 PM, Marek Polacek wrote:
On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote:
I have a static hash_map object that needs to persist across passes:
static GTY(()) hash_map *map;
I initialize the map like so:
map = hash_map::create_ggc (4);
But I see crashes when accessing the map after adding and removing
some number of entries in a few passes. The crashes are due to
the map having been garbage-collected and the memory allocated to
it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see
in GDD being written into the map by poison_pages()).
I assumed marking the map pointer GTY(()) would keep the garbage
collector from touching the map. Is there something else I need
to do to keep it from doing that?
Thanks
Martin
PS Just in case it matters, the bitmap in the table is allocated
via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
the map.
My sense is that this is the problem. What happens if you use
BITMAP_GGC_ALLOC?
Same thing :(
I reduced the problem to the following patch/test case no involving
a bitmap or other pointers. With it applied, GCC reliably crashes.
An example of a stack trace is below the patch. What am I missing?
It seems that assigning the address of an object allocated by
ggc_alloc() (which presumably includes BITMAP_GGC_ALLOC()) to
a GTY-marked pointer "defeats" the purpose of the marker and
allows it to be garbage collected.
But this is not true. There are plenty of counterexamples, including
in tree.c which defines several GTY hash_tables (but no maps). I tried
moving the test case below from gimple.c to tree.c but there it doesn't
even compile. I get this error (and a couple of others):
In file included from /src/gcc/master/gcc/tree.c:16179:
./gt-tree.h: In function ‘void gt_ggc_mx(int_hash&)’:
./gt-tree.h:156:21: error: no matching function for call to
‘gt_ggc_mx(int_hash*)’
gt_ggc_mx (&((*x)));
^
So as another experiment I moved it builtins.c where it does compile
(go figure) but then it crashes when I call it the same way from
c_strlen().
(Aren't you glad you tried to help? ;)
I suppose it's the spirit
of "garbage in, garbage out" (pun intended). Since (if?)
the combination makes no sense I shouldn't be too surprised
that it results in a crash.
If it really doesn't make sense, it would be really nice if
the compiler warned about it. I suppose expanding the GTY marker
to some GCC-internal attribute would make it possible to detect.
Alternatively, it would be helpful if this "gotcha" was at
least documented, both in the code and in the manual. That
would have saved me a day's worth of frustrating debugging.
Let me put something together.
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 87864f3d0dd..0e6cded166e 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -2749,11 +2749,21 @@ gimple_call_operator_delete_p (const gcall *stmt)
return false;
}
+typedef int_hash i_hash;
+
+static GTY(()) hash_map *ii_map;
+
/* Return true when STMT is builtins call. */
bool
gimple_call_builtin_p (const gimple *stmt)
{
+ if (!ii_map)
+ ii_map = ii_map->create_ggc (4);
+
+ uintptr_t key = gimple_code (stmt);
+ ii_map->put (key, key);
+
tree fndecl;
if (is_gimple_call (stmt)
&& (fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
during GIMPLE pass: cplxlower0
/src/gcc/master/gcc/testsuite/gcc.dg/builtins-1.c:97:55: internal
compiler error: Segmentation fault
0x1308b30 crash_signal
/src/gcc/master/gcc/toplev.c:327
0xe7eaa0 bool simple_hashmap_traits0, 2147483647> >, int>::is_empty2147483647>, int,
simple_hashmap_traits
>, int> >::hash_entry>(hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry const&)
/src/gcc/master/gcc/hash-map-traits.h:75
0xe7e36a hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry::is_empty(hash_map2147483647>, int,
simple_hashmap_traits
>, int> >::hash_entry const&)
/src/gcc/master/gcc/hash-map.h:71
0xe7ea32 hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false,
xcallocator>::is_empty(hash_map, int,
simple_hashmap_traits
>, int> >::hash_entry&)
/src/gcc/master/gcc/hash-table.h:541
0xe7e89d hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false, xcallocator>::expand()
/src/gcc/master/gcc/hash-table.h:819
0xe7e155 hash_table, int,
simple_hashmap_traits
>, int> >::hash_entry, false, xcallocator>::find_slot_with_hash(int
const&, unsigned int, insert_option)
/src/gcc/master/gcc/hash-table.h:964
0xe7d9b8 hash_map, int,
simple_hashmap_traits
>, int> >::put(int const&, int const&)
/src/gcc/master/gcc/hash-map.h:166
0xe7932f gimple_call_builtin_p(gimple const*)
/src/gcc/master/gcc/gimple.c:2766
0xece684 maybe_fold_stmt
/src/gcc/master/gcc/gimplify.c:3303
0xed888e gimplify_modify_expr
/sr
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 17:23, Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. Specifically - /tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/semaphore_base.h:259: error: #error "No suitable semaphore implementation available"
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: > > On 2021-04-20 17:09, David Edelsohn wrote: > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > wrote: > > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > wrote: > > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > and shortly its mirrors. It has been generated from git revision > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > As I have reported in Bugzilla, the last minute > > libstdc++: Refactor/cleanup of C++20 atomic wait implementation > > has severely regressed libstdc++ on AIX due to changes to > bits/semaphore_base.h header. > > - David > > > I posted a patch to BZ that should disable entirely for AIX (and > other targets where there's not a supported implementation strategy). > > This patch isn't the best way of addressing this for a variety of reasons, > but this support is intended as experimental for GCC11 anyway. Unfortunately > I can't test it on AIX because it would seem that my ssh keys never landed on > the AIX cfarm machines. > > > I am testing the patch on an AIX system inside IBM. > > But it seems that you are disabling semaphore entirely on AIX, which > is an unnecessary regression. AIX has POSIX semaphores. libstdc++ > configure defines > > _GLIBCXX_HAVE_POSIX_SEMAPHORE > > I don't understand your comments about disabling semaphore on AIX > while the comment about experimental for GCC11 implies that this is > some new, experimental feature. I could understand disabling the > experimental feature, but not disabling all semaphore support. > > Thanks, David > > > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, > but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: > > On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers > wrote: > > > > On 2021-04-20 17:09, David Edelsohn wrote: > > > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > > wrote: > > > > > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > > wrote: > > > > > > The first release candidate for GCC 11.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > > > and shortly its mirrors. It has been generated from git revision > > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux and i686-linux. Please test it and report any issues to > > bugzilla. > > > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > > > > As I have reported in Bugzilla, the last minute > > > > libstdc++: Refactor/cleanup of C++20 atomic wait implementation > > > > has severely regressed libstdc++ on AIX due to changes to > > bits/semaphore_base.h header. > > > > - David > > > > > > I posted a patch to BZ that should disable entirely for AIX > > (and other targets where there's not a supported implementation strategy). > > > > This patch isn't the best way of addressing this for a variety of reasons, > > but this support is intended as experimental for GCC11 anyway. > > Unfortunately I can't test it on AIX because it would seem that my ssh keys > > never landed on the AIX cfarm machines. > > > > > > I am testing the patch on an AIX system inside IBM. > > > > But it seems that you are disabling semaphore entirely on AIX, which > > is an unnecessary regression. AIX has POSIX semaphores. libstdc++ > > configure defines > > > > _GLIBCXX_HAVE_POSIX_SEMAPHORE > > > > I don't understand your comments about disabling semaphore on AIX > > while the comment about experimental for GCC11 implies that this is > > some new, experimental feature. I could understand disabling the > > experimental feature, but not disabling all semaphore support. > > > > Thanks, David > > > > > > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, > > but it shows up in your error report. > > You now have pinpointed the problem. > > It's not that AIX doesn't have semaphore, but that the code previously > had a fallback that hid a bug in the macros: > > #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE > // Use futex if available and didn't force use of POSIX > using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; > #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE > using __fast_semaphore = __platform_semaphore; > #else > using __fast_semaphore = __atomic_semaphore; > #endif > > The problem is that libstdc++ configure defines > _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to > rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h > contains > > #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 > > And bits/semaphore_base.h is not testing that corrupted macro. Either > semaphore_base.h needs to test for the corrupted macro, or libtsdc++ > configure needs to define HAVE_POSIX_SEMAPHORE without itself > prepending _GLIBCXX_ so that the c++config.h rewriting works > correctly and defines the correct macro for semaphore_base.h. > > Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David
Re: help debug hash_map garbage collection issue
On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc wrote: > > On 4/20/21 5:03 PM, Martin Sebor wrote: > > On 4/20/21 4:15 PM, Martin Sebor wrote: > >> On 4/20/21 2:36 PM, Martin Sebor wrote: > >>> On 4/20/21 2:13 PM, Marek Polacek wrote: > On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote: > > I have a static hash_map object that needs to persist across passes: > > > >static GTY(()) hash_map *map; > > > > I initialize the map like so: > > > >map = hash_map::create_ggc (4); > > > > But I see crashes when accessing the map after adding and removing > > some number of entries in a few passes. The crashes are due to > > the map having been garbage-collected and the memory allocated to > > it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see > > in GDD being written into the map by poison_pages()). > > > > I assumed marking the map pointer GTY(()) would keep the garbage > > collector from touching the map. Is there something else I need > > to do to keep it from doing that? > > > > Thanks > > Martin > > > > PS Just in case it matters, the bitmap in the table is allocated > > via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside > > the map. > > My sense is that this is the problem. What happens if you use > BITMAP_GGC_ALLOC? > >>> > >>> Same thing :( > >> > >> I reduced the problem to the following patch/test case no involving > >> a bitmap or other pointers. With it applied, GCC reliably crashes. > >> An example of a stack trace is below the patch. What am I missing? > > > > It seems that assigning the address of an object allocated by > > ggc_alloc() (which presumably includes BITMAP_GGC_ALLOC()) to > > a GTY-marked pointer "defeats" the purpose of the marker and > > allows it to be garbage collected. > > But this is not true. There are plenty of counterexamples, including > in tree.c which defines several GTY hash_tables (but no maps). I tried > moving the test case below from gimple.c to tree.c but there it doesn't > even compile. I get this error (and a couple of others): > > In file included from /src/gcc/master/gcc/tree.c:16179: > ./gt-tree.h: In function ‘void gt_ggc_mx(int_hash&)’: > ./gt-tree.h:156:21: error: no matching function for call to > ‘gt_ggc_mx(int_hash*)’ > gt_ggc_mx (&((*x))); > ^ > So as another experiment I moved it builtins.c where it does compile > (go figure) but then it crashes when I call it the same way from > c_strlen(). This is because tree.c is in GTFILES, while gimple.c and tree.c are not, so gengtype never sees the GTY decoration in the latter files. I don't know why when it does see the GTY, it ends up trying to mark an int_hash*. Jason
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 18:08, David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David Ok, I'll see if I can get a patch out before calling it a night. Thanks! Tom.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 18:08, David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David I think the attached patch (also in BZ) addresses the issue in bits/semaphore_base.h, but I'm going to defer to Jonathan on why the macro name is being transformed incorrectly in the first place.From b1892fe84fb702ff3085eee8a062bc8606e5566a Mon Sep 17 00:00:00 2001 From: Thomas Rodgers Date: Tue, 20 Apr 2021 21:56:21 -0700 Subject: [PATCH] [libstdc++] Work around for PR100164 As dje@gmail.com pointed out, the _GLIBCXX_HAVE_POSIX_SEMAPHORE macro is being munged into _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE. This caused the detection logic in bits/semaphore_base.h to not define __platform_semaphore. Fixing this uncovered the issue that __platform_semaphore::_M_try_wait() was missing. This patch works around the former issue and addresses the latter issue. libstdc++-v3/ChangeLog: * include/bits/semaphore_base.h: Define __platform_semaphore::_M_try_wait(), temporarily adjust detection macro to reflect the actual name being generated during configuration. * testsuite/30_threads/semaphore/try_acquire_posix.cc: Force use of Posix semaphores if available and always run the test. --- libstdc++-v3/include/bits/semaphore_base.h| 27 --- .../30_threads/semaphore/try_acquire_posix.cc | 15 --- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h index 7e3235d182e..5c687bfae6f 100644 --- a/libstdc++-v3/in
