[c++] Question about "write_unscoped_name (const tree decl)"
Hi, In gcc/cp/mangle.c (write_unscoped_name) we have: /* If not, it should be either in the global namespace, or directly in a local function scope. */ gcc_assert (context == global_namespace || context != NULL || TREE_CODE (context) == FUNCTION_DECL); Which doesn't look like a thought-out assert: e.g. TREE_CODE (context) will segfault when context==NULL. According to the comment before the assert supposed to look more like: gcc_assert (context == global_namespace || (context != NULL && TREE_CODE (context) == FUNCTION_DECL)); But it gives us an ICE with g++.dg/cpp0x/lambda/lambda-defarg3.C BTW: First the check was "|| context == NULL", then it was removed by r149964 and then came back as "|| context != NULL" by r153768. May be I am missing something here? Could somebody clarify that peace of code please. --Alexander
Re: [c++] Question about "write_unscoped_name (const tree decl)"
Alexander Ivchenko writes: > BTW: First the check was "|| context == NULL", then it was removed by > r149964 and then came back as "|| context != NULL" by r153768. Looks like r153734 got it wrong first. It was supposed to revert r149964, but failed. Then r153742 reverted the revertion, and when r153768 reintroduced it it was apparently modeled after r153734 instead of the state before r149964. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [c++] Question about "write_unscoped_name (const tree decl)"
2013/7/29 Andreas Schwab : > Alexander Ivchenko writes: > >> BTW: First the check was "|| context == NULL", then it was removed by >> r149964 and then came back as "|| context != NULL" by r153768. > > Looks like r153734 got it wrong first. It was supposed to revert > r149964, but failed. Then r153742 reverted the revertion, and when > r153768 reintroduced it it was apparently modeled after r153734 instead > of the state before r149964. Sounds like a riddle :) Anyway, if we assume that r153734 got it wrong and hence it is now wrong in the mainline, we can pull up the r149964 state with: /* If not, it should be either in the global namespace, or directly in a local function scope. */ gcc_assert (context == global_namespace - || context != NULL + || context == NULL || TREE_CODE (context) == FUNCTION_DECL); but then we will get ICE with g++.dg/cpp0x/lambda/lambda-defarg3.C, which would be a problem itself. --Alexander
Re: fatal error: gnu/stubs-32.h: No such file
> As a consensual first step toward addressing this issue, I suggest the
> following patch to the doc. I hope it is clear enough, but suggestions are
> obviously welcome. (I haven't even compiled the docs with it, as I'm on my
> laptop with little battery.)
Given that I received no feedback, I'd like to submit this doc patch formally.
Tested by doing "make info html pdf".
OK to commit to trunk? What about other active release branches?
FX
Index: install.texi
===
--- install.texi(revision 201292)
+++ install.texi(working copy)
@@ -255,6 +255,26 @@ may need to use @option{--disable-stage1
bootstrapping the compiler with such earlier compilers is strongly
discouraged.
+@item C standard library and headers
+
+In order to build GCC, the C standard library and headers must be present
+for all target variants for which target libraries will be built (and not
+only the variant of the host C++ compiler).
+
+This affects the popular @samp{x86_64-unknown-linux-gnu} platform (among
+other multilib targets), for which 64-bit (@samp{x86_64}) and 32-bit
+(@samp{i386}) libc headers are usually packaged separately. If you do a
+build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
+either:
+
+@itemize @bullet
+@item having 32-bit libc developer package properly installed (the exact
+name of the package depends on your distro); otherwise, you may encounter an
+error such as @samp{fatal error: gnu/stubs-32.h: No such file}
+@item building GCC as a 64-bit only compiler, by configuring with the
+option @option{--disable-multilib}
+@end itemize
+
@item GNAT
In order to build the Ada compiler (GNAT) you must already have GNAT
Summary of the Accelerator BOF at Cauldron
The Accelerator BOF at the GNU Tools Cauldron was worthwhile. Several people presented their current work or announced upcoming projects in the accelerator space. There was significant interest from the Cauldron attendees; we had about 40 People in the room on the first day, and about 20 in the follow-up session that we had to schedule on the next day due to interest in further discussion. How to support accelerators is a very broad topic, so we often hadn't time to discuss everything in detail nor all the subtopics we would have liked to talk about -- but we covered the main issues, and got the discussion started. Thomas Schwinge (Mentor Graphics) talked about their plans to support OpenACC in GCC; OpenACC constructs and the enclosed code are transformed into NVIDIA's PTX virtual ISA and calls into CUDA libraries. Martin Jambor (SuSE) is working on expanding GIMPLE into HSAIL, the HSA virtual ISA. They are currently focusing on code suitable for kernels (i.e., the parallel tasks that one could send off to an accelerator) and haven't started looking at transforming programming-language-level parallelism constructs (e.g., parallel loops) into code that makes use of the HSA queues or runtime. Kirill Yukhin (Intel) gave an overview of how offloading works in the current generation of MIC accelerators. Jakub Jelinek (Red Hat) has been working on OpenMP 4.0, including the parsing of OpenMP 4.0's accelerator-related constructs. However, any such accelerator code isn't offloaded to an actual accelerator yet but still executed on the host. The topics we discussed fell roughly into three categories: Programming abstractions and front-end, middle-end, and back-end. In the first category, OpenMP and OpenACC are the most obvious candidates that we could support; they have a lot of similarities, but also differ in a few aspects such as how they treat potential aliasing between data on the host and on the accelerator: OpenACC specifies that copying happens, whereas OpenMP specifies a mapping between the data (which does not require copying, but would allow data to remain at the same place). We want interoperability in this regard, and at least for the OpenACC/OpenMP integration, libgomp is probably the centerpiece. It was also noted that the ISO C++ committee doesn't seem to want to be too favorable to including OpenMP-like constructs in the standard; however, neither the ISO C++ nor the C study group on parallelism currently work on support for accelerators. Furthermore, while auto-parallelization (or auto-vectorization) are very useful features, they also have their limits, and there's no reason to not support standards such as OpenMP or OpenACC. Regarding the middle-end, the most interesting topic is how to represent accelerator constructs in the intermediate representation. We didn't discuss in detail how to do this, but there was strong support for striving for one way of representing accelerator code that's common across the several programming abstractions / frontends we might support. It was noted that finding the right semantics to target internally would be key for this. The various GCC accelerator efforts are all in a rather early "experimentation stage"; thus, to find the right general abstraction for how to describe any kind of parallel regions, it could make sense to first try implementating, for example, the OpenACC support by making use of existing OpenMP contructs (and extending them as necessary). The main issue we discussed in the backend category was how to target more than one ISA when generating code (i.e., we need code in the host's ISA and in the accelerator(s)' (virtual) ISA(s)). Multi-target support in GCC might be one option, but would probably need quite some time and thus depending on it would probably delay the accelerator efforts. It might be simpler to stream code several times to different backends using the LTO infrastructure. However, there is a (likely) risk of having target dependencies in the code before LTO; we concluded that for this approach to work, the target ABIs would thus need to be sufficiently compatible (e.g., regarding data type sizes). A third option that SuSE is experimenting with is not writing a new backend but instead generating code right after the last GIMPLE pass; however, HSAIL needs register allocation, so it was noted that writing a light-weight backend might be easier. We also discussed a few other topics, such as where to store accelerator code in binaries (e.g., Thomas is thinking about store PTX textual representation in separate ELF segments), or how to deal with dispatching of functions that might have both an accelerator and a host variant (e.g., math functions). We didn't have time to discuss other topics such as how to debug or link applications with accelerator code. Thanks to Thomas Schwinge for providing additional notes for this summary. Torvald
Re: fatal error: gnu/stubs-32.h: No such file
On 07/29/2013 02:06 PM, FX wrote:
> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
> +either:
> +
> +@itemize @bullet
> +@item having 32-bit libc developer package properly installed (the exact
> +name of the package depends on your distro); otherwise, you may encounter an
> +error such as @samp{fatal error: gnu/stubs-32.h: No such file}
> +@item building GCC as a 64-bit only compiler, by configuring with the
> +option @option{--disable-multilib}
> +@end itemize
Looks good.
This should be
"Make sure you either have the 32-bit libc developer package properly
installed (the exact name of the package depends on your distro) or
you must build GCC as a 64-bit-only compiler by configuring with the
--disable-multilib option. Otherwise, you may encounter an
error such as @samp{fatal error: gnu/stubs-32.h: No such file}
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote: > There should be a better diagnostic. If you remember, the start of this thread was: > Why is it that configure worked but stubs-32.h was not found? That is the correct thing to do. The reply, basically, was: It's too hard. OK, fine, the backup is to Google: fatal error: gnu/stubs-32.h: No such file or directory and have an early hit that tells you that you did not configure some 32 bit developer package you had never heard of before. I guess that's easier than configure tests or #error directives for the folks who do the multi-lib stuff. > > But we know people are running into this issue and reporting it. > Yes. But that on its own is not sufficient to change the default That's a pretty obnoxious comment. I translate it as, "I don't care if people are having trouble. It is a nuisance to me to do that and anyone building GCC should already know they need -devel for 32 bits." I guess I can be obnoxious, too. But slightly more politely put: > No, we aren't. We're disagreeing about whether it's acceptable to > enable a feature by default that breaks the compiler build half way > through with an obscure error message. Real systems need features that > aren't enabled by default sometimes. The fundamental issue, to me, is: What do you do when you cannot proceed? I think you should detect the issue as *soon as practical* and then *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. This failure is later than it could be and leaves the user hanging and twisting in the wind. Not good.
Re: New file extension
On Sat, Jul 27, 2013 at 9:42 AM, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) Agreed. Diego.
Re: fatal error: gnu/stubs-32.h: No such file
On 07/29/2013 02:55 PM, Bruce Korb wrote: > On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote: > >> There should be a better diagnostic. > > If you remember, the start of this thread was: > >> Why is it that configure worked but stubs-32.h was not found? > > That is the correct thing to do. The reply, basically, was: > > It's too hard. It was "This is possible, but it's tricky, and it's really important to get it right. We don't want a half-arsed patch." >>> But we know people are running into this issue and reporting it. >> Yes. But that on its own is not sufficient to change the default > > That's a pretty obnoxious comment. Oh dear. > I translate it as, "I don't care if people are having trouble. That's a mistranslation. It means that there are other criteria beyond some people having trouble. Such as, we really want multilibs to be built. > It is a nuisance to me to do that and anyone building GCC should > already know they need -devel for 32 bits." I guess > I can be obnoxious, too. But slightly more politely put: > >> No, we aren't. We're disagreeing about whether it's acceptable to >> enable a feature by default that breaks the compiler build half way >> through with an obscure error message. Real systems need features that >> aren't enabled by default sometimes. > > The fundamental issue, to me, is: What do you do when you cannot > proceed? > > I think you should detect the issue as *soon as practical* and then > *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. Yes! Yes! Yes! Andrew.
Re: [c++] Question about "write_unscoped_name (const tree decl)"
On 07/29/2013 07:14 AM, Alexander Ivchenko wrote: 2013/7/29 Andreas Schwab : Looks like r153734 got it wrong first. It was supposed to revert r149964, but failed. Then r153742 reverted the revertion, and when r153768 reintroduced it it was apparently modeled after r153734 instead of the state before r149964. And the NULL-handling changes in r149964 shouldn't have been reverted anyway. Anyway, if we assume that r153734 got it wrong and hence it is now wrong in the mainline, we can pull up the r149964 state with: /* If not, it should be either in the global namespace, or directly in a local function scope. */ gcc_assert (context == global_namespace - || context != NULL + || context == NULL || TREE_CODE (context) == FUNCTION_DECL); but then we will get ICE with g++.dg/cpp0x/lambda/lambda-defarg3.C, which would be a problem itself. Yep, I'll deal. Jason
Altera Nios II port accepted
I am pleased to announce that the GCC Steering Committee has accepted the Altera Nios II port for inclusion in GCC and appointed Chung-Lin Tang and Sandra Loosemore as port maintainers. The initial patch needs approval from a GCC GWP maintainer before it may be committed. Please join me in congratulating Chung-Lin and Sandra on their new roles. Please update your listing in the MAINTAINERS file. Happy hacking! David
Re: New file extension
On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) Oh, I suppose this applies to ubsan, e.g. (Haven't commited it to trunk yet, but so far the files still have the '.c' extension.) Will rename it then, though I like '.c' more ;). Marek
Re: New file extension
On Mon, Jul 29, 2013 at 11:11 AM, Marek Polacek wrote: > On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: >> Hi, >> >> I would like to suggest that new implementation files have >> the '.cc' extension, unless they are meant to be processed >> with a C compiler. (I am not proposing wholesale renaming.) > > Oh, I suppose this applies to ubsan, yes. :-) -- Gaby
Re: New file extension
On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) > I do not care very much but I disagree. Having some files with .c suffix and some with .cc suffix would imply some sort of difference where there is going to be none. Much more confusing than C++ compiled .c files, especially to newcomers, I suppose... and I though we cared about them, that's the reason why I'm writing this email. I will not be surprised by this myself, so I can live with it. Martin
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: > On 07/29/2013 02:55 PM, Bruce Korb wrote: >> On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote: >> >>> There should be a better diagnostic. >> >> If you remember, the start of this thread was: >> >>> Why is it that configure worked but stubs-32.h was not found? >> >> That is the correct thing to do. The reply, basically, was: >> >> It's too hard. > > It was "This is possible, but it's tricky, and it's really important > to get it right. We don't want a half-arsed patch." > But we know people are running into this issue and reporting it. >>> Yes. But that on its own is not sufficient to change the default >> >> That's a pretty obnoxious comment. > > Oh dear. > >> I translate it as, "I don't care if people are having trouble. > > That's a mistranslation. It means that there are other criteria > beyond some people having trouble. Such as, we really want multilibs > to be built. > >> It is a nuisance to me to do that and anyone building GCC should >> already know they need -devel for 32 bits." I guess >> I can be obnoxious, too. But slightly more politely put: >> >>> No, we aren't. We're disagreeing about whether it's acceptable to >>> enable a feature by default that breaks the compiler build half way >>> through with an obscure error message. Real systems need features that >>> aren't enabled by default sometimes. >> >> The fundamental issue, to me, is: What do you do when you cannot >> proceed? >> >> I think you should detect the issue as *soon as practical* and then >> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. > > Yes! Yes! Yes! > > Andrew. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
Sorry about the blank message; I accidentally hit the wrong button. On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: > It was "This is possible, but it's tricky, and it's really important > to get it right. We don't want a half-arsed patch." We've all seen cases where a quick patch is rejected in favor of a hypothetical patch, and years down the road, the program still has the problem. The people who blocked the quick patch, naturally, never bothered trying to write the patch they wanted. > That's a mistranslation. It means that there are other criteria > beyond some people having trouble. Such as, we really want multilibs > to be built. Who is we here? And why do you really want multilibs built? >> I think you should detect the issue as *soon as practical* and then >> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. > > Yes! Yes! Yes! Then what are we going to do about it? As per my first comment, nobody has offered to produce a patch in the form you would be happy with, so I'm not going to hold my breath that it's going to appear. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 9:50 PM, David Starner wrote: > Sorry about the blank message; I accidentally hit the wrong button. > > On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: >> It was "This is possible, but it's tricky, and it's really important >> to get it right. We don't want a half-arsed patch." > > We've all seen cases where a quick patch is rejected in favor of a > hypothetical patch, and years down the road, the program still has the > problem. The people who blocked the quick patch, naturally, never > bothered trying to write the patch they wanted. The problem here is a quick patch makes the situation worse rather than better. That is the reason why the quick patch is rejected. > >> That's a mistranslation. It means that there are other criteria >> beyond some people having trouble. Such as, we really want multilibs >> to be built. > > Who is we here? And why do you really want multilibs built? The simple answer is testing, you should be build the multi-libs which are there for your target that means 32bit for x86_64. If you don't want them, explicitly disable them. The defaults are there for the majority of users and majority of users of compiling a compiler knows the risks of not having the current libraries installed. >>> I think you should detect the issue as *soon as practical* and then >>> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. >> >> Yes! Yes! Yes! > > Then what are we going to do about it? As per my first comment, nobody > has offered to produce a patch in the form you would be happy with, so > I'm not going to hold my breath that it's going to appear. That is because it is a hard to do and will force extra time in compiling and might cause incorrect handling of cross builds. Remember the host compiler does not have to compile for the multi-lib; only the newly compiled compiler will be able to. Thanks, Andrew Pinski > > -- > Kie ekzistas vivo, ekzistas espero.
